Re: [reiserfs-list] Some obscure messages with postfix (20010228pl03-5) and probably reiser-fs(3.6.25)
On Mon, Jul 02, 2001 at 04:42:41AM +0200, Jörg Spilker wrote: Hello, here a part of my syslog: Jun 30 11:33:04 daolin postfix/smtpd[2310]: 1F1101536: client=localhost[127.0.0.1] Jun 30 11:33:04 daolin postfix/cleanup[2193]: 1F1101536: message-id=[EMAIL PROTECTED] Jun 30 11:33:04 daolin kernel: vs-9020: reiserfs_readdir things are moving under hands. Researching.. Jun 30 11:33:04 daolin postfix/qmgr[1566]: fatal: scan_dir_push: open directory incoming/6/7/?: No such file or directory Jun 30 11:33:04 daolin ip-up: reading message 29 of 31 (2988 octets) .. flushed i found these kind of messages typically 1-2 times a day in my logs. I'm not sure if the reiserfs message has anything to do with the postfix message. The appear as a pair everytime. A reiserfsck on my var partition (which is an LVM device) doesn't show any problems. May be a LVM problem ? I have been running Postfix on reiserfs for weeks without any single warning from ReiserFS or errors from Postfix. Stephane
Re: [reiserfs-list] Some obscure messages with postfix (20010228pl03-5) and probably reiser-fs(3.6.25)
Hi Jörg Spilker wrote: Hello, here a part of my syslog: Jun 30 11:33:04 daolin postfix/smtpd[2310]: 1F1101536: client=localhost[127.0.0.1] Jun 30 11:33:04 daolin postfix/cleanup[2193]: 1F1101536: message-id=[EMAIL PROTECTED] Jun 30 11:33:04 daolin kernel: vs-9020: reiserfs_readdir things are moving under hands. Researching.. Jun 30 11:33:04 daolin postfix/qmgr[1566]: fatal: scan_dir_push: open directory incoming/6/7/?: No such file or directory Do you have any idea abour what are file name lengths of files postfix uses? Are they longer than 31 chars? Thanks, vs Jun 30 11:33:04 daolin ip-up: reading message 29 of 31 (2988 octets) .. flushed i found these kind of messages typically 1-2 times a day in my logs. I'm not sure if the reiserfs message has anything to do with the postfix message. The appear as a pair everytime. A reiserfsck on my var partition (which is an LVM device) doesn't show any problems. Greetings, Joerg
Re: [reiserfs-list] CPU useage of ReiserFS
On Saturday 30 June 2001 20:29, Jens Benecke wrote: I just had a, er, 'lively' discussion with someone claiming ReiserFS is crap because it hogs even the fastest CPU too much, and it uses 4x as much processing power to do metadata operations, and in general is slower because of the journal. My benchmarks don't reflect this, especially on current hardware (ATA-66 and ATA-100 disks on VIA chipsets). While I agree that the journal does create an additional overhead, I'd like to know if the CPU overhead is really that much. I've seen your benchmarks on the web site but they don't say anything about CPU useage. I agree with Craig, I have one thing to add that Craig missed. Every 12 to 24 months CPU speed doubles. Now 1.4GHz CPUs with advanced cache and memory architectures are common while in 1990 20MHz CPUs without any caches were where it was at. Hard drive speed increases much more slowly. Now typical seek times are around 5ms and transfer rates are 35MB/s. In 1990 seek times were around 24ms and transfer rates were around 1MB/s. For future scalability a file system that uses lots of CPU time may be better than a file system that uses lots of disk access. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
[reiserfs-list] Re: file attributes problem
Thank you for the information. I am forwarding this to the list. Andreas Steinmetz writes: Hi, just saw your post in the reiserfs list (I'm not subscribed) about LIDS compatability. I must say that as LIDS works at the VFS layer it works well in combination with reiserfs, at least for the 2.2 series kernels I'm using right now. There is no need to have init drop capabilities when you use LIDS, LIDS does this already. The nice feature about LIDS is that you can grant processes (a script is a process in this context) capabilities with a defineable inheritabce depth. Thus e.g. a well defined and LIDS secured startup script may grant some process capabilities through inheritance where the process when started from any other context doesn't have the capabilities. This allows for fine grained system security. Nikita.
[reiserfs-list] Problem with reiserfs 2.4.5 (bug in journal.c)
Hello all. I'm using reiserfs on a a SuSE 7.1 machine. I've upgraded the kernel to 2.4.5. Seems to work pretty well. I do have some issues. When I shutdown, too often there seems to be a problem with unmounting the partitions. Last night, when I shut down, I got this: journal_begin called without kernel lock held. Kernel BUG at journal.c: 423! or very close. Then the kernel oopsed. Not good! Should I be using a different version of the kernel or apply a patch for reiserfs? Thanks!
Re: [reiserfs-list] Problem with reiserfs 2.4.5 (bug in journal.c)
TRHello all. I'm using reiserfs on a a SuSE 7.1 machine. I've upgraded TR the kernel to 2.4.5. Seems to work pretty well. I do have some issues. TR When I shutdown, too often there seems to be a problem with unmounting TR the partitions. TRLast night, when I shut down, I got this: TR journal_begin called without kernel lock held. Kernel BUG at journal.c: TR 423! TR or very close. Then the kernel oopsed. TRNot good! Should I be using a different version of the kernel or apply a TR patch for reiserfs? Thanks! It is a known problem. http://ftp.namesys.com/pub/reiserfs-for-2.4/linux-2.4.5-reiserfs-umount-fix.patch -- Thanks, Alex.
Re: [reiserfs-list] Problem with reiserfs 2.4.5 (bug in journal.c)
Timothy Reaves writes: Hello all. I'm using reiserfs on a a SuSE 7.1 machine. I've upgraded the kernel to 2.4.5. Seems to work pretty well. I do have some issues. When I shutdown, too often there seems to be a problem with unmounting the partitions. Last night, when I shut down, I got this: journal_begin called without kernel lock held. Kernel BUG at journal.c: 423! or very close. Then the kernel oopsed. Have you applied umount-fix patch? ftp://ftp.namesys.com/pub/reiserfs-for-2.4/linux-2.4.5-reiserfs-umount-fix.patch Not good! Should I be using a different version of the kernel or apply a patch for reiserfs? Thanks! Nikita.
