>Number: 174060 >Category: misc >Synopsis: Ext2FS system crashes (buffer overflow?) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Dec 02 18:30:00 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Tomasz CEDRO >Release: FreeBSD 9.1-RC3 >Organization: CeDeROM >Environment: FreeBSD hexagon 9.1-RC3 FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>Description: There is still something very wrong with the Ext2FS driver - my system crashes very often with that, reproducibly with torrtn/transmission client running that stores data on Ex2FS drive (multi system 1.2TB partition). I had this problem previously very ofthen when using VirtualBox images stored on ext2fs but it was gone so I thought the problem is gone... The Ext2FS was created from the beginning with FreeBSD, has no journal and use 128 byte inodes. The filesystem is 100% clean before mount I am checking all ext2fs driver by hand with e2fsck -fyC0 <drive>. >How-To-Repeat: Use something that intensively use ext2fs drive, then note lots of console messages like: g_vfs_done(): ada0s5 write(offset=X, length=Y) error = 5 and when you try to dmesg you get: dmesg: sysctl kern.msgbuf: Cannot allocate memory The messages does not stop even though application using the drive is terminated. This looks dangerous :-) >Fix: Fix in the Ext2FS kernel module? Produce native UFS driver for windows/linux/mac and forget about ext2 support? :-) >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"