Quote:

Quote:
How many attempts at a /dev filesystem have there been?

The original "static /dev" from 1991 is still supported and works fine. Over the past two years, various new features in the kernel have enabled proper hotplug support, and a userspace "udev" device manager app has grown up to use those features. But again, the original 1991 method still works just fine.

Quote:
How often did that break existing things?

Zero, or near to it, unless one deliberatly switched to a different method.
Installing an entire new system, eg. Ubuntu, of course will give the new methods as default. As it should.

As a matter of fact, because I installed my machines a *looong* time ago and just slowly upgraded, swapping out graphics, RAM, CPUs, motherboards, hard disks etc over time (no 'activation' here) I only moved to udev last week.
I think I wanted better device naming for my USB memory stick.
Everything else just worked the same
I just typed:
apt-get install udev
and there it was (no reboot FWIW, just a completely different way of accessing hardware online at once).
This is under Debian though - none of this flash Ubuntu nonsense

Quote:

Quote:
The list goes on and on.

It certainly does! Stellar backward compatibility, no major upheavals in established distros. The hot new ones like (K)Ubuntu of course install only the latest stuff by default, but the older stuff is there too.

I installed Redhat 4.1 (I think) on an AMD something machine a while back (1997). Then I upgraded to Redhat 7.2 when it came out. in 2002-ish Then, since it worked, I left it serving my emails. I upgraded the kernel along the way for various reasons - it became a firewall so I suspect I did the ipxxxx things. I'm sure a lot of the code was the same as I ran in '96 - it certainly was running the same 1992 1Gb SCSI disks I liberated from the skip at SGI when I retired it. It's still in the spare room for sentimental reasons.

Also, just before I retired it, since it had an ISA motherboard I dug out an old 10Mb hard disk that I used in college on an Amstrad 2086 in about 1992-ish. It was MFM and used RLE (I think). Compiled the kernel, plugged it in and read my data.

Couldn't run the turbo-pascal - though I daresay I could have loaded an emulator and installed something...

And, as for the gcc thing - last week was yet another first for me
My first empeg kernel compile on my 2.6.18.3 (old, I know) *Intel based* kernel.
I just downloaded the 2.95 arm cross compile toolchain built on god-knows what system back in the mists of time and ran it and got a new kernel.

I wonder if the same proprietary toolchain used in Cambridge back in the day would run under Vista?
I can't remember why the player code is now totally dead but isn't it because the toolchain won't run? (really, I don't know but I thought that was the reason).

Feel free to moan about suspend/hibernate though
Or 3D-acceleration on graphics cards.
or many many other things - what's life without tribes?

Quote:
mdadm --force is a scary thing to use late at night trying to recover the array.

Yep - been there...

One of my motivations for the wiki was to try and gather best-practices to explain what you should do in this situation.

Oh, and 'this situation" is usually a catastrophic failure where you've lost multiple drives at once or in a cascade. Your array is dead, dead, dead. You have blown the redundancy you designed in (ie you lost 3+ drives in a RAID6 array).

You have however done data-recovery using ddrescue and friends and there is a chance that you can recover something - try *that* on a hardware raid

I think I'm right in saying that if you use --force it will recreate your superblocks and not touch your data.
If you get it wrong you re-run it with different parameters until it works.

**BUT**
If, for some reason the kernel thinks that your array needs 'synchronising' then it will start writing all over your data and 'goodnight Vienna'.
So it's a good idea to use --force with the 'missing' keyword to assemble the array in 'degraded' mode. That way you can try a read-only mount and see if there is anything resembling a filesystem there...

This kind of stuff is what I want to put up on the wiki after running it by the list.

The linux-raid list (http://vger.kernel.org/majordomo-info.html) is a very friendly and helpful place BTW - far less busy than lkml and much more newbie-friendly - do pop in if you have any raid or recovery questions...


PS My favourite HW raid issues: when your raid card goes titsup - how much are they? Do they even make those Adaptec raid cards you bought 4 years ago? Are the new ones compatible? What happens if you can't get a disk that's *exactly* the same anymore?

Quote:
PS My favourite HW raid issues: when your raid card goes titsup - how much are they? Do they even make those Adaptec raid cards you bought 4 years ago? Are the new ones compatible? What happens if you can't get a disk that's *exactly* the same anymore?

Quote:
I wonder if the same proprietary toolchain used in Cambridge back in the day would run under Vista?
I can't remember why the player code is now totally dead but isn't it because the toolchain won't run? (really, I don't know but I thought that was the reason).

