From: Theodore Tso <tytso@MIT.EDU>
To: Andreas Dilger <adilger@sun.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH e2fsprogs-next] Fix extent flag validity tests in pass1 on big endian boxes.
Date: Mon, 24 Mar 2008 22:19:37 -0400 [thread overview]
Message-ID: <20080325021937.GE30110@mit.edu> (raw)
In-Reply-To: <20080325003250.GM2691@webber.adilger.int>
On Mon, Mar 24, 2008 at 06:32:51PM -0600, Andreas Dilger wrote:
> On Mar 24, 2008 17:13 -0500, Eric Sandeen wrote:
> > Extent data is shared with the i_block[] space in the inode,
> > but it is always swapped on access, not when the inode is read.
> >
> > In e2fsck/pass1.c we must be careful when checking validity
> > of the extents flag on the inode. If the flag was set when
> > the inode was read & swapped, then the extents data itself
> > (in ->i_block[]) was NOT swapped, so testing for a valid
> > extent header requires some swapping first. Then, if we
> > ultimately set the extents flag, all of i_block[] must be
> > re/un-swapped.
>
> This seems pretty awkward for any other users of the library. Having the
> i_block[] array NOT be swabbed if it is an extent file means that every
> place in the code which is accessing this array also needs to do the
> swabbing itself. This would break the abstraction that the in-memory
> inode is in host-endian order, and also forces every application to
> understand the difference between extent- and non-extent-mapped inodes,
> and the on-disk byte order. Ugh.
I did this design intentionally, because the *only* part of e2fsprogs
which is supposed to know about byte-swapping is lib/ext2fs/extents.c.
Well, at least normally unless EXTENTS_FL is wrongly set or unset. So
e2fsck needs to have some special case code to undo swapping
i_blocks[], but that's the only part of the library that will need to
deal with byte-swapping extents.
The reason why I did that is was because I didn't want to have a lot
of messy code in lib/ext2fs/swapfs.c that might need to change if we
needed to support new extents format (some of which might have more
complicated byte-swapping formats) in order to support 64-bit block
numbers, for example --- or, if we end up using a bit-packed more
compressible format so we can fit more extents into i_blocks[]. So
right now, by *design* the only place that needs to know about extents
formats is lib/ext2fs/extent.c.
- Ted
prev parent reply other threads:[~2008-03-25 2:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-24 22:13 [PATCH e2fsprogs-next] Fix extent flag validity tests in pass1 on big endian boxes Eric Sandeen
2008-03-25 0:32 ` Andreas Dilger
2008-03-25 0:56 ` Eric Sandeen
2008-03-25 2:19 ` Theodore Tso [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080325021937.GE30110@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.