> > zpool list doesn't reflect pool usage stats instantly. Why? > > This is no different to how UFS behaves.
It is different now (although I spent about 5 minutes looking for an old bug that would point to *when* the UFS change went in, I wasn't able to find one). > If you rm a file, this uses the system call unlink(2) to do the work > which is asynchronous. In other words, unlink(2) almost immediately > returns a successful return code to rm (which can then exit, and > return the user to a shell prompt), while leaving a kernel thread > running to actually finish off freeing up the used space. Normally you > don't see this because it happens very quickly, but once in a while > you blow a 100GB file away which may well have a significant amount of > metadata associated with it that needs clearing down. The UFS stat doesn't require synchronization, but prediction based on the delete queue. Such a solution may be impractical for ZFS. But it does suggest that it may be a problem worth solving. Actually, I care less about any synchronicity with any 'zpool' output if the traditional interfaces for the specific filesystem involved can reflect the intention. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
