tstor

No, the data you write is encoded for two reasons: guarantee a minimum of transitions for clock recovery (see RLL codes, https://en.wikipedia.org/wiki/Run-length_limited) and modern error recovery algorithms (https://en.wikipedia.org/wiki/Low-density_parity-check_code, https://web.archive.org/web/20161213104211/http://www.marvell.com/storage/assets/Marvell_88i9422_Soleil_pb_FINAL.pdf) In other words, there will always be a lot of flux reversals / polarity changes regardless of what exactly you write. Yes, but assume you have an address line defect in a higher address line (or a fake SSD with only 128 GB instead of the expected 2 TB). You would write a block, e.g. 1 GB and successfully read back from there. All your tests would be successful. During your tests you would never notice, that when you assume to write into the second 128 GB you actually overwrite the first. Only when you write the whole disk first and then start reading back would you detect this kind of defect / cheating. Since you are unlikely to have enough RAM to keep a copy of written random data for the whole disk, you need a pseudo-random sequence as a source for the written data. When you read back you can then just use the same generator and seed and generate the sequence again for comparison with the read data.

Your assumptions on magnetic media are wrong. The information on a disk is not coded into magnetised / demagnetised spots, it is coded into transitions of magnetisation with opposite polarities. The read heads detect magnetic flux changes, not the magnetisation itself. Also what is written are not the bits that the disk driver hands over to the drive. The data coming from the driver gets re-encoded in a way that optimises several parameters, e.g. number of transitions for clock recovery, influence on neighbouring spots, error correction. How it is done on a given drive is the secret sauce of its manufacturer, but whatever bit patterns you send to the drive, what ends up on the disk is something different and the spots on the disk platter will always get magnetised with one polarity or the other. For disk surface testing it does therefore not matter much, whether you write zeroes or random data. For stressing the mechanical elements and forcing early failures of marginal drives it doesn't matter either. For pre-clearing a disk you obviously need to write zeroes. There are some scenarios, e.g. a controller circuit on the drive having issues or a fake SSD with less capacity than advertised, where using a pseudo-random sequence would be far superior to using zeroes. But in that case you would need reproducible pseudo-random sequences so that you only need to store the seed between write / read and not the sequence itself. Your proposal to create a block of random data and repeatedly write / read that block would not detect issues with addressing. I do however think that those scenarios are beyond the intention of this plugin. There are already tools for that kind of tests. Pre-clearing was very important when Unraid was not able to clear a disk while keeping the array available. This has changed, but the plugin can still be used to stress-test a drive before adding it to the array.

Excellent, I'l use it with the next swap. And with the current one I have learned a few new things about encrypted drives.

blkid did not show any duplicate UUIDs. I changed the duplicate UUID of the encrypted partition with "cryptsetup luksUUID...", but I didn't think about the XFS file system becoming visible once the encrypted partition is unlocked. So here is write-up of what I did ultimately to get access in case someone else gets into the same situation Goal: Access an encrypted drive taken out of the array in UD on the same system. Issue: If this was due to a swap and the drive taken out has been reconstructed, there will be UUID conflicts that prevent mounting. This is because the reconstructed drive is a true clone including UUIDs. So one needs to change the UUIDs of the drive no longer being in the array. In my case the UD drive is /dev/sdv First generate two new UUIDs root@Tower:/mnt# uuidgen 2284b0b6-eead-4d1c-adf0-58efb36085e2 root@Tower:/mnt# uuidgen 980b09f3-ced6-4fc4-8875-f94086100f39 Use the first one with luksUUID command to change the first conflicting UUID root@Tower:~# cryptsetup luksUUID --uuid=2284b0b6-eead-4d1c-adf0-58efb36085e2 /dev/sdv1 WARNING! ======== Do you really want to change UUID of device? Are you sure? (Type 'yes' in capital letters): YES Now the encrypted partition needs to be unlocked in order to get access at the XFS file system UUID that also needs to be changed using the second UUID generated above. root@Tower:/mnt# /usr/sbin/cryptsetup --verbose luksOpen /dev/sdt1 UAdisklabel Enter passphrase for /dev/sdt1: Key slot 0 unlocked. Command successful. root@Tower:/mnt# ls /dev/mapper/ control md10@ md11@ md12@ md13@ md14@ md2@ md3@ md4@ md5@ md6@ md7@ md8@ md9@ UAdisklabel@ root@Tower:/mnt# xfs_admin -U 980b09f3-ced6-4fc4-8875-f94086100f39 /dev/mapper/UAdisklabel Clearing log and setting UUID writing all SBs new UUID = 980b09f3-ced6-4fc4-8875-f94086100f39 In order to allow mounting via UD, I used the same label ("UAdisklabel") as UD uses for that drive. Helpful additional commands: blkid cryptsetup luksUUID /dev/sdv1 xfs_admin -lu /dev/mapper/UAdisklabel blkid lists the UUIDs visible for the system. Initially it does not show the XFS file system UUID because that one is not yet accessible. luksUUID displays the UUID of the encrypted partition xfs_admin shows the UUID of the unmounted XFS partition after unlocking Now I can mount the previous array drive in UD and access / change its content. I hope it helps and if someone with deeper knowledge would do a sanity check of what I wrote, it would not hurt.

I did, the diagnostics in my previous post to which you replied were the ones after changing the UUID manually and rebooting. https://forums.unraid.net/topic/92462-unassigned-devices-managing-disk-drives-and-remote-shares-outside-of-the-unraid-array/?do=findComment&comment=935227 But here is a fresh set: tower-diagnostics-20210116-1333.zip

Thanks Thanks again, I really appreciate the efforts you put into the UD plugins. Now even though I have first changed the UUID via CLI and then rebooted the server, UD does not mount the encrypted disk. Any idea?

Here they are. Please note that in the mean time I have changed the conflicting UUID manually (/dev/sdt). However UD still does not show any disk under "Change Disk UUID". By the way and completely unrelated, when searching this thread for information regarding LUKS and UD I got a bit confused regarding LUKS and SSDs. In your first post it is stated first that "SSD disks formatted with xfs, btrfs, or ext4 will be mounted with 'discard'. This includes encrypted disks." Then further down in the same post it is said that "Discard is disabled on an encrypted SSD because of potential security concerns. Fstrim will fail." Finally a post much later contains this: "Add '--allow-discards' to luks open when an encrypted disk is a SSD so discard and trim will work on the disk." What is the current status regarding SSD / discard / encryption? tower-diagnostics-20210115-0306.zip

Makes sense and is correct. Partition 1 however has a different GUID on the rebuilt drive. Is this Unraid's work when resizing the partition after the rebuild? For some reason it didn't. The list of available drives for changing the GUID in UD is empty. Any idea?

I have a question regarding UD / encrypted disks. I replaced one of the encrypted array data drives with larger one. After rebuild had successfully finished, I plugged the previous data drive into an empty slot and wanted to mount it. However it does not mount. It obviously has the same password as the array and the array is mounted. UD displays "luks" as file system for both the drive as well as partition 1. Mount button for the drive is clickable, for partition 1 it is greyed out. If I click on mount, UD spends some seconds doing something, the disk log adds one line of "/usr/sbin/cryptsetup luksOpen /dev/sdv1 TOSHIBA_HDWN180_xxxxxxxxxxxxx", but the partition does not mount. Is there a misunderstanding on my side or is something wrong that I need to troubleshoot? Unraid 6.8.3, UD 2021.01.09

Just for curiosity: why would writing zeroes to multiple disks at once consume lots of RAM? Except for a progress counter per disk I don‘t see anything that would need to be stored. Do you have an idea? I did however also unsuccessfully try to clear three 12TB drives at the same time and it is true that unRAID locked up due to lack of memory although I have 32 GB and there was nothing else running, no dockers, no VMs. Alas I did not have a lot of time for analysis and the diagnostics script was unable to collect its data to due lack of memory. So I did a reboot which obviously wiped out all traces of what had filled memory.

I did a preclear of a 12TB disk. At the next boot I got the following error in syslog: Dec 17 13:56:26 Tower kernel: sd 6:0:13:0: [sdq] 2929721344 4096-byte logical blocks: (12.0 TB/10.9 TiB) Dec 17 13:56:26 Tower kernel: sd 6:0:13:0: [sdq] Write Protect is off Dec 17 13:56:26 Tower kernel: sd 6:0:13:0: [sdq] Mode Sense: 7f 00 10 08 Dec 17 13:56:26 Tower kernel: sd 6:0:13:0: [sdq] Write cache: enabled, read cache: enabled, supports DPO and FUA Dec 17 13:56:26 Tower kernel: sdq: sdq1 Dec 17 13:56:26 Tower kernel: sdq: p1 size 34359738360 extends beyond EOD, enabling native capacity Dec 17 13:56:26 Tower kernel: sdq: sdq1 Dec 17 13:56:26 Tower kernel: sdq: p1 size 34359738360 extends beyond EOD, truncated Dec 17 13:56:26 Tower kernel: sd 6:0:13:0: [sdq] Attached SCSI disk Is this a bug in the plugin that it creates a partition that is too big or does the plugin not create a valid partition at all and the boot process interprets the preclear header written onto the disk as a partition? parted sees the cleared disk with an invalid MSDOS partition, while array disks have GPT partitions. Another new disk of the same type that has not yet been cleared, does not show the "extends beyond EOD" message and has no partition info at all.

Me too, df has a strange way to round.

It does, except for the rounding where UD shows 91.1 GB while CLI df -H shows 92 GB. UD's 91.1 is the correct value if we can believe the free block count.

df is a bit of mystery for me. Even taking into account the reserved blocks the figures don't add up and also the rounding is strange: 500048128 blocks of 4096 Bytes each would result in 2048197132288 Bytes. With SI Terabytes this would be 2.048 TB or, rounded 2.0 TB, not 2.1 TB Anyway, I think the idea to display the free value from df instead of the calculated one is good, although you will then get questions as to why they don't add up :-)

