linux-ext4 - Re: [PATCH, RFC] Add new "development flag" to the ext4 filesystem

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]

Message-ID: <20080128121600.GA14038@duck.suse.cz>
Date:	Mon, 28 Jan 2008 13:16:01 +0100
From:	Jan Kara <jack@...e.cz>
To:	Theodore Tso <tytso@....EDU>, Eric Sandeen <sandeen@...hat.com>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH, RFC] Add new "development flag" to the ext4 filesystem

On Fri 25-01-08 03:50:04, Andreas Dilger wrote:
> On Jan 25, 2008  11:05 +0100, Jan Kara wrote:
> > For example ext2 on fsync() just sync's a single inode
> > (and has to use private_list to track metadata buffers associated with
> > the inode) while ext3 flushes the whole journal.
> 
> As for fsync(), we definitely need to preserve correct behaviour for the
> file itself, but there isn't a requirement that ext2 behave exactly like
> ext3 (it of course cannot).  In the proposed ext4-mount-unjournaled-ext2
> case, the superblock would be marked dirty as it is today and an e2fsck
> would need to be run at boot time.  That is fine so long as the fsync()
> will cause the one file's data to be on disk before it returns.
  Well, you have to also make sure that all indirect blocks are on disk
before fsync() returns. Otherwise there's not much point in the fact that
data itself reached the disk. And for that you need something like
private_list.

> > In ext2, directory
> > handling code is quite different. ext2 works in page cache of the
> > directory while ext3 uses page cache of the underlying device via buffer
> > heads - at least this second thing would be more or less mechanical
> > thing to change and would make sence (we wouldn't have to reimplement
> > readahead in ext3 directory handling code as we do now). I've looked at
> > it once but then more urgent things came and ... you know it.
> 
> I don't think it is a requirement that ext3 mounting a filesystem without
> a journal has to use page cache for directories.  I wouldn't object to
> that being fixed.  It definitely isn't a requirement for this to work,
> just an implementation difference.
  Yes, of course. I just wanted to point out that ext2 isn't a strict
subset of ext3 so there is some non-trivial work to be done before you can
safely mount ext2 as ext3-without-journal.

									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