[Gllug] Partioning advice needed

[Anthony Newman]

Nix wrote:
>> evaluate on the basis of the extra work and the difficulty added to
>> system recovery if you have, say, a botched kernel upgrade.
> 
> If you're using initramfs, no difficulty at all. That's one of the
> things that's so nice about initramfs: because the rootfs contents are
> linked into the kernel image, they never get out of synch, and if they
> worked in your old working kernel, they'll still work later, even if
> you've installed totally broken LVM tools in the meantime.

I have little choice but to use initramfs at home, where I'm running 
root-on-LVM-on-RAID just because I'd never done it before. If I cock up 
the kernel or initramfs (obviously unintentionally), I have to recover 
it by hand which takes ages. A few years ago I might have viewed that as 
fun, now it just pisses me off :)

It's odd that init{rd,ramfs} used to be one of those optional things, 
now people seem to see it as indispensable whether you actually need it 
or not. I just consider it an extra hassle and a hack to make things 
work that unfortunately became the norm.

I suppose if you use a distro that hides the magic behind some build 
utility it's easier to ignore it.


>> Compared to commercial storage options, which effectively provide
>> highly flexible redundant storage in software, Linux RAID/LVM has a
>> way to go yet.
> 
> I dunno. I'd say I've *got* `highly flexible redundant storage in
> software'. Many of the commercial RAID options in particular come with
> lovely extra features:
> 
> <snip informative stuff>


You get what you pay for as usual; the sort of stuff I was alluding to 
would probably cost a significant part of a person's lifetime salary 
over its 3-5 year lifetime. There's no reason why the technology under 
such things won't trickle down into the free implementations though, 
provided it isn't too heavily patented.

I'm being deliberately obtuse because I've been recently trying to make 
Linux RAID/LVM go fast, stay fast and be able to be made to go faster 
rather than just being able to store huge quantities of data (which is 
in itself trivial), and it isn't particularly easy. Adding more disks to 
try and give you greater throughput doesn't work if your data stays in 
the same place on the platters afterwards.

I've also seen no mention of parity scrubbing of RAID 4/5/6 arrays under 
Linux; anyone know if it's possible? I saw 500GB of data go down the pan 
last year because of an undetected disk error on a 14 disk RAID5 array. 
Which was nice.


>> [0] Maybe there are experimental ones, but not that I'd use for any
>> data I care about
> 
> ext3?

I probably should have mentioned that I was thinking "while both online 
and mounted" in the same thought, although I failed to mention that at 
any point. Resizing unmounted file systems is tantamount to recreating 
them, and thus cheating :)


Ant
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug