linux-ext4 - 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-next>] [day] [month] [year] [list]

Message-ID: <20150417161809.GA27500@quack.suse.cz>
Date:	Fri, 17 Apr 2015 18:18:09 +0200
From:	Jan Kara <jack@...e.cz>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Use of resize2fs for enabling 64-bit inodes

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

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?

								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