Re: rumpdisk status
If I remember well, Qemu usually has problems emulating SATA devices. Maybe can be necessary to test It over real hardware El mar, 24 nov 2020 a las 7:59, Samuel Thibault () escribió: > Damien Zammit, le mar. 24 nov. 2020 11:15:15 +1100, a ecrit: > > On 24/11/20 5:16 am, Samuel Thibault wrote: > > > Had you tested support for cd-rom? With qemu I am getting a media sense > > > error with status 0x50. > > > > I think that was the reason for the qemu patch for syncing IDE cache > iirc. > > I thought so too and tried so, with the same result. > > Samuel > >
Re: rumpdisk status
Damien Zammit, le mar. 24 nov. 2020 11:15:15 +1100, a ecrit: > On 24/11/20 5:16 am, Samuel Thibault wrote: > > Had you tested support for cd-rom? With qemu I am getting a media sense > > error with status 0x50. > > I think that was the reason for the qemu patch for syncing IDE cache iirc. I thought so too and tried so, with the same result. Samuel
Re: rumpdisk status
On 24/11/20 5:16 am, Samuel Thibault wrote: > Hello, > > Had you tested support for cd-rom? With qemu I am getting a media sense > error with status 0x50. I think that was the reason for the qemu patch for syncing IDE cache iirc. Damien
Re: rumpdisk status
Hello, Had you tested support for cd-rom? With qemu I am getting a media sense error with status 0x50. Samuel
Re: rumpdisk status
On 11/11/20 5:58 am, Samuel Thibault wrote:
> Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit:
>> I also printed inside rumpdisk to dump the offsets before calling
>> pread/pwrite,
>> these offsets are sometimes wider than 32 bits, sometimes not.
>
> Ok. Do pread/pwrite get called concurrently, or is pread/pwrite always
> finished before the next one starts?
Looks like all the pread/pwrites occur serially one-by-one with no overlap.
I tried booting off IDE and mounting 2x rumpdisks with gdb attached.
I tried to mount the second partition twice and got two failures,
root@zamhurd:~# mount /dev/wd0s3b /part3 -t ext2 -o ro
RUMP: OPEN: /dev/wd0d
ext2fs: /dev/wd0s3b: panic: get_hypermetadata: Cannot read hypermetadata
mount: cannot start translator /hurd/ext2fs: Translator died
root@zamhurd:~# mount /dev/wd0s3b /part3 -t ext2 -o ro
RUMP: OPEN: /dev/wd0d
ext2fs: /dev/wd0s3b: panic: get_hypermetadata: Cannot read hypermetadata
mount: cannot start translator /hurd/ext2fs: Translator died
then on the third time running the same command I got the following crash and
backtrace in rumpdisk.static:
root@zamhurd:~# mount /dev/wd0s3b /part3 -t ext2 -o ro
RUMP: OPEN: /dev/wd0d
/hurd/crash: /hurd/rumpdisk.static(777) crashed, signal {no:11, code:2, error:2}
, exception {1, code:2, subcode:16}, PCs: {0x804d77e, 0x81c0ecc, 0x81c0ecc, 0x81
c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0e
cc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc,
0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc, 0x81c0ecc}, writing core
file.
ext2fs: /dev/wd0s3b: panic: get_hypermetadata: Cannot read hypermetadata
mount: cannot start translator /hurd/ext2fs: Translator died
```
(gdb) bt full
#0 0x0804d77e in ports_port_deref (portstruct=0x10040420) at
../../libports/port-deref.c:30
pi = 0x10040420
result =
#1 0x08049dd1 in device_open (reply_port=115, reply_port_type=18, mode=3,
name=0x1fffd5c "/dev/wd0",
devp=0x2001d64, devicePoly=0x1fffc7c) at ../../rumpdisk/block-rump.c:257
err =
bd =
dev_name = "/dev/wd0d\000\061\b(\327\004\b
\323\061\bc\000\000\000\001\000\000\000\001\000\000"
media_size = 2
block_size = 137446780
#2 0x0804a25a in ds_device_open (open_port=99, reply_port=115,
reply_port_type=18, mode=3,
name=0x1fffd5c "/dev/wd0", devp=0x2001d64, devicePoly=0x1fffc7c) at
../../libmachdev/ds_routines.c:112
i = 0
dev_master = 3
err = 2502
#3 0x0804b319 in _Xdevice_open (InHeadP=0x1fffd30, OutHeadP=0x2001d40) at
deviceServer.c:125
In0P = 0x1fffd30
OutP = 0x2001d40
msgh_simple =
modeCheck = {msgt_name = 2, msgt_size = 32, msgt_number = 1,
msgt_inline = 1, msgt_longform = 0,
msgt_deallocate = 0, msgt_unused = 0}
deviceType =
master_port =
reply_port =
devicePoly = 134525592
#4 0x0804a6d9 in demuxer (inp=0x1fffd30, outp=0x2001d40) at
../../libmachdev/trivfs_server.c:479
routine =
#5 0x0804da8d in internal_demuxer (inp=0x1fffd30, outheadp=)
at ../../libports/manage-one-thread.c:96
pi = 0x1003ef40
link = {thread = 4, next = 0x0, prevp = 0x1003ef5c, notifies = 0x0,
interrupted_next = 0x1fffd30}
status =
err =
outp = 0x2001d40
RetCodeType =
#6 0x0815fea0 in mach_msg_server_timeout ()
No symbol table info available.
#7 0x0804db65 in ports_manage_port_operations_one_thread (bucket=0x10002c50,
demuxer=0x804a6a0 ,
timeout=0) at ../../libports/manage-one-thread.c:120
thread = {color = 1}
err =
#8 0x0804b132 in machdev_trivfs_server (bootstrap=9) at
../../libmachdev/trivfs_server.c:515
fsys = 0x10002d10
err =
#9 0x08048f2c in main (argc=1, argv=0x2003ef4) at ../../rumpdisk/main.c:126
bootstrap = 9
err = 0
t = 27
```
Something fishy is going on.
Damien
Re: rumpdisk status
Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit: > I also printed inside rumpdisk to dump the offsets before calling > pread/pwrite, > these offsets are sometimes wider than 32 bits, sometimes not. Ok. Do pread/pwrite get called concurrently, or is pread/pwrite always finished before the next one starts? Samuel
Re: rumpdisk status
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: 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 = 0xcbba0 found /dev/wd0d d m u ya G _ G _ SG _8 a MB 62 G /mnt3dia/damien/1c0c6182- rump kernel halting...f19aa22 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 0xbba0, 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. Damien
Re: rumpdisk status
Damien Zammit, le mar. 10 nov. 2020 13:17:52 +1100, a ecrit: > On 10/11/20 10:39 am, Samuel Thibault wrote: > >> sdd2 is / that boots with rumpdisk.static > >> sdd3 is the second partition I am trying to mount with the injected > >> translator > > > > That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its > > off_t etc. will be 32bit, thus probably issues with 4GiB-ness. > > 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. Samuel
Re: rumpdisk status
Hi, On 10/11/20 10:39 am, Samuel Thibault wrote: >> sdd2 is / that boots with rumpdisk.static >> sdd3 is the second partition I am trying to mount with the injected >> translator > > That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its > off_t etc. will be 32bit, thus probably issues with 4GiB-ness. It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default: set -e; gcc -std=gnu99 -fgnu89-inline -Wall -g -O3 -fno-strict-aliasing -g -O2 -I. -I../../rumpdisk -I.. -I../.. -I../include -I../../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DPACKAGE_NAME=\"GNU\ Hurd\" -DPACKAGE_TARNAME=\"hurd\" -DPACKAGE_VERSION=\"0.9\" -DPACKAGE_STRING=\"GNU\ Hurd\ 0.9\" -DPACKAGE_BUGREPORT=\"bug-hurd@gnu.org\" -DPACKAGE_URL=\"http://www.gnu.org/software/hurd/\; -DHAVE_MIG_RETCODE=1 -DHAVE_FILE_EXEC_PATHS=1 -DHAVE_EXEC_EXEC_PATHS=1 -DHAVE__HURD_EXEC_PATHS=1 -DUTIME_NOW=-1 -DUTIME_OMIT=-2 -DHAVE_LIBCRYPT=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_PARTED_PARTED_H=1 -DHAVE_LIBPARTED=1 -DHAVE_LIBUUID=1 -DHAVE_LIBDL=1 -DYYTEXT_POINTER=1 -DX11_PREFIX=\"/usr\" -DHAVE_DAEMON=1 -DHAVE_STRUCT_THREAD_SCHED_INFO_LAST_PROCESSOR=1 -DHAVE_BLKID=1 -M -MG ../../rumpdisk/block-rump.c | sed > block-rump.d.new -e 's%block-rump\.o:%block-rump.o block-rump_pic.o block-rump_p.o block-rump.d: %' -e 's% [^ ]*/gcc-lib/[^ ]*\.h%%g' Damien
Re: rumpdisk status
Damien Zammit, le mar. 10 nov. 2020 11:01:29 +1100, a ecrit: > On 10/11/20 6:06 am, Samuel Thibault wrote: > > Perhaps add prints in the rump code to determine what really returns > > that error and why. Possibly it's really a constraint of wd0d, perhaps > > it can only be opened once at a time. > > I am getting EBUSY when trying to reopen /dev/wd0d in rump_sys_open(). So you'd have to use the same rump fd. That shouldn't be a problem, really. Samuel
Re: rumpdisk status
Damien Zammit, le mar. 10 nov. 2020 10:33:39 +1100, a ecrit: > Hi, > > On 10/11/20 6:12 am, Samuel Thibault wrote: > > Btw, is your second partition within small bounds? (e.g. within 4GiB > > that can be expressed with 32bit integers) > > Device Boot Start End Sectors Size Id Type > /dev/sdd12048 1953791 1951744 953M 82 Linux swap / Solaris > /dev/sdd2 1953792 22925312 20971521 10G 83 Linux > > sdd2 is / that boots with rumpdisk.static > sdd3 is the second partition I am trying to mount with the injected translator That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its off_t etc. will be 32bit, thus probably issues with 4GiB-ness. Samuel
Re: rumpdisk status
Hi, On 10/11/20 6:12 am, Samuel Thibault wrote: > Btw, is your second partition within small bounds? (e.g. within 4GiB > that can be expressed with 32bit integers) Device Boot Start End Sectors Size Id Type /dev/sdd12048 1953791 1951744 953M 82 Linux swap / Solaris /dev/sdd2 1953792 22925312 20971521 10G 83 Linux /dev/sdd3 106811392 316526592 209715201 100G 83 Linux /dev/sdd4 316528640 368962049 52433410 25G 83 Linux sdd2 is / that boots with rumpdisk.static sdd3 is the second partition I am trying to mount with the injected translator Damien
Re: rumpdisk status
Samuel Thibault, le lun. 09 nov. 2020 20:06:28 +0100, a ecrit: > I'd say track the offset within the pread calls, to make sure that it is > not getting lost along the path. Also, I'd say put prints around the pread and pwrite calls. Actually now realizing that rumpdisk is for now single-threaded, they shouldn't even be getting intermixed at all. Btw, is your second partition within small bounds? (e.g. within 4GiB that can be expressed with 32bit integers) Samuel
Re: rumpdisk status
Damien Zammit, le lun. 09 nov. 2020 19:43:05 +1100, a ecrit:
> On 9/11/20 4:50 am, Samuel Thibault wrote:
> > But you can as well replace these two calls with a single tall to
> > rump_sys_pread() that avoids such issue (ditto for write).
>
> http://git.zammit.org/hurd-sv.git/log/
>
> Even with the new pread/pwrite calls, it still seems to mix up the
> reads/writes
> between the ext2fs and tune2fs clients.
ergl.
> Using branch above but if I comment out the following line :
>
> diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
> index befe0dbb..be6e38d9 100644
> --- a/rumpdisk/block-rump.c
> +++ b/rumpdisk/block-rump.c
> @@ -205,8 +205,6 @@ device_open (mach_port_t reply_port, mach_msg_type_name_t
> reply_port_type,
>mach_print(dev_name);
>mach_print("\n");
>
> - /* Find previous device or open if new */
> - bd = search_bd (dev_name);
>if (!bd)
> {
>err = machdev_create_device_port (sizeof (*bd), );
>
> so it always opens new regardless of device, dir_lookup("dev/wd0s3") returns
> no such device.
Perhaps add prints in the rump code to determine what really returns
that error and why. Possibly it's really a constraint of wd0d, perhaps
it can only be opened once at a time.
I'd say track the offset within the pread calls, to make sure that it is
not getting lost along the path.
> Do we need multithreaded device_read / device_write as well as pread/pwrite?
There shouldn't be any requirement for multithread. At best it would
bring more problems that fix any :)
In the long run for good performance we'd probably want multithread
+ using aio_read/write, but pread/pwrite should be working fine, and
proceeding further would only be asking for more troubles, so better
first fix things with pread/pwrite.
Samuel
Re: rumpdisk status
Hi,
On 9/11/20 4:50 am, Samuel Thibault wrote:
> But you can as well replace these two calls with a single tall to
> rump_sys_pread() that avoids such issue (ditto for write).
http://git.zammit.org/hurd-sv.git/log/
Even with the new pread/pwrite calls, it still seems to mix up the reads/writes
between the ext2fs and tune2fs clients. (using branch above).
Using branch above but if I comment out the following line :
diff --git a/rumpdisk/block-rump.c b/rumpdisk/block-rump.c
index befe0dbb..be6e38d9 100644
--- a/rumpdisk/block-rump.c
+++ b/rumpdisk/block-rump.c
@@ -205,8 +205,6 @@ device_open (mach_port_t reply_port, mach_msg_type_name_t
reply_port_type,
mach_print(dev_name);
mach_print("\n");
- /* Find previous device or open if new */
- bd = search_bd (dev_name);
if (!bd)
{
err = machdev_create_device_port (sizeof (*bd), );
so it always opens new regardless of device, dir_lookup("dev/wd0s3") returns no
such device.
?2004hroot@zamhurd:~# showtrans /dev/wd0s3
/hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0
?2004hroot@zamhurd:~# tune2fs -l /dev/wd0s3
tune2fs 1.45.5 (07-Jan-2020)
RUMP: OPEN: /dev/wd0d
RUMP: OPEN: /dev/wd0d
tune2fs: No such device or address while trying to open /dev/wd0s3
Couldn't find valid filesystem superblock.
root@zamhurd:~#
rpctrace output:
---
27<--73(pid619)->dir_lookup ("dev/wd0s3" 1 0)RUMP: OPEN: /dev/wd0d
RUMP: OPEN: /dev/wd0d
= 0x4006 (No such device or address)
---
Do we need multithreaded device_read / device_write as well as pread/pwrite?
Damien
Re: rumpdisk status
Samuel Thibault, le dim. 08 nov. 2020 18:50:12 +0100, a ecrit: > But you can as well replace these two calls with a single tall to > rump_sys_pread() that avoids such issue (ditto for write). (IIRC we had already discussed about it and left it in some TODO-list, is that recorded somewhere?) Samuel
Re: rumpdisk status
Damien Zammit, le dim. 08 nov. 2020 16:10:32 +1100, a ecrit: > I am using the libparted access method via > storeio `-T typed part:x` but using the same underlying device. > Do I need to make opening a new partition on the same disk device > open a new handle on the same disk? Since your device_read() is doing rump_sys_lseek() rump_sys_read() then yes, you'd absolutely need different handles, otherwise concurrent requests will get mixtures of offsets. But you can as well replace these two calls with a single tall to rump_sys_pread() that avoids such issue (ditto for write). Samuel
Re: rumpdisk status
Hi Samuel, When I access a different partition on the same disk, I am using the libparted access method via storeio `-T typed part:x` but using the same underlying device. Do I need to make opening a new partition on the same disk device open a new handle on the same disk? If so, how? I think currently, it does not reopen the same device twice, it just passes the caller a send right to the old one. Damien On 8/11/20 10:51 am, Samuel Thibault wrote: > Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit: >> On 8/11/20 2:35 am, Samuel Thibault wrote: >>> Perhaps, before mounting, try to run >> >> DISK >>> fdisk -l /dev/wd0 >> >> root@zamhurd:~# showtrans /dev/wd0 >> /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 >> root@zamhurd:~# fdisk -l /dev/wd0 >> ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; >> PLEAS > > It looks to me like your translator is mixing read/write requests from > the different clients (bootstrap ext2fs and fdisk). > > Samuel >
Re: rumpdisk status
Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit: > On 8/11/20 2:35 am, Samuel Thibault wrote: > > Perhaps, before mounting, try to run > > DISK > > fdisk -l /dev/wd0 > > root@zamhurd:~# showtrans /dev/wd0 > /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 > root@zamhurd:~# fdisk -l /dev/wd0 > ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; > PLEAS It looks to me like your translator is mixing read/write requests from the different clients (bootstrap ext2fs and fdisk). Samuel
Re: rumpdisk status
Hi, On 8/11/20 2:35 am, Samuel Thibault wrote: > Perhaps, before mounting, try to run DISK > fdisk -l /dev/wd0 root@zamhurd:~# showtrans /dev/wd0 /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# fdisk -l /dev/wd0 ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: UNCLEANED FILESYSTEM NOW WRITABLE ext2fs: part:2:device:/dev/wd0: warning: bit already cleared for inode 49995 ext2fs: part:2:device:/dev/wd0: warning: bit already cleared for inode 50221 ext2fs: part:2:device:/dev/wd0: warning: bit already cleared for inode 50221 ext2fs: ../../libdiskfs/disk-pager.c:109: fault_handler: Assertion 'err' failed. /hurd/startup: Crashing system; essential task proc died startup: notifying random of reboot... ROOTFS > tune2fs -l /dev/wd0s1 root@zamhurd:~# ls /dev/wd0s2 ls: cannot access '/dev/wd0s2': No such file or directory ?2004hroot@zamhurd:~# touch /dev/wd0s2 root@zamhurd:~# settrans -ap /dev/wd0s2 /hurd/storeio -T typed part:2:device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# showtrans /dev/wd0s2 /hurd/storeio -T typed part:2:device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# tune2fs -l /dev/wd0s2 tune2fs 1.45.5 (07-Jan-2020) ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: UNCLEANED FILESYSTEM NOW WRITABLE ext2fs: ../../libdiskfs/disk-pager.c:109: fault_handler: Assertion 'err' failed. /hurd/startup: Crashing system; essential task proc died startup: notifying random of reboot... > Also, perhaps first try to mount it readonly. root@zamhurd:~# showtrans /dev/wd0s3 /hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# mount /dev/wd0s3 /mnt -o ro -t ext2 LONG PAUSE ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMOUNTED CLEANLY; PLEAS E fsck ext2fs: part:2:device:/dev/wd0: warning: UNCLEANED FILESYSTEM NOW WRITABLE ext2fs: ../../libdiskfs/disk-pager.c:109: fault_handler: Assertion 'err' failed. /hurd/startup: Crashing system; essential task proc died startup: notifying random of reboot... Damien
Re: rumpdisk status
Hello, Damien Zammit, le sam. 07 nov. 2020 18:39:32 +1100, a ecrit: > I think I managed to get the rumpdisk bootstrapped translator installed on a > filesystem node, Yay :) > but when I try to mount a second partition on the same disk it crashes the / > partition. Perhaps, before mounting, try to run fdisk -l /dev/wd0 tune2fs -l /dev/wd0s1 tune2fs -l /dev/wd0s3 to check that it is indeed reading a different filesystem UUID. Also, perhaps first try to mount it readonly. Samuel
