On Thu, Jan 16, 2025 at 8:09 PM Felix E. Klee wrote:
>
> Thank you for the detailed explanation! The overhead for metadata is
> what I expected. However, I wasn’t aware of the default protection
> period of one hour, also not of the concept of segments.
>
> Now, a few days later, I get:
>
> $ df -h /bigstore/
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/bigstore 3.5T 2.7T 699G 80% /bigstore
> $ du -sh /bigstore/
> 2.5T /bigstore/
>
> The used space reported by `df -f` is not 2.7T vs 3.0T a few days ago.
> Back then I was apparently too close to a major file operation. I had
> geotagged tens of thousands of raw image files, modifying them directly
> (exif headers).
>
> Should the following command have freed up diskspace?
>
> # nilfs-clean -S 20/0.1 --protection-period=0 /bigstore
>
> I realize it doesn’t reduce the number of checkpoints.
The nilfs-clean command is a maintenance command, so use it when you
want to free up disk space quickly (especially if you don't mind
turning off the protection period). GC runs automatically in the
background based on the watermark conditions set in
/etc/nilfs_cleanerd.conf, even if you don't run the nilfs-clean
command.
However, the GC speed is slow by default, so if the capacity is large,
you may want to adjust parameters such as "nsegments_per_clean" (and
"mc_nsegments_per_clean") and "cleaning_interval" (and
"mc_cleaning_interval") to increase the GC speed.
The nilfs-clean command takes a device path as an argument, so the
command line is:
# nilfs-clean -S 20/0.1 --protection-period=0 /dev/mapper/bigstore
or, omitting the device:
# nilfs-clean -S 20/0.1 --protection-period=0
Also, I forgot to explain one thing. The current GC skips segments
whose free block ratio is equal to or less than the
"min_reclaimable_blocks" parameter (default is 10%, and 1% of
mc_min_reclaimable_blocks if the remaining capacity is low) in
/etc/nilfs_cleanerd.conf.
If you want to ignore this ratio and force GC, use the "-m" option, like this:
# nilfs-clean -S 20/0.1 -p 0 -m 5
or specify a percentage:
# nilfs-clean -S 20/0.1 -p 0 -m 1%
When running GC manually, be aware that once GC of all segments is
finished, GC will be skipped until some change is made to avoid
infinite GC execution.
If you change the GC conditions and rerun it, it may work if you make
a change and then run the nilfs-clean command, as in the example
below:
# touch /bigstore
# mkcp
# nilfs-clean -S 20/0.1 -p 0 -m 1%
I've gotten into a lot of detail. Please understand that these are
tips to use for when you're in trouble.
> I really am a n00b when it comes to log structured file systems. I just
> want to use NILFS2 for the ability to revert accidental file changes.
LFS is a legacy method and is not common, so the need for this kind of
interaction is a drawback in a sense, and it may be an area where the
tools need to be improved.
One thing to note is that while nilfs can save you from data loss due
to user misoperation, it is powerless against physical device failure,
so you still need to back up important data.
> One more question, as you wrote:
> > Incidentally, the reason why the df output (used capacity) of NILFS is
> > calculated from the used segments and not the number of used blocks is
> > because the blocks in use on NILFS change dynamically depending on the
> > conditions, making it difficult to respond immediately. If the
> > dissociation is large, I think some kind of algorithm should be
> > introduced to improve it.
> >
> > The actual blocks in use should be able to be calculated as follows
> > using the output of "lssu -l" (when the block size is 4KiB). For your
> > reference.
> >
> > $ sudo lssu -l -p 0 | awk 'NR>1{sum+=$6}END{print sum*4096}' | numfmt --to=iec-i
>
> Certainly interesting! But, I assume, without garbage collection I
> cannot use the space in sparse segments anyhow. So `df` should give me
> the space that currently is available for actual use. Do I understand
> that correctly?
That understanding is correct. The above example is for checking
potential free space and isolating the problem.
On the other hand, the current capacity calculation is not without issues.
For example, I think it is counterintuitive that a segment is judged
to be in use even if all the blocks inside are garbage (reclaimable)
until the GC runs.
Well, but rather than improving the capacity calculation, it may be
better to cover this by improving the GC.
Regards,
Ryusuke Konishi
