On Fri 17-04-15 11:58:49, Darrick J. Wong wrote: > On Fri, Apr 17, 2015 at 06:18:09PM +0200, Jan Kara wrote: > > Hello, > > > > I've noticed that you've implemented enabling 64-bit mode of a filesystem > > in resize2fs. That is quite logical from the implementation point of view > > however IMHO it doesn't make too much sense from user point of view. I'd > > I agree it's awkward; right now there's a bandaid that tune2fs -O 64bit will > tell you how to run resize2fs... > > > rather expect that functionality to be in tune2fs. So shouldn't we rather > > abstract the code into a separate library that would be linked to both > > resize2fs and tune2fs? Alternatively we could just make tune2fs call > > resize2fs with appropriate options. > > ...but I've wondered myself why we have two utilities for transforming ext4 > filesystems. A library would probably be cleaner, but it wouldn't be too > hard to change existing tune2fs functionality to run (instead of telling > the user how to run) resize2fs for 64bit conversion. Yes. The only catch is that executing resize2fs needn't always execute the right one (e.g. in a system where you just test new version of e2fsprogs in the source directory). > I guess one could combine the two into a frankentool that uses argv[0] to > figure out which half of itself to run, with the tune2fs side being able > to call into the resize2fs side. But maybe it's time for the 'high level > e2fs library' that Ted has been talking about for a while? Yeah, highlevel e2fsprogs library seems as a nice idea and it would solve the problem. It's quite some work though... > > I'm asking because I'm now looking into implementing increasing number of > > reserved inodes. For that we may need to move some inodes and it would be > > natural to use code from resize2fs for that. But adding that as an option > > to resize2fs is just unintuitive from user point of view so I'd like to > > have some concensus on how we do this... Darrick, Ted, any opinion? > > What do you think of the thread "e2fsprogs: reserve more special inodes" from a > month or so ago? Ah, I've missed that one. From a first look it looks OK. It seems Konstantin did the work I wanted to do already :) So it's mostly about creating a sane user interface. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
