Comments on: Troubleshooting: "du: fts_read: No such file or directory" error

By: Andrew Gascoyne

Andrew Gascoyne — Thu, 26 Nov 2009 09:25:02 +0000

I simply ran a quick ls of the directory I had the eror on then ran the du without error.

I think it's similar to not being able to stat a directory as the filesystem doesn't recognise it as being properly mounted.

By: vovets

vovets — Thu, 23 Jul 2009 14:13:44 +0000

Solaris now default filesystem zfs is said to have "snapshots" feature. So you can make snapshot and then use du on the snapshot rather than on the original dataset. That will guarantee that file structure won't chage while du'll be running.

By: Gleb Reys

Gleb Reys — Thu, 26 Feb 2009 15:37:36 +0000

We don't use much of it, but if I understand the technology correctly (at least in NetApps), inodes are still used for each of the files. When you're removing duplicated data, you get rid of inode and get rid of references to the original data blocks, that's all

By: Matt Simmons

Matt Simmons — Thu, 26 Feb 2009 15:10:44 +0000

Are you using data dedup? I've always wondered how it handled inode mapping…

By: Gleb Reys

Gleb Reys — Thu, 26 Feb 2009 13:33:06 +0000

Thanks for your comment!

Yes, for the data sets I personally manage, I lean towards identifying the really specific subdirs rather than looking at the du of a parent directory.

Great point about df, it's even more twisted in my case because I'll be looking at the df/inode counts returned by the filer behind the data, and not the client-side df.

By: Matt Simmons

Matt Simmons — Thu, 26 Feb 2009 13:30:03 +0000

Great detective work.

I've got this problem as well. One of my SAN arrays houses a 600GB directory with 1.2mil files (at last count). It takes a while to run du

I think that the solution to this problem is adminstrative rather than technical. As you mentioned, it's possible to run du on subdirectories rather than the big directory. Beyond that, it's actually preferable.

By running du on there subdirs you can monitor their growth discretely rather than in a lump. This allows you to work on specific causes.

I've gotten to the point that I only run du on a couple of giant sub directories. I then take their sum and compare it to the results of 'df' and only look into the problem if there's a large disparity.

If you use this method, remember that du and df will return different numbers due to df checking free inodes and du counting the space used by the files it finds. The difference being that air a file is deleted while it is still open, the file disappears from the directory listing but the inodes don't get freed until the process releases them.

Great post. I'll link to it as soon as I'm off the train.

–Matt