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
|
