[Rule-list] Partitioning not always straight forward

[Martin Stricker]

James wrote:
> 
> On Wed, 27 Mar 2002 01:56:17 +0100
> Martin Stricker <shugal at gmx.de> wrote:

> > Gordon Buzowetsky wrote:
> > >
> > > > Hello All
> > > >
> > > > Using druid or fdisk with weird results:
> > > >
> > > > > mount point, saw "mount point:(not applicable)" but with ext3
> > > > snip
> > > > > again chose first free space, chose new, etc. as before but
> > > > > came out with same free space in what was hda1 and a new hda6,
> > > > > with 5 & 6 each half of hda3
> > > >
> > > > Another time an attempt to delete hda2 swap partition resulted
> > > > in hda2 remaining while free space shows up elsewhere.
> > > >
> > > > Both times with miniconda 0.7.1 with early swap hack to hda2.
> > > >
> > > > Richard
> > > >
> > > Hi All...
> > >
> > > Just reading back through some posts...and wanted to mention that
> > > Richard isn't the only one that gets some strange results using
> > > Disk Druid and fdisk.   I too; get to that part...enter the sizes
> > > for swap and / and most times the partitions will be
> > > interchanged....eg---40meg swap hdb1 350meg / hdb2-----after all
> > > is said and done I end up with 40meg swap hdb2 and 350 meg / hdb1.
> > >  No idea of what's causing that; I thought it was just my
> > > inexperience with the proggies...but I guess not.  OTOH using
> > > 'cdisk' in slinky...the partitions come out as originally
> > > setup....go figure.
> >
> > I had similar problems. There are some bugs in the wrapper around
> > fdisk/DiskDruid in RHL 7.2. I don't like that wrapper altogeter,
> > when I say fdisk I want fdisk... If that's still the case in
> > Skipjack I'll bugzilla it.
> 
> Gordon,
>   Don't know if this is true but I've heard that the reason for this
> is so that your swap is on the "fastest" part of the drive.  In
> short "it's a heppin ya" Wich is when you think about it kind of
> commical The fastest part of a 486DX 33mhz with a 320meg hdd.  Kinda
> like a turtle with racing stripes.  So they may not consider it a
> bug... but a feature.

But the fastest part of any haddisk is it's *beginning*, not the end!
The end is only then faster if you can read *huge* chunks of data in one
big slurp without beeing interrupted - not exactly what kswapd does...
So it *is* really a bug. I'll see Skipjack and if it's still there I'll
bugzilla it.

Best egards,
Martin Stricker
--
Homepage: http://www.martin-stricker.de/
Red Hat Linux 7.2 for low memory: http://www.freesoftware.fsf.org/rule/
Registered Linux user #210635: http://counter.li.org/

_______________________________________________
Rule Project HOME PAGE:  http://www.freesoftware.fsf.org/rule/
Rule Development Site:   http://savannah.gnu.org/projects/rule/ Rule-list at mail.freesoftware.fsf.org
http://mail.freesoftware.fsf.org/mailman/listinfo/rule-list