Eric Sandeen wrote:
The remaining issue may be xfs+4kstacks+complicated/deep IO stacks
on
x86. Honestly I've never much liked 4kstacks... layered filesystems
coming down the pipe (ecryptfs, unionfs) may well have trouble too.
I'd prefer to see the stack size boot-time selectable, maybe - or
perhaps disallow xfs (or issue a stern warning) on x86 boxes? (x86_64 &
ia64, with sane stack size, work fine in this regard).
I can confirm that xfs on 4KSTACKS over lvm is still a problem.
Basic functionality is fine, but I can't make it through all of xfsqa
w/o a stack overflow. Even just mounting with -o quota gets us pretty
close to the edge:
mount used greatest stack depth: 180 bytes left
I'll look at some of the bigger offenders if I have any spare time in
the evenings. It's the callchains, too though, not just the individual
functions that come into play.
0x0001b719 xfs_bmapi [xfs]: 276
0x00016dfa xfs_bmap_add_extent_delay_real [xfs]: 252
0x0003b4dc xfs_bulkstat [xfs]: 252
0x0004acb0 _xfs_trans_commit [xfs]: 240
0x00018c1e xfs_bmap_del_extent [xfs]: 236
0x000529a4 xfs_symlink [xfs]: 236
0x0002e3c0 xfs_growfs_data [xfs]: 228
0x0003a6fa xfs_iomap_write_delay [xfs]: 224
0x0001f282 xfs_bmbt_delrec [xfs]: 216
0x00020335 xfs_bmbt_split [xfs]: 212
0x00014d4b xfs_bmap_add_extent_unwritten_real [xfs]: 204
0x00028658 xfs_dir2_leaf_getdents [xfs]: 204
0x00019dc8 xfs_bunmapi [xfs]: 200
0x0001c89d xfs_getbmap [xfs]: 200
0x00046b97 xfs_mountfs [xfs]: 200
0x0004fc95 xfs_free_file_space [xfs]: 200
...
(OTOH, my FC6 mythbox has been just fine for a year on xfs over plain
partitions)
-Eric