[SATLUG] file server design

[Justizin]

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
> paradigm.

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
whatever.

You could, however, put a single loopback file into an LVM volume,
then create a larger LVM volume, move the data, and resize2fs or
whatever.

Being non-contiguous is bad news.

-- 
Justizin, Independent Interactivity Architect
ACM SIGGRAPH SysMgr, Reporter
http://www.siggraph.org/