Tomas Ögren wrote:
On 20 October, 2009 - Matthew Ahrens sent me these 0,7K bytes:

Tomas Ögren wrote:
On a related note, there is a way to still have quota used even after
all files are removed, S10u8/SPARC:
In this case there are two directories that have not actually been removed. They have been removed from the namespace, but they are still open, eg due to some process's working directory being in them.

Only a few processes in total were involved in this dir.. cd into the
fs, untar the tarball, remove it all, cd out, run sync. Quota usage
still remains.

This is confirmed by your zdb output, there are 2 directories on the
delete queue. You can force it to be flushed by unmounting and
re-mounting your filesystem.

.. which isn't such a good workaround for a busy home directory server
which I will use this in shortly...

Mark Shellenbaum provides some additional details, and a simpler workaround:

This is a well known problem with negative dnlc (Directory Name Lookup Cache) entries on the directory. The problem affects both zfs and ufs, and is covered by bugs 6400251 and 6179228, which are being worked on.

You don't necessarily have to unmount the file system to get it to flush the dnlc and recover the space. All you need to do is cd to the root directory of the file system and do a zfs umount <dataset>. That will fail, but a side effect is that the vfs layer will have purged the dnlc for that file system.
That should cause the files to be deleted.

--matt
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to