Joe L.

from what I've read so far in the forums... the performance is roughly the same.

That sounds like a bug. Even if it does not currently start from where it left off, it should NOT mark the parity as "clean" until AFTER it completes a parity check. It sounds as if it is marking it "clean" at the start of a parity check. Joe L.

Did you select the specific flash drive as the BOOT device in the BIOS? That could easily explain why one boots (the one selected in the BIOS) and the other does not.

They both have their place. If, for example, you've made a copy of an mp3 file, and edited it in some way (added tags, or changed length, or whatever) and put the copy in a different directory, but with the exact same name, it will be found by your script, but not mine, since its checksum and size will be different. My script will find exactly identical files on different disks or in different directories regardless if they are named the same name or different names. users of your script should NOT just delete duplicates until they verify which of the files is the one they wish to keep. They should open each in turn to verify AND check their length. More than once I've copied a movie file from one disk to another only to run out of space and have the target file truncated and end up much shorter than the original. It would be horrible if I deleted the original file and kept a similarly named, but corrupted file that was in a different directory found by your script. Joe L.

A script I wrote a while back to find duplicate files is described in and attached to this post: http://lime-technology.com/forum/index.php?topic=7018.msg68073;topicseen#msg68073 It is a series of commands that create and use intermediate files on /mnt/disk1 You can run one line at a time and examine the intermediate files if you wish. It differs from the script in this post in that it does NOT rely on the file names to be identical. It will find duplicate files even if you've renamed them. It narrows down the files it needs to examine by eliminating files that cannot be duplicates by using this logic: 1. It first gets a list of all the files on your disks, and their lengths, and eliminates any file whose length is not the same as another file. (A unique length indicates it must be a unique file) 2. Then, it generates the md5 checksum for the first 4Meg of every file where their length is not unique. (A unique MD5 checksum in the first 4 Meg would indicate a unique file, no need to verify by reading the remainder) 3. Then, it generates the md5 checksum on the entire file where the md5 checksum on the first 4Meg is not unique. (If the md5 on the first 4 Meg was not unique we need to read the remainder) 4. Lastly, it lists the files, grouping them where they have identical md5 checksums, (and identical contents), even though they may be in different folders, or even have different names. The resulting list will look like this (each group is set of identical files, regardless of their names): /mnt/disk4/Mp3/KC and the Sunshine Band/KC_The_Sunshine_Band_-_Shake_Your_Booty.mp3 /mnt/disk4/Mp3/KC and the Sunshine Band/Shake Your Booty-Earth Wind and Fire.mp3 /mnt/disk3/data/mg35/mg-kernel/mg-kernel/include/linux/i2c-id.h /mnt/disk3/data/mg35/mg35tools/firmware/uClinux-2.4/include/linux/i2c-id.h /mnt/disk1/Pictures/2009 - July 4th/IMG_1374.JPG /mnt/disk1/Pictures/PictureFrame/DCIM/2009 - July 4th/IMG_1374.JPG /mnt/disk3/data/mg35/mg-kernel/mg-kernel/fs/nls/nls_cp865.c /mnt/disk3/data/mg35/mg35tools/firmware/uClinux-2.4/fs/nls/nls_cp865.c /mnt/disk1/Movies/SD_VIDEO/PRG002/MOV0AB.avi /mnt/disk1/Pictures/Movies/20080315_135748.MPG /mnt/disk1/Pictures/PRG002/MOV0AB.MOD /mnt/disk1/Movies/SD_VIDEO/PRG001/MOV024.avi /mnt/disk3/data/USADanceShowcase-Sept2006/MOV024.MOD /mnt/disk3/data/shared/JVC-VIDEO-CAMERA/SD_VIDEO/PRG001/MOV024.MOD Once you get the list it will be up to you to decide which files in each set can be deleted. (Make sure you leave at least one of them, otherwise for certain, you will not have another copy elsewhere.) Have fun. Joe L.

What issues are you seeing in those reports? They look just fine to me, in fact, the raw-read-error rate IMPROVED on both drives from starting values of 100 to 112 and 114. Joe L.

Actually, The only time the preclear is recognized is when you install an additional data drive to an array currently protected by a parity drive

SMART report looks fine. It's hard to say what the times should be for a 6tb drive, until other reports come in. Doesn't look wildly wrong though. You used Preclear 1.9, which is very old, probably too old for very large drives. I'm not sure you can trust the result on drives over 2TB using any Preclear less than 1.13, and perhaps Preclear 1.15 (the latest). You should definitely upgrade Preclear, and you may want to try it again. At least, try a Preclear -t test on it, with the latest Preclear. unRAID will NOT consider the disk pre-cleared. (the older version of the preclear script did not know how to properly create the preclear signature for disks over 2.2TB. ) A clue is that it says the partition starts on sector 64. That is completely WRONG for any disk over 2.2TB. Now, the disk did get zeroed, and does look good, but it does not contain a valid "protective" MBR starting on sector 1, nor a valid unRAID precleared signature. If you attempted to assign it to an array already protected by parity, unRAID will clear it again. (while the array is kept off-line) Joe l.

Are you seeing those same error messages in your syslog as the person who reported the issue with unMENU?? (are you running loop-back devices?? with docker images??)

