[reiserfs-list] reiserfs_read_inode2: dead inode read from disk
clm-6004: convert tail failed inode 2300597, error -122 clm-6004: convert tail failed inode 2300597, error -122 clm-6004: convert tail failed inode 2300597, error -122 clm-6004: convert tail failed inode 2300597, error -122 clm-6004: convert tail failed inode 4563293, error -122 vs-13075: reiserfs_read_inode2: dead inode read from disk [3547658 9266355 0x0 SD]. This is likely to be race with knfsd. Ignore vs-2100: add_save_link:search_by_key ([-1 9266355 0x1001 DIRECT]) returned 1 PAP-5660: reiserfs_do_truncate: wrong result -1 of search for [3547658 9266355 0xfff DIRECT] vs-5355: reiserfs_delete_solid_item: [3547658 9266355 0x0 SD] not found Is this a bug, or a warning ? This appear very seldom (approx. 1 time per month) on high filesystem load. (This is a NFS server, that share home directories to ~ 200 clients) Linux version 2.4.19-pre5 (root@home) (gcc version 2.95.3 20010315 (release)) #1 Sat Mar 30 14:26:43 MSK 2002 Reiserfs quota patch from ftp://ftp.suse.com/pub/people/mason/patches/reiserfs/quota-2.4 processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 10 cpu MHz : 1002.304 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1998.84 Module Size Used by nfs72640 0 (autoclean) nfsd 66800 8 (autoclean) lockd 48064 1 (autoclean) [nfs nfsd] sunrpc 59744 1 (autoclean) [nfs nfsd lockd] eepro100 17184 1 (autoclean)
Re: [reiserfs-list] reiserfs_read_inode2: dead inode read from disk
Hello! On Mon, Apr 29, 2002 at 03:13:35PM +0400, Basil A. Evseenko wrote: clm-6004: convert tail failed inode 2300597, error -122 This one failed because of disk quota exceed. Safe to ignore I assume. vs-13075: reiserfs_read_inode2: dead inode read from disk [3547658 9266355 0x0 SD]. This is likely to be race with knfsd. Ignore This one is safe, as it told you already. vs-2100: add_save_link:search_by_key ([-1 9266355 0x1001 DIRECT]) returned 1 PAP-5660: reiserfs_do_truncate: wrong result -1 of search for [3547658 9266355 0xfff DIRECT] vs-5355: reiserfs_delete_solid_item: [3547658 9266355 0x0 SD] not found This one seems to be some kind of race. We have yet to found a way to reproduce. But it's quite safe, anyway. Bye, Oleg
[reiserfs-list] fsync() Performance Issue
I'm wondering if anyone out there may have some suggestions on how to improve the performance of a system employing fsync(). I have to be able to guaranty that every write to my fileserver is on disk when the client has passed it to the server. Therefore, I have disabled write cache on the disk and issue an fsync() per file. I'm running 2.4.19-pre7, reiserfs 3.6.25, without additional patches. I have seen some discussions out here about various other speed-up patches and am wondering if I need to add these to 2.4.19-pre7? And what they are and where can I obtain said patches? Also, I'm wondering if there is another solution to syncing the data that is faster than fsync(). Testing, thusfar, has shown a large disparity between running with and without sync.Another idea is to explore another filesystem, but I'm not exactly excited by the other journaling filesystems out there at this time. All ideas will be greatly appreciated. Wayne EMC Corp Centera Engineering 4400 Computer Drive M/S F213 Westboro, MA01580 email: [EMAIL PROTECTED] voice: (508) 898-6564 pager: (888) 769-4578 (numeric) [EMAIL PROTECTED] (alpha) fax: (508) 898-6388 One man can make a difference, and every man should try. - JFK Wayne Berthiaume (E-mail).vcf
Re: [reiserfs-list] fsync() Performance Issue
On Fri, 26 Apr 2002 22:28, [EMAIL PROTECTED] wrote: It's interesting to note your email address and what it implies... I'm wondering if anyone out there may have some suggestions on how to improve the performance of a system employing fsync(). I have to be able to guaranty that every write to my fileserver is on disk when the client has passed it to the server. Therefore, I have disabled write cache on the disk and issue an fsync() per file. I'm running 2.4.19-pre7, reiserfs 3.6.25, without additional patches. I have seen some discussions out here about various other speed-up patches and am wondering if I need to add these to 2.4.19-pre7? And what they are and where can I obtain said patches? Also, I'm wondering if there is another solution to syncing the data that is faster than fsync(). Testing, thusfar, has shown a large disparity between running with and without sync.Another idea is to explore another filesystem, but I'm not exactly excited by the other journaling filesystems out there at this time. All ideas will be greatly appreciated. These issues have been discussed a few times, but not with any results as exciting as you might hope for. One which was mentioned was using fdatasync() instead of fsync(). One thing that has occurred to me (which has not been previously discussed as far as I recall) is the possibility for using sync() instead of fsync() if you can accumulate a number of files (and therefore replace many fsync()'s with one sync() ). -- If you send email to me or to a mailing list that I use which has 4 lines of legalistic junk at the end then you are specifically authorizing me to do whatever I wish with the message and all other messages from your domain, by posting the message you agree that your long legalistic sig is void.
Re: [reiserfs-list] fsync() Performance Issue
On Mon, 29 Apr 2002 18:20:18 +0200, Russell Coker [EMAIL PROTECTED] wrote: On Fri, 26 Apr 2002 22:28, [EMAIL PROTECTED] wrote: It's interesting to note your email address and what it implies... I'm wondering if anyone out there may have some suggestions on how to improve the performance of a system employing fsync(). I have to be able to guaranty that every write to my fileserver is on disk when the client has passed it to the server. Therefore, I have disabled write cache on the disk and issue an fsync() per file. I'm running 2.4.19-pre7, reiserfs 3.6.25, without additional patches. I have seen some discussions out here about various other speed-up patches and am wondering if I need to add these to 2.4.19-pre7? And what they are and where can I obtain said patches? Also, I'm wondering if there is another solution to syncing the data that is faster than fsync(). Testing, thusfar, has shown a large disparity between running with and without sync.Another idea is to explore another filesystem, but I'm not exactly excited by the other journaling filesystems out there at this time. All ideas will be greatly appreciated. These issues have been discussed a few times, but not with any results as exciting as you might hope for. One which was mentioned was using fdatasync() instead of fsync(). One thing that has occurred to me (which has not been previously discussed as far as I recall) is the possibility for using sync() instead of fsync() if you can accumulate a number of files (and therefore replace many fsync()'s with one sync() ). I can see write to file A write to file B write to file C sync might be faster than write to file A fsync A write to file B fsync B write to file C fsync C but is it possible for it to be faster than write to file A write to file B write to file C fsync A fsync B fsync C ? Toby Dickenson [EMAIL PROTECTED]
Re: [reiserfs-list] fsync() Performance Issue
On Mon, 2002-04-29 at 12:20, Russell Coker wrote: On Fri, 26 Apr 2002 22:28, [EMAIL PROTECTED] wrote: It's interesting to note your email address and what it implies... I'm wondering if anyone out there may have some suggestions on how to improve the performance of a system employing fsync(). I have to be able to guaranty that every write to my fileserver is on disk when the client has passed it to the server. Therefore, I have disabled write cache on the disk and issue an fsync() per file. I'm running 2.4.19-pre7, reiserfs 3.6.25, without additional patches. I have seen some discussions out here about various other speed-up patches and am wondering if I need to add these to 2.4.19-pre7? And what they are and where can I obtain said patches? Also, I'm wondering if there is another solution to syncing the data that is faster than fsync(). Testing, thusfar, has shown a large disparity between running with and without sync.Another idea is to explore another filesystem, but I'm not exactly excited by the other journaling filesystems out there at this time. All ideas will be greatly appreciated. These issues have been discussed a few times, but not with any results as exciting as you might hope for. One which was mentioned was using fdatasync() instead of fsync(). The speedup patches should help fsync some, since they make it much more likely a commit will be done without the journal lock held. If all the writes on the FS end up being done through fsync, the data logging patches might help a lot. These should be ready for broader testing this week. If you are using IDE drives, the write barrier patches are almost enough to allow you to turn on write caching safely. They make sure metadata triggers proper drive cache flushes, I can try to rig up something that will also trigger a cache flush on data syncs. -chris
Re: [reiserfs-list] fsync() Performance Issue
On Mon, 2002-04-29 at 12:32, Toby Dickenson wrote: One thing that has occurred to me (which has not been previously discussed as far as I recall) is the possibility for using sync() instead of fsync() if you can accumulate a number of files (and therefore replace many fsync()'s with one sync() ). I can see write to file A write to file B write to file C sync might be faster than write to file A fsync A write to file B fsync B write to file C fsync C Correct. but is it possible for it to be faster than write to file A write to file B write to file C fsync A fsync B fsync C It depends on the rest of the system. sync() goes through the big lru list for the whole box, and fsync() goes through the private list for just that inode. If you've got other devices or files with dirty data, case C that you presented will always be the fastest. For general use, I like this one the best, it is what the journal code is optimized for. If files A, B, and C are the only dirty things on the whole box, a single sync() will be slightly better, mostly due to reduced cpu time. -chris
Re: [reiserfs-list] fsync() Performance Issue
Toby Dickenson [EMAIL PROTECTED] writes: write to file A write to file B write to file C sync Be careful with this approach. Apart from syncing other processes' dirty data, sync() does not make the same guarantees as fsync() does. Barring write cache effects, fsync() only returns after all blocks are on disk. While I'm not sure if and if yes, which, Linux file systems are affected, but for portable applications, be aware that sync() may return prematurely (and is allowed to!). -- Matthias Andree
RE: [reiserfs-list] fsync() Performance Issue
Agreed, it would be better to sync to disk after multiple files rather than serially; however, in the interest of not being concerned of a power outage during the process, one of the reason the disk cache is disabled, the choice was to fsync() each write. -Original Message- From: Chris Mason [mailto:[EMAIL PROTECTED]] Sent: Monday, April 29, 2002 12:46 PM To: [EMAIL PROTECTED] Cc: Russell Coker; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [reiserfs-list] fsync() Performance Issue On Mon, 2002-04-29 at 12:32, Toby Dickenson wrote: One thing that has occurred to me (which has not been previously discussed as far as I recall) is the possibility for using sync() instead of fsync() if you can accumulate a number of files (and therefore replace many fsync()'s with one sync() ). I can see write to file A write to file B write to file C sync might be faster than write to file A fsync A write to file B fsync B write to file C fsync C Correct. but is it possible for it to be faster than write to file A write to file B write to file C fsync A fsync B fsync C It depends on the rest of the system. sync() goes through the big lru list for the whole box, and fsync() goes through the private list for just that inode. If you've got other devices or files with dirty data, case C that you presented will always be the fastest. For general use, I like this one the best, it is what the journal code is optimized for. If files A, B, and C are the only dirty things on the whole box, a single sync() will be slightly better, mostly due to reduced cpu time. -chris
Re: [reiserfs-list] fsync() Performance Issue
On Mon, 29 Apr 2002 19:56:59 +0200, Matthias Andree [EMAIL PROTECTED] said: Barring write cache effects, fsync() only returns after all blocks are on disk. While I'm not sure if and if yes, which, Linux file systems are affected, but for portable applications, be aware that sync() may return prematurely (and is allowed to!). And in fact is the reason for the old recipe: # sync # sync # sync # reboot On the older Vax 750-class machines, sync could return LONG before the blocks were all flushed - the second 2 sync's were so you were busy typing for several seconds while the disks whirred. Failure to understand the typing speed issue has lead at least one otherwise-clued author to recommend: # sync;sync;sync # reboot (the distinction being obvious if you think about when the shell reads the commands, and when it does the fork/exec for each case) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg05263/pgp0.pgp Description: PGP signature
Re: [reiserfs-list] fsync() Performance Issue
[EMAIL PROTECTED] wrote: On Mon, 29 Apr 2002 19:56:59 +0200, Matthias Andree [EMAIL PROTECTED] said: Barring write cache effects, fsync() only returns after all blocks are on disk. While I'm not sure if and if yes, which, Linux file systems are affected, but for portable applications, be aware that sync() may return prematurely (and is allowed to!). And in fact is the reason for the old recipe: # sync # sync # sync # reboot On the older Vax 750-class machines, sync could return LONG before the blocks were all flushed - the second 2 sync's were so you were busy typing for several seconds while the disks whirred. Failure to understand the typing speed issue has lead at least one otherwise-clued author to recommend: # sync;sync;sync # reboot (the distinction being obvious if you think about when the shell reads the commands, and when it does the fork/exec for each case) Finally I understand this. Doing more than one sync always seemed mysterious to me.;-) Thanks Matthias. Hans
