Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss- > bounces+blu=nedharvey.com at blu.org] On Behalf Of > > there is caching in the file system layer that we > wouldn't get with LVM, Think about it like this: On reads: The guest OS will read some file. If it's a partial file, or it's fragmented, then the guest OS is smart enough to know how much to readahead, and which sectors. Unfortunately, the host OS doesn't know any of that, and the host OS might be doing readahead for useless sectors. But the host OS is only going to do readahead when/if the disks were otherwise going to be idle. So there's no benefit and no harm, regardless of whether you have LVM or file backing. On async writes: The guest OS will be buffering these anyway. The guest OS writes them to "disk." The host OS now buffers them. They're queued up and going to disk, in the background, everything is smooth. No benefit and no harm either way, whether you have LVM or file backing. On sync writes: The guest OS writes something to "disk" and issues the flush command to the "device." The host OS then interprets this, and issues the actual flush command to the actual device. It returns exactly the same as the guest would have thought. No benefit and no harm either way, whether you have LVM or file backing. I say it's neutral either way.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |