On Tuesday 21 October 2014 at 20:01:55, Edward Shishkin wrote: > On 10/21/2014 06:42 PM, Ivan Shapovalov wrote: > > On Tuesday 21 October 2014 at 18:33:11, Edward Shishkin wrote: > >> On 10/21/2014 06:23 PM, Ivan Shapovalov wrote: > >>> On Tuesday 21 October 2014 at 18:21:56, Edward Shishkin wrote: > >>>> [...] > >>>> > >>>> Sorry, but I don't see any explanation. > >>> "given a filesystem with (5% + eps) free space left, not using the reserved > >>> space will result in trimming of (eps) blocks at a time." > >>> > >> > >> This is something that I am not able to parse :) > >> > >> Ok, it is clear, why we can not fail with -ENOSPC when trying to delete > >> a file from a full partition, yes? > > Sure. Please note that making reiser4_trim_fs's allocations BA_RESERVED will > > not hinder this: delete_mutex is there for a reason. > > > Sure, and this is the reason, because when I hear "let's take a mutex", > I start to feel bad :) > > > > > >> I want to see explanation, why FITRIM ioclt can not finish the work when > >> there is no free space on disk. > > Suppose we do not use reserved space for reiser4_trim_fs's allocations. > > Let's analyze those two cases: > > > > 1. There is <= 5% free space on disk. > > Initial grabbing fails, nothing can be trimmed. > > This is wrong. > > > > 2. There is 5% + X (where X is some small number) free space on disk. > > We can grab only X blocks at a time, so a total of ((SIZE * 5% / X) + 1) > > transactions will be created. BTW, if X < erase unit, nothing can be trimmed. > > This is ineffective. > > > > Hope this makes sense. > > > This is already much better, thanks! > Then I should say that the whole idea to reserve % of free space is > incorrect. > Try to reserve 1% of total partition size with BA_CAN_COMMIT for an > iteration. > If it fails, then try to reserve 1 block with BA_CAN_COMMIT. Hm? Both described cases are still broken. In #1 (free space <= 5%) nothing changes; reiser4_trim_fs will never be able to do its task without using reserved space. In updated #2 (5% < free space < 6%), a transaction per every block (!) will be created, and none of them will trim anything (1 block < erase unit). Have I misunderstood you? -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part.
