Automatic drive partitioning

Automatic drive partitioning

[Thomas Jarosch]

Hello,

is there a tool that can copy a partition table from one drive
and adapt it for another drive?

In an ideal world both source and destination drive share the same geometry.
The partition table could easily be copied using sfdisk.

But let's assume the geometry mismatches (RAID1 configuration
using drives from different brands). The destination partitions
have to be computed to match the source drive as close as possible.

What's this all for you might ask?
If one disc in a RAID1 array (without a preconfigured hot spare) fails,
I want to plug in a replacement disc and the rest should be handled
by some automatic system (partition the drive, hot-add it afterwards).

So, is there a tool that can copy and adapt partition tables?

Cheers,
Thomas

Re: Automatic drive partitioning

[Mark Hahn]

> is there a tool that can copy a partition table from one drive
> and adapt it for another drive?

I use dd.

> In an ideal world both source and destination drive share the same geometry.
> The partition table could easily be copied using sfdisk.

or dd.  but really, with LBA, most drives already use the same geometry;
have you looked?  255 heads, 64 sectors/track, but a variable number of cylinders.

which makes sense, since "rectangular" geometries have been lies for a long
time (all drives have variable spt.)

> What's this all for you might ask?
> If one disc in a RAID1 array (without a preconfigured hot spare) fails,
> I want to plug in a replacement disc and the rest should be handled
> by some automatic system (partition the drive, hot-add it afterwards).

this level of automaticity is normally considered bad because it 
has extremely unpleasant failure modes.  (consider what happens if 
your sysadmin-assistant, low on coffee one monday morning,
plugs in a drive which he *doesn't* want to be auto-sucked into the array...)

does the devfs/hotplug mechanism let you trigger a script when a new
drive appears?  this would depend somewhat on the fabric - I suspect that 
scsi still needs an explicit rescan command.

Re: Automatic drive partitioning

[Thomas Jarosch]

Mark,

On Saturday 08 October 2005 18:16, you wrote:
> > In an ideal world both source and destination drive share the same
> > geometry. The partition table could easily be copied using sfdisk.
>
> or dd.  but really, with LBA, most drives already use the same geometry;
> have you looked?  255 heads, 64 sectors/track, but a variable number of
> cylinders.
>
> which makes sense, since "rectangular" geometries have been lies for a long
> time (all drives have variable spt.)

I tried copying the partition table using sfdisk and it complained
about "partition does not start at a cylinder boundary". After re-running
with the --force flag (like a dd copy would do) and formatting the partition,
the system went nuts.

Thanks for the hint of variable number of cylinders, but I rather not rely on 
that as I want to solve this in a generic manner.

> > What's this all for you might ask?
> > If one disc in a RAID1 array (without a preconfigured hot spare) fails,
> > I want to plug in a replacement disc and the rest should be handled
> > by some automatic system (partition the drive, hot-add it afterwards).
>
> this level of automaticity is normally considered bad because it
> has extremely unpleasant failure modes.  (consider what happens if
> your sysadmin-assistant, low on coffee one monday morning,
> plugs in a drive which he *doesn't* want to be auto-sucked into the
> array...)

;-)

> does the devfs/hotplug mechanism let you trigger a script when a new
> drive appears?  this would depend somewhat on the fabric - I suspect that
> scsi still needs an explicit rescan command.

I don't want it that automatic. You still have to push a button / run a script 
to activate the new drive. Ideally from a little web frontend which shows
the current status of the array, too.

Thomas

Re: Automatic drive partitioning

[Mark Hahn]

> > which makes sense, since "rectangular" geometries have been lies for a long
> > time (all drives have variable spt.)
> 
> I tried copying the partition table using sfdisk and it complained
> about "partition does not start at a cylinder boundary". After re-running
> with the --force flag (like a dd copy would do) and formatting the partition,
> the system went nuts.

hmm, well, I guess you are coming from an older/non-LBA disk.  I suppose 
I should have mentioned that little caveat: don't try the dd trick
going from CHS to LBA.  LBA->LBA should be OK, and CHS is OK if nheads
and nsectors match (and ncyl doesn't go off the end of the disk, of course!)
I don't think the kernel's partition code cares much about
cylinder-alignment (in the CHS world), but other OS's would.
the definition of where the first possible partition starts also 
depends on the size of cylinders (nheads*nsectors)...

> Thanks for the hint of variable number of cylinders, but I rather not rely on 
> that as I want to solve this in a generic manner.

I believe that in an all-LBA world, it's a non-problem.

Re: Automatic drive partitioning

[Carlos Carvalho]

Mark Hahn (hahn@physics.mcmaster.ca) wrote on 8 October 2005 15:09:
 >> I tried copying the partition table using sfdisk and it complained
 >> about "partition does not start at a cylinder boundary". After re-running
 >> with the --force flag (like a dd copy would do) and formatting the partition,
 >> the system went nuts.
 >
 >hmm, well, I guess you are coming from an older/non-LBA disk.  I suppose 
 >I should have mentioned that little caveat: don't try the dd trick
 >going from CHS to LBA.  LBA->LBA should be OK

Agreed. I've been using sfdisk without problems with various drives. I even
usually start the first partition on sector 1... When I want to copy
the partition table of one disk to the other I do
sfdisk -d partitioned-disk | sfdisk --force new-disk.

It works for drives of different sizes as well. Yesterday I tried
this pipe with logical partitions and even with force it refused,
complaining that an extended partition didn't start at a cylinder
boundary. That's non-sense so I just did a

# for i in each-of-the-disks; do
sfdisk -uS /dev/sd$i << EOF
partition info
EOF
done

and all was well.

The concept of cylinder et. al is history now. Only the manufacturer
knows how the info is organized on the disk surface.

Re: Automatic drive partitioning

[Dan Stromberg]

On Sat, 2005-10-08 at 17:32 -0300, Carlos Carvalho wrote:

> The concept of cylinder et. al is history now. Only the manufacturer
> knows how the info is organized on the disk surface.

...but one could probably do some performance testing to determine the
true physical geometry, at least until the (performance) block
relationships change due to a new underlying technology.

Nice article about use of sfdisk.

Re: Automatic drive partitioning

[Thomas Jarosch]

Carlos,

On Saturday 08 October 2005 22:32, you wrote:
> Agreed. I've been using sfdisk without problems with various drives. I even
> usually start the first partition on sector 1... When I want to copy
> the partition table of one disk to the other I do
> sfdisk -d partitioned-disk | sfdisk --force new-disk.
>
> It works for drives of different sizes as well. Yesterday I tried
> this pipe with logical partitions and even with force it refused,
> complaining that an extended partition didn't start at a cylinder
> boundary. That's non-sense so I just did a
>
> # for i in each-of-the-disks; do
> sfdisk -uS /dev/sd$i << EOF
> partition info
> EOF
> done
>
> and all was well.
>
> The concept of cylinder et. al is history now. Only the manufacturer
> knows how the info is organized on the disk surface.

Thanks a lot! Just tried again and this time it worked.
Dunno why the system oopsed the first time.

Thomas

Re: Automatic drive partitioning

[Thomas Jarosch]

Dan,

On Saturday 08 October 2005 18:08, you wrote:
> This isn't really what you were asking for, but if you decide you want a
> starting point and/or a project to maintain whatever code you might
> write, then you might look over:
>
> http://dcs.nac.uci.edu/~strombrg/dup-label.html

Thanks for the link. If there is no such tool as I described yet,
I thought about adding some kind of "--adapt" mode to sfdisk
as it can already dump & read partition tables.

Thomas