Hi Connie, Urs, On Wed, 15 Nov 2006, Connie Sieh wrote: > On Wed, 15 Nov 2006, Urs Beyerle wrote: > > > Hi, > > > > As written in ftp://ftp.scientificlinux.org/linux/scientific/44/i386/contrib/RPMS/xfs/README , XFS > > is not recommended on SL4 32bit kernels. > > > > What kind of problems where observed? > > Some problems are because the Upstream Vendor kernel, which we of course > use, has 4k kernel stacks vs a more common 8k kernel stack. > > Problems with layers of filesystems, lvm for instance. > > > Is somebody working on a solution, which does not require to recompile the standard SL4 kernel? > > I do not think that anyone is working on a solution. I talked to a > developer from SGI while I was at "Linux Symposium". His answer was to > just use 64 bit. Alas, this only solves the "4k stacks" problem, while there's at least one more: The "possible memory allocation deadlock" one. I recently hit this while filling two filesystems on a system with ISO images, for burn-in and to verfiy data integrity by checksumming the images in a later read pass. Writing the files went smoothly for hours, at 6-700 MB/s, but when the smaller filesystem got filled up things ground to a halt, no request to an XFS filesystem on the host would complete anymore, and the only way to recover was rebooting the system. SL4.4, kernel 2.6.9-42.0.3.ELsmp, x86_64. A faster and quite reliable way to trigger this problem seems to be to run iozone in mmap mode. XFS is much faster for some workloads (especially: deletion of large files), but it's just not as reliable as ext2/3 at least on SL. As much as I'd like to see TUV providing and supporting it, I'm afraid their decision not to include it is quite reasonable. I think XFS code was rewritten to get around the 4k stack problem a while ago, and to alleviate the memory allocation deadlock problem recently. But I'm not aware of any way to use the new codebase with TUV's EL3/4 kernels. Cheers, Stephan -- Stephan Wiesand DESY - DV - Platanenallee 6 15738 Zeuthen, Germany