[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080716130340.4a9646a5@ichigo>
Date: Wed, 16 Jul 2008 13:03:40 -0500
From: "Jose R. Santos" <jrs@...ibm.com>
To: Theodore Tso <tytso@....edu>
Cc: Goswin von Brederlow <goswin-v-b@....de>,
linux-ext4@...r.kernel.org
Subject: Re: [PATCH 15/15][e2fsprogs] 64-bit mke2fs cleanup
On Wed, 16 Jul 2008 13:18:24 -0400
Theodore Tso <tytso@....edu> wrote:
> On Wed, Jul 16, 2008 at 11:02:42AM -0500, Jose R. Santos wrote:
> > > PS: Should functions that chop off upper bits like that make sure they
> > > are 0?
> >
> > I think this is something that need to be cheched at fsck since having
> > these be non-zero on a non-64-bit FS should be pointing to file system
> > corruption. Not sure if its something that need to be done every time
> > we set a value on the lower bit only though.
>
> Well, to quote Postel's law (also known as the robustness principle):
> "Be conservative in what you do; be liberal in what you accept from
> others."
>
> This is a generalization from what Jon Postel wrote in RFC 793: "TCP
> implementations will follow a general principle of robustness: be
> conservative in what you do, be liberal in what you accept from
> others," but it applies here as well. So yes, the library code should
> clear the upper bits even if 64-bit feature flag is not set. However,
> we should not depend on the upper bits being zero if the 64-bit
> feature flag is not set.
>
> Does that make sense?
Set it; don't check it. Got it.
I'll just check for large descriptors instead of the 64-bit feature
flag. That should set the upper bit regardless of whether we use a
64bit fs or not.
>
> - Ted
>
-JRS
--
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
Powered by blists - more mailing lists