[SATLUG] file server design
justizin at siggraph.org
Tue Dec 5 12:06:07 CST 2006
On 12/5/06, Travis H. <travis at subspacefield.org> wrote:
> By the way, I've been reading storagemojo.com a bit and came up with
> this design for a file server.
> Basically, the problem I had with LVM was that I had to operate in
> a one-dimensional space when resizing filesystems.
> So I read about this trick; make each filesystem a loopback onto a file,
> that is then stored on a file system. Export the loopback filesystems
> as AoE or iSCSI. Now, to resize, or copy, or anything, you can use the files
> instead of a block device. You can expand one "filesystem" or the other
> without doing _any_ shuffling about. And you can probably even create
> them as sparse files!
> There is an extra layer of overhead, like when you make a database reside
> on a file system instead of a partition/block device, but it's a small
> penalty compared to the cost (in time) of resizing when _not_ using this
I disagree staunchly that it would be a small penalty - you would have
horrible fragmentation unless you were on OSX with hot file sync or
You could, however, put a single loopback file into an LVM volume,
then create a larger LVM volume, move the data, and resize2fs or
Being non-contiguous is bad news.
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
More information about the SATLUG