Re: [PATCH] nilfs-utils: Work around uncleanable full filesystem

[Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

On Monday 14 January 2013 22:49:50 Vyacheslav Dubeyko wrote:
> Hi Sven,
> 
> On Jan 14, 2013, at 6:54 PM, Sven Eckelmann wrote:
> > The filesystem can end up in a state were the filesystem is full and the
> > returned ss_nongc_ctime is smaller than sui_lastmod of all reclaimable
> > segments. The garbage collector will not clean anything and therefore no
> > new room for new files will be available and ss_nongc_ctime/sui_lastmod
> > will not be updated without using special tools. This makes the
> > filesystem unusable without manual recovery.
> > 
> > Signed-off-by: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
> > --
> > This problem appeared on a current 3.2 stable kernel (Debian Wheezy
> > build). I am not an FS developer and have therefore not much background
> > knowledge about the NILFS codebase. Nevertheless, this problem hit me
> > quite hard after creating some files on a nilfs partition until it was
> > full and deleting them again.
> > 
> > $ for i in `seq 0 150`; do dd if=/dev/zero of=foo$i count=22528; done
> > $ rm foo*
> > 
> > Looking at the output debugging output using
> > 
> > $ watch -n .5 'df -h;tail /var/log/syslog;'
> 
> As I understand, you did such sequence of actions:
> 1. Generate such count of files that the whole size of used space was about
> the partition size. 2. Delete all generated files.
> 3. Expect that previously used space is become fully free.
> 
> Am I correct?

Nearly. Here is my config file:

protection_period       0
min_clean_segments      10%
max_clean_segments      20%
clean_check_interval    5
selection_policy        timestamp
nsegments_per_clean     8
mc_nsegments_per_clean  8
cleaning_interval       5
mc_cleaning_interval    1
retry_interval          40
use_mmap
log_priority            debug


and an alternative version

protection_period       20
min_clean_segments      10%
max_clean_segments      20%
clean_check_interval    5
selection_policy        timestamp
nsegments_per_clean     8
mc_nsegments_per_clean  8
cleaning_interval       5
mc_cleaning_interval    1
retry_interval          40
use_mmap
log_priority            debug

So I would have expected that nilfs would have some free space again after 20 
seconds (+ time it needs to free stuff). But it did not and I've showed the 
reason in my explanation (threshold vs. the time stored in each reclaimable  
segment).

At least "no free space after a work day" was not the expected result using 
this setup.

> I think that you have some misunderstanding of NILFS2 working. The GC of
> NILFS2 works in background and it needs to wait sometime before segments
> will be clean. If you have necessity to begin cleaning immediately then you
> can execute "nilfs-clean -p 0". Did you try to use it?
> 
> I think that you try to achieve by this patch the result of  "nilfs-clean -p
> 0".

This was default set in the configuration file and therefore I did not have to 
set it manually using nilfs-clean -p 0.

> Sorry, if I misunderstand something. Please, correct me if I am wrong.

See above.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]