[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-users] RE: Differences in performance between file and LVM based images.
> -----Original Message----- > From: Ligesh [mailto:myself@xxxxxxxxxx] > Sent: 23 August 2006 18:02 > To: Petersson, Mats > Cc: xen-users@xxxxxxxxxxxxxxxxxxx > Subject: Re: Differences in performance between file and LVM > based images. > > On Wed, Aug 23, 2006 at 05:52:13PM +0200, Petersson, Mats wrote: > > > > Probably yes. How much? Don't know. > > > > But I was more referring to the fact that different applications do > > different things to disks in the first place, so the application > > behaviour may depend on "seek time" or "write time" or > "read time" in > > different proportions [1], so just using "hdparm" or > something like that > > wouldn't really be a useful measure of how some particular > application > > will perform on any given setup. > > > > Now that I have given it some thought, it seems to me that > there's going to be some performance issues with files, and > it might even be severe. For each seek, the control has to go > through the ext3 driver, which is the only guy who knows how > the file is structured. So if you are doing a seek on loop > device, the OS needs the help of the ext3 driver to translate > this into a position inside the file. > > The steps involved in doing a an operation on a loop device would be: > > 1) Linux will have to first locate the file on the main > filesystem. (Or does linux use the file's harddisk postion as > the identifier for the loop device?...). Finding the file should only happen ONCE when it's being opened (whether this happens in a loop-back filesystem driver or otherwise... So unless your starting and stopping the virtual machine or mounting/unmouting a device, it's not really relevant to the overhead of using files vs. some other storage for virtual disks. > > 2) Then it has to find out how the file is structured in the > harddisk. Yes, that's true. > > 3) To read/write anything, it will again need the entire > ext3 logic for file structure. Yes. But hopefully this is fairly efficient. And it's quite feasible for the EXT3 system to cache data regarding where things are kept and how to get at it quickly. There's certainly overhead with using a file-system based virtual disk, but I don't think it's a HUGE overhead. > > Anyway, some benchmarks would be great. And I think this > should be explicitly mentioned in the documentation. Primary > purpose of virtualization is to squeeze the maximum out of > hardware, and so we cannot really afford performance > penalties arising from wrong implementation decisions. Yes, but my original point is that it's not going to be straightforward to say under which circumstance the administrator should choose what. I also don't agree that virtualization is (always) about squeezing the most performance out of the hardware. It is use-case for virtualization [for example merging multiple servers into one physical machine], but there are many other use-cases where other features given by virtualization is much more important. One of those would be security and the ability to migrate a guest from one physical machine to another. > > I will see if I can do some benchmarks. Please do. > > > Thanks. > > -- > :: Ligesh :: http://ligesh.com > > > > > _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |