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>. Fix: Fix in the Ext2FS kernel module? Produce native UFS driver for windows/linux/mac and forget about ext2 support? :-) 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 :-)
Responsible Changed From-To: freebsd-bugs->freebsd-fs reclassify
It got worse, now the system crash on single file save :-( Maybe this is not the reason but the address/location number is printed as negative value... Is there any way to see why this happens? Maybe some backtrace from kernel dump? I noticed some time ago that the filesystem was too big to handle so many files, some sort of inodes exhaustion, so I have removed lots of unnecessary files and it was fine for some time. Should I increase bytes-per-inode and/or number of inodes? Any hints are welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
State Changed From-To: open->closed Testing with fsx revealed issues that have been worked around by disabling reallocation in r245817 (MFC'd). Without reallocation the filesystem appears to be stable.