* Re: [9fans] Anatomy of a vblade image [not found] <bcf6455ae643bb5cb35cb1b7877e2401@quanstro.net> @ 2008-07-13 20:13 ` matt 2008-07-13 20:54 ` erik quanstrom 0 siblings, 1 reply; 4+ messages in thread From: matt @ 2008-07-13 20:13 UTC (permalink / raw) To: 9fans >> Fans of the OS Plan 9 from Bell Labs > > 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Anatomy of a vblade image 2008-07-13 20:13 ` [9fans] Anatomy of a vblade image matt @ 2008-07-13 20:54 ` erik quanstrom 2008-07-13 22:20 ` matt 0 siblings, 1 reply; 4+ messages in thread From: erik quanstrom @ 2008-07-13 20:54 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [9fans] Anatomy of a vblade image 2008-07-13 20:54 ` erik quanstrom @ 2008-07-13 22:20 ` matt 2008-07-14 14:24 ` [9fans] offtopic: winaoe erik quanstrom 0 siblings, 1 reply; 4+ messages in thread From: matt @ 2008-07-13 22:20 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 :> ^ permalink raw reply [flat|nested] 4+ messages in thread
* [9fans] offtopic: winaoe 2008-07-13 22:20 ` matt @ 2008-07-14 14:24 ` erik quanstrom 0 siblings, 0 replies; 4+ messages in thread From: erik quanstrom @ 2008-07-14 14:24 UTC (permalink / raw) To: mattmobile, 9fans > 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-07-14 14:24 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bcf6455ae643bb5cb35cb1b7877e2401@quanstro.net> 2008-07-13 20:13 ` [9fans] Anatomy of a vblade image matt 2008-07-13 20:54 ` erik quanstrom 2008-07-13 22:20 ` matt 2008-07-14 14:24 ` [9fans] offtopic: winaoe erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).