December 28, 201015 yr Hi, Summary: I can no longer move data from the cache to the array. The syslog is full of entries like: Dec 28 07:59:51 TowerWAV shfs0: shfs_write: write: (28) No space left on device Dec 28 07:59:51 TowerWAV logger: rsync: writefd_unbuffered failed to write 4 bytes [sender]: Broken pipe (32) Background: As I had run out of space on my unRAID server (4.6 final), I purchased a new 2TB HDD (Samsung HD204UI), and did the following: 1. Updated the firmware on the HDD 2. Removed the existing 1,5 TB parity drive, and replaced it with the new HDD 3. Re-built the parity and ran a parity check 4. Added the former parity drive as a new HDD (after clearing and formatting) 5. Proceeded to "Move" data (by clicking "Move Now") from the Cache drive onto the array (in essence onto the new HDD, as other drives were already full) After moving some 200 GB of data, the move ground to a halt before completing, and the rest of the data on the cache can not be moved onto the array even though there is plenty of space (see the two attached syslogs). User Shares are all set to "High Water" w Split Level "3". Sofar, I have: 1. Obtained SMART reports from all drives (see attachment). As they all show "No Errors Logged", I assume/hope that this is not a HDD hardware issue? 2. Commenced running "reiserfschk" on the drives. The added HDD (former parity) produced "No corruptions found", but I imagine that an FS problem producing my issues must not necessarily relate to the new/empty disk? As running reiserfsck on all drives in the array will take quite some time, I would only like to check if I am on the right track? Am I, or should I be doing something else? Best regards syslog.2010.12.28_11.10.zip syslog.2010.12.28_11.19.zip smartsd_all.zip
December 28, 201015 yr You are close, but you also need to set the min-free space for the user share. The problem is that the physical disk has enough space for the initial file being created and appended to as the file is moved, but not enough for the entire file. Any single file must fit on a physical disk. You need to set the user-share min-free parameter to a value larger than the largest single file being moved. If the individual files you move are 5Gig, I suggest a value for min-free of 10Gig. Since the entry field on the user-shares page is in kb, set the field to 10000000
December 28, 201015 yr Author You are close, but you also need to set the min-free space for the user share. The problem is that the physical disk has enough space for the initial file being created and appended to as the file is moved, but not enough for the entire file. Any single file must fit on a physical disk. You need to set the user-share min-free parameter to a value larger than the largest single file being moved. If the individual files you move are 5Gig, I suggest a value for min-free of 10Gig. Since the entry field on the user-shares page is in kb, set the field to 10000000 Thanks for the quick response! My min-free was set at 2GB, so that's worth changing for sure. I wonder if that can really be the problem in this particular case though, since the only free disk has well over 1 TB of free space and the remaining data on the cache is only around 100 GB (see attachment)? I now also wonder/worry regarding the "0" bytes of free space on all the other disks. If only whole files can be transferred onto any single disk, it seems highly unprobable that they would all fill up so nicely. What have I done!? Cheers
December 28, 201015 yr The management display may be rounding the free space. Or, you may have used up every byte with "partial" files Log in via telnet as "root" and type df to see the true free space on each of your disks.
December 28, 201015 yr Author The management display may be rounding the free space. Or, you may have used up every byte with "partial" files Log in via telnet as "root" and type df to see the true free space on each of your disks. Ran "df" with the following outcome: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sde1 1012464 146112 866352 15% /boot /dev/sdm1 390699424 100076960 290622464 26% /mnt/cache /dev/md6 976732736 976732736 0 100% /mnt/disk6 /dev/md3 976732736 976732736 0 100% /mnt/disk3 /dev/md9 1465093832 1465093832 0 100% /mnt/disk9 /dev/md7 976732736 976732736 0 100% /mnt/disk7 /dev/md8 1465093832 1465093832 0 100% /mnt/disk8 /dev/md5 976732736 976732736 0 100% /mnt/disk5 /dev/md4 976732736 976732736 0 100% /mnt/disk4 shfs 11623110072 10080972928 1542137144 87% /mnt/user shfs 11232410648 9980895968 1251514680 89% /mnt/user0 /dev/md1 976732736 976732736 0 100% /mnt/disk1 /dev/md2 976732736 976732736 0 100% /mnt/disk2 /dev/md10 1465093832 213579152 1251514680 15% /mnt/disk10 Strange that a min-free of 2 GB can produce free space values on the array disks that become zero, right? Anyway, I still do not understand how the min-free value can be the problem in this case, since the disk/array has 1.200 GB of free space, and only 100 GB of data (in many files) on the cache? Cheers
December 28, 201015 yr The web interface is telling the truth. You have managed to fill every possible byte on those other drives. (not normally possible unless you have partial files, and not good for file-system management since you have no room to move files to re-balance the files on those drives. Can you share the exact settings in each of the fields where you set the min-free and allocation method for the user-shares. (A screen-print of the user-shares pages might be easiest) I'd send an e-mail to lime-tech to see if they have any ideas. Joe L.
December 28, 201015 yr Author Can you share the exact settings in each of the fields where you set the min-free and allocation method for the user-shares. Nope. Or rather, see below... But I can share that you, Joe, are brilliant, and that I am an IDIOT. The key was in "each of the fields". Don't know why I had concluded that the min-free parameter is set only for the cache, when logic and basic literacy indicate that it should be set for each user share. I have now changed the min-free settings for all user shares from "0" to "20000000" (which I assume is 20 GB), see attachment. I also deleted enough data from each of the disks to create between 10 and 40 GB of free space on each disk. I then re-booted just-in-case. Furthermore, I had screwed up the "split levels". There seems to be a hierarchy between "min-free" and "split level". For my "video" share, I had a "split level" of 4, but the files I tried to move were in "\\Towerwav\Video\000_TV_Series\_Deutsch\Tatort\_Brinkmann\", i.e. "split level" overrides "min-free", right? RTFM... Thanks for all you help, and for setting me on the right track! Could easily have spent the whole night on pointless reiserfschks otherwise. Cheers
Archived
This topic is now archived and is closed to further replies.