On Wednesday, February 09, 2011 04:13:03 pm you wrote: > > is there a reasonably easy way to check the size of the current (most > > recent) content of the NILFS filesystem? > > The current nilfs doesn't have an effiecient way to do that. > So, the easy way is using 'du -s': > > # du -s /nilfs-mount-point that's true, but it relies on 1) user being able to see all the allocated files (and even root won't see some allocated files, for example if they have been unlinked but are still held open by a process), and 2) disk having low seek times > > We need adding API (ioctl) to get extended space information and may > need minor disk format change for that. The `lscp' lists, under NBLKINC, the incremental count of blocks added by this particular checkpoint. As far as I understand, if one summed up all NBLKINCs of all checkpoints, the actual number of allocated blocks would result. However, that seems to work only when no checkpoints have been ever removed... Would it be possible to change the semantics of NBLKINC (and possibly the on- disk structure) to report increment from the last existing checkpoint rather than just any (existing or not) previous checkpoint? I assume that'd make the NBLKINC summing up a viable way of counting used space (at least with good approximation). @Ryusuke: apologies for direct reply, I've forgotten to put mailing list's addres in To field. -- dexen deVries [[[â][â]]] > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron minnich, in response to Charles Forsyth http://9fans.net/archive/2011/02/90 -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
