That's my personal opinion, and I realize that some of the commercial
vendors may care about their insane customers' satisfaction, but I'm
simply not interested in insane users. If they have that much RAM (and
bought it a few years ago when a 64-bit CPU wasn't an option), they can't
be poor.
F
This is pretty much a vanilla kernel, with just one patch to work
around a deadlock problem in the reiserfs_file_write code that I
think isn't fixed.
http://lists.linuxcoding.com/kernel/2006-q1/msg32508.html
So that sounds like a reiserfs bug.
Yes, and it was definitely there still in 2.6.16.
Just an update to this, I've found some more information. I can now reliably
reproduce this lock up.
I was trying to remove a large number of files from a reiserfs partition
nohup rm -rf /var/spool/imap3/?/user/.migrated/*&
And just a second or two after I started that command, I got a message
I have a feeling this might be related back to this issue...
http://www.uwsg.iu.edu/hypermail/linux/kernel/0507.1/1518.html
As a reminder: we've been running a number of IBM x235 machines with 6G of
RAM with a 2.6.12.3 kernel fine for a couple of weeks now. Last night one of
the machines start
Sorry for the confusion, you're hitting the other mmap_sem -> transaction
lock
problem. This one should be solvable with an iget so we make sure not to
do
the final unlink until after the mmap sem is dropped.
Lets see what I can do...
Oh dang.
I thought this last crash after upgrading to
There is a much less complex solution that I've just recently gotten
working
in the SUSE kernel. If reiser3/ext3 don't log the inode during atime
updates, the problem goes away.
You can solve this now by mounting with -o noatime (although that might
not
play well with cyrus, not sure). My c
> We're also applying the attached patch. There's a bug in reiserfs that
> gets tickled by our huge MMAP usage (it's amazing what really busy
> Cyrus daemons can do to a server, ouch). It's fixed in generic_write,
> so we take the few percent performance hit for something that doesn't
> break!
> We recently tried upgrading one of the machines to the latest kernel
> (2.6.12.2) and it's died after about 24 hours. It seemed to end up in
> some
> weird state where we could ssh into it, and some commands worked (eg
> uptime)
> but process list related commands (ps) would just freeze up
As background, we've been using a relatively old kernel (2.6.4-mm2) on some
IBM x235 machines with 6G of RAM, umem cards, and serveraid storage. These
machines are under continuous heavy-ish load, load avg between about 1 and
5, with between 2500-3500 procs at all times, with several largish Rei
9 matches
Mail list logo
