Joe L.

Good. Not likely, that is the correct setting. Emulated-IDE is typically slower. You apparently have not yet read the post I linked to earlier. to get any further support from any forum member, a syslog is needed for analysis. Otherwise, all we can do is say "yes, your system is not working as well as expected" Too bad we have no clue what might be happening. Joe L.

No. If you did not use any "-A" or "-a"' then the default alignment is used as you set in your unRAID configuration. It has ABSOLUTELY no impact when clearing a disk as it only is involved once you create a file-system on it AFTER configuring it in your array. It simply determines if the disk partition will start on sector 63 or sector 64. Even that is only meaningful on one specific model/brand of drive... (That one drive works perfectly fine with either partition start sector, but works slightly faster if the partition starts on a 4k alignment (sector 64 instead of 63).) If you have not installed and configured mail, this option is un-usable. If you did, then "root" IS the e-mail address for "root" (usable IF you configured it to be forwarded to you), otherwise, use YOUR e-mail so they get sent to you. Also the "-m e-mail" should follow the -M option if you want it sent to an alternate mail address. ./preclear_disk.sh -M 4 /dev/sdX will mail to "root" by default since you did not specify any alternative. ./preclear_disk.sh -M 4 -m "[email protected]" /dev/sdX will send to [email protected]

As an alternative to giving up, you might want to post a system log for analysis See here: http://lime-technology.com/forum/index.php?topic=9880.0 Odds are very high there is something wrong. If you "give up" you will not have good results regardless of which NAS you load on those disks. It sounds as if errors are being logged filling and using all available memory. It could be anything from incorrectly set up memory (wrong voltage. timing, or clock speed), wrong BIOS settings, to a bad disk. Joe L.

Did you mean 1.12beta and 1.13 will correctly preclear a 3TB drive? yes. The 1.12 (non-beta) however was actually the 1.11 version. (I had accidentally uploaded the wrong file) so... 1.12beta will clear a 3TB drive 1.13 also will clear a 3TB, and it fixes a different bug in knowing the default partition alignment set if you do not specify "-a" or "-A"

Your disk looks great. Good luck with your server. Your copy of the pre-clear script is one version old. Current is 1.13 (You should always download and use the current version as I constantly improve it. The 1.12 version will not clear a 3TB drive properly, the 1.11 and 1.13 version will.)

you still need to tell the array you are using a new disk configuration. Type: initconfig or, use the button in the web-interface in the "Utils" tab for a "New Config".

If you closed the putty sessions, and did not use "screen", the pre-clear scripts were all terminated. It is easy to tell you the status. They are not running... and they did not complete. Start them again... This time, either use the system console, or "screen", or do not shut down the telnet sessions. Joe L.

You will tell us. Run in the foreground to see what it does. I have have that RAM and it works fine for me. Are you running an 8086 or greater? Then it is enough.

Probably a mistake I made in the newest version.. in the test option. Won't be able to look at it till next week. Sorry ...

Does not matter,green or not, if the find completes without spinning up the disks then all the directory blocks are in the buffer cache. Cache_dirs is doing its job.

.07 seconds indicates all is in ram or you have very fast disks. Cache_dirs will not help if your laptop is a accessing files.to create thumbnails, or store attributes. It does not cache file contents, just directory entries. The whole idea is the directory entries will not be displaced from the cache in the next three seconds until the next scan.

run it in the foreground so you ran watch it as it runs. Invoke with -F -v Options

I'm not 100% sure, but the "TV Shows" option, because it is quoted, does not need the backslash. -i "TV Shows" should do it. Also, based on how the program works: If no "-i" options are given, it will scan all the top level directories in /mnt/disk* and /mnt/cache and create an initial top-level list of directories to scan and cache (those same top level directories represent your user-shares). If "-i" entries are given, they will be the only top level directories to scan and cache. Those will be the initial top-level list. If "-e" (exclude) directories are given, they are then deleted from the initial top-level-list created by either the "-i" options, or the lack of "-i" options. So, you probably do not need the -e options, since those are not in your list of "-i" entries. They do not do any harm, but you've already excluded them by only including the other three "-i" options. Joe L.

yes. Only that specific 2TB drive. Quoting from another post: Action items for the WD20EARS drive: If you are installing a new WD20EARS drive, and you are running version 4.6.1/5.0-beta3 (or greater), do not install the jumper. If you already have the jumper installed, and the drive has already been formatted by unRAID version 4.6/5.0-beta2 or earlier, you do not have to do anything. Your drive is already operating at full speed, and I recommend you just leave it this way.

The "-A" option indicates you wish the partition to start at sector 64. All disks will work with the partition starting on sector 64 (EXCEPT for an EARS drive with an added jumper) Use of the "-A" option is fine for your samsung disk, leaving it off is fine too.

If you are first creating an array, it really does not matter. The array will not clear it if parity has not already been established.

If AFP is reading anything other than the directory listing, no... since those disk blocks would not be in the recently used set of disk blocks in the cache.

OK, that explains the issue better. I was not thinking you were trying to kill the initial "find", but subsequent ones. In some cases, the initial find has to spin up drives. I'm not sure it is killable while waiting for a drive to spin up. (basically, the "find" process is in kernel space and not looking for user-signals at that time) It would be easy if the initial "find" was a single command... It is not. It is a "find" on each of the data drives in turn, for each of the user-shares in turn. With 10 disks and 3 user-shares, it is 30 "find" commands. I'll give it some thought. Might not be too difficult. Joe L.

