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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
