Buried in this is a little bit of grumpiness, but only a little. See if you
can find it. Mainly, this is about a success that I thought was worth
sharing.

Starting in 1999 or so I had Debian running on a PowerCenter Pro 180 (PPC
604 180MHz, 1997 vintage Mac clone) maxed out to 512MB of memory. I ran an
8-drive RAID5 on an Adaptec SCSI card in an HP RAID rack with 18GB 10K RPM
disks, for a total of a (loud) 118GB of disk space. Just for fun, I also
ran a cryptoloop on top of it. On top of that, of course, I had LVM (1.0,
since 2 wasn't out yet and neither was the 2.6 kernel) and ext3. I even
threw in a Tulip-based "fast" (100baseT) ethernet card.

This machine served files via NFS (fast enough to play audio and video from
it directly, which meant it was plenty fast for my purposes), served IMAP,
ran spam filtering, retrieved email from a number of remote accounts, ran a
web server (with very minimal traffic, but also webmail), and basically
chugged along like a good little server.

Then, some time in 2003 or 2004, the motherboard fried. No idea what
happened, exactly, but it was toast. I had a Celeron box lying around
(already running Debian, even, though it had started out running Knoppix),
so I tried to get everything working on it. Moving the PCI cards was
trivial, but the RAID array wasn't recognized. It turns out that Linux
software RAID was endian-specific until kernel 2.6.13, so I couldn't use an
Intel box to run my existing array. Fortunately, I had a 2000-era dual G4
800 I'd been using as my primary machine, and I got Linux installed on it
with tolerable ease and that became my server. I even gave it the same name
and IP address, so it wound up being a drop-in replacement from the
perspective of the other machines depending on it.

Eventually, in 2005, I got tired of the noise and heat of 8 10K RPM drives.
If I'd been smart, I would have gotten tired of it before moving them 400
miles, but hindsight is 20/20. So I went and bought a couple of 250GB
Firewire drives, planning on setting them up in a RAID1. When I plugged one
in, it was noticed immediately by the kernel. When I plugged the other one
in, however, the kernel thought the serial number had changed on the first
one and was still convinced that there was only one drive. It didn't matter
which I plugged in first. It turns out that the firewire enclosures were
cheap, non-compliant pieces of crap and were indistinguishable. One
firewire enclosure and some unscrewing and rescrewing later, and I had a
workable pair. Setting up the RAID1 was trivial, and this time it shouldn't
be endian-specific. Creating a dm-crypt loop instead of the legacy
cryptoloop was almost trivial. Setting up LVM2 was trivial. Copying the
volumes from the old RAID to the new one was tedious, but not as slow as I
would have expected. Thus I doubled my capacity, cut my heat and power
consumption by 3/4, and reduced the noise level to a bare minimum.

Recently, I started running low on space on a couple of volumes. Since I'd
copied them from the old RAID, I'd left them the same size they'd been
there. This meant that I had some 130GB of unused disk space that I could
allocate to them. Two lvextend commands later (one for each volume) and I
had enough space. One ext2resize command later, and I was pissed:

ext2resize v1.1.19 - 2001/03/18 for EXT2FS 0.5b
Can't resize on big endian yet!

If ext2resize is its own package, and it doesn't work on big endian, why is
it even available for the ppc architecture? I then dug around and looked for
e2fsadm. Turns out it's in the lvm10 package, which I didn't have
installed because I am using lvm2. Installed it, looked at the e2fsadm man
page, and see that it can use resize2fs, which I already have installed.
I looked at the resize2fs man page, uninstalled lvm10, and resized my
filesystems to fill the newly extended volumes.

In summary, I've been having success managing my home digital storage with
Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
broken hardware (dead motherboard, non-compliant firewire enclosures) and
endianness issues. Not bad.

--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
> Buried in this is a little bit of grumpiness, but only a little. See if you
> can find it. Mainly, this is about a success that I thought was worth
> sharing.
.....
> In summary, I've been having success managing my home digital storage with
> Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
> broken hardware (dead motherboard, non-compliant firewire enclosures) and
> endianness issues. Not bad.
>
> --Greg

This juggling to keep all the balls (disks) in the air sounds familiar.
Non-partisan caution: before you settle on Reiserfs, read some recent
threads about Reiserfsck and Reiserfs vs JFS. I went to JFS when
Reiserfsck fscked up my drives. Never had a problem with JFS despite
many power failures.

Doug.




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Dec 03, 2006 at 06:03:44PM -0500, Douglas Tutty wrote:
} On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
} > Buried in this is a little bit of grumpiness, but only a little. See if you
} > can find it. Mainly, this is about a success that I thought was worth
} > sharing.
} ....
} > In summary, I've been having success managing my home digital storage with
} > Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
} > broken hardware (dead motherboard, non-compliant firewire enclosures) and
} > endianness issues. Not bad.
} >
} > --Greg
}
} This juggling to keep all the balls (disks) in the air sounds familiar.
} Non-partisan caution: before you settle on Reiserfs, read some recent
} threads about Reiserfsck and Reiserfs vs JFS. I went to JFS when
} Reiserfsck fscked up my drives. Never had a problem with JFS despite
} many power failures.

