linux-ext4 - Re: [PATCH] ext3: skip orphan cleanup on rocompat fs

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:	Mon, 28 Feb 2011 13:22:58 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Rogier Wolff <R.E.Wolff@...wizard.nl>
Cc:	Amir Goldstein <amir73il@...il.com>, Jan Kara <jack@...e.cz>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] ext3: skip orphan cleanup on rocompat fs

On Mon, Feb 28, 2011 at 11:14:55AM +0100, Rogier Wolff wrote:
> If the cleanup/fixup is really neccesary, do so in in-core buffers of
> the filesystem. Write the infrastructure that allows us to have dirty
> buffers that MAY NOT (yet?!?) be written to the device. This will also
> solve the problem of journal recovery on readonly mount of a root
> filesystem. when it has been fscked, and it's remounted rw, we can
> remove the ban on the writeback of the dirty buffers.

That would be an interesting and useful thing to add, but it's not a
trivial change.  There is the risk that if the journal is very large,
and system memory is very, that there might not be enough memory to
hold all of the dirty buffers (or it might handicap the machine).
That shouldn't be an issue on reasonably configured machines, but as
we know, not all file servers are reasonably configured (see previous
discussions about tdb :-)

If someone want to work on this as a project, that would be great, but
to be honest it's not high on my priority list at the moment.

      	     	      	      	 	  - 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