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@xxxxxxxxxxxxx> > > -- > > 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:
signature.asc
Description: This is a digitally signed message part.
