in-situ conversion to FT disk config?

[Ben Scott]

On 11/15/05, Michael ODonnell <michael.odonnell at comcast.net> wrote:
> theoretically it should be possible to lay the {RAID,LVM,otherFT}
> metadata down on the disks such that any existing
> MBR,filesystem} bits remain untouched and the disk becomes
> usable as part of an FT config ...

  Sure!  Just use the extra space at the start/end of the partition
you left unused for future expansion of metadata!  What's that?  You
allocated the entire disk to the filesystem?  Well, then, tsk tsk
tsk... ;-)

On 11/15/05, Bill McGonigle <bill at bfccomputing.com> wrote:
> I bet this has something to do with the MS-DOS-style disk layout Linux
> x86 uses.  There just isn't extra space to add the proper headers, I'm
> guessing.

  It isn't really the IBM-PC partition layout, per se, but a
consequence of the Unix philosophy, which Linux tends to follow. 
Linux layers filesystems on top of RAID and other device management
functions.  The RAID stuff takes arbitrary block devices, does the
RAID magic, and then presents the result as arbitrary block devices.

  There are some major advantages to this.  It keeps the code a *lot*
cleaner, as now the filesystem doesn't have know about device
management.  It lets you store arbitrary filesystems or other data on
arbitrary device types.  That's one of the reasons things like network
block devices and crypto loopback and stuff like that tend to show up
on Linux first; they're a lot easier to implement.

  The downside is, as noted above in my tougne-in-cheek reply to
Michael ODonnell, since the filesystem is not aware of device
management, there are no provisions for device management in the
filesystem.  The RAID metadata takes up room on disk above and beyond
the filesystem.  That space has to come from somewhere.

  It might be possible to shrink (and shift, if needed) the filesystem
to make room for the RAID metadata, but that would likely take almost
as long as just doing the copy, and put the data (which is apparently
not backed up anywhere) at decidedly higher risk.

>    http://blog.bfccomputing.com/index.php?p=25
[link to rsync]

  Or, for something simple like this,

          cp -a /source /target/

will do the job nicely, too (the "-a" is a GNU extension to "cp").

-- Ben "Soylent green is people!" Scott