I would appreciate if someone could explain an error message I have started receiving after opening UnMenu. I am running V6 beta 8 a cache drive with Docker on the cache drive Sep 6 16:40:18 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory Sep 6 17:17:53 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory Sep 6 17:45:13 Tower unmenu[1636]: cat: /sys/block/loo/stat: No such file or directory With only the basic beta 8 upgraded from Beta 7 install I started receiving the same error messages everytime UnMenu is started. Is there a correction needed or some other change or is it a bug in Beta 8 causing an error in Unmenu that wa not there in beta7 I am not running the beta versions of unRAID, so I cannot check personally, but I did look quickly at where the device names are being captured. It appears as if the device names are being captured from the output of the /root/mdcmd status command. Perhaps somebody with this issue can type /root/mdcmd status | strings | grep loo and post the output to see if the "loop" device names are being truncated in it, or if I need to look further in unMENU's code. Joe L.

This topic has been moved to User Customizations. [iurl]http://lime-technology.com/forum/index.php?topic=34934.0[/iurl]

I understood it was a sample from your server, but it did illustrate exactly the type of abort of a test if you were to allow unRAID to spin down the drive from inactivity. Basically, I was telling the person with the off-line-disk to remember to disable ANY disk-spin-down for the duration of the long-test.

I had to shutdown my laptop (which I used to start the test, via putty) before the 3 hours had passed. I assumed the test would continue, since I thought it was actually running on the server. I just ran smartctl --test=long /dev/sdb on my laptop (in a new putty session), and it seems to have just restarted the test again, but didn't provide any results from the last test. Do I just need to leave this session open on my laptop until it finishes, or how can I see the results of the long test? It runs on the drive, you don't have to stay connected. You should see output like this in the smart report: SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 7071 - # 2 Extended offline Aborted by host 60% 6850 - # 3 Extended offline Interrupted (host reset) 60% 3003 - # 4 Short offline Completed without error 00% 2939 - You DO have to disable any automatic spin-down timers, as that WILL abort the "long test" So, if you have 1 hour spin-down, and the long test normally would take 4 hours, it would abort after 1 hour when unRAID spins down the disk. That was shown in these two attempts at running a "long" test in the smart report excerpt you attached to your post. # 2 Extended offline Aborted by host 60% 6850 - # 3 Extended offline Interrupted (host reset) 60% 3003 -

and those are the INCORRECT names. They will never in unRAID be the correct names to use for a reiserfsck command. If you had run the --rebuild-sb command on those device names, you would have corrupted the file-systems (possibly beyond repair)

1.6.9

yes, it is. You've written parity yesterday, but never read it (checked it) to verify it was written properly.

At least we know why it is happening. I'm also not sure how to handle this without the possibility of listing a disk that is in the array. On older arrays, lime-tech used disk.cfg. It was easy at that point. Newer versions of unRAID no longer used disk.cfg in the same way. It could not be relied upon to determine assigned disks. With the newer cache-pool, etc, I've no idea what is the definitive list of assigned devices. Best to be overly cautious. At some point, I expect a native preclear to exist. At that point, it will be Tom's job to determine which disks are assigned, and which are not. Joe L.

I have no way to help you there. Since unRAID has no definitive list of assigned disks, the -l option of the preclear script looks in super.dat too. You assigned it, so it is there, and apparently the value has not been overwritten by another disk's serial number. If you are sure of the disk, it will probably let you pre-clear it. It is just being VERY cautious.

I'm sorry, but I have no idea what the plugin does, nor do I support it in any way. There is never a need to kill cache_dirs (at least with the version I wrote) It will suspend itself when the mover is run. Joe L.

If you do have that option to change file-system type, I expect you will then need to reformat that disk, and you will lose any/all files that are currently on it. There is no magical convert the current file-system (with its files) into a different file-system (retaining all the files) command. You've been warned.

' How about instead of Unformatted we have [glow=red,2,300][shadow=red,left]Unformatted[/shadow][/glow] Yeah I wasn't really going to use unformatted*, just a placeholder. how about "not mounted" or "cannot be mounted"

Before you proceed, you need to check that the disk you ran the smartctl command on is the disk that is marked as not-writable. Do the model/serial number in the smartctl report match that of the failed drive? Every time you re-start unRAID the /dev/sdX device names are re-assigned. If you really had a failed disk then the current /dev/sdc would NOT be the same disk, but the a different disk in your server (one that is still working). No device name would be assigned to a failed disk (one that is not responding at all) I am assuming you've re-started unRAID several times now since to re-seat the cables and swap disks. A dead drive would be assigned no device name, a functional, but off-line-because-a-write-to-it-failed drive would get assigned a device.

you have it right. /boot IS the root of the drive once it is mounted by Linux. unMENU is compatible, none of the 32 bit packages are. If you've not updated unMENU recently, you'll need to use the check-for-updates and subsequent install-updates buttons that are on the user-scripts pages. You'll only see unMENU packages that are 64 bit compatible (and "disable re-install on reboot" buttons for those that are not 64 bit compatible) There are 64 bit versions available for install of many of the more popular packages. Joe L.

The disk names (sda, sdb. etc) are assigned in the order in which the disks initialize upon bootup. They can change from one boot to the next. DO NOT BE FOOLED INTO THINKING /dev/sdb is always the parity disk... On newer unRAID versions unRAID uses the model/serial number of the disk when making assignments. (that never changes for any given disk) Older versions of unRAID used the disk-controller-PCI port ID to track a given disk. (Until it was learned that too chane change when identical multiple disk controller boards can also initialize in different order upon boot-up) So... when deciding on replacing disks, and re-assigning disks, use the model/serial number of the disks to make your assignments, not the disk device names. Joe L.

for a file in cron.daily to be invoked, it must be made executable. after this line in your config/go script (which you already have): cp /boot/custom/bin/cache_backup.sh /etc/cron.daily add this line: chmod +x /etc/cron.daily/cache_backup.sh