frequent kernel BUG and lockups - 2.6.39 + xfs_fsr

[Michael Monnerie]

On Montag, 8. August 2011 Marc Lehmann wrote:

First of all, please calm down. Getting personal is not bringing us 
anywhere.

> > On older kernels (2.6.34 and earlier) I can corrupt filesystems
> > using xfs-fsr just by crafting a file with a specific layout.
[snip]
> > IOWs, xfs_fsr on old kernels is actually dangerous and should not
> > be used if you
> 
> Logic error - if I can corrupt an XFS without special privileges then
> this is not a problem with xfs_fsr, but simply a kernel bug in the
> xfs code. And a rather big one, one step below a remote exploit.

No, it's not a kernel bug because as long as you don't use xfs_fsr, 
nothing will ever happen.

And the rest of the mail goes into lots of details which look very 
strange to me. I've double checked with our servers, which generally 
have these xfs mount options: 
(rw,nodiratime,relatime,logbufs=8,logbsize=256k,attr2,barrier,largeio,swalloc)
and sometimes also 
,allocsize=64m
and I can't find evidence for fragmentation that would be harmful.Yes 
they are fragmented, of course. When you write to ~500 log files a time 
via syslog (as we do on some servers), there must be some fragmentation. 
The allocsize option helps a lot there. I looked at one webserver access 
log, it has 640MB with 99 fragments, but that's not a lot. On our 
Spamgate I see 250MB logs with 374 fragments. That's a bit more, but we 
don't use the allocsize option there, which I changed now that I looked 
at it ;-)

But your words
> If XFS is bad at append-only workloads, which is the most common type
> of workload, then XFS fails to be very relevant for the real world.

may be valid for your world, not mine. We have webservers, fileservers 
and database servers, all of which are not really append style, but more 
delete-and-recreate. Well, db-servers are rather exceptional here.

Append style is mostly for log files, at least on our servers.

But if the numbers for fragmentation on your servers are true, you must 
have a very good test case for fragmentation prevention. Therefore it 
could be really interesting if you could grab what Dave Chinner asked 
for:
> If you think it's a good workload that we should use, then capture a
> typical directory profile and the IO/filesystem operations made on a
> busy server for an hour or so. Then write a script to reproduce that
> directory structure and IO pattern.....

And maybe he could use it for optimizations. Is there any tool on Linux 
to record such I/O patterns? Would need to keep all metadata and data 
operations for a partition to be interesting.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110809/653bd8bc/attachment.sig>