Re: ext3 vs reiserfs 3.6
MichaÅ PaÅka <[EMAIL PROTECTED]> writes: > On Fri, 2006-07-28 at 13:31 +0200, Goswin von Brederlow wrote: >> >> We (at my workplace) have lots of them, smp and not, with reiserfs and >> they don't usualy crash. They do crash a lot when we get new ones >> untill we weed out all the bad ram and such but after that the >> majority runs stable. The rest we swap cpu or the mainboard till they >> work. >> >> We still do have problems with reiserfs every now and then >> though. Having power getting cut from nodes without proper shutdown >> seems to be a problem for reiserfs. On reboot the syslogd hangs for >> ages unless /var is reformated. Recently I convinced my boss to switch >> to another filesystem but we still have to test crash (e.g. pull the >> power every 5 minutes) the different FSes a lot to see which is most >> robust. >> >> Personaly I use ext3 and never had problems on amd64. >> > I'm quite surprised to hear all these bad opinions about reiserfs since > I have never had any problems with it not caused by bad hardware. Which is the norm rather than the exception. > One thing that many people seem to be missing is the fact that their > drives might have write-cache enabled. In that case, even journalling > filesystems can be damaged by non-clean unmount if they don't handle the > caching issues. Meta-data corruption in ext3 might be less visible > because of the defensive layout of its structures. Drives, especially the cheap kind, lie, cheat and have bugs. Again, bad hardware is the norm not the exception. Reiserfs has the big assumption that the hardware works perfect. Any screwup there throws reiserfs totaly off track. Even just a power loss causing the drive to stop a block write in the middle of a block. Ext3 has a defensive layout of its structures, as you put it, to battle such inconsistencies and still function even when the hardware does screw up slightly. I think such robustness is essential. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
Michal Palka wrote: But you still have to enable barrier code AFAIK. No, you should not have to if you have a real write-through drive. It will however, generally improve performance for such drives to enable the barriers, if supported. If you have write-back, then you need the barriers, yes. But you don't have to have them for write-through drives, as they never cache written data without putting it on the platters first. That was the real thrust of my reply. If your drive supports it, which isn't many drives. Can you give some references? I would like to determine if my drives lie about flushes. Well, I misspoke. Most IDE hardware doesn't support tagged flushes, which are faster. You still need a drive that doesn't lie about putting out the cache, and that supports it. Older drives do not. ATA-6 drives are supposed to, but we know how that goes: Anyway, here's a reference to a thread describing some Maxtors that don't support it properly due to implementation issues. http://lkml.org/lkml/2004/5/12/189 Thanks, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Sat, 2006-07-29 at 09:57 -0400, Adam Skutt wrote: > Michal Palka wrote: > > > One thing that many people seem to be missing is the fact that their > > drives might have write-cache enabled. In that case, even journalling > > filesystems can be damaged by non-clean unmount if they don't handle the > > caching issues. > Nope, not quite right. They're only damaged by drives that either: > * Lie about their cache (i.e., say write-through while being write-back) > * Lie about cache-flushes. But you still have to enable barrier code AFAIK. > > That's most (but not all) IDE drives and SATA drives. Most SCSI drives do > not participate in this behavior. My commodity SATA drives are detected write-back: SCSI device sda: drive cache: write back > > If you use reiserfs or ext3 then you can keep write-cache enabled, since > > those filesystems support that setup via mount options. Use > > barrier=flush for reiserfs and barrier=1 for ext3. > If your drive supports it, which isn't many drives. Can you give some references? I would like to determine if my drives lie about flushes. Thanks, Michal Palka -- PS. Fajny portal... >>> http://link.interia.pl/f196a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
Michal Palka wrote: One thing that many people seem to be missing is the fact that their drives might have write-cache enabled. In that case, even journalling filesystems can be damaged by non-clean unmount if they don't handle the caching issues. Nope, not quite right. They're only damaged by drives that either: * Lie about their cache (i.e., say write-through while being write-back) * Lie about cache-flushes. That's most (but not all) IDE drives and SATA drives. Most SCSI drives do not participate in this behavior. If you use reiserfs or ext3 then you can keep write-cache enabled, since those filesystems support that setup via mount options. Use barrier=flush for reiserfs and barrier=1 for ext3. If your drive supports it, which isn't many drives. Thanks, Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
Didn't make it to the list, so resending from another account. On Fri, 2006-07-28 at 13:31 +0200, Goswin von Brederlow wrote: > > We (at my workplace) have lots of them, smp and not, with reiserfs and > they don't usualy crash. They do crash a lot when we get new ones > untill we weed out all the bad ram and such but after that the > majority runs stable. The rest we swap cpu or the mainboard till they > work. > > We still do have problems with reiserfs every now and then > though. Having power getting cut from nodes without proper shutdown > seems to be a problem for reiserfs. On reboot the syslogd hangs for > ages unless /var is reformated. Recently I convinced my boss to switch > to another filesystem but we still have to test crash (e.g. pull the > power every 5 minutes) the different FSes a lot to see which is most > robust. > > Personaly I use ext3 and never had problems on amd64. > I'm quite surprised to hear all these bad opinions about reiserfs since I have never had any problems with it not caused by bad hardware. One thing that many people seem to be missing is the fact that their drives might have write-cache enabled. In that case, even journalling filesystems can be damaged by non-clean unmount if they don't handle the caching issues. Meta-data corruption in ext3 might be less visible because of the defensive layout of its structures. You can use hdparm/sdparm to find out if the write-cache is enabled on your drives and disable it. Note that disabling write-cache can cause performance loss and decrease MTBF of the drive. If you use reiserfs or ext3 then you can keep write-cache enabled, since those filesystems support that setup via mount options. Use barrier=flush for reiserfs and barrier=1 for ext3. See this website for more info: http://www-dt.e-technik.uni-dortmund.de/~ma/linux/kernel/safe-write-caches.html Michal Palka -- PS. Fajny portal... >>> http://link.interia.pl/f196a -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
A google search... http://www.debian-administration.org/articles/388 On 7/28/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: Lennart Sorensen <[EMAIL PROTECTED]> writes: > On Fri, Jul 28, 2006 at 09:12:43AM -0400, [EMAIL PROTECTED] wrote: >> Weird! That's supposed to be the very thing reiserfs *is* good at. > > No actually reiserfs is rather fragile since it has essentially no > redundancy in the meta data, unlike ext2/ext3 which have redundant > superblocks and such. I have had major file corruption with reiserfs > 3.6 when a system was turned of in the middle of a write, since (at > least at the time) reiserfs would journal the meta data changes, and > then just start overwriting the old contents of the file, and at boot it > would update the meta data from the journal, and you end up with a > partially updated file. ext3 on the other hand gives you either the > version prior to the write, or the completely updated version, at least > in my experience. I imagine with larger writes with some programs even > ext3's ordered mode can't help you. > > -- > Len Sorensen Ordered mode makes sure that any data in the file is what was written to it. It never fails. But it doesn't help if you have a big file, start overwriting it with new data and then turn of the power. You will end up with the file partialy overwritten with the new data and then the old data remains. So better stick with appending or creating a new file to replace the old and such, don't rewrite files. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Engañarse por amor es el engaño más terrible; es una pérdida eterna para la que no hay compensación ni en el tiempo ni en la eternidad. Kierkegaard Jaime Ochoa Malagón Integrated Technology Tel: (55) 52 54 26 10
Re: ext3 vs reiserfs 3.6
Lennart Sorensen <[EMAIL PROTECTED]> writes: > On Fri, Jul 28, 2006 at 09:12:43AM -0400, [EMAIL PROTECTED] wrote: >> Weird! That's supposed to be the very thing reiserfs *is* good at. > > No actually reiserfs is rather fragile since it has essentially no > redundancy in the meta data, unlike ext2/ext3 which have redundant > superblocks and such. I have had major file corruption with reiserfs > 3.6 when a system was turned of in the middle of a write, since (at > least at the time) reiserfs would journal the meta data changes, and > then just start overwriting the old contents of the file, and at boot it > would update the meta data from the journal, and you end up with a > partially updated file. ext3 on the other hand gives you either the > version prior to the write, or the completely updated version, at least > in my experience. I imagine with larger writes with some programs even > ext3's ordered mode can't help you. > > -- > Len Sorensen Ordered mode makes sure that any data in the file is what was written to it. It never fails. But it doesn't help if you have a big file, start overwriting it with new data and then turn of the power. You will end up with the file partialy overwritten with the new data and then the old data remains. So better stick with appending or creating a new file to replace the old and such, don't rewrite files. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: ext3 vs reiserfs 3.6
My biggest problem with reiser wasn't crashing, but data/disk corruption with sleepcat databases. But I agree, the memory testing is critical before putting a system into service. Since moving to XFS, rock solid! Even during power outages. Peter Yorke Sr. Linux Server Engineer Vulcan, Inc. -Original Message- From: Goswin von Brederlow [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 4:32 AM To: Giacomo Mulas Cc: debian-amd64@lists.debian.org Subject: Re: ext3 vs reiserfs 3.6 Giacomo Mulas <[EMAIL PROTECTED]> writes: > On Fri, 28 Jul 2006, Francesco Pietra wrote: > >> Since I changed from reiserfs 3.6 to ext3 with debian etch amd64, the system >> no more suffered any crash, after days of running a very heavy computation >> with mpqc 2.3.1 with thread command for two dual opterons and 8 GB ram. The >> computation has now ended to full convergence. That was the most stressing >> action of memory I could conceive. > > Would you be able to put together and make available a simple script with > such a stress test for other people to try? Especially if you know that it > consistently crashes your previous setup. I, for one, am curious, since I > have 7 rock stable amd64 machines happily crunching numbers with (other) > quantum chemistry applications and using reiserfs. None of them is SMP > though. > > Bye > Giacomo We (at my workplace) have lots of them, smp and not, with reiserfs and they don't usualy crash. They do crash a lot when we get new ones untill we weed out all the bad ram and such but after that the majority runs stable. The rest we swap cpu or the mainboard till they work. We still do have problems with reiserfs every now and then though. Having power getting cut from nodes without proper shutdown seems to be a problem for reiserfs. On reboot the syslogd hangs for ages unless /var is reformated. Recently I convinced my boss to switch to another filesystem but we still have to test crash (e.g. pull the power every 5 minutes) the different FSes a lot to see which is most robust. Personaly I use ext3 and never had problems on amd64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Fri, 28 Jul 2006, Francesco Pietra wrote: Anyway, install mpqc 2.3.1 on a two dual opteron machine with 8GB ram. Have no gui, no applications other that for crushing numbers. Launch a geometry optimization for a conformationally mobile molecule complex enough that on threads n=4 command it takes a couple of hours for each iteration. Have about 80 full iterations to get complete convergence. If the system does not crash, you are happy (and may probably conclude that ECC memories are not faulty). Observing (top) the dance on ram, I got the impression that ram was heavily stressed. That occurred to me with debian amd64 etch on ext3 filesystem. Same "test" with reiserfs 3.6 as filesystem led to repeated crashes. Thanks, I will try that some time in the future when I can (i.e. I have deadlines to meet and a paper to submit first). Maybe I will ask you for suggestions on the input filesfor mpqc when it comes to that. I would like to be at the beach in Alghero, rather than here today. well, I am far enough from Alghero, but I work very close to Chia, and I tell you it's frustrating to have to keep working like crazy when you can see the dunes of the beach at less than 10 minutes driving distance, all of this with an outdoor temperature of about 36 C degrees... I should probably relocate away from Sardinia for working days and only come back for the weekends. Well, that's tomorrow, not so bad now that I think about it :) Cheers, Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Friday 28 July 2006 09:55, Giacomo Mulas wrote: > On Fri, 28 Jul 2006, Francesco Pietra wrote: > > Since I changed from reiserfs 3.6 to ext3 with debian etch amd64, the > > system no more suffered any crash, after days of running a very heavy > > computation with mpqc 2.3.1 with thread command for two dual opterons and > > 8 GB ram. The computation has now ended to full convergence. That was > > the most stressing action of memory I could conceive. > > Would you be able to put together and make available a simple script with > such a stress test for other people to try? After the change to ext3, I had memtest86+ running for one full day. Then I was said here (Goswin) that it may be an inconclusive test, if no errors are detected. Therefore, I went to the calculations of my interest. I do not believe it is a test. If not else because it takes so much time that one has to have specific interest in the result from the application. Anyway, install mpqc 2.3.1 on a two dual opteron machine with 8GB ram. Have no gui, no applications other that for crushing numbers. Launch a geometry optimization for a conformationally mobile molecule complex enough that on threads n=4 command it takes a couple of hours for each iteration. Have about 80 full iterations to get complete convergence. If the system does not crash, you are happy (and may probably conclude that ECC memories are not faulty). Observing (top) the dance on ram, I got the impression that ram was heavily stressed. That occurred to me with debian amd64 etch on ext3 filesystem. Same "test" with reiserfs 3.6 as filesystem led to repeated crashes. I am not implying that reiserfs 3.6 is no good (I have it on my PC i386 Athlon with gui, openoffice, wine , etc) also because I am not entitled to conclude that. But I am happy that I can work smoothly on ext3. I would like to be at the beach in Alghero, rather than here today. Have a good weekend, Giacomo. Cheers francesco > Especially if you know that it > consistently crashes your previous setup. I, for one, am curious, since I > have 7 rock stable amd64 machines happily crunching numbers with (other) > quantum chemistry applications and using reiserfs. None of them is SMP > though. > > Bye > Giacomo > > -- > _ > > Giacomo Mulas <[EMAIL PROTECTED]> > _ > > OSSERVATORIO ASTRONOMICO DI CAGLIARI > Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) > > Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 > Tel. (UNICA): +39 070 675 4916 > _ > > "When the storms are raging around you, stay right where you are" > (Freddy Mercury) > _ > > -- > Il messaggio e' stato analizzato alla ricerca di virus o > contenuti pericolosi da MailScanner, ed e' > risultato non infetto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Fri, Jul 28, 2006 at 09:12:43AM -0400, [EMAIL PROTECTED] wrote: > Weird! That's supposed to be the very thing reiserfs *is* good at. No actually reiserfs is rather fragile since it has essentially no redundancy in the meta data, unlike ext2/ext3 which have redundant superblocks and such. I have had major file corruption with reiserfs 3.6 when a system was turned of in the middle of a write, since (at least at the time) reiserfs would journal the meta data changes, and then just start overwriting the old contents of the file, and at boot it would update the meta data from the journal, and you end up with a partially updated file. ext3 on the other hand gives you either the version prior to the write, or the completely updated version, at least in my experience. I imagine with larger writes with some programs even ext3's ordered mode can't help you. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Fri, Jul 28, 2006 at 01:31:58PM +0200, Goswin von Brederlow wrote: > Giacomo Mulas <[EMAIL PROTECTED]> writes: > > > On Fri, 28 Jul 2006, Francesco Pietra wrote: > > > >> Since I changed from reiserfs 3.6 to ext3 with debian etch amd64, the > >> system > >> no more suffered any crash, after days of running a very heavy computation > >> with mpqc 2.3.1 with thread command for two dual opterons and 8 GB ram. The > >> computation has now ended to full convergence. That was the most stressing > >> action of memory I could conceive. > > > > Would you be able to put together and make available a simple script with > > such a stress test for other people to try? Especially if you know that it > > consistently crashes your previous setup. I, for one, am curious, since I > > have 7 rock stable amd64 machines happily crunching numbers with (other) > > quantum chemistry applications and using reiserfs. None of them is SMP > > though. > > > > Bye > > Giacomo > > We (at my workplace) have lots of them, smp and not, with reiserfs and > they don't usualy crash. They do crash a lot when we get new ones > untill we weed out all the bad ram and such but after that the > majority runs stable. The rest we swap cpu or the mainboard till they > work. > > We still do have problems with reiserfs every now and then > though. Having power getting cut from nodes without proper shutdown > seems to be a problem for reiserfs. Weird! That's supposed to be the very thing reiserfs *is* good at. > On reboot the syslogd hangs for > ages unless /var is reformated. Recently I convinced my boss to switch > to another filesystem but we still have to test crash (e.g. pull the > power every 5 minutes) the different FSes a lot to see which is most > robust. I'd be interested in the results of your tests. > > Personaly I use ext3 and never had problems on amd64. And I'm using reiser and having problems on my AMD64. I guess that's another thing for me to try, though my problems seem to be X server-related. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
Giacomo Mulas <[EMAIL PROTECTED]> writes: > On Fri, 28 Jul 2006, Francesco Pietra wrote: > >> Since I changed from reiserfs 3.6 to ext3 with debian etch amd64, the system >> no more suffered any crash, after days of running a very heavy computation >> with mpqc 2.3.1 with thread command for two dual opterons and 8 GB ram. The >> computation has now ended to full convergence. That was the most stressing >> action of memory I could conceive. > > Would you be able to put together and make available a simple script with > such a stress test for other people to try? Especially if you know that it > consistently crashes your previous setup. I, for one, am curious, since I > have 7 rock stable amd64 machines happily crunching numbers with (other) > quantum chemistry applications and using reiserfs. None of them is SMP > though. > > Bye > Giacomo We (at my workplace) have lots of them, smp and not, with reiserfs and they don't usualy crash. They do crash a lot when we get new ones untill we weed out all the bad ram and such but after that the majority runs stable. The rest we swap cpu or the mainboard till they work. We still do have problems with reiserfs every now and then though. Having power getting cut from nodes without proper shutdown seems to be a problem for reiserfs. On reboot the syslogd hangs for ages unless /var is reformated. Recently I convinced my boss to switch to another filesystem but we still have to test crash (e.g. pull the power every 5 minutes) the different FSes a lot to see which is most robust. Personaly I use ext3 and never had problems on amd64. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ext3 vs reiserfs 3.6
On Fri, 28 Jul 2006, Francesco Pietra wrote: Since I changed from reiserfs 3.6 to ext3 with debian etch amd64, the system no more suffered any crash, after days of running a very heavy computation with mpqc 2.3.1 with thread command for two dual opterons and 8 GB ram. The computation has now ended to full convergence. That was the most stressing action of memory I could conceive. Would you be able to put together and make available a simple script with such a stress test for other people to try? Especially if you know that it consistently crashes your previous setup. I, for one, am curious, since I have 7 rock stable amd64 machines happily crunching numbers with (other) quantum chemistry applications and using reiserfs. None of them is SMP though. Bye Giacomo -- _ Giacomo Mulas <[EMAIL PROTECTED]> _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ "When the storms are raging around you, stay right where you are" (Freddy Mercury) _ -- Il messaggio e' stato analizzato alla ricerca di virus o contenuti pericolosi da MailScanner, ed e' risultato non infetto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
