[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rumpdisk status

From: Damien Zammit
Subject: Re: rumpdisk status
Date: Tue, 10 Nov 2020 21:11:31 +1100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

Hi Samuel,

On 10/11/20 6:21 pm, Samuel Thibault wrote:
>> It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default:
> But is rumpkernel itself also built with it?
> Really, better actually *test* that offsets are getting properly
> propagated.

Test program output:
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 298 GB, 620181 cyl, 16 head, 63 sec, 512 bytes/sect x 625142448 sectors
irq handler [10]: release a dead delivery port ee61c668 entry f5cef8e0
irq handler [10]: removed entry f5cef8e0
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (
using DMA)
Offset = 0xcbba00000
found /dev/wd0d
d  m u  ya      G _ G _  S    G _    8   a   MB 62 G   /mnt3dia/damien/1c0c6182-
rump kernel halting...f19aa    22 M2 t  )  U   9 \  qM
syncing disks... done
unmounting file systems...
unmounted rumpfs on / type rumpfs
unmounting done

I compiled a test program that opens the block device and reads a page
from the beginning of /dev/wd0s3 using rump libs and dumps it as ASCII above.

I tested in linux on the same disk with dd to dump the same page and it matches 
what hurd found with rump libs.
If I truncate the offset to 32 bits, ie 0xbba00000, it has different content.
Therefore, the 64 bit offsets seem to be propagating.
I also printed inside rumpdisk to dump the offsets before calling pread/pwrite,
these offsets are sometimes wider than 32 bits, sometimes not.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]