Thanks for the reply. I have opted for an aoe backend on top of md -> LVM for a number of reasons aside from the ones I have mentioned.
LVM can fragment blocks better with its allocation policies whilst gluster saves files on a per-file basis all across its cluster - thats not good for what I will be using it for. The ability to resize on the fly and in a live environment appeals to me with LVM along with being able to manage extents. Now my only concern is rebuilding 1TB raid arrays is likely to take a long time since I have a limited bandwidth. 1GB with potentially 8 aoe machines! So im looking for 1MB a second - over a day and a half for a rebuild! Im also hoping using block i/o along all paths rather than block i/o to file i/o will reduce overhead. I am actually going to retransport logical volumes made from the aoe backend as iscsi for direct client connection! Id be much happier if I had a 10GB aoe network behind all of this but one will see how this works out in the long run soon enough. A couple more questions if I may, the default deadsecs parameter seems to be quite high. In the tests I have ran removing a vblade from a md->lvm->iscsi mounted drive causes lvm to deadlock until the device is marked as down, in turn this causes the client filesystem to remount read only due to the length of non responsivity - not good. Fedora 9 currently looks to be using version 47 of the aoe kernel module - I have had a brief look around without success - do you know when the deadsecs parameter became manually reconfigurable? I can of course always rebuild the module from source albeit I'd prefer not to. Is there any ballpark figures as to how many frames per second / bytes per second a direct aoe connection to a vblade would take when idle? (im not sure if theres at least a polling packet or anything). Frames per second would be nicer as I'll likely be changing the MTU. On Tue, 2008-09-02 at 11:38 -0400, Ed Cashin wrote: > On Fri, Aug 29, 2008 at 11:13:48PM +0100, Matthew Ife wrote: > ... > > a) When an initiator has found its target will it "remember" and always > > send to the same MAC address when sending future requests? Is there a > > timeout with this remembering assuming its there? Plus will it > > rediscover in the event it cannot find the mac address again? > > It depends on which AoE initiator you are using. The current Linux > aoe driver from the Coraid website will stop using a remote MAC > address if it is unsuccessfully retransmitting to the MAC address and > half of the number of seconds specified by the "aoe_deadsecs" > parameter have elapsed. > > More comments follow below. > > > b) Will running vblade off of a NAS level filesystem, be it Gluster or > > NFS be problematic? (bandwidth/latency issues aside for now - im > > thinking more about locking) > > > > c) Will concurrently running vblades in this manner cause all kinds of > > unpredictability - again, locking issues? > > Unfortunately, I bet you'd need a Gluster guru who really understands > what the vblade does and how it would interact with Gluster. Perhaps > mention the "sync" option to vblade so that the page cache gets > considered. > > My intuition is that this configuration is too complex and too far off > the beaten path to use if the possibility of failure is not acceptable > and the investment has no side benefits---Sometimes learning about > technologies has unforseeable benefits. > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Aoetools-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aoetools-discuss