Quote:
I could be wrong, but as far as I know there was no such proprietary toolchain. The empeg player code is C/C++ code that runs on Linux, I have always assumed that it was also built on Linux using the standard toolchain.

Quote:
compiled with Visual C++ 6, which does still run on Vista, so ner.

to you too

(at last, a proper debate!)

Quote:

Quote:
I will give your suggestion a try and see how I get on.

Ack. I'm pulling down the current daily build of "Fiesty Server" to try on one of the racks here later today or tomorrow. If I remember, I'll report back on how it looks for RAID stuff.

Cheers

I'm building the Ubuntu Feisty system right now using yesterday's image of the "alternate" installer CD. So far, so good. I found this set of instructions that I'm using as a loose guide for this:

http://www.debian-administration.org/articles/512

There are a few things I'm trying differently, and we'll see how those work out.

My oh my, it certainly does take some time to construct a 3TB RAID5 array from scratch..

Quote:

My oh my, it certainly does take some time to construct a 3TB RAID5 array from scratch..

Quote:

Quote:

My oh my, it certainly does take some time to construct a 3TB RAID5 array from scratch..

Seriously?
Or do you mean the whole system rather than just the array?

Quote:
Just the array -- it does it in the background, of course, but the initial sync involves rewriting the entire contents of the entire space of the entire array. That takes a while with 3TB of disk space.

Quote:

But I'm redoing it again now -- my experiment didn't pan out, and smaller physical RAID partitions will make testing failure modes a lot less time consuming later on.

So this time, the RAID5 will be only 120GB instead of 3TB.

don't forget bitmaps.

Resyncing a dirty Tb array takes seconds

Quote:

Why, though? Can't it just treat the sector contents as undefined until written to? Why isn't setup of an empty array instantaneous?

Quote:
There is an --assume-clean option which is safe for raid1 and raid6 but for raid5 it is NOT safe to skip the initial sync.

Quote:
For raid6 it is also safe to not sync first, though with the same caveat as raid1. Raid6 always updates parity by reading all blocks in the stripe that aren't known and calculating P and Q. So the first write to a stripe will make P and Q correct for that stripe. This is current behaviour. I don't think I can guarantee it will never changed.

Quote:
Why, though? Can't it just treat the sector contents as undefined until written to? Why isn't setup of an empty array instantaneous?

Quote:
Just because I'm interested.... could you use the array whilst this was going on?

Quote:
But I'm redoing it again now -- my experiment didn't pan out

Well that makes me feel a whole lot better

If you have problems it must be nearly impossible for me to do it!

Amazingly I got a knock on my door about an hour ago, it was the postman. I bid on one of the LSI cards the otherday and it's turned up already! £35 (US$65 ?) no bad!

Within the hour I have FreeNAS running, RAID5 working and the box sat on my network taking files. Certainly pain free to this point. I haven't however figured out how to tell the array is healthy to start with, and of course haven't tested it yet for drive failure/recovery.

On thing I have noticed is speed, so far this seems to be much slower than the software solution, but maybe this is because the array is still building in the background, the drive are certainly running, or maybe the card won't let them power down?

I still want to try the software approach due to some of the arguments put forward in the thread, I just need a slightly less painful experience.

Cheers

Cris.

Quote:
and of course haven't tested it yet for drive failure/recovery

Quote:

Quote:
But I'm redoing it again now -- my experiment didn't pan out

Well that makes me feel a whole lot better

Quote:

Quote:

Quote:
But I'm redoing it again now -- my experiment didn't pan out

Well that makes me feel a whole lot better

Heh.. I just didn't follow the directions given -- tried something different (yet similar..) and it failed to boot after the install. Got distracted with another project afterwards, so I'll try it again today sometime.

Quote:
I'll try pulling/reinserting drives next.

Quote:

I could of course just drop back to a simple mirror and forget RAID5, but I really want that extra 250Gb.

Quote:

I could of course just drop back to a simple mirror and forget RAID5, but I really want that extra 250Gb.

Yeah, I know the feeling.

A *lot* of people seem to prefer RAID 1+0 with a four drive setup.
That's two pairs of RAID1, which are then combined into a single virtual drive
with RAID0 striping across the two pairs. Or the other way around (0+1)

Very reliable, very fast -- more so than just two pairs of RAID1 would be.
But still no extra 250GB.

Cheers

Quote:
Wow! Thanks Mark!