Bug#685407: ext4 dir_index + nfs duplicate cookies problem with large dovecot maildirs
 

Hi again,

Jonathan Nieder wrote:

> Hi kernel team,
[...]
> Please consider the attached patch for the sid branch of the packaging
> repo. It applies the five aforementioned patches from upstream:
>
> 6a8a13e03861 fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash
> d1f5273e9adb ext4: return 32/64-bit dir name hash according to usage type
> 999448a8c020 nfsd: rename 'int access' to 'int may_flags' in nfsd_open
> 06effdbb49af nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)
> d7dab39b6e16 ext3: return 32/64-bit dir name hash according to usage
> type
>
> which make NFSv3/4 use 64-bit hashes as readdir cookies instead of
> crippling itself for the sake of NFSv2 which only supports 32-bit
> cookies. The most interesting of these (patches #2 and #5) are
> unfortunately a bit too big for the letter of the upstream stable
> rules, but the patches are straightforward, make sense, and are well
> tested.

Ping. Do you think these could work for stable@? If not, could they
make sense for wheezy anyway?

Even if I cheat by stripping out some comments and such, patch #2 is
257 lines including context and diff headers, but semantically the
patches are very clear and seem safe and sensible.

Thanks,
Jonathan


--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/20121009040926.GA8442@elie.Belkin

Bug#685407: ext4 dir_index + nfs duplicate cookies problem with large dovecot maildirs
 

Jonathan Nieder <jrnieder@gmail.com> 2012-10-08 21:09:

Hi again,

Jonathan Nieder wrote:


Hi kernel team,

[...]

Please consider the attached patch for the sid branch of the packaging
repo. It applies the five aforementioned patches from upstream:

6a8a13e03861 fs: add new FMODE flags: FMODE_32bithash and FMODE_64bithash
d1f5273e9adb ext4: return 32/64-bit dir name hash according to usage type
999448a8c020 nfsd: rename 'int access' to 'int may_flags' in nfsd_open
06effdbb49af nfsd: vfs_llseek() with 32 or 64 bit offsets (hashes)
d7dab39b6e16 ext3: return 32/64-bit dir name hash according to usage
type

which make NFSv3/4 use 64-bit hashes as readdir cookies instead of
crippling itself for the sake of NFSv2 which only supports 32-bit
cookies. The most interesting of these (patches #2 and #5) are
unfortunately a bit too big for the letter of the upstream stable
rules, but the patches are straightforward, make sense, and are well
tested.


Ping. Do you think these could work for stable@? If not, could they
make sense for wheezy anyway?

Even if I cheat by stripping out some comments and such, patch #2 is
257 lines including context and diff headers, but semantically the
patches are very clear and seem safe and sensible.

Thanks,
Jonathan


I think these are a must for wheezy. It's a fairly major flaw in my
opinion.


I would also really like to see this in stable, since wheezy felt a long
way off the last time I tried it, and there's some nice benefits from
the backports kernel that we like, though we can probably continue to
limp along on the original 2.6.32 kernel on those affected machines for
a bit.


</cent></cent>

Brian