Linux application bugs

[Missing Ghost]

Hi,
I'm a linux user since a few months.
I would like to know, what are you supposed to do when you receive stuff like
THIS
Is there some sort of thing I should do or what? Can it cause any problems?
What does it mean?

 

[Nothinman]

That one in particular means you ran out of memory, it's not really a bug in anything.

smbd: page allocation failure. order:4, mode:0xd0

It means that it tried to allocate 5 contiguous pages (order 0 is 1 page, order 1 is 2 pages, etc) and failed. The rest of it is the function backtrace to tell you how you got to the failure in __alloc_pages.

 

[Missing Ghost]

hum...so what should I do about it?

 

[Nothinman]

Depends, there's no cut and dry answer that covers all out of memory situations, especially since something wanted a physically contiguous allocation that large. Adding more memory may or may not help. I'm not 100% sure but it looks like it was XFS that wanted that chunk of memory and if that's true adding more memory will likely just postpone the problem since memory fragmentation will eventually cause large allocations like that to fail no matter how much memory you have. If it's even something that's recurring, have you only seen it the one time and did it even cause a problem that time?

 

[bersl2]

Ether add more memory, or use programs that use less memory. What kind of machine are we talking about here?

 

[Nothinman]

Ether add more memory, or use programs that use less memory. What kind of machine are we talking about here?

Adding more memory will only postpone the problem and probably not even very much since Linux will just use the extra memory for file caching. The problem wasn't so much an out of memory but an out of free physically contiguous memory. And the problem isn't in any userland program, smbd just got named because it's the process that did the syscall that eventually caused XFS to try to allocate that memory, XFS is the real culprit. And I'm using XFS on a handful of machines without any issues like this so I'm guessing that what happened here is a pretty rare case.

 

[drag]

Couldn't it be a kernel bug were the XFS driver isn't behaving correctly?

Google'ng around for this it shows that many times people just go 'it's a kernel bug'.

If it's a rare thing I figure it's not a big deal. Maybe make sure that your swap is activated and present so the kernel can page out memory stuff?

If your using a older kernel maybe trying a new one will help. Or maybe ext3.

 

[xtknight]

I've used XFS on SMB and haven't had problems like this so I'm not sure. (Though I have had plenty of other trouble with SMB, just not memory allocation issues.) How big is your swap file? Which kernel and distro?

 

[Missing Ghost]

The message appears like 1 time by 1-2 hours, and appears at random times. I'm not out of memory, because the OS uses only 0% of the 2GB of swap space it could use.
The computer has not a lot of memory, only 256MB, but that should be enough. It's a dual P3 1gHz. Kernel is 2.6.8-3 686 SMP. Distro is Debian.
Top shows this about memory:
Mem: 256260k total, 249148k used, 7112k free, 1028k buffers
Swap: 1951888k total, 2920k used, 1948968k free, 87440k cached
Any more details could be useful?

 

[Nothinman]

The message appears like 1 time by 1-2 hours, and appears at random times. I'm not out of memory, because the OS uses only 0% of the 2GB of swap space it could use.
The computer has not a lot of memory, only 256MB, but that should be enough. It's a dual P3 1gHz. Kernel is 2.6.8-3 686 SMP. Distro is Debian.

No, you're not running out of memory but you are running out of large sections of contiguous free memory. Because of the way VM works physical memory gets fragmented very fast and anything wanting to allocate more than one page stands a chance of that failing.

But you never said whether or not you're noticing any problems? If not, I would say just ignore it cause I can't think of anything that you can do to help it anyway.

Actually you might be able to fix it by defragmenting your filesystem: http://oss.sgi.com/archives/xfs/2005-09/msg00185.html The message is kind of old, but it looks relevant. Run 'xfs_db -c frag -r /dev/whatever' to see how fragmented the filesystem is and you can use 'filefrag <filename>' to see how fragmented a particular file is.

 

[Missing Ghost]

ironmaiden:/var/log# xfs_db -c frag -r /dev/mapper/LVM-var
actual 41010, ideal 14585, fragmentation factor 64.44%
ironmaiden:/var/log# xfs_db -c frag -r /dev/mapper/LVM-usr
actual 13414, ideal 13384, fragmentation factor 0.22%
ironmaiden:/var/log# xfs_db -c frag -r /dev/mapper/LVM-home
actual 3816, ideal 3479, fragmentation factor 8.83%
ironmaiden:/var/log# xfs_db -c frag -r /dev/md0
actual 154399, ideal 35695, fragmentation factor 76.88%

Is that anything to worry about? And, is memory fragmentation really likely to be related with filesystem fragmentation?
If I were to defrag my filesystems, is there any package to install for that, or do I get it in the XFS-utils? Should I umount the filesystems to defrag them or can it be done at any time?

 

[Nothinman]

And, is memory fragmentation really likely to be related with filesystem fragmentation?

I didn't try and figure out how the XFS code works but the message I linked to is from an XFS developer so I'd have to give it some weight. And it would make sense if there had to be something in memory for each extent of a file and the more extents you have the more of those little structures in memory would be coming and going as you use the filesystem fragmenting memory.

If I were to defrag my filesystems, is there any package to install for that, or do I get it in the XFS-utils? Should I umount the filesystems to defrag them or can it be done at any time?

xfs_fsr is part of the xfsdump package and it has to be used on a mounted filesystem.

 

[Missing Ghost]

Thanks a lot! I'm definitely going to put this xfs_fsr into some cronjob.