BFS volume not fully written to
|Reported by:||andreasf||Owned by:||axeld|
|Has a Patch:||no||Platform:||x86|
As discussed on the haiku-development list, I have a 4.0 GB BFS volume, second primary Intel partition, slave IDE device. I am unable to get more than ~2400 MB onto the volume.
Ways to reproduce:
bzr branch http://bazaar-vcs.org/bzr/bzr.dev bzr.dev
results 100% reproducible (here during phase 2/5) in the KDL:
PANIC: block_cache: supposed to be clean block was changed!
[...] panic put_cached_block block_cache cached_block put_cached_block block_cache <kernel>block_cache_put <bfs>Unset CachedBlock _GrowStream Inode Transaction SetFileSize Inode Transaction WriteAt Inode Transaction bfs_write fs_volume fs_vnode <bfs>file_write file_descriptor common_user_io_FixPvUlb _user_write <kernel>pre_syscall_debug_done [iframe] _IO_new_file_write _IO_do_write _IO_new_file_xsputn <libroot.so>fwrite <python>PyFile_GetLine
(This KDL can be
Bazaar 1.3.1 is based on Python >= 2.4 and requires
bz2 modules; to satisfy the latter, I compiled Python 2.5.x (stable) SVN branch using this patch, enabling said modules in
Modules/Setup. This patch was still considered work-in-progress but its incompleteness shouldn't be able to cause such a KDL.
To successfully run Bazaar, the hostname needs to be set, here using
ii) Copying a large source code folder (such as a successful
bzr.dev branch from my main volume) onto the volume (dragging from one window to another) results in a Tracker error message box (during Tracker Status progress window), showing a large negative system error code.
dd if=/dev/zero of=/ToBe/zerofile
stops and presents the error message
Read-only file system
After each of these ways to reproduce, unexpected high CPU usage remains, and the volume has become read-only - no further files can be written or removed. But the volume is neither shown as full, nor could it theoretically be full number-wise. For i) it was slightly over 2400 MB the first time, for ii) and iii) slightly above to 2380 MB.
In each case,
chkbfs on BeOS Max is able to repair the volume, it fixes
block allocation mismatches.
System is a real P4 with HyperThreading (SMP), 512 MB DDR RAM. firewire bus_manager was removed to avoid issues like on gcc4, no difference.
The partition was created using GParted on Linux, left unformatted, it is being shown as
Linux native (not
BeOS) in BeOS' DriveSetup. The partition was most likely initialized with Haiku's DriveSetup, using default values. Despite the apparently wrong partition type, BFS filesystem is always recognized correctly.
bfsinfo -s /dev/disk/ide/ata/0/slave/0/0_1 on BeOS I get this twice, in the clean state:
disk_super_block: name = "ToBe" magic1 = 0x42465331 (BFS1) valid fs_byte_order = 0x42494745 (BIGE, little endian) block_size = 2048 block_shift = 11 num_blocks = 2096482 used_blocks = 1174951 inode_size = 2048 magic2 = 0xdd121031 (...1) valid blocks_per_ag = 4 ag_shift = 16 num_ags = 32 flags = 0x434c454e (CLEN) log_blocks = (0, 129, 2048) log_start = 1483 log_end = 1483 magic3 = 0x15b6830e root_dir = (8, 0, 1) indices = (0, 2177, 1)