linux-ext4 - Re: [PATCH] Get rid of extents mount option

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:	Sat, 7 Oct 2006 13:20:27 -0400
From:	Theodore Tso <tytso@....edu>
To:	Dave Kleikamp <shaggy@...tin.ibm.com>
Cc:	Andrew Morton <akpm@...l.org>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] Get rid of extents mount option - try 2

On Sat, Oct 07, 2006 at 10:53:47AM -0500, Dave Kleikamp wrote:
> I noticed we are missing Documentation/filesystems/ext4.txt.  Over the
> weekend, I'll try to put something together with instructions on getting
> the right version of e2fsprogs, etc.

For now just say to grab the latest from:

ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs-interim

We'll have to upgrade it once we have a released version of e2fsprogs
that supports extents (although by then we may need e2fsprogs-interim
for 48 or 64 bit extents, or whatever next new feature we're working
on :-).

> I guess this would be useful to turn the feature off immediately after
> turning it on, but with the removal of the extents mount option, we no
> longer have the ability to make old-style files once the feature is
> turned on.  So it's unlikely that you'd be able to turn the feature off
> once a file system has been used.

Well, we could have tune2fs scan all inodes, and have it allocate
triple/double/indirect blocks to replace the extent tree, at some
point.  The count would allow us to turn it off immediately after
turning it on without forcing the full scan of all inodes.  Maybe it's
not worth the overhead though.  

> Also, do we update the superblock in every transaction that creates or
> deletes a file?  Otherwise, how do we guarantee the count is accurate
> after replaying the journal?

Yes, we do.  The number of free inodes has to be kept up-to-date,
after all, so the superblock is marked dirty and as being part of the
transaction.

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