Checking actually used space on NILFS
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,
Signature · 3 lines
dexen deVries [[[↓][→]]]
Quoted 1 line
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 201102091333.39072.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Hi,
Quoted 7 lines · 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?
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
Quoted 21 lines
As in, how much space would remain used if I decided to purge all old checkpoints and only keep the current one.
Regards,
Signature · 3 lines
dexen deVries [[[↓][→]]]Quoted 1 line
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 [email protected] 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · you
Quoted 2 lines
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
Quoted 3 lines
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.
Signature · 3 lines
dexen deVries [[[↓][→]]]
Quoted 1 line
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 201102091625.55553.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Quoted 7 lines · dexen deVries
Quoted 6 lines · you
Quoted 2 lines
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':
Quoted 7 lines
Quoted 1 line
# du -s /nilfs-mount-pointthat'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.
Quoted 9 lines
Quoted 2 lines
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...
Quoted 5 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html