I was flipping through the code recently and noticed that we still have
the double whammy of allocating dir entry positions with
parent_dir->counter++ and that weird setting of f_pos to 2^31-1.
So after enough creates (and deletes :)) in a directory we end up with
an entry item whose key is past that value. f_pos gets rewound instead
of being set to that magical EOF. readdir() gets stuck returning the
entries after INT_MAX over and over (just one in this strace):
getdents(3, {{d_ino=257, d_off=2147483647, d_reclen=32, d_name="file-54"}}, 32768) = 32
getdents(3, {{d_ino=257, d_off=2147483647, d_reclen=32, d_name="file-54"}}, 32768) = 32
It took around 10 hours on a workstationy box over here to reproduce
this with createmany.c from the lustre tests ("./createmany -m f- -u f-
0x8000000" mknod()s and unlink()s 2^31 files), but that's tedious. It's
easier to force initialization of index_cnt in the kernel to test
things.
1) The fundamental fix is to re-use deleted entry positions. Do we add
another cache to index unlinked positions? Do we add an unreliable
best-effort walk of the tree looking for holes in the key space? At the
very least test index_cnt in unlink to get the basically useless
index_cnt--? :)
2) Regardless of that, we have to deal with existing entry items with
giant keys. If for no other reason than big jerks making corrupt images
and leaving them on usb keys in Josef's driveway. Should we drop the
silly INT_MAX setting for 64bit callers and return -EOVERFLOW for 32bit
callers? (That'd be gross, but not unheard of. ext4 has grown htree
behaviour that depends on compat detection: see its is_32bit_api()
callers.)
I can make up some fixes but I'd love to hear strong opinions first, if
anyone's got 'em :).
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
