Wrong/Incomplete Data Read from Disk

[bonefish]

VMWare, 1 CPU, 256 MB RAM, 100 MB Haiku image (hrev20309) as IDE 0:0, 100 MB ReiserFS image as IDE 0:1, CD ROM IDE 1:0,...

When trying to mount the ReiserFS volume (through UserlandFS) readv_pos()/read_pos() retrieve incorrect data from the device for one of the blocks. I've traced the read requests to scsi_dsk:das_read() where they look OK. I dumped the read block in block_io:block_io_read() (io.c) showing the beginning reflect the actual data stored on disk, but the remainder is zero'd out. Of the two attempts to read the block in question the second one returned more of the correct data. An md5sum over the device returned the correct checksum, though.

Attached is the part of the serial debug output showing the dumped block. The second attachment shows a dump of the block how it should look like.

For testing ReiserFS via UserlandFS add the following to you UserBuildConfig:

# UserlandFS kernel add-on, server, and BeOS FS interface lib
AddFilesToHaikuImage beos system add-ons kernel file_systems : userlandfs ;
AddFilesToHaikuImage beos system servers : UserlandFSServer ;
AddFilesToHaikuImage beos system lib : libuserlandfs_beos_kernel.so ;

# settings file
local ufsSettings = <userlandfs!settings>userlandfs ;
SEARCH on $(ufsSettings)
	= [ FDirName $(HAIKU_TOP) src add-ons kernel file_systems userlandfs ] ;
AddFilesToHaikuImage home config settings kernel drivers : $(ufsSettings) ;

# ReiserFS
AddFilesToHaikuImage home config add-ons userlandfs : <userland>reiserfs ;

When Haiku has booted start the UserlandFSServer in one Terminal:

/system/servers/UserlandFSServer

and mount the volume in another one:

mkdir /mnt
mount -t userlandfs -p reiserfs /dev/disk/ata/0/slave/raw /mnt

I've uploaded my ReiserFS test image to:

​http://cs.tu-berlin.de/~bonefish/private/haiku_reiserfs_test_image.bz2

[bonefish]

part of the serial debug output

[bonefish]

Correct Dump of the On-Disk Data

[bonefish]

Disabling IDE DMA in the boot menu doesn't help with this problem. So it doesn't seem to be related with bug #985 in any obvious way.

[bonefish]

I wrote a little test program causing the same disk access pattern (reading the same sequence of 512 and 4096 byte blocks), but it wouldn't reproduce the bug. However, changing the UserlandFSServer to directly invoke the FSs mount() hook allows to run the server without the kernel add-on, and this way one still can reproduce it.

The change needs to be done in UserlandFSServer.cpp in UserlandFSServer::_CreateBeOSKernelInterface() after the block cache initialization, by inserting the following snippet:

void* volumeCookie;
vnode_id rootID;
fsOps->mount(7, "/dev/disk/ata/0/slave/raw", 0, NULL, 0, &volumeCookie,
    &rootID);
exit(1);

Test with:

/system/servers/UserlandFSServer reiserfs

[bonefish]

I can reproduce the bug with qemu (0.8.2, Linux).

[bonefish]

Spotted the bug in lock_memory(). Fixed in 20362.

I think get_memory_map() needs reviews, though. Since vm_translation_map_ops::query() never returns an error (x86), but a NULL address in what I would consider an error case (Huh, what's the point of a return value, if it is constant?), get_memory_map() fills the respective physical_entry() with NULL in such a case.

How about a get_memory_map_etc() with additional parameters returning the number of physical entries set and the total amount of they cover?