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