:-) Now I am really confused. Why do I get different values on the console than UD? The disk is mounted read-only, so there is no way that the value could have changed between the read-out in CLI vs. GUI and anyway the values are still the same now. I also tested whether device vs. mount point would make a difference, but they don't: root@Tower:/# df /dev/sdl2 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdl2 1968675628 1779677440 88972180 96% /tmp/ssd root@Tower:/# df /tmp/ssd Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdl2 1968675628 1779677440 88972180 96% /tmp/ssd root@Tower:/# df -H /dev/sdl2 Filesystem Size Used Avail Use% Mounted on /dev/sdl2 2.1T 1.9T 92G 96% /tmp/ssd root@Tower:/# df -H /tmp/ssd Filesystem Size Used Avail Use% Mounted on /dev/sdl2 2.1T 1.9T 92G 96% /tmp/ssd By adding the reserved blocks I get closer to UD's numbers, but still not the same: root@Tower:/# tune2fs -l /dev/sdl2 | more tune2fs 1.43.6 (29-Aug-2017) Filesystem volume name: <none> Last mounted on: /media/ssd_out Filesystem UUID: 39d177ab-434d-4c62-b51a-dd892fef93f8 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file un init_bg dir_nlink extra_isize Filesystem flags: unsigned_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 125018112 Block count: 500048128 Reserved block count: 25002406 Free blocks: 47249547 Free inodes: 125004626 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 904 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Wed Aug 10 02:35:21 2016 Last mount time: Fri Oct 27 18:55:12 2017 Last write time: Sat Oct 28 18:29:47 2017 Mount count: 78 Maximum mount count: -1 Last checked: Wed Aug 10 02:35:21 2016 Check interval: 0 (<none>) Lifetime writes: 19 TB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 9d471dae-1834-4b79-ad17-cbe71464c01f Journal backup: inode blocks Any ideas? Is "free" in UD the df value for free or is it size minus used?