Re: rumpdisk status

2020-11-24 Thread Almudena Garcia
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: >

Re: rumpdisk status

2020-11-23 Thread Samuel Thibault
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 thoug

Re: rumpdisk status

2020-11-23 Thread Damien Zammit
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

2020-11-23 Thread Samuel Thibault
Hello, Had you tested support for cd-rom? With qemu I am getting a media sense error with status 0x50. Samuel

Re: rumpdisk status

2020-11-13 Thread Damien Zammit
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

Re: rumpdisk status

2020-11-10 Thread Samuel Thibault
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

Re: rumpdisk status

2020-11-10 Thread Damien Zammit
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:

Re: rumpdisk status

2020-11-09 Thread Samuel Thibault
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 _

Re: rumpdisk status

2020-11-09 Thread Damien Zammit
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 i

Re: rumpdisk status

2020-11-09 Thread Samuel Thibault
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. >

Re: rumpdisk status

2020-11-09 Thread Damien Zammit
Hi, 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_op

Re: rumpdisk status

2020-11-09 Thread Samuel Thibault
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 Typ

Re: rumpdisk status

2020-11-09 Thread Damien Zammit
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 / Solar

Re: rumpdisk status

2020-11-09 Thread Samuel Thibault
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,

Re: rumpdisk status

2020-11-09 Thread Samuel Thibault
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 t

Re: rumpdisk status

2020-11-09 Thread Damien Zammit
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 b

Re: rumpdisk status

2020-11-08 Thread Samuel Thibault
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?) Samue

Re: rumpdisk status

2020-11-08 Thread Samuel Thibault
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_r

Re: rumpdisk status

2020-11-07 Thread Damien Zammit
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 cu

Re: rumpdisk status

2020-11-07 Thread Samuel Thibault
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:~# fdis

Re: rumpdisk status

2020-11-07 Thread Damien Zammit
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 UNMO

Re: rumpdisk status

2020-11-07 Thread Samuel Thibault
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, t

rumpdisk status

2020-11-06 Thread Damien Zammit
Hi all, I think I managed to get the rumpdisk bootstrapped translator installed on a filesystem node, but when I try to mount a second partition on the same disk it crashes the / partition. ``` root@zamhurd:~# showtrans /dev/wd0s3 /hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0 ?2