Now that you mention it, I got a drive that does this;
hda: WDC AC21600H, 1549MB w/128kB Cache, CHS=787/64/63, DMA
hdc: ST317242A, 16446MB w/512kB Cache, CHS=33416/16/63
Partition check:
hda: hda1 hda2 hda3 hda4
hdc: [PTBL] [2096/255/63] hdc1
Should I take off my data, and force CHS then reformat?
Thanks
Michael
On Thu, 20 Jan 2000, Angus Lees wrote:
> On Thu, Jan 20, 2000 at 07:20:48PM +1100, Jeff Waugh wrote:
> > I've got two IDE drives, both as masters on separate channels. The
> > first one has many and varied OS partitions on it (mostly
> > primaries), the second has a primary partition (for Windows apps)
> > and a huge logical partition for archives and saved stuff. It's
> > this partition that's unhappy.
>
> > DOS7: "dir" returns garbage, but it thinks there's an E: drive
> > there.
> > Win98: An E: drive is there, albeit unaccessible and with no label.
> > An F: drive appears, showing everything that E: normally would.
> > It's all fine, it all works, but it's SLOW.
> > Win2K: (don't ask) Sees the E: drive as usual, but runs SLOW.
> > Everything works normally.
> > Linux: During boot, the kernel comes up with [PTBL] (which does not
> > normally appear) and the geometry of the hard drive, listing all of
> > the partitions as it should. I can mount and play with my /dev/hdc5
> > without any troubles at all, but again, it's SLOW.
>
> [PTBL] (i believe) means that linux is trusting the drive geometry
> given in the partition table, instead of going with what the bios says
> (usually they agree, so you don't see this). i get it on one of my
> drives cos i forced the c/h/s layout into something other than what
> the bios wanted. its ok, relatively harmless, and works (i only run
> linux, so i don't know how other os's treat it)
>
> i'm presuming the partition is some form of fat/vfat/fat32 filesystem.
>
> unless the kernel is logging disturbing things like "unable to access
> beyond end of device" while accessing files on the partition, i'd say
> its a problem with the filesystem, not the partition table or drive
> geometry.
>
> its probably either:
>
> 1. stuffed, but somehow still readable most of the time (a
> scandisk/fsck should tell you if this is the case)
>
> 2. horribly fragmented
>
> 3. some wierd cluster size inefficiency (esp. since its such a large
> partition). i don't really know (or care, to be honest) enough about
> fat filesytems to know how to tell if this is the case. partition
> magic, etc should be able to do conversions for you, if this is the
> problem.
>
> 4. just a really slow drive. but i doubt it, since the other
> partition works fine (?). "hdparm" is good for this sort of
> testing/tweaking.
>
>
> i'd access it, then check the kernel logs (/var/log/kern.log on debian
> or the output of dmesg(8)) to see if the kernel thinks there is
> anything wrong with the hardware or filesystem.
>
> --
> - Gus
> --
> SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
> To unsubscribe send email to [EMAIL PROTECTED] with
> unsubscribe in the text
>
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
