Checking actually used space on NILFS

Checking actually used space on NILFS

[dexen deVries]

Hello list,


it's my first day with NILFS, and one issue bothers me:

is there a reasonably easy way to check the size of the current (most recent) 
content of the NILFS filesystem?

As in, how much space would remain used if I decided to purge all old 
checkpoints and only keep the current one.


Regards,
-- 
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

Re: Checking actually used space on NILFS

[Ryusuke Konishi]

Hi,
On Wed, 9 Feb 2011 13:33:38 +0100, dexen deVries wrote:
> Hello list,
> 
> 
> it's my first day with NILFS, and one issue bothers me:
> 
> 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

We need adding API (ioctl) to get extended space information and may
need minor disk format change for that.

Regards,
Ryusuke Konishi

> As in, how much space would remain used if I decided to purge all old 
> checkpoints and only keep the current one.
>
> Regards,
> -- 
> 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
--
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

Re: Checking actually used space on NILFS

[dexen deVries]

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

Re: Checking actually used space on NILFS

[Ryusuke Konishi]

On Wed, 9 Feb 2011 16:25:55 +0100, dexen deVries wrote:
> 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

Right.

> > 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).

It seems possible, but cleaner routine have to track back the most
recent live checkpoint when deleting each checkpoint.

Fortunately, I just remembered that each checkpoint metadata has an
reserved block_count field and the current checkpoint API can get it
through ioctl though lscp command doesn't display this field.

So, we can use the block_count field to store space information that
you wanted initially.  Bad news is that enabling this field will break
forward compatibility since the current nilfs doesn't update this
field. (sigh).

Anyway, I will consider implementing the block_count field and
updating lscp so that it can display "the block count at that moment"
instead of NBLKINC.


Thanks,
Ryusuke Konishi
--
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