As long as ext3 serves my purposes (and so far it has), I'll stick with it.
I have no present need for reiserfs or JFS or XFS.

} Doug.
--Greg


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Sun, Dec 03, 2006 at 06:03:44PM -0500, Douglas Tutty wrote:
> On Sun, Dec 03, 2006 at 10:27:27AM -0500, Gregory Seidman wrote:
> > Buried in this is a little bit of grumpiness, but only a little. See if you
> > can find it. Mainly, this is about a success that I thought was worth
> > sharing.
> ....
> > In summary, I've been having success managing my home digital storage with
> > Debian GNU/Linux on PPC since around 1999, and the only hiccups have been
> > broken hardware (dead motherboard, non-compliant firewire enclosures) and
> > endianness issues. Not bad.
> >
> > --Greg
>
> This juggling to keep all the balls (disks) in the air sounds familiar.
> Non-partisan caution: before you settle on Reiserfs, read some recent
> threads about Reiserfsck and Reiserfs vs JFS. I went to JFS when
> Reiserfsck fscked up my drives. Never had a problem with JFS despite
> many power failures.

We made the choice for EXT3 ourselves, since it is the only filesystemm which
can be grown online and shrinked offline, and reiserfs is not really a
solution.

JFS/XFS can be grown online, but not shrinked, so they are problematic.

Friendly,

Sven Luther


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Mon, Dec 04, 2006 at 08:30:38AM +0100, Sven Luther wrote:
> On Sun, Dec 03, 2006 at 06:03:44PM -0500, Douglas Tutty wrote:
>
> > This juggling to keep all the balls (disks) in the air sounds familiar.
> > Non-partisan caution: before you settle on Reiserfs, read some recent
> > threads about Reiserfsck and Reiserfs vs JFS. I went to JFS when
> > Reiserfsck fscked up my drives. Never had a problem with JFS despite
> > many power failures.
>
> We made the choice for EXT3 ourselves, since it is the only filesystemm which
> can be grown online and shrinked offline, and reiserfs is not really a
> solution.
>
> JFS/XFS can be grown online, but not shrinked, so they are problematic.
>

Hi Sven,

I went from ext3 to reiserfs because of corruption after power failures.
Ditto reiserfs to JFS. With JFS there have been no problems that I can
see. Once I get my new system running etch stable, I'll put in one of
the comprehesive file integrity monitors (current computer doesn't have
the juice to do that __and__ get anything accomplished) so I get a
notice if anything goes missing.

Now that I'm using LVM I'll want that ability to grow. But I doubt I'll
need to shrink.

I wish that there was a filesystem format that had built-in redundancy
for the data (not just the superblocks). Its OK to have raid1 to
protect against drive failure, but it would be nice to have something be
a little more concerned about data integrity. Reading all the docs, it
seems that all the fsck utils focus on getting the filesystem to a
mountable state; loss of data is a secondary concern.

There was a long thread here recently looking at this in some detail.

Doug.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org