JorgeB

Preclear not working on 6.2 beta, any idea what this error is about? This is from the script, but the plugin returns same error: root@Testv6:/boot# preclear_disk.sh -n /dev/sdb sfdisk: invalid option -- 'R' Usage: sfdisk [options] <dev> [[-N] <part>] sfdisk [options] <command> Display or manipulate a disk partition table. Commands: -A, --activate <dev> [<part> ...] list or set bootable MBR partitions -d, --dump <dev> dump partition table (usable for later input) -J, --json <dev> dump partition table in JSON format -g, --show-geometry [<dev> ...] list geometry of all or specified devices -l, --list [<dev> ...] list partitions of each device -F, --list-free [<dev> ...] list unpartitions free areas of each device -s, --show-size [<dev> ...] list sizes of all or specified devices -T, --list-types print the recognized types (see -X) -V, --verify [<dev> ...] test whether partitions seem correct --part-label <dev> <part> [<str>] print or change partition label --part-type <dev> <part> [<type>] print or change partition type --part-uuid <dev> <part> [<uuid>] print or change partition uuid --part-attrs <dev> <part> [<str>] print or change partition attributes <dev> device (usually disk) path <part> partition number <type> partition type, GUID for GPT, hex for MBR Options: -a, --append append partitions to existing partition table -b, --backup backup partition table sectors (see -O) --bytes print SIZE in bytes rather than in human readable format -f, --force disable all consistency checking --color[=<when>] colorize output (auto, always or never) colors are enabled by default -N, --partno <num> specify partition number -n, --no-act do everything except write to device --no-reread do not check whether the device is in use -O, --backup-file <path> override default backup file name -o, --output <list> output columns -q, --quiet suppress extra info messages -X, --label <name> specify label type (dos, gpt, ...) -Y, --label-nested <name> specify nested label type (dos, bsd) -L, --Linux deprecated, only for backward compatibility -u, --unit S deprecated, only sector unit is supported -h, --help display this help and exit -v, --version output version information and exit Available columns (for -o): gpt: Device Start End Sectors Size Type Type-UUID Attrs Name UUID dos: Device Start End Sectors Cylinders Size Type Id Attrs Boot End-C/H/S Start-C/H/S bsd: Slice Start End Sectors Cylinders Size Type Bsize Cpg Fsize sgi: Device Start End Sectors Cylinders Size Type Id Attrs sun: Device Start End Sectors Cylinders Size Type Id Flags For more details see sfdisk(. Sorry: Device /dev/sdb is busy.: 1

https://lime-technology.com/forum/index.php?topic=44989.msg430393#msg430393

I can answer this one, only MD5 checksums made by this plugin than can be verified by CORZ.

maybe this:

That only thing I ever experienced running more than 4 preclears is the WebGUI becoming sluggish, but never had any other issues.

+3 Also it should check for disk.cfg and warn to create one for new servers without any array assignments, fastest way is click new config.

Parity checks speed is affected by many factors, including size of parity disk, controllers used (older ones have limited bandwidth when accessing all disks), disks used (higher platter density disks are faster), different sized disks (the more you have, the slower it will be), and to a lesser degree CPU and memory used.

I’m trying to isolate the issue better but on some of my servers new files begin to hash while I’m still copying more files, making the write speed much slower, is there a way to make the plugin wait until copy is over before starting to hash new files? Strangely, like I mentioned, on other servers the hashing begins only when all files are copied.

I didn't know that. I'm surprised that more users haven't caught on to this, because it saves a lot of time not having to New Config and reassign everything, and you don't have to worry about getting the Parity drive right. Did some quick tests, and can confirm that it works from at least v5beta12a, you can change the order of all disks, except parity naturally, it could be even better if LT allowed to trade an empty slot, this could be useful for when users remove a disk, very nice find Rob.

