From: Theodore Tso <tytso@mit.edu>
To: Andreas Dilger <adilger@sun.com>
Cc: Wei Yongjun <yjwei@cn.fujitsu.com>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: Fix to read empty directory blocks correctly in 64k blocksize filesystems
Date: Wed, 11 Feb 2009 10:15:47 -0500 [thread overview]
Message-ID: <20090211151547.GK29220@mini-me.lan> (raw)
In-Reply-To: <20090211054816.GP3209@webber.adilger.int>
On Wed, Feb 11, 2009 at 12:48:16AM -0500, Andreas Dilger wrote:
>
> I'm glad that the MAX_REC_LEN value is being kept, because "0" is
> too easily hit due to disk corruption.
>
I'm not too worried about that, actually. If there is a disk
corruption, we will detect it easily enough no matter which encoding
we use. I am thinking though that neither 65535 nor 0 is the best way
of encoding 65536. In fact, I would suggest the encoding 0x01.
Specifically, I suggest:
(rec_len & 65532) | ((rec_len >> 16) & 3)
This encodes valid rec_len values in the range 0 through 2**18-4, and
allows for maximum block sizes of up to 256k. To retain backwards
compatibility, and to allow for a 256k blocksize, we can have a
special case where a rec_len of either 0 or 65535 means
EXT4_BLOCK_SIZE(s).
It's unlikely we'll see VM pages of up to 256k, but at some point we
might find that the Linux VM has been enhanced to support filesystem
block sizes > than the VM page size, at which point it might be useful
for some applications to allow very large filesystem block sizes.
- Ted
next prev parent reply other threads:[~2009-02-11 15:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 3:56 [PATCH] ext4: Fix to read empty directory blocks correctly in 64k blocksize filesystems Wei Yongjun
2009-02-10 8:26 ` [PATCHv2] ext4: Fix support for empty directory blocks " Wei Yongjun
2009-02-10 15:20 ` [PATCH] ext4: Fix to read empty directory blocks correctly " Theodore Tso
2009-02-11 5:48 ` Andreas Dilger
2009-02-11 15:15 ` Theodore Tso [this message]
2009-02-12 6:42 ` Wei Yongjun
2009-02-15 4:07 ` Theodore Tso
2009-02-16 23:32 ` Andreas Dilger
2009-02-17 0:05 ` Theodore Tso
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=20090211151547.GK29220@mini-me.lan \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=yjwei@cn.fujitsu.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.