On Fri, 2014-06-27 at 10:14 +0530, dE wrote: [snip] > > I can confirm that at 4K block size, this issue never existed. It > started happening when I reduced the block size to improve write and > read seek performance when very small amounts of data was being > read/written. > > Yes, the FS was made at the specified day, but it was running > continuously since then. > > This problem triggers after running the programs for long amounts of > time. Like 1 day+ with GC running the background at low priority (idle > i/o). nilfs_cleanerd.conf -- > > clean_check_interval 300 > nsegments_per_clean 1 > mc_nsegments_per_clean 1 > cleaning_interval 0 > mc_cleaning_interval 0 > protection_period 0 > min_clean_segments 100% > max_clean_segments 100% > selection_policy timestamp # timestamp in ascend order > retry_interval 300 > use_mmap > log_priority warning > > As of the nature of the program which's using files on the FS, it reads > and writes very small amounts of data from random places on a set of > files (which are reasonably large). Then programs themselves are running > at either real time class or normal class. > > The bug triggers when I exit the program (which are all of similar nature). > > I tried to reproduce this issue by doing random write using the 'seeker' > tool, but it didn't trigger. So it triggers specifically on existing the > program. > > You may like to install the Bitcoin qt wallet from your repositories > (maybe it's reproducible with bitcoind client also) and after a day or 2 > of running with the above nilfs_cleanerd, try exiting the program. You > may trigger the bug. Great. Thank you. I'll try to reproduce the issue. One more question. Do you use this file system as rootfs or not? I suppose that it's not rootfs file system, as I remember your previous description of the issue. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
