From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@9fans.net
Subject: Re: [9fans] 9vx
From: "Russ Cox" <rsc@swtch.com>
Date: Tue,  1 Jul 2008 10:40:47 -0400
In-Reply-To: <66b9839fdb955f8f969063ccff722c4c@quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20080701143831.E53B11E8C6B@holo.morphisms.net>
Topicbox-Message-UUID: d31daf4c-ead3-11e9-9d60-3106f5b1d025

> this must be a quirk of the interaction between
> devsd and fdisk.  by hand data does disappear:
>
> 	; lc
> 	9fat	ctl	data	nvram	plan9	raw
> 	; for(i in 9fat data nvram plan9 data)echo delpart $i>ctl
> 	; lc
> 	ctl	raw

You are allowed to delete the data partition.
The problem is that fdisk should not be trying to.
Since it doesn't do that on native Plan 9, there
must be some aspect of devsd that is not behaving
the same way under 9vx that it does under Plan 9.
The bug is in devsd, though you'll probably have to
add prints to fdisk to find it.

Plan 9:

glenda# disk/fdisk -p /dev/sdC0/data
part linux 63 58589055
part plan9 58589055 241248105
glenda#

9vx:

% bind '#Z' /n/unix
% echo loop rw /n/unix/dev/sda >/dev/sdctl
% disk/fdisk -p /dev/sd00/data
delpart data
part linux 63 476230860
part linuxswap 476230923 488392065
%

That's running on a different disk but the same
fdisk binary (the one from sources as of today,
dated May 10).

Russ