Opened 13 years ago

Closed 13 years ago

#1075 closed bug (fixed)

Wrong/Incomplete Data Read from Disk

Reported by: bonefish Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Disk Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


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 : ;

# 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:


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:

Attachments (2)

serial (20.6 KB ) - added by bonefish 13 years ago.
part of the serial debug output
reiserfs.out (10.0 KB ) - added by bonefish 13 years ago.
Correct Dump of the On-Disk Data

Download all attachments as: .zip

Change History (6)

by bonefish, 13 years ago

Attachment: serial added

part of the serial debug output

by bonefish, 13 years ago

Attachment: reiserfs.out added

Correct Dump of the On-Disk Data

comment:1 by bonefish, 13 years ago

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.

comment:2 by bonefish, 13 years ago

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,

Test with:

/system/servers/UserlandFSServer reiserfs

comment:3 by bonefish, 13 years ago

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

comment:4 by bonefish, 13 years ago

Resolution: fixed
Status: newclosed

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?

Note: See TracTickets for help on using tickets.