Re: [9fans] Anatomy of a vblade image

Re: [9fans] Anatomy of a vblade image

[matt]

>
> however you can use the -i switch to initialize a blank
> file.  (you're free to use a raw disk or partition, too.)
>
> - erik
>
>
or say "damn, where did my partition table go !"

I can't remember if I lost any work :)

strings /dev/sdC0/plan9 will let me know eventually !

note to self, be more careful when messing around at storage :>


I'm serving drives to WinXP64 via AOE with http://winaoe.org/
I've had a few blue screens but I think they have been caused by the
server side serving bad data. If the vblade goes away after being
mounted the NT kernel keeps trying to read it which amounts to waiting
for network packets to arrive and of course they never do so any NT
syscalls take forever (though they run eventually). It does come back to
life even if you vblade a different sized disk.

Re: [9fans] Anatomy of a vblade image

[erik quanstrom]

> I'm serving drives to WinXP64 via AOE with http://winaoe.org/
> I've had a few blue screens but I think they have been caused by the
> server side serving bad data.

what do you mean by "server side"?

> If the vblade goes away after being
> mounted the NT kernel keeps trying to read it which amounts to waiting
> for network packets to arrive and of course they never do so any NT
> syscalls take forever (though they run eventually). It does come back to
> life even if you vblade a different sized disk.

it is expected behavior for aoe devices to be
able to take short vacations.  our main fs uses
aoe.  we can upgrade the shelf without bringing
down the fs.

it does sounds like the free windows aoe driver
needs to handle the case where storage goes
away more gracefully.  it may be that it is retransmitting
too agressively.

- erik

Re: [9fans] Anatomy of a vblade image

[matt]

erik quanstrom wrote:
>> I'm serving drives to WinXP64 via AOE with http://winaoe.org/
>> I've had a few blue screens but I think they have been caused by the
>> server side serving bad data.
>>
>
> what do you mean by "server side"?
>
My dodgy programming :> I'm hacking around in vblade.c
Sorry, I see now I should have made that clear.


>
> it does sounds like the free windows aoe driver
> needs to handle the case where storage goes
> away more gracefully.  it may be that it is retransmitting
> too agressively.
>
>
I haven't had the ethernet sniffer looking at it


I got my data back btw. I ran the installer and guessed at what I'd told
fdisk :>

[9fans] offtopic: winaoe

[erik quanstrom]

> erik quanstrom wrote:
>>> I'm serving drives to WinXP64 via AOE with http://winaoe.org/

i've been ignoring this driver.  i'm worthless at windows.
(it's the small blessings, right?)  but now that i've taken
a look, i naively wonder about some things.

i think i see why syscalls take so long when a device has gone
missing.  the thread Thread (seems to be roughly a kproc?) doesn't
appear to have a sleep in it so it ends up grabbing spin locks all the
time.  this is going to be hell on performance.  without thinking very
hard about the problem, i think that spin lock could be made a QLock,
if such a concept exists in windows.  also, there should be a sleep
of 25ms or so to keep the sweeper thread from chewing cpu for no
reason.  AoERequest would then need to send its own requests or
kick Thread into action.  i would think this will have a big effect on
windows performance when a device is down, since it is effectively
running this in a tight loop:

	for(;;){
		KeAcquireSpinLock(&SpinLock, &Irql);
		KeQuerySystemTime(&CurrentTime);
		KeReleaseSpinLock(&SpinLock, Irql);
	}

it's pretty impressive that windows withstands this abuse at all.

another quirk i see is the way the outstanding requests are managed
doesn't appear to square with the standard.  this driver starts
declaring Tags failed if the number of outstanding requests is
>64.  (again in Thread.)  the number of outstanding tags needs to
be bounded by the maximum frames the aoe device allows and
if the driver itself has hit its limit, the io should sleep until there
is room in the queue.

- erik