big jump in free space after update (5.0.4)

[smellthebean]

Yesterday I upgraded from 5.0-rc3 to 5.0.4.  After parity check (which found one error, which was apparently fixed) I am back up but user shares which were showing 3.61 TB free space are now showing 4.59 TB.  I've looked through all of the shares and from a cursory investigation I can't find any missing files (and folder sizes seem correct, best I can tell).  All disks show green status icons on the main screen  and all of them pass a SMART test.  User shares show Temporary Items and Network Trash Folder shares (as they always have).  I didn't create these, although I assume at least one of them was created when I connected via AFP to various shares in the past (I typically connect via SMB but have gone occasionally via AFP). 

 

Is it possible that I had a terabyte of cache/trash that was purged?  It seems a bit large?  I've attached my syslog (i've removed lines for some .nfo and .tbn files which apparently had bad resource forks).  If any of you can offer some ideas (other checks I can run, e.g.) I'd very much appreciate your guidance.

 

Thank You.

RAID_syslog_4jan2013_reduced.txt

[bonienl]

The moment a user share (read: top level folder) is created on another disk, the capacity of that disk is counted in the share size calculation.

 

Did you perhaps create a folder on another 1 TB disk ?

 

[smellthebean]

Thank you for your prompt reply.  No, contents of all disks were unchanged.  I guess it's possible a disk was previously unrecognized (i.e., pre-update) but I ran parity within the last couple of weeks and detected no drive issues.  Furthermore, at least one of my most frequently used shares contains data distributed amongst all six disks in the array.

[DaleWilliams]

Wasn't there something in the way the old SimpleFeatures calculated disk space that was in error?

Or was that pre-Release 5.0 stock web interface?  The aggregate total of disks was off somehow. 

 

 