Hi Joe L., Was it that dumb question that you don't have any feedback on it or you missed this one? Cheers! Saw it, have not had time to investigate... However... something is wrong in your use of the command. Let me explain. The very first "find" should take a while going through all your disks. Subsequent "find" commands should just read from the buffer cache, since the blocks needed should not be the least recently used, and should not have been reused, and are all in RAM. In that way, these subsequent "find" commands should be really quick... fractions of a second typically. You can see what the cache_dirs program is doing by running it in the foreground by use of the "-F" option (possibly in combination with the "-v" option for even more information.) On my server, with only 500 Meg of ram, I had to exclude my "data" directory and only cache my "Movies" and "Music" directories. I simply use "-e data" when I invoke the command. the reason I did not kill the "find" was that typically it was never there long enough to worry about. Joe L.

I have 512 Meg of RAM in my older server and it has 6TB of media. Been using it for nearly 6 years. unRAID, needs at least 512 Meg. It will use ALL you give it for disk buffer cache. In other words, if you were to install 16Gig of RAM and watch 4 DVD ISO Images, all your RAM would be used as buffer cache. the RAM used as cache is freed when there is no more "free" ram and more is needed. The least recently used ram in the cache is reused first. (In most cases, the movie/music you played least recently) In my case, once I'm part way watching a DVD ISO image all my RAM is in use. re-playing the previous chapter in the movie is typically done without needing to read the disk. Obviously the entire movie does not fit in my RAM, so playing to the end and then going back to chapter 1 will access the disk once more. So... using cache_dirs uses all the memory is needs to hold the directory listings. That depends on how many files you have. It works by listing the files on your server (keeping their directory listing most recently accessed and in the disk buffer cache) The "memory" it uses is exactly the same as the buffer cache used when watching a movie. It is available for re-use if it is the least-recently used. (It however, constantly repeats its scan of the directories every few seconds, so usually, they are not the least recently used memory in the cache)

That's not how wake-on-lan works. You need to send a special wake-up packet. And, it has to be listening for it. Joe L.

So did the 4gb ram change the numbers? Sorry, haven't gotten to that test yet. I'll get it started today. Joe L.: I wanted to bring to your attention what I believe to be a small bug with preclear 1.12beta. When using it with unRAID 4.7, preclear 1.12beta defaults to sector 63. Changing the 4k alignment setting in 4.7 does cause preclear to automatically switch to sector 64, without using the -A flag. Everything seems normal when using preclear1.12beta in conjunction with unRAID 4.7. The same is not true when using preclear1.12beta in conjunction with unRAID 5.0beta10. unRAID 5.0beta10 defaults to 4k alignment. When running preclear 1.12beta with a default install of unRAID 5.0beta10, preclear still defaults to sector 63, which is a mis-match compared to unRAID's default settings. Switching 5.0beta10 to 4k unaligned and then back to 4k aligned gets preclear 1.12beta to default to sector 64. It appears as though preclear is looking for a change in the disk alignment parameter, and that if there is no change it defaults to sector 63. I suggest that what should happen is that preclear has no knowledge of unRAID's default setting, and instead checks the disk alignment setting each time to make sure that it matches. I was grabbing the default format, but it had a trailing cr/nl in disk.cfg. I was stripping off the carriage return, but the newline remained. Change this line (line 363) from: default_format=`grep defaultFormat /boot/config/disk.cfg | sed -e "s/\([^=]*\)=\([^=]*\)/\2/" -e "s/\\r//" -e 's/"//g' ` to: default_format=`grep defaultFormat /boot/config/disk.cfg | sed -e "s/\([^=]*\)=\([^=]*\)/\2/" -e "s/\\r//" -e 's/"//g' | tr -d '\n'` Thanks for reporting it. Joe L.

Looks like the disk stopped responding to all commands from the OS. The "dd" commands stating zero records read are a big clue. In past cases, it takes a power cycle to get it to respond again. (power down server, then restore power, then try smartctl report again) What version of the preclear script are you using? Early versions attempt to read past the end of the disk and some disks react by locking up. (firmware on the disk is probably buggy in not being able to handle this) To see the version of the preclear script, type: preclear_disk.sh -v

Doesn't really instill me with confidence I know... but you had two different disks with similar symptoms. More than likely on different cables connected to different ports on your old MB. The only common factors are Your old MB. Your old power supply MS-Windows Which one did you have the most confidence in? Joe L. Now I'm confused... my preclear results are for only one disk, and this is the first time I've posted here... I think you have me confused... or I'm confused. Looks like 1 sector re-allocated, 5 pending, but were written in place and not re-allocated, and you are using an OLD version of the pre-clear script. Type preclear_disk.sh -v to see the version. Other than that, the disk does not look too bad. Spin up time getting worse, and has had to re-try 41 times out of 11,566, so perhaps bearings showing some wear.

Doesn't really instill me with confidence I know... but you had two different disks with similar symptoms. More than likely on different cables connected to different ports on your old MB. The only common factors are Your old MB. Your old power supply MS-Windows Which one did you have the most confidence in? Joe L. Now I'm confused... my preclear results are for only one disk, and this is the first time I've posted here... I think you have me confused... or I'm confused. My mistake. I confused you with a prior user.