On Thu, May 24, 2018 at 10:42:43AM +0200, Jan Kara wrote: > > Yes, it's more complexity but pinning is OTOH user visible API so that has > some maintenance overhead as well as we have to maintain it indefinitely. > And your hack with dumpe2fs works good enough (as much as hit's ugly) that I > don't think we need to hurry some half baked solutions... If the user-visible API is a mount option, it's really not that hard deprecate it later in favor of something which is done automatically via some kind of compressed in-memory pinning mechanism --- we would just turn the mount option into a no-op plus a print-once warning message saying it's no longer needed. Jan's design makes much more sense as the long-term direction --- and if the good folks at DDN are willing to code it, I would be greatly pleased. That being said, if they only want the short-term hack, my primary concern is code maintenance and complexity issue. If there is a simple for loop that calls the existing functions to load the block bitmap, and then pin them by bumping the ref count, I'm not going to object that much. What I didn't like about the inital patch was the large number of new code that duplicates existing functionality, since that's a code maintenance burden. I will say that if we use an rbtree of free block extents, we could probably use this instead of the buddy bitmaps, and the resulting code could probably do a better job finding free blocks and reducing fragmentation. So that's another reason to go down the patch suggested by Jan. Regards, - Ted
