Re: nilfs_clean_segments: segment construction failed. (err=-2)

[dE <de.techno-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 06/27/14 12:00, Vyacheslav Dubeyko wrote:
> 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.
>
>

No no... it's the data directory of the bitcoin-qt/bitcoind application 
(~/.bitcoin is a symlink to .bitcoin which is on a nilfs dir).

If you you see, a full bitcoin wallet is a stress test for nilfs cause 
it results in a HUGE number of garbage blocks.

Initially it's not going to be a challenge, but later on, as Bitcoin 
became more popular, the no. of  Bitcoin transactions dramatically 
increased, this increase the i/o on the device cause the wallet will 
verify each transaction as it downloads the blockchain (or old 
transactions).

Thanks for your corporation.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html