(...did it count empty space correctly? I can't remember exactly what the error was.  It seems like each disk was individually okay, but the calculation across of a 'share' across all the disks was wrong. all available free space was shown as available to each share which distorted the total free space by doublecounting once for each share.)

 

 

[DaleWilliams]

 

That parity error is bugging me.I'd run Reiserfsck on each disk to see what it reports. (making no changes and not allowing Reiserfsck to fix anything yet.)

[smellthebean]

it seems like everything is ok:

 

Replaying journal: Done.

Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed

Checking internal tree.. finished                               

Comparing bitmaps..finished

Checking Semantic tree:

finished                                                                     

No corruptions found

There are on the filesystem:

Leaves 304383

Internal nodes 1945

Directories 13127

Other files 120436

Data block pointers 292454885 (0 of them are zero)

Safe links 0

###########

reiserfsck finished at Sat Jan  4 18:12:01 2014

[DaleWilliams]

You got the same Reiserfsck response from your other data drives, too?

 

 

Your Mac (for AFP) would not maintain a Trash file on a NAS device. When you delete something, you get a prompt reminding you that the file will be deleted immediately.

There is a plug-in called 'VFS-Recycle' which sets up 'trash can' like folder system on unRAID for SMB.  If you had that installed, its emptied on a timer, and its possible that it emptied.

 

 

[smellthebean]

I have no plug-ins installed.  I had not carefully read the directions wrt reiserfsck so I just finished running it on all six data drives.  They all come out clean.  I do want to confirm something here which I have read earlier in the forum:  alternately mounting to shares via afp and smb is ok(?).  I don't know if there was ever a situation in which a device (e.g. a jailbroken Apple TV) was connecting to a share via SMB while I was simultaneously connected to it on my Mac via AFP.  It's conceivable, though.  Would this cause problems?

 

Thanks again.

[dgaschk]

Try this: http://lime-technology.com/forum/index.php?topic=28484.0

[DaleWilliams]

... was ever a situation in which a device (e.g. a jailbroken Apple TV) was connecting to a share via SMB while I was simultaneously connected to it on my Mac via AFP.  It's conceivable, though.  Would this cause problems?

Nope. That would not matter.

 

 

Try dgaschk's suggestion in prior posting...

[smellthebean]

I have looked for the extraneous extended attributes on all data drives, as guided.  One of my user shares (with data spanning five of the six data drives) did produce netatalk errors.  I ran the rmattrs script, rechecked attributes and the directory structures, and results appear to be clean.  I am still showing the same amount of free space (4.59 TB vs. 3.61 TB prior to the update) but I still have yet to notice any missing files (for what that's worth: my backup docs share is very horizontal, with a large number of files at top level).

 

Is there anything else I should check?  At this point it seems that it's quite possible that my previous free space reading was erroneous?

 

Thanks again for all of your help.

[DaleWilliams]

Your server log shows this, "Jan  3 13:47:07 Tower emhttp: unclean shutdown detected".

Check to be sure the following files are good:

 

Jan  4 10:37:40 Tower afpd[1931]: getfilparams(I Know Where I'm Going! [1945].nfo): bad resource fork

Jan  4 10:37:40 Tower afpd[1931]: getfilparams(The Human Condition [1961].nfo): bad resource fork

Jan  4 11:27:22 Tower afpd[2585]: getfilparams(Peeping Tom (1960).nfo): bad resource fork

Jan  4 11:27:22 Tower afpd[2585]: getfilparams(The Patchwork Girl Of Oz (1914).nfo): bad resource fork

That's the end of the log.

[smellthebean]

I'll check on those.  Should I do another parity check?

 

On a related (to the thread) note, since you are a Mac and Windows user:  what are your thoughts about connecting to shares via the Mac OS now that Mavericks has made SMB the default protocol?  Historically, afp always seemed to offer better performance but would SMB now be a better choice?  I've always stuck with SMB because that was what my jailbroken Apple TV was using to connect to shares, but on the Mac OS side I've consistently gotten permissions and 'disk full' errors when transferring files to my unRAID shares ever since Lion (when Apple apparently changed their SMB implementation).  I always stuck with SMB because of the annoyance of AppleDouble file creation with AFP and because of my concerns about mixing protocols (thanks for your help on clarifying this, I was never entirely sure).

 

Thanks.

[DaleWilliams]

It sounds like your unRAID server is fine, which leaves two theories about your missing free space:

1. The unRAID screens were wrong when you compared your before and after.  (Some older web gui pages had issues)

2. The four movies shown as 'bad' weren't really/totally on your unRAID server.  More likely, they were partially written, but not completely. Or, they could be bad on your Mac, and were copied to unRAID with the resource errors.

 

 

(Simplistically, OS X sets up a hidden 'dot' file for each file that's to be copied. Dot files do take up space, but are 'hidden' from the Finder. When you copy from finder to unRAID...OS X would write to unRAID a '.PeepingTom.MOV' file, for example. When all data is successfully written, the file is renamed after the successful copy is complete. The rename strips the dot off the front and the file becomes visible.  If something goes wrong, your disk doesn't show the 'partial' file (because its 'hidden'), even though it still takes up space.  OS X has routines that clean out the hidden dot trash on your Mac disks, OS X doesn't do so well on NAS devices.  For unRAID, there's a script available which cleans up the dot trash automatically on each startup.)

So...for #2, either your four files were only 'partially' written, OR they were already bad on your Mac and then copied. Check the original files. And maybe run 'Disk Utility' on your Mac to look for any file system issues.

---

 

Apple has publicly announced that they are stopping support of AFP and shifting to SMB. In Mavericks, the only reason for AFP to still be around is Time Machine.

Effective in unRAID 5.0.3, there were a number of changes to SMB and AFP that dramatically increased stability and improved the Mac experience. Time Machine in particular, is more stable and requires less 'hand holding'.

I've been very happy with unRAID 5.0.3 and later. Combined with Mavericks, its a great combination.

I mentioned earlier that there's a script that will clean up your Dot files, including the AppleDouble files...if that's annoying, you'll find it discussed in the Wiki. Instances of uncleaned Dot files usually result from abnormally aborted copy commands (Like an unexpected Disk Full), or other system failure, not normal operations.

[DaleWilliams]

More thoughts... Go ahead and run another parity check.  It'll allow everyone to sleep easier.

If those four bad movies are still on your Mac, (and disk utility runs okay) then copy the four from Mac to unRAID.

 

---

 

To expand on your earlier questions....there shouldn't be any problem in running both SMB and AFP simultaneously, nor having both active and processing data traffic at the same time.  A jailbroken Apple TV shouldn't affect anything, (unless the SMB protocol in the jailbreak was bad...and that seems unlikely.)

 

 

What I suspect happened is that for those four movies with bad resource forks, the copies were stopped abruptly by OS X before completion, which left the hidden dot files behind.

---

 

An issue can arise on unRAID if a copy is aborted by power failure, or other system error.

 

 

Another issue can arise from simultaneous copies via the Finder if you're close to a disk full situation.

(One multi-file copy command is fine. This is a problem with multiple copy operations, each operation being one or many files):

 

 

With each copy operation from the Finder, OS X will check to see that there's room on the target disk for all the files in the copy command.

A problem could arise if you start a second (or third, etc.) large copy command while the first is underway.

(When the second one starts, OS X will again check for available space for the second copy, but because the first hasn't finished, OS X won't know how much space the first is going to still need to use.)  As the Finder copy operations continue, should the combo of the multiple copies exhaust the available empty space, OS X will stop both copies part way through.

This can result in a bunch of hidden DOT files being left behind on unRAID.

If Parity is correct, reiserfsck shows no errors, then I suspect the difference in free space results from the deletion of the hidden Dot files, which probably came from an incomplete copy command. 

[OMGerm]

(Simplistically, OS X sets up a hidden 'dot' file for each file that's to be copied. Dot files do take up space, but are 'hidden' from the Finder. When you copy from finder to unRAID...OS X would write to unRAID a '.PeepingTom.MOV' file, for example. When all data is successfully written, the file is renamed after the successful copy is complete. The rename strips the dot off the front and the file becomes visible.  If something goes wrong, your disk doesn't show the 'partial' file (because its 'hidden'), even though it still takes up space.  OS X has routines that clean out the hidden dot trash on your Mac disks, OS X doesn't do so well on NAS devices.  For unRAID, there's a script available which cleans up the dot trash automatically on each startup.)

 

Related, maybe helpful:  To configure a Mac OS X user account so that .DS_Store files are not created when interacting with a remote file server using the Finder, open up Terminal and:

 

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

 

This will affect the user's interactions with SMB/CIFS, AFP, NFS, and WebDAV servers.  Either restart the computer or log out and back in to the user account for your change to have taken effect.

[smellthebean]

Thanks for the information!  I checked the wiki wrt the AppleDouble files and couldn't get any hits.  Do you have a link?  There are terminal commands I've run from the Mac side to remove 'dot' files and there are also Mac scripts/apps that supposedly prevent them from being written.  I've not had success with the latter.  So a script from the unRAID side would be helpful.

 

I've removed all of the .nfo and .tbn files that had bad resource forks.  These were created by a movie scraper I no longer use.  The movie files themselves appear to be fine.

 

I will re-run parity tonight and, assuming it comes back clean, will mark this issue as solved.  Thanks again for your prompt and helpful responses.

 

[DaleWilliams]

... I checked the wiki wrt the AppleDouble files and couldn't get any hits.  Do you have a link? ...

Oh Heck! I was afraid you'd call my bluff. I don't actually use the dot cleanup script. I saw it on the Wiki, bookmarked it, and have always meant to try it:

http://lime-technology.com/wiki/index.php/UnRAID_Add_Ons#Add_On_Scripts

.DS_Store and ._ file cleanup scriptThis script removes the .DS_Store and ._ files that Mac OS X creates when viewing a file through Finder. Please see the Wikipedia entry on cron to get a better idea on how cron works. There is no error checking for the removal time entered, so please be careful when entering your desired time.

and here:

http://lime-technology.com/wiki/index.php/Plugin/webGui/AFP

Other notesPrevent .DS_Store file creation on network volumes - from the article:To prevent the creation of these files, open the Terminal and type:defaults write com.apple.desktopservices DSDontWriteNetworkStores true It may be necessary to log out and back in, or even to restart the computer (which is what the article states), for the change to take effect.[/size]

[Pro-289]

There's also a calculation bug in 5.0.4 that calculates the total space used, I believe, when you have unformatted disks present. After I pre-cleared 4 drives and went to the main page they showed up as unformatted, but the space used from working 4 drives didn't add up to the total used. It said there was somewhere around double used. Oh well, went away after formatting the drives.

[smellthebean]

I re-ran parity last night and produced no sync errors.  There is no sign that I have lost any data so at this point I believe the conclusion is that my pre-update value for free array space was erroneous.

 

Thanks for all of your help.

[david81]

Is this, perhaps related to the use of a cache disk? I just noticed a similar behavior on my setup.

 

User share spans 2 disks, only 90GB free between the two, yet unRAID reports nearly 1TB free. When calculating free space from the Shares tab of the web UI it seems to include cache disk space in the free space calculation for the user share. Is that expected? It only seems to do that if there is currently a top level folder for that particular user share on the cache drive.

 

Personally, I'd prefer to exclude cache drive space from the free space calculation since the cache drive is not "real" space (protected). I can't remember if pre-5 versions behaved the same way, but I only noticed it after my upgrade to 5.

[garycase]

Is it possible that I had a terabyte of cache/trash that was purged?

 

Not sure what happened, but it's not this.  The cache doesn't contribute to the available space calculations -- that's just for the array's data drives.  At least that's how it's supposed to behave.  David81's comment indicates that may not be the case with v5 => I don't have a cache drive, so I can't confirm that.  But if there is indeed an error in this calculation in the latest release, then it may simply be that your new free-space computation includes your cache drive -- if it's a 1TB drive that would explain why you're seeing the difference (or if it's a larger drive with all but 1TB used).

 

[david81]

Here's a screen shot of what I'm seeing on 5.0.5. The Movies share does not have a top level folder on the cache drive currently. The TV share does.

 

[garycase]

Clearly it's reporting the free space on the cache drive as available space.

 

That is an error in the reporting -- not an extra 1TB of "magically available" space.

 

[DaleWilliams]

That is an error in the reporting -- not an extra 1TB of "magically available" space.

RATS! That would have been a great unRAID selling feature.