> Hmm, I'll look into using LVM first.
BEWARE -- there are teo thingw ahich both call themselves Linux LVM !
> It seems logical that someone would want to do this, right?
Expand their FS later -- sure ...
> I mean I'm just planning for the future in disk space,
Maybe not sensible ...
Maybe just wait, get a new, bigger, faster, cheaper, ... disk when needed ...
> but there's no reason to have the space at this point and I'm trying to
> avoid having to wipe things out and restore in the future,
Well ... copy ...
> so starting it with raid in mind from the get go seems like the way to go.
Sure -- my idea is to have a "mkfs" flag which says "leave space for a RAID SB
at the end" -- pretty trivial !
( Sure, one can alwqays tell mkfs the required number of blocks, but I prefer
to let the computer do the maths ! )
Makes moving a partition from raw to RAID1 a piece of piss !
Slam in the SB, hot add the second disk and you're flying !
I have tweaked mkraid to allow a "one off" mount of a raw device as RAID:
basal:~: really mkraid --one /dev/hda13 /dev/md14
handling MD device /dev/md14
analyzing super-block
disk 0: /dev/hda13, 1984kB, raid superblock at 1920kB
basal:~: really mkfs -b 4096 /dev/hda13
mke2fs 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
Linux ext2 filesystem format
Filesystem label=
512 inodes, 496 blocks
24 blocks (4.84%) reserved for the super user
First data block=0
Block size=4096 (log=2)
Fragment size=4096 (log=2)
1 block group
32768 blocks per group, 32768 fragments per group
512 inodes per group
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
basal:~: really sb.pl hda13
rdev hda13: md14 (psb=0) CSUM:0620a9cd S:6 superblock@001984
a92b4efc CT=Apr 18 07:47:29 1999, UT=Apr 18 07:47:29 1999,
SB: (V:0.90.0) ID:<ce1eb1e5.fd9b4d9a.eb0948a3.37fede70> CT:37198e11
L-1 S00001920 ND:1 RD:1 md14 LO:0 CS:4096
UT:37198e11 ST:6 AD:1 WD:1 FD:0 SD:0 CSUM:0620a9cd E:000000001
D 0: DISK<N:0,hda13(3,13),R:0,S:6>
THIS: DISK<N:0,hda13(3,13),R:0,S:6>
basal:~: really raidstop /dev/md14
basal:~: really fsck /dev/hda13
Parallelizing fsck version 1.12 (9-Jul-98)
e2fsck 1.12, 9-Jul-98 for EXT2 FS 0.5b, 95/08/09
/dev/hda13: clean, 11/512 files, 33/496 blocks
basal:~: really sb.pl -d hda13
sb.pl: /dev/hda13 disabled
basal:~:
(really is a "run this command as root" command)
Bingo -- one RAID ready FS (if it should ever be needed).
Who cares about lossing 64-127KB ?
Even though I have a tweaked mkraid, something along the lines of
raiddev /dev/md14
raid-level linear
persistent-superblock 1
nr-raid-disks 1
device /dev/hda13
(you might need a "chunk-size 4" or some such) should work ...
However, if it's linear that concerns you, there is less of a need.
If you are going to enlarge the ext2 FS anyway,m you can almost as easily do:
umount the FS
resize2fs it down a bit to make space for the SB
mkraid the new FS (this is non destructive!)
resize2fs the new md device to full size
mount the FS
> Heh, I didn't see any replies to this before today which usually says to
> me that I suggested something totally stupid. I hope not.
Nah -- possible just so simple ?
