Re: Checking actually used space on NILFS

[dexen deVries <dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html