I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. Thank you for reply Jakub Siroky
Jakub Siroky wrote:> I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes.Interesting. I have ext2fs partitions in the same size range for the same purpose under 8-CURRENT and I don't have the problems you described, so it's unlikely the problem were introduced in 7. Did you run e2fsck on the file systems? Can you verify there is no hardware or driver data corruption (though I don't know how would you verify this one - maybe by writing to the partition from one OS and reading from the other, amd using md5 to check)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20080118/3ffbd2c1/signature.pgp
Jakub Siroky wrote:> I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quitedisappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes. 1) Please wrap your lines so your emails can be easily read. 2) Check the developer's handbook, it explains how to configure the debugger so you can investigate this further. Kris
Jakub Siroky wrote:> I have two large ext2fs partitions (368 and 313GB) to hold data shared between several OSes. While there were no problems on 6-STABLE branch I was quite disappointed after upgrade to 7-STABLE. Whenever I copy/write to ext2fs partition the system freezes totally without crashdump. So I set debugging settings to kernel config (DEBUG,WITNESS,..) and in console I reproduced error situation ending with full screen of unstoppable running text with lot of memory addresses and a few recognisable words: 'new block bit set for ext already' - again with no crashdump. Then I have formatted 1GB partition with ext2fs and the problem on this small partition appears only sometimes.OK, I am able to reproduce this. Kris
Jakub Siroky wrote:> I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I > did not noticed it before because I started using ext2fs extensively > some months ago. > > Regards, > Jakub > > On Sat, 19 Jan 2008 16:44:34 +0100 > Kris Kennaway <kris@FreeBSD.org> wrote: > >> Kris Kennaway wrote: >>> Jakub Siroky wrote: >>>> I have two large ext2fs partitions (368 and 313GB) to hold data >>>> shared between several OSes. While there were no problems on >>>> 6-STABLE branch I was quite disappointed after upgrade to >>>> 7-STABLE. Whenever I copy/write to ext2fs partition the system >>>> freezes totally without crashdump. So I set debugging settings to >>>> kernel config (DEBUG,WITNESS,..) and in console I reproduced error >>>> situation ending with full screen of unstoppable running text with >>>> lot of memory addresses and a few recognisable words: 'new block >>>> bit set for ext already' - again with no crashdump. Then I have >>>> formatted 1GB partition with ext2fs and the problem on this small >>>> partition appears only sometimes. >>> OK, I am able to reproduce this. >>> >>> Kris >>> >> Is anyone able to look at this? I could not spot a candidate change >> that has not been merged to 6.x. >> >> Kris > >Sounds like it may have been broken by the change to ext2_bitops.h by cracauer. Can you confirm whether backing out 1.2.2.1 fixes it? Kris
I've just confirmed the same situation on 6.2-RELEASE amd64/GENERIC. I did not noticed it before because I started using ext2fs extensively some months ago. Regards, Jakub On Sat, 19 Jan 2008 16:44:34 +0100 Kris Kennaway <kris@FreeBSD.org> wrote:> Kris Kennaway wrote: > > Jakub Siroky wrote: > >> I have two large ext2fs partitions (368 and 313GB) to hold data > >> shared between several OSes. While there were no problems on > >> 6-STABLE branch I was quite disappointed after upgrade to > >> 7-STABLE. Whenever I copy/write to ext2fs partition the system > >> freezes totally without crashdump. So I set debugging settings to > >> kernel config (DEBUG,WITNESS,..) and in console I reproduced error > >> situation ending with full screen of unstoppable running text with > >> lot of memory addresses and a few recognisable words: 'new block > >> bit set for ext already' - again with no crashdump. Then I have > >> formatted 1GB partition with ext2fs and the problem on this small > >> partition appears only sometimes. > > > > OK, I am able to reproduce this. > > > > Kris > > > > Is anyone able to look at this? I could not spot a candidate change > that has not been merged to 6.x. > > Kris