Completely agree, I never checked mine when I did the conversion (except the redballed disk), have run some checks after and never found any corruption. I believe it should be checked if you suspect a disk, e.g., destination disk x reallocated some sectors during a copy, or if you get a redball, in my case I was using the --remove-source-files switch, so when I woke up I had a redballed disk but all data was deleted from source, so after rebuilding the disk I verified checksums (using corz at the time), and had one corrupted file.

Agree, should also allow it, maybe LT didn’t anticipate that situation, should be easy to add.

Are you sure this is true? From my online searches and experience I’m don’t think so, I posted somewhere on this thread that one of my disks redballed during the rsync copy, this resulted in a corrupted file, there was no error on the rsync operation. You would also expect to see some read activity after copying a file if rsynch was verifying it and it does not happen. But I do believe you don’t need to run checksums after copying unless a disk error occurs. Edit: I believe this below better explains it and why it’s only important to run checksums in case of a disk write error. http://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives

I did the New Config the first time, but got to thinking, and tried the shortcut - and it was over and done so fast I couldn't believe it. But it checked out completely! And I've repeated it since. I first tried to figure out how to trick super.dat, to avoid having to reassign all the drives over and over after New Config, but it was going to be more work than it was worth, so I gave up on that idea, then hit on the simple idea above. But I didn't actually expect it to work! Especially so quickly! The changing the formats part I discovered the hard way, but it's easy enough to do. This works since at least v6.0.0, note that you can only change assigned disk slots, i.e., you can trade disks from slot 1 and 2, but if you have slot 4 empty and want to trade a disk from slot 5 it won’t let you, for that you still need a new config.

I don't find this. I recently set up a new install and run the script on 5 old drives on my test server. I did use the Preclear Plugin though. If you at any point in the past had a drive configured it will run, but on a new installation disk.cfg does not exist and the plugin won’t run without it, easiest way it to hit new config like Jbartlett pointed out.

This is normal while doing multiple preclears, on my server noticeble with 3 or more.

Tools > new config

Dual channel helps parity checks on server with many disks (12+), if I’m remembering correctly got an increase of about 10 to 15% on an Intel server and a little more on AMD.

UnRaid creates redundancy on a drive by drive basis. And to unRaid, a drive is always full of 1s and 0s. It has no idea what they mean. Different drives from different manufacturers do have different reliability characteristics. I've had excellent luck with HGST drives (previously Hitachi). Toshiba got some of that technology and the 5T drives they made have also been reliable for me. The newer models, X300, I have no experience with. I don't think they use the Hitachi technology. Of all the drives I have owned, Seagates have been the most unpredictable. Some models have been awful. Others good. I have not jumped into the 8T world, but experience here appears good. The idea that using a drive for it's intended purpose is somehow going to make it fail sooner is flawed. It they are going to fail under normal usage, you want that to happen so you can return them and get new ones. Although there are things you can duo to make drives fail early, like running them at very high temps, copying large amounts of data to them is not dangerous at all. Do it and let the chips fall where they may and then return for factory new replacement (if possible) or RMA (if past return date) the bad ones. Take the lessons learned to your next purchase decision. We tend to think of finding smart issues as a bad thing, but it is far better to get these errors during preclear and weed out the bad ones before your valuable data is at risk. Good luck! What he said. You were either unlucky with your previous disks or have some underlying issue, like bad cooling or inadequate power supply.

The initial parity sync will always write 100% of the disk, even if all data disks are empty. After that parity is updated, i.e., you write 20GB to a data disk, same amount will be written to parity.

I did that on mine, also upgraded one 3tb drive with an 8tb, this is the same “workout” as building parity.

Looks like a controller issue, all disks on the SASLP dropped offline, maybe try it on different slot if available.

Either way will work, use the most convenient for you.

I tried both and could not find any performance difference with Unraid, still ended up using the LSI firmware just in case.

Should be plug n play, didn’t need to disable bios on mine, it needs latest firmware for >2tb support.

Yep