linux-ext4 - Re: ext4 compat flag assignments

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: <200609290106.27852.ak@suse.de>
Date:	Fri, 29 Sep 2006 01:06:27 +0200
From:	Andi Kleen <ak@...e.de>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	Alexandre Ratchov <alexandre.ratchov@...l.net>,
	Theodore Ts'o <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: ext4 compat flag assignments


> Actually, there are several plans afoot in that direction already.
> Some of them need at least some help in the "finish up and get it
> into the kernel" department, some of them are just ideas previously
> discussed..

The important part right now is to just keep enough space in all 
structures that are being changed anyways.

> 
> One of the reason for Alexandre pushing the 64-bit inode/block counters
> into the "large" descriptor is because the 64-bit filesystem is already
> incompatible with a 32-bit filesystem so there is no extra harm, and this
> leaves space in the "original" group descriptor for checksums of the block
> and inode bitmaps.  The bitmap checksums are a critical single-point-of-
> failure, and having checksums allows the kernel to avoid cascading
> filesystem corruption even if it can't (yet) do anything about it.
> Having the checksums in the "original" group descriptor allows this
> feature to be used on both 32-bit and 64-bit filesystems.

Ok.

> No work has been done on this yet.  Getting checksums to be efficient
> depends on having a generic callback mechanism from the journal code
> to avoid repeated checksums on a block while it is being modified.

You can just do incremental checksumming which is very cheap. 

Or did you mean the flushing to disk of the checksum? If it's always in the same
object that would be free, but that is not possible for bitmaps at least.
But I guess the checksum write in the block descriptor 
could be done very lazily at least, perhaps keeping track on disk if invalid
checksums are expected or not.

> Finally, the extents format has the capability (though no code is implemented
> for this yet) to store a checksum in each index and extent block.  This
> would be done by reducing the count of allowed entries in the block and
> storing an ext3_extent_tail (checksum, inode+generation backpointer) as
> the last entry in the block.  No work has been done on this, but I've
> described the ext3_extent_tail a few times previously on this list.

Old style indirect blocks will need them too. My thinking was
to use another block for those (so a indirect block would be two nearby
blocks) 

Inodes need them, but with the inode extension that will be hopefully
not a problem to keep a few bytes for this.

And directories, which should be relatively easy to extend with
the current format.

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