perc3: 1: importing containers; 2: snapshots

Matthew Burgoon dell at
Sat Oct 11 22:43:01 CDT 2003

> > I've got a couple of questions, and as I'm now beating my head
> > against the wall in frustration, I am now sending email to this list
> > begging for help and ideas. I have a poweredge 2450 with a Perc3/Si
> > running firmware build #2951.
> you may want to consider an upgrade - i think the latest rev is build
> #3571 (aka 2.7-1)

I will once I'm able to reboot, which requires me to get this snapshot
first :/

> > Here's my basic need: I need to take a snapshot of a live file
> > system that is sitting on top of a mirrored container. Assume I
> > cannot reboot the machine, remount the file system read only, let
> > alone unmount the disk at all, and doing a tar isn't an option. It
> > must be a real-time snapshot.
> i believe this is what people have been installing LVM for as it is meant
> to allow you to do FS snapshots.  of course this probably doesn't help
> you in your current config..

Yeah, and with ext3, the kernel doesn't like an LVM snapshot of a
mounted ext3 partition due to the extra flag, the partition has to be
re-mounted read-only, which I can't do. But you're right, doesn't help
me in my current situation regardless.

> > So, I thought perhaps if I just yank the disk, put it into another
> > 2450 with a Perc3/Si controller, I could just import what it would
> > think is a degraded mirror. But I cannot figure out how to get it to
> > do this, and I would hope this is possible. Anyone know? Nothing
> > shows up in disk show partition/space, container list, nada.
> enclosure prepare slot 0 <number of slot>
> you should then be able to take this to another machine.

Hmm. I'm not next to the box to try this. Would I have to do this
command before I yanked the disk? Would it let me do this to a disk
that's currently in a mirror? If not, and I unmirror the disk first,
will that screw over the data so that it's useless? I'll certainly try
it tomorrow though.

> > If anyone could provide me with some commands, ideas, facts,
> > suggestions or a lot of beer so the problem magically goes away, it
> > would be greatly appreciated.
> the long term solution is perhaps to look at LVM and it may do what you
> want in a more graceful manner.

Once I get database mirroring set up, it'll all be moot :)

Also, one of the DB mirrors will be solaris using DiskSuite, which
doesn't allow for snapshots in the netapp (or even linux LVM sense), but
you can simply remove the disk from the mirror with a command and mount
it as you normally would, do what you're gonna do, and add it back in
once you're done. I've been doing this for years. Hence my frustration
with this perc3 card.

> the main problem that i see is snapshotting files with open handles.
> otherwise i would have recommended looking at rsync (have you
> considered this?).  just rsync to another disk at regular internals
> and just before you need a snapshot runn rsync again - it should
> pickup only the changes and finish in a few seconds.

Yeah, that is definitely a problem in a lot of cases, but one good thing
for me is that this is a file system for a database with some huge
honkin files, and the database is capable of being told to close all of
it's tables, syncing them, at which point I can to do my snapshot. Once
it's completed, I tell the database to re-open them. The problem is that
this process can't take more than 20 seconds, else things start timing
out and service gets interrupted. Rsync wouldn't work on a live database
file, they have to be closed lest you get data inconsistencies in the
middle of the file (I've tried), and anything but an immediate snapshot
is too slow, even doing a disk to disk copy of any one of these files is
going to take way longer than 20 seconds.

Another thing I've been trying (as I have a non-production machine that
I can dink with) is that I've created a mirror, unmirrored it, created
one large volume out of the disk that was unmirrored, and looked at the
first 10 megs or so of it. The file system markers are completely gone.
And I've verified that things started at the same place while it was in
a mirror and after I made it a volume. I guess taking a section of disk
and putting in a container writes things all over the disk. Even if
other super blocks are intact somewhere (and I'm sure they are) it's
almost impossible to tell where the real 'old' file system begins in
order to dd it correctly.

Thanks for you input, I'll definitely be trying the prepare commands
tomorrow :)

More information about the Linux-PowerEdge mailing list