linux-ext4 - Re: Use of resize2fs for enabling 64-bit inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Apr 2015 11:58:49 -0700
From:	"Darrick J. Wong" <darrick.wong@...cle.com>
To:	Jan Kara <jack@...e.cz>
Cc:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: Use of resize2fs for enabling 64-bit inodes

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.

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?

> 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?

--D

> 
> 								Honza
> 
> -- 
> Jan Kara <jack@...e.cz>
> SUSE Labs, CR
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html