Re: rumpdisk status

[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 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), &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