Re: Reiser4 Upstream Git Repositories on GitHub

[Ivan Shapovalov <intelfx@intelfx.name>]

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

On 2016-09-29 at 17:07 +0200, Edward Shishkin wrote:
> 
> On 09/28/2016 11:50 PM, Ivan Shapovalov wrote:
> > On 2016-09-28 at 21:58 +0200, Edward Shishkin wrote:
> > > On 09/28/2016 05:03 PM, Ivan Shapovalov wrote:
> > > > On 2016-09-28 at 16:44 +0200, Edward Shishkin wrote:
> > > > > [...]
> > > > > 
> > > > > BTW, your fstrim-scanner is the first candidate to scrub ;)
> > > > > Actually, I think about a common multi-functional scanner,
> > > > > with 3
> > > > > modes:
> > > > > 1) discard only (handle only free blocks);
> > > > > 2) scrub only (handle only busy blocks);
> > > > > 3) combined (scan the whole partition; for free blocks call
> > > > > discard,
> > > > >        for busy ones call scrub).
> > > > > Any ideas?
> > > > > 
> > > > > Thanks,
> > > > > Edward.
> > > > > PS: We have an own ioctl number: 0xCD inherited from
> > > > > ReiserFS(v3).
> > > > 
> > > > I still have to finish the erase unit detection (which has
> > > > completely
> > > > stalled) to merge all this work. Moreover:
> > > > 
> > > > For the fstrim, we have dropped all locking and serialization
> > > > issues
> > > > and declared that fstrim is best-effort: if it misses some
> > > > blocks
> > > > due
> > > > to concurrent transactions allocating and freeing blocks, it
> > > > doesn't
> > > > matter.
> > > > 
> > > > For the scrub, this won't fly...
> > > 
> > > Indeed, the requirements to fstrim and scrub are different,
> > > but, as I remember, the last decision was to not miss:
> > > http://marc.info/?l=reiserfs-devel&m=141391883022745&w=2
> > > so everything will fly just perfectly..
> > > 
> > > Edward.
> > 
> > This is different thing, it's about grabbing space in bigger
> > chunks...
> > If a concurrent transaction allocates some space and frees some
> > space,
> > we don't care, because it will then be discarded "online".
> > 
> > But in case of the scrub, how do we protect from the storage tree
> > changing right beneath us?
> 
> Yup, it seems that the idea of common scanner is dead.
> It should be an independent tool. I think, we need to simply scan the
> storage tree, do whatever is needed for each node, and make it dirty.
> 
> Edward.

How does it work in btrfs? They have their "allocation group"
equivalents ("chunks", IIRC), so I suppose they just walk them
sequentially and lock each one completely for processing?

-- 
Ivan Shapovalov / intelfx /

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