On Friday 01 August 2014 at 00:03:58, Edward Shishkin wrote: > grab_space() is only for processes which require disk space (including > wandered blocks). For example ->read() modifies a superblock (atime), > which should be written via journal. So ->read() grab 1 block, etc. > > As to FITRIM ioctl: I don't think it needs to reserve disk space at all: > it will > issue only discard requests. > > Edward. OK. But it still needs to allocate space (even if just to deallocate it shortly), which means that someone could get ENOSPC while the discard is in progress, and this ENOSPC will come from the allocator itself. Do you have any ideas on how to do it gracefully? Thanks, -- Ivan Shapovalov / intelfx / > > > On 07/31/2014 10:47 PM, Ivan Shapovalov wrote: > > ...and here is volume 2 of my neverending question series :) > > > > A stub ioctl, placed as I described, seems to work and log a warning each time > > I invoke `fstrim` on anything mounted. > > > > Now on to space allocation. This seems pretty easy in the first approximation: > > reiser4_alloc_blocks_bitmap() seems to do what's needed, finding the nearest > > free extent, not the biggest one. So we could just call reiser4_alloc_blocks() > > plus reiser4_dealloc_blocks(BA_DEFER) repeatedly, while allocations succeed. > > > > However, I suppose we need to grab all free space before proceeding. There is > > no primitive for grabbing all free space, so we need to read block counters, > > calculate amount of space to grab and then call reiser4_grab_reserved() > > (as we want to allocate everything, including the reserved space. This creates > > two problems (as I see it): > > - there is a race between reading block counters (under sb spinlock) and > > performing the grab (which takes the spinlock on its own); > > - if anything will try to grab space during discarding, it will get an ENOSPC, > > while it's better to make the process wait until discarding is completed. > > > > I'm not sure whether the last problem really exists (there is BA_CAN_COMMIT, > > but I don't know whether is it used consistently where possible). > > > > Could you explain these things? > > > > Thanks, >
Attachment:
signature.asc
Description: This is a digitally signed message part.
