Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Tuesday, February 13, 2001 01:39:02 AM +0300 Hans Reiser <[EMAIL PROTECTED]> wrote: > Chris, your quoting is very confusing above. but I get your very > interesting remark (thanks for noticing) that the nulls are specific to > crashes on 2.2, and therefor could be due to the elevator bug on 2.4. It > even makes rough sense that the elevator bug (said to occasionally cause > a premature write of the wrong buffer) could cause an effect similar to a > crash. I hope it is true, let's ask all users to upgrade to pre2 (a good > idea anyway) and see if it cures. > Ok, I'll try again ;-) People have been seeing null bytes in data files on reiserfs. They see this without seeing any other corruption of any kind, and they only see it on files of very specific sizes. They see this without crashing, and without hard drive suspend kicking in. They see it on scsi and ide, on servers and laptops. Elevator bugs and general driver bugs could certainly cause nulls in data files. But they would also cause other corruptions and probably would not be selective enough to pick files that happen to have the same range in size that reiserfs packs tails on. In other words, updating to 2.4.2pre2 or your favorite ac series kernel is probably a good plan. It won't fix this bug ;-) Perhaps I haven't seen it yet because I've also been testing code that does direct->indirect conversions slightly differently, I'll try again on a pure kernel. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > > On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser > <[EMAIL PROTECTED]> wrote: > > >> Chris, > >> > >> Do you know if the people reporting the corruption with reiserfs on > >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > >> > >> If so, it may be caused by the problem fixed by Russell King on > >> 2.4.2-pre2. > >> > >> Without his fix, I was able to corrupt ext2 while using PIO+multicount > >> very very easily. > > > > I suspect the bugfixes in pre2 will fix some of the more exotic corruption > reports we've seen, but this one (nulls in log files) probably isn't caused > by a random (or semi-random) lower layer corruption. These users are not > seeing random metadata corruption, so I suspect this bug is different (and > reiserfs specific). > > > Was the bug you describe also present in the 2.2.* series? If not, then > > the bugs are not the same. > > > > In 2.2 code the only data file corruption I know if is caused by a crash > > -chris I'd like to announce on our website and mailing list that all XXX users should upgrade to 2.4.2pre2. Do you all agree with this? What is the exact definition of XXX? Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > > On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser > <[EMAIL PROTECTED]> wrote: > > >> Chris, > >> > >> Do you know if the people reporting the corruption with reiserfs on > >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > >> > >> If so, it may be caused by the problem fixed by Russell King on > >> 2.4.2-pre2. > >> > >> Without his fix, I was able to corrupt ext2 while using PIO+multicount > >> very very easily. > > > > I suspect the bugfixes in pre2 will fix some of the more exotic corruption > reports we've seen, but this one (nulls in log files) probably isn't caused > by a random (or semi-random) lower layer corruption. These users are not > seeing random metadata corruption, so I suspect this bug is different (and > reiserfs specific). > > > Was the bug you describe also present in the 2.2.* series? If not, then > > the bugs are not the same. > > > > In 2.2 code the only data file corruption I know if is caused by a crash > > -chris Chris, your quoting is very confusing above. but I get your very interesting remark (thanks for noticing) that the nulls are specific to crashes on 2.2, and therefor could be due to the elevator bug on 2.4. It even makes rough sense that the elevator bug (said to occasionally cause a premature write of the wrong buffer) could cause an effect similar to a crash. I hope it is true, let's ask all users to upgrade to pre2 (a good idea anyway) and see if it cures. zam is perhaps very clever for deferring working on this bug..:-) Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Monday, February 12, 2001 11:42:38 PM +0300 Hans Reiser <[EMAIL PROTECTED]> wrote: >> Chris, >> >> Do you know if the people reporting the corruption with reiserfs on >> 2.4 were using IDE drives with PIO mode and IDE multicount turned on? >> >> If so, it may be caused by the problem fixed by Russell King on >> 2.4.2-pre2. >> >> Without his fix, I was able to corrupt ext2 while using PIO+multicount >> very very easily. > I suspect the bugfixes in pre2 will fix some of the more exotic corruption reports we've seen, but this one (nulls in log files) probably isn't caused by a random (or semi-random) lower layer corruption. These users are not seeing random metadata corruption, so I suspect this bug is different (and reiserfs specific). > Was the bug you describe also present in the 2.2.* series? If not, then > the bugs are not the same. > In 2.2 code the only data file corruption I know if is caused by a crash -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Marcelo Tosatti wrote: > > On Mon, 12 Feb 2001, Hans Reiser wrote: > > > Marcelo Tosatti wrote: > > > > > > On Sun, 11 Feb 2001, Chris Mason wrote: > > > > > > > > > > > > > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > Daniel Stone wrote: > > > > >> > > > > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > > > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > > > >> > > > > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > > > >> > mbox'es randomly. > > > > >> > > > > > >> > what kind of corruption are you seeing? > > > > >> > > > > >> Zeroed bytes. > > > > > > > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > > > > reproduce it. > > > > > > > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > > > > > > > > > > I had a bunch of scripts running over the weekend to try and reproduce > > > > this, but the results were ruined when a major storm killed the power (no, > > > > still haven't gotten around to configuring my UPS to shut things down ;-). > > > > > > > > So, I'll try again. > > > > > > Chris, > > > > > > Do you know if the people reporting the corruption with reiserfs on > > > 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > > > > > > If so, it may be caused by the problem fixed by Russell King on > > > 2.4.2-pre2. > > > > > > Without his fix, I was able to corrupt ext2 while using PIO+multicount > > > very very easily. > > > > Was the bug you describe also present in the 2.2.* series? If not, then the > > bugs are not the same. > > N. Zam will try to reproduce it tomorrow, he successfully escaped me today and got to write fun code (a simpler block allocator) instead. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Mon, 12 Feb 2001, Hans Reiser wrote: > Marcelo Tosatti wrote: > > > > On Sun, 11 Feb 2001, Chris Mason wrote: > > > > > > > > > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Daniel Stone wrote: > > > >> > > > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > > >> > > > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > > >> > mbox'es randomly. > > > >> > > > > >> > what kind of corruption are you seeing? > > > >> > > > >> Zeroed bytes. > > > > > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > > > reproduce it. > > > > > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > > > > > > > I had a bunch of scripts running over the weekend to try and reproduce > > > this, but the results were ruined when a major storm killed the power (no, > > > still haven't gotten around to configuring my UPS to shut things down ;-). > > > > > > So, I'll try again. > > > > Chris, > > > > Do you know if the people reporting the corruption with reiserfs on > > 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > > > > If so, it may be caused by the problem fixed by Russell King on > > 2.4.2-pre2. > > > > Without his fix, I was able to corrupt ext2 while using PIO+multicount > > very very easily. > > Was the bug you describe also present in the 2.2.* series? If not, then the > bugs are not the same. N. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Marcelo Tosatti wrote: > > On Sun, 11 Feb 2001, Chris Mason wrote: > > > > > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > > <[EMAIL PROTECTED]> wrote: > > > > > Daniel Stone wrote: > > >> > > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > >> > > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > >> > mbox'es randomly. > > >> > > > >> > what kind of corruption are you seeing? > > >> > > >> Zeroed bytes. > > > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > > reproduce it. > > > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > > > > I had a bunch of scripts running over the weekend to try and reproduce > > this, but the results were ruined when a major storm killed the power (no, > > still haven't gotten around to configuring my UPS to shut things down ;-). > > > > So, I'll try again. > > Chris, > > Do you know if the people reporting the corruption with reiserfs on > 2.4 were using IDE drives with PIO mode and IDE multicount turned on? > > If so, it may be caused by the problem fixed by Russell King on > 2.4.2-pre2. > > Without his fix, I was able to corrupt ext2 while using PIO+multicount > very very easily. Was the bug you describe also present in the 2.2.* series? If not, then the bugs are not the same. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Sun, 11 Feb 2001, Chris Mason wrote: > > > On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser > <[EMAIL PROTECTED]> wrote: > > > Daniel Stone wrote: > >> > >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > >> > > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my > >> > mbox'es randomly. > >> > > >> > what kind of corruption are you seeing? > >> > >> Zeroed bytes. > > > > This sounds like the same bug as the syslog bug, please try to help Chris > > reproduce it. > > > > zam, if Chris can't reproduce it by Monday, please give it a try. > > > > I had a bunch of scripts running over the weekend to try and reproduce > this, but the results were ruined when a major storm killed the power (no, > still haven't gotten around to configuring my UPS to shut things down ;-). > > So, I'll try again. Chris, Do you know if the people reporting the corruption with reiserfs on 2.4 were using IDE drives with PIO mode and IDE multicount turned on? If so, it may be caused by the problem fixed by Russell King on 2.4.2-pre2. Without his fix, I was able to corrupt ext2 while using PIO+multicount very very easily. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
[EMAIL PROTECTED] (Andi Kleen) writes: >to the low level file system for efficient lookup (actually is all not >too difficult to implement, just requires very uncodefreezefriendly changes >to nfsd) Well, at least I would really prefer a change for 2.4.x the sooner the better as I will never ever want to repeat the NFS nightmare from 2.2. I prefer a working NFS on Reiser over a non working, but codefreezed at any time. ;-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED] D-91054 Buckenhof Fax.: 09131 / 50654-20 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://vger.kernel.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Rogerio Brito <[EMAIL PROTECTED]> writes: > On Feb 11 2001, Andi Kleen wrote: > > The reiserfs nfs problem in standard 2.4 is very simple -- it'll > > barf as soon as you run out of file handle/inode cache. Any workload > > that accesses enough files in parallel can trigger it. > > I'm just trying to evaluate if I should use reiserfs here or > not: is this phenomenon that you describe above happening > independently of whether I choose the knfsd or userspace nfsd? This should be all covered extensively in the reiserfs FAQ and list archives, here a last time: It only applies to knfsd, but unfsd unfortunately has different problems with reiserfs. It makes assumptions about the inode space by the underlying filesystem by assuming that it can encode a dev_t in upper bits. Reiserfs unlike ext2 periodically cycles through the full 31bit of inode values, and after some weeks on a busy file system unfsd starts to complain about conflicts. There is a patch at ftp.suse.com:/pub/people/ak/nfs/unfsd* that works around the problem when you specify --no-cross-mounts (but you cannot export trees of multiple file systems then with a single mount anymore) Please also note that the patch also adds a rather obscure bug, which triggers very seldom (patch partly exists, but not really tested yet) Another alternative is to use knfsd with Chris Mason's 2.4 knfsd patches. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> Not the slightest idea. Is the connectathon test suite something that stresses > the FS heavily? If so, we can always add it to our stable, whether or not it > stresses this particular bug. It certainly has been stressing the NFS side of things enough to show up a lot of problems so maybe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Feb 11 2001, Andi Kleen wrote: > The reiserfs nfs problem in standard 2.4 is very simple -- it'll > barf as soon as you run out of file handle/inode cache. Any workload > that accesses enough files in parallel can trigger it. I'm just trying to evaluate if I should use reiserfs here or not: is this phenomenon that you describe above happening independently of whether I choose the knfsd or userspace nfsd? From your message, I got the impression that it would happen with knfsd only, but I'm just checking before I make a wrong decision. Thanks from a humble (and ignorant) network admin, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Sunday, February 11, 2001 10:00:11 AM +0300 Hans Reiser <[EMAIL PROTECTED]> wrote: > Daniel Stone wrote: >> >> On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: >> > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: >> > >> > I run Reiser on all but /boot, and it seems to enjoy corrupting my >> > mbox'es randomly. >> > >> > what kind of corruption are you seeing? >> >> Zeroed bytes. > > This sounds like the same bug as the syslog bug, please try to help Chris > reproduce it. > > zam, if Chris can't reproduce it by Monday, please give it a try. > I had a bunch of scripts running over the weekend to try and reproduce this, but the results were ruined when a major storm killed the power (no, still haven't gotten around to configuring my UPS to shut things down ;-). So, I'll try again. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: > > > LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > > finished testing his changes, we will ask someone to test it for us though. > > > > Do you know if the connectathon test suites show the problem? Not the slightest idea. Is the connectathon test suite something that stresses the FS heavily? If so, we can always add it to our stable, whether or not it stresses this particular bug. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox <[EMAIL PROTECTED]> writes: > > LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > > finished testing his changes, we will ask someone to test it for us though. > > > > Do you know if the connectathon test suites show the problem? The reiserfs nfs problem in standard 2.4 is very simple -- it'll barf as soon as you run out of file handle/inode cache. Any workload that accesses enough files in parallel can trigger it. Fixes do exist, but require bigger changes in nfsd. Basically you need to hand out an 64bit inode in the nfs filehandle, and pass the upper 32bits to the low level file system for efficient lookup (actually is all not too difficult to implement, just requires very uncodefreezefriendly changes to nfsd) -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and > NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has > finished testing his changes, we will ask someone to test it for us though. > Do you know if the connectathon test suites show the problem? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> run reiserfs on several servers, workstations, and a notebook. I have > current kernels and have watched carefully for corruption. I haven't > seen any evidence of corruption on any of them including my notebook > which has a bad battery and bad power connection so it tends to > instantly die. > > Alan, is there a particular trigger to this? The 2.4.1 stuff is a specific low level block I/O pattern. Its fixed in 2.4.2pre2/2.4.1ac-something - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Adrian Phillips wrote: > > > "Hans" == Hans Reiser <[EMAIL PROTECTED]> writes: > > Hans> Adrian Phillips wrote: > >> Does your test procedure include other systems, for example > >> reiserfs plus NFS ? > > Hans> Our NFS testing is simply inadequate, we need a copy of > Hans> LADDIS but haven't found the money for it yet. > > Excuse my ignorance, but what is LADDIS ? > > Sincerely, > > Adrian Phillips > > -- > Your mouse has moved. > Windows NT must be restarted for the change to take effect. > Reboot now? [OK] LADDIS is the industry standard benchmark for NFS. It crashes for ReiserFS and NFS. We can't afford to buy it, as it is proprietary software. Once Nikita has finished testing his changes, we will ask someone to test it for us though. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> "Hans" == Hans Reiser <[EMAIL PROTECTED]> writes: Hans> Adrian Phillips wrote: >> Does your test procedure include other systems, for example >> reiserfs plus NFS ? Hans> Our NFS testing is simply inadequate, we need a copy of Hans> LADDIS but haven't found the money for it yet. Excuse my ignorance, but what is LADDIS ? Sincerely, Adrian Phillips -- Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [OK] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Adrian Phillips wrote: > > Does your test procedure include other systems, for example reiserfs > plus NFS ? Our NFS testing is simply inadequate, we need a copy of LADDIS but haven't found the money for it yet. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > problems below the reiserfs layer I forgot, this bug exists on reiserfs for Linux 2.2.*, so it isn't going to be fixed by 2.4.2 (assuming that the bug is not in 2.2.*). Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
David Ford wrote: > > Alan Cox wrote: > > >> I run Reiser on all but /boot, and it seems to enjoy corrupting my > >> mbox'es randomly. > >> Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 > >> chipset with the fixes enabled. > >> This also occurs in some log files, but I put it down to syslogd > >> crashing or something. > > > > > > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > > problems below the reiserfs layer > > Just as an aside, I've watched this conversation go on and on while I > run reiserfs on several servers, workstations, and a notebook. I have > current kernels and have watched carefully for corruption. I haven't > seen any evidence of corruption on any of them including my notebook > which has a bad battery and bad power connection so it tends to > instantly die. > > Alan, is there a particular trigger to this? > > -d Guys, instability is a relative word. One of our users in Russia said that reiserfs was as stable as a mountain, and he didn't understand my email. We have some number of users, I wish I really knew how many. If you look at a few hundred thousand mountains, you'll discover that a number of them are really quite unstable. We used to get a bug report a week, now we get one or two a day. Does this mean we went from a few hundred thousand mountains to a few million? I don't really know. I can assure the users though that we have an extensive testing procedure, and that our releases all pass a testing that can roughly be described as hammering the filesystem every different way we can think of (this is more limited than what being put into the kernel by Linus does) for twelve or more hours. What I do know is the following: there was a recent elevator bug fix. Our filesystem is a journaling filesystem and it is extremely dependent on an assumption that nothing is going to get written to disk before it should. I think fsck even makes assumptions about certain states relating to rename being made atomic never reaching disk (and I think this is being fixed thanks to this bug). Could this cause the bug in which syslog gets zeros in it? Don't know, we haven't reproduced that bug yet though it "should" be straightforward to reproduce. We do have an NFS bug, which Nikita is still fixing. What I can tell you is that in a few weeks we will have it back to a bug report every week or two, and until we do version 4 of ReiserFS is going to be stalled (not so different from Linux 2.5 being stalled until 2.4 satisfies Linus). Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Daniel Stone wrote: > > On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > > mbox'es randomly. > > > > what kind of corruption are you seeing? > > Zeroed bytes. This sounds like the same bug as the syslog bug, please try to help Chris reproduce it. zam, if Chris can't reproduce it by Monday, please give it a try. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Wedgwood wrote: > > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > mbox'es randomly. > > what kind of corruption are you seeing? > > This also occurs in some log files, but I put it down to syslogd > crashing or something. > > syslogd crashing shouldn't corrupt files... > > --cw There is a known bug in which nulls get added to log files. We are having trouble reproducing it on our machines. There is an elevator bug in 2.4 which just got found/fixed. We don't know what part of our bug reports are due to it. Hans - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Saturday 10 February 2001 22:16, David Ford wrote: > Just as an aside, I've watched this conversation go on and on while I > run reiserfs on several servers, workstations, and a notebook. I > have current kernels and have watched carefully for corruption. I > haven't seen any evidence of corruption on any of them including my > notebook which has a bad battery and bad power connection so it tends > to instantly die. > > Alan, is there a particular trigger to this? Want to trigger this? Just install reiserfs on Dual SMP machine with huge RAID acting as mail server for 90k mailboxes. After several hours you'll get a lot reiserfs_read_inode2/reiserfs_iget: bad_inode msgs in your kern.log... Good luck. -- Andrius [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Alan Cox wrote: >> I run Reiser on all but /boot, and it seems to enjoy corrupting my >> mbox'es randomly. >> Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 >> chipset with the fixes enabled. >> This also occurs in some log files, but I put it down to syslogd >> crashing or something. > > > Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be > problems below the reiserfs layer Just as an aside, I've watched this conversation go on and on while I run reiserfs on several servers, workstations, and a notebook. I have current kernels and have watched carefully for corruption. I haven't seen any evidence of corruption on any of them including my notebook which has a bad battery and bad power connection so it tends to instantly die. Alan, is there a particular trigger to this? -d - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
> I run Reiser on all but /boot, and it seems to enjoy corrupting my > mbox'es randomly. > Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 > chipset with the fixes enabled. > This also occurs in some log files, but I put it down to syslogd > crashing or something. Before you put that down to reiserfs can you chek 2.4.2-pre2. It may be problems below the reiserfs layer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On 11 Feb 2001 02:02:00 +1300, Chris Wedgwood wrote: > On Thu, Feb 08, 2001 at 05:34:44PM +1100, Daniel Stone wrote: > > I run Reiser on all but /boot, and it seems to enjoy corrupting my > mbox'es randomly. > > what kind of corruption are you seeing? Zeroed bytes. > This also occurs in some log files, but I put it down to syslogd > crashing or something. > > syslogd crashing shouldn't corrupt files... Actually, I meant to say my hard drive crashing. I have two hard drives, side-by-side, and sometimes they overheat and one of them powers down due to the excess heat. They haven't done that lately, though, as I have a dedicated fan for both of them, but the corruption persists. -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On 07 Feb 2001 11:48:16 -0500, Chris Mason wrote: > > > On Wednesday, February 07, 2001 08:38:54 AM -0800 David Rees > <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: > >> > >> Ok, how about we list the known bugs: > >> > >> zeros in log files, apparently only between bytes 2048 and 4096 (not > >> reproduced yet). > > > > Could this bug be related to the reported corruption that people with > > new VIA chipsets have been also reporting on ext2? It seems similar > > because of the location of the corruption: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=98147483712620&w=2 > > > > Anyway, it can't hurt to ask the bug reported if they're using a > > newer VIA chipset and see if they will upgrade their BIOS which seems > > to fix the problem. > > I'd love to blame this on VIA problems, but people are seeing it on other > chipsets too ;-) > > People who report this aren't seeing general corruption, just zeros in > files of specific sizes. So, it really should be a reiserfs bug. I run Reiser on all but /boot, and it seems to enjoy corrupting my mbox'es randomly. Using the old-style Reiser FS format, 2.4.2-pre1, Evolution, on a CMD640 chipset with the fixes enabled. This also occurs in some log files, but I put it down to syslogd crashing or something. d -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wednesday, February 07, 2001 11:05:51 PM +0100 Xuan Baldauf <[EMAIL PROTECTED]> wrote: > Mhhh. It's a busy server from which I am about 700km away. I don't like to > restart it now. (Especially because it cannot boot from hard disk, only > from floppy disk, due to bios problems). But I'd be happy if following is > true: > > (1) Enabling "-o notails" is possible at runtime, i.e. "mount / -o > remount,notails" works and Nope. > (2) Notails is compatible with all the tails found on disk (so notails > only changes the way the disk is written, not the way the disk is read). > This part is true. Honestly, I don't want to do this kind of debugging on a busy server. Sure, it is completely safe, etc, etc, but ... We'll get the info elsewhere, leave the busy servers out of it ;-) -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood > <[EMAIL PROTECTED]> wrote: > > > these appear on your system every couple of days right? if so... are > > you able to run with the fs mount notails for a couple of days and > > see if you still experience these? > > > > my guess is you probably still will as most log files aren't > > candidates for tail-packing (too large) but it will help eliminate > > one more thing > > > > Yes, it really would. > > 1) mount -o notail > 2) rm old_logfile > 3) restart syslog > > This will ensure the log files don't have tails at all. Knowing for sure > the bug doesn't involve tails would remove much code from the search. > > -chris Mhhh. It's a busy server from which I am about 700km away. I don't like to restart it now. (Especially because it cannot boot from hard disk, only from floppy disk, due to bios problems). But I'd be happy if following is true: (1) Enabling "-o notails" is possible at runtime, i.e. "mount / -o remount,notails" works and (2) Notails is compatible with all the tails found on disk (so notails only changes the way the disk is written, not the way the disk is read). Is this true? Xuân. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Thursday, February 08, 2001 10:47:29 AM +1300 Chris Wedgwood <[EMAIL PROTECTED]> wrote: > these appear on your system every couple of days right? if so... are > you able to run with the fs mount notails for a couple of days and > see if you still experience these? > > my guess is you probably still will as most log files aren't > candidates for tail-packing (too large) but it will help eliminate > one more thing > Yes, it really would. 1) mount -o notail 2) rm old_logfile 3) restart syslog This will ensure the log files don't have tails at all. Knowing for sure the bug doesn't involve tails would remove much code from the search. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Hi Chris,
this is the output of my zero block detection utility. Note that in all the
files mentioned, zero bytes never can exist there, so every zero byte is a bug.
The output format is:
${filename} ${decompressed?"d":"n"} ${startIndex} ${endIndex} ${length}
The data (sorted):
_log.2001-01-16--00-04-57.broken.orig n 231238581546
_log.2001-01-17--00-02-27.orig.broken n 20882391303
_log.2001-02-06--00-00-30.corrupted n 926010116 856
log.2000-04-07--00-00-20.gz d 41988 42231 243
log.2000-04-29--00-00-17.gz d 91843 91924 81
log.2000-07-20--00-00-01.gz d 14690 14780 90
log.2000-07-20--00-00-08.gz d 26234 26314 80
log.2000-07-20--00-01-06.gz d 82558430175
log.2000-11-08--00-00-02n 37232 37959 727
log.2000-11-08--00-00-10.gz d 200835881580
log.2000-11-08--00-01-01.gz d 27237 27681 444
log.2000-11-08--00-01-38.gz d 15547 15721 174
log.2000-11-08--00-01-52.gz d 8254834288
log.2000-11-08--00-03-42.gz d 10985 11522 537
log.2000-11-11--00-00-03n 31523923771
log.2000-11-11--00-00-03.gz d 31523923771
log.2000-11-12--00-40-18.gz d 239 1167928
log.2000-11-14--00-01-17.gz d 24723273801
log.2000-11-14--00-01-26.gz d 31523874722
log.2000-11-15--00-00-58.gz d 29443112168
log.2000-11-15--02-55-09.gz d 203 33433140
log.2000-11-16--00-01-47.gz d 854 22061352
log.2000-11-18--00-01-42.gz d 170429411237
log.2000-11-20--00-03-28.gz d 10981914816
log.2000-11-21--00-00-35.gz d 32083392184
log.2000-11-22--00-15-01.gz d 63206632312
log.2000-11-23--00-00-57.gz d 27843354570
log.2000-11-23--00-02-14.gz d 28963697801
log.2000-11-24--00-03-46.gz d 27843413629
log.2000-11-25--00-01-25.gz d 25603363803
log.2000-11-26--00-09-39.gz d 112 35133401
log.2000-11-27--00-56-50.gz d 252 16601408
log.2000-11-28--00-01-34.gz d 145828581400
log.2000-11-28--00-02-07.gz d 757 31172360
log.2000-11-29--00-00-07.gz d 170434041700
log.2000-11-29--00-02-20.gz d 936 1384448
log.2000-11-29--00-05-40.gz d 241635771161
log.2000-12-02--00-06-03.gz d 627 34192792
log.2000-12-02--00-12-42.gz d 321 14171096
log.2000-12-05--00-00-47.gz d 153631231587
log.2000-12-06--00-00-35.gz d 108034922412
log.2000-12-08--00-07-01.gz d 35923692100
log.2000-12-09--00-11-02.gz d 122439552731
log.2000-12-10--00-10-03.gz d 121136912480
log.2000-12-12--00-04-25.gz d 32003743543
log.2000-12-13--00-00-42.gz d 24083104696
log.2000-12-13--00-01-31.gz d 527068221552
log.2000-12-13--11-09-43.gz d 35923757165
log.2000-12-14--00-01-30.gz d 16002500900
log.2000-12-15--00-00-28.gz d 25603423863
log.2000-12-19--00-04-08.gz d 442 26822240
log.2000-12-20--00-01-29.gz d 26723199527
log.2000-12-20--00-02-47.gz d 46825378696
log.2000-12-21--00-00-16.gz d 487266831811
log.2000-12-21--00-01-23.gz d 921010170 960
log.2000-12-21--00-08-48.gz d 25443256712
log.2000-12-22--00-01-42.gz d 446669382472
log.2000-12-23--00-00-11.gz d 487267741902
log.2000-12-23--00-03-01.gz d 135238272475
log.2000-12-24--00-00-15.gz d 206435971533
log.2000-12-25--00-01-07.gz d 100421881184
log.2000-12-26--00-01-36.gz d 208035081428
log.2000-12-27--00-01-13.gz d 112826841556
log.2000-12-27--00-05-42.gz d 43964836440
log.2000-12-30--00-06-54.gz d 128036132333
log.2001-01-01--00-05-32n 28963534638
log.2001-01-01--00-12-07n 420459641760
log.2001-01-03--00-03-11.gz d 153631041568
log.2001-01-03--00-04-22n 216032431083
log.2001-01-04--00-23-53.gz d 240835871179
log.2001-01-05--00-26-01.gz d 31843422238
log.2001-01-06--00-01-52.gz d 110435432439
log.2001-01-09--00-00-07.gz d 28143310496
log.2001-01-09--00-01-45.gz d 196038351875
log.2001-01-09--09-43-49n 139237042312
log.2001-01-11--00-00-18.gz d 204835111463
log.2001-01-11--00-01-24.gz d 111022141104
log.2001-01-12--00-00-10.gz d
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wed, 7 Feb 2001, Chris Mason wrote: > > > On Wednesday, February 07, 2001 07:41:25 PM +0100 Vedran Rodic > <[EMAIL PROTECTED]> wrote: > > > > > So could some of this bugs also be present in 3.5.x version of reiserfs? > > Will you be fixing them for that version? > > > > This list of reiserfs bugs was all specific to the 3.6.x versions, and they > don't appear with the 3.5.x code. You will probably have problems if you > compile 3.5.x reiserfs with an unpatched redhat gcc 2.96, though. Apologies if I'm mis-understanding (I don't follow the list too closely), but the zeros-in-log-files thing happens to me a lot on 3.5.X. Is there some sort of debugging info I could offer to help figure it out? Ivan... --- Ivan Pulleyn 4942 N. Winchester Ave. #3 Chicago, IL 60640 [EMAIL PROTECTED] (847) 980-1400 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wednesday, February 07, 2001 07:41:25 PM +0100 Vedran Rodic <[EMAIL PROTECTED]> wrote: > > So could some of this bugs also be present in 3.5.x version of reiserfs? > Will you be fixing them for that version? > This list of reiserfs bugs was all specific to the 3.6.x versions, and they don't appear with the 3.5.x code. You will probably have problems if you compile 3.5.x reiserfs with an unpatched redhat gcc 2.96, though. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: > > > Ok, how about we list the known bugs: > > zeros in log files, apparently only between bytes 2048 and 4096 (not > reproduced yet). > > preallocated block leak on crash (fix in testing) > > hidden directory entry cleanup (still reproducing, very hard to hit). > > knfsd (patches in testing). > > oops in reiserfs_symlink, create_virtual_node (bug in redhat gcc 2.96, > fixed by downloading the update). > > We've also had a few reports of other corruptions, most of which have been > traced to hardware problems. There are two where I'm not sure of the cause > yet, but the method to trigger the bug was too simple to not be a hardware > problem. So could some of this bugs also be present in 3.5.x version of reiserfs? Will you be fixing them for that version? Vedran Rodic - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
Chris Mason wrote: > On Wednesday, February 07, 2001 06:30:01 PM +0100 Xuan Baldauf > <[EMAIL PROTECTED]> wrote: > > In my case, it's a SIS5513 board. > > > > I have to note that I now have one case which is between offset 9260 and > > 11016. So probably the tails unpacking theory does not work out. > > > > After a more systematical search, I have found following offsets: > > > > 9260..11016 = 1756 > > 4204.. 5964 = 1760 > > 2160.. 3243 = 1083 > > 2896.. 3534 = 638 > > 1392.. 3704 = 2312 > > > > and so on. Maybe I should write a program which automatically detects and > > reports the zero blocks. I think the theory of tails unpacking does not > > work out, because there are also areas affected which are not between 2048 > > and 4096. Also the length of the zeroing can be greater than 2048. > > However, I did not encounter a length of over 4096. > > > > Files up to around 16k in length can have tails, and tails can be larger > than 2048 bytes. Oh, I thought that if tails are larger than 2048 bytes, they get converted to ordinary 4k blocks. The last case (with 2312 zero block size) is the only case where the first entry after the zero block is the last entry of the file. (This file is smaller than 4k, all other files should be larger than 4k). > > > Also interesting would be info about when the file closes. reiserfs only > creates a tail on file close (file writes always go to full blocks). If > you application has the file mmap'd the rules change a little (does it?). I have to admit that I do not really know: The ad server is a java application, I do not know wether java on linux does mmap for FileInputStream and FileOutputStream. "lsof" shows an ordinary file descriptor (such as "13u") at the FD column for those files, libraries do not have an fd, they have "mem" in the FD section. So I guess that the files are not memmapped, the implementation is easier with ordinary read()s and write()s. It's interesting that the zeroed section never crosses a 4k boundary... > > > -chris Xuân. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wednesday, February 07, 2001 06:30:01 PM +0100 Xuan Baldauf <[EMAIL PROTECTED]> wrote: > In my case, it's a SIS5513 board. > > I have to note that I now have one case which is between offset 9260 and > 11016. So probably the tails unpacking theory does not work out. > > After a more systematical search, I have found following offsets: > > 9260..11016 = 1756 > 4204.. 5964 = 1760 > 2160.. 3243 = 1083 > 2896.. 3534 = 638 > 1392.. 3704 = 2312 > > and so on. Maybe I should write a program which automatically detects and > reports the zero blocks. I think the theory of tails unpacking does not > work out, because there are also areas affected which are not between 2048 > and 4096. Also the length of the zeroing can be greater than 2048. > However, I did not encounter a length of over 4096. > Files up to around 16k in length can have tails, and tails can be larger than 2048 bytes. Also interesting would be info about when the file closes. reiserfs only creates a tail on file close (file writes always go to full blocks). If you application has the file mmap'd the rules change a little (does it?). -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wednesday, February 07, 2001 08:38:54 AM -0800 David Rees <[EMAIL PROTECTED]> wrote: > On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: >> >> Ok, how about we list the known bugs: >> >> zeros in log files, apparently only between bytes 2048 and 4096 (not >> reproduced yet). > > Could this bug be related to the reported corruption that people with > new VIA chipsets have been also reporting on ext2? It seems similar > because of the location of the corruption: > > http://marc.theaimsgroup.com/?l=linux-kernel&m=98147483712620&w=2 > > Anyway, it can't hurt to ask the bug reported if they're using a > newer VIA chipset and see if they will upgrade their BIOS which seems > to fix the problem. I'd love to blame this on VIA problems, but people are seeing it on other chipsets too ;-) People who report this aren't seeing general corruption, just zeros in files of specific sizes. So, it really should be a reiserfs bug. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [reiserfs-list] Re: Apparent instability of reiserfs on 2.4.1
On Wed, Feb 07, 2001 at 10:47:09AM -0500, Chris Mason wrote: > > Ok, how about we list the known bugs: > > zeros in log files, apparently only between bytes 2048 and 4096 (not > reproduced yet). Could this bug be related to the reported corruption that people with new VIA chipsets have been also reporting on ext2? It seems similar because of the location of the corruption: http://marc.theaimsgroup.com/?l=linux-kernel&m=98147483712620&w=2 Anyway, it can't hurt to ask the bug reported if they're using a newer VIA chipset and see if they will upgrade their BIOS which seems to fix the problem. -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
