RE: fstab/mount filesystem nomenclature
Pigeon, a postscript. WD has their own BIOS on the Promise controller.
It gets hooked in by the system BIOS and then does it's own thing
without leaving any fingerprints elsewhere
I will email Western Digital and see if I can get some insight into what
they are doing
--
David
-----Original Message-----
From: David Turetsky [mailto:davidturetsky@earthlink.net]
Sent: Tuesday, February 11, 2003 11:58 PM
To: debian-user@lists.debian.org
Subject: RE: fstab/mount filesystem nomenclature
[My latest on top]
Pigeon, I'm chicken! I think it's safer for now leaving well enough
alone and spending a little more time on pressing real world issues. In
Windows, I've got 160GB (/hde) and 120GB (/hdf) and that's a lot. In
linux, I can see the first partition on /hde and and both partitions on
/hdf. The second partition on /hde is backup for the ms stuff on /hda
(which I can of course read directly) so it's of no special interest to
me in linux. If I need to write anything for subsequent use in Windows,
I can always put it on /hda and get it from the Windows side
Some time back, I copies off 'Large Disk HOWTO' and read enough to have
a sense of the problem. That was back when I first installed potato's
predecessor and had to strap my 32GB drive down to 30GB which was the
max that linux then accommodated
So I consider myself way ahead of the game, and now have Woody running
and can read all of the ntfs files on /hde and /hdf and have Gnome up
and running with my nvidia graphics card
I'm in pig heaven!
When there's more native support for 160GB, I can always revisit the
problem and saw a little more wood off of the end of the plank
Thanks for all of your interest and erudition
--
David
-----Original Message-----
From: Pigeon [mailto:jah.pigeon@ukonline.co.uk]
Sent: Tuesday, February 11, 2003 10:13 PM
To: debian-user@lists.debian.org
Subject: Re: fstab/mount filesystem nomenclature
On Tue, Feb 11, 2003 at 04:25:23PM -0500, David Turetsky wrote:
> Indeed! cfdisk /dev/hde and cfdisk /dev/hdf are what is required.
> Interesting about my problem in accessing the fat32 partition on /hde,
> when I run cfdisk on this drive (WD 160GB, all available in Windows
XP,
> formatted using the WD utility), I get "FATAL ERROR: Bad primary
> partition 1: Partition ends after end-of-disk"
AH!!!
EZ-Drive. Or something like it.
> So your comment about standard kernel "mostly" support for the 160GB
WD
> drive appears to be on target.
We can bin that theory now. The Linux kernel is fine. It's the Windoze
kernel that has problems...
> One gets the impression that WD has done
> some sort of jury-rigging to provide support for the full 160GB
Yes. It has, essentially, jury-rigged Windoze, and Linux is
complaining about what that means for the hard drive.
The partition table contains information about the partition sizes in
two formats: CHS and LBA. Linux fdisk, from your previous post, is
reading the LBA information and giving what looks like a consistent
output for a 160Gb drive with a 120Gb primary and 40Gb extended
partition.
Now, this is where I learn something new. I thought Linux used LBA
exclusively and ignored CHS. Apparently this is not so. cfdisk
obviously does take some notice of the CHS information.
Your WD formatting utility has installed a CHS translator somewhere -
possibly EZ-Drive, possibly something in Windoze. It has written a
partition table which contains CHS entries that are correct for the
WD CHS translation algorithm. Linux, however, is unaware of the WD
translation algorithm. It has quite likely read the raw CHS parameters
off the drive itself. It is probably working with a smaller number of
cylinders than the WD algorithm provides. So the cylinders entry in
the CHS info for your primary partition, having been calculated the WD
way, is larger than the total number of cylinders that Linux knows are
available from the drive itself. cfdisk detects this anomaly and TELLS
YOU IT'S A FATAL ERROR.
mount, I believe, is using LBA and simply expects the extended
partitiion to start on sector x. The problem is that sector x
calculated using the WD translation algorithm, and sector x calculated
using Linux's algorithm, ends up being a different physical spot on
the disk. So mount is looking for the start of the partition in the
wrong place, and can't find it.
To cure the problem... back up all the data on the drive, wipe out the
MBR, and start afresh. Partition it with the Windoze utility and live
with the fact that Windoze only sees 120Gb. The remaining 40Gb can be
Linux-only space.
You MAY be lucky and find that Partition Magic can fix it without
having to wipe out and reload. I don't know; as I say, I've never used
it. But since you'll STILL have to back up your data before using PM,
the wipe and reload isn't too much extra work... especially given that
if PM is able to fix it it'll probably take all night.
You might also have to manually disable the WD CHS translator. If it's
EZ-Drive, it's probably on /dev/hda, in the blank space on the zeroth
cylinder right after the MBR. There should be some sort of
prompt when you boot up that'll let you go in and uninstall or
configure it. If it's in Windoze I'm not sure where to look. It'd
probably be something that gets read as soon as possible after boot; a
DOS-based variant might have something in CONFIG.SYS but I don't know
about the NT variants.
> because,
> as I previously indicated, when I use native Windows partition support
> to partition the second drive (which WD suggested by email when their
> utility would not run for the second drive), I only got 120GB. And the
> linux kernel has no complaints about this second drive, either in
cfdisk
> or in routinely accessing the 137.21GB in two partitions
>
> I have a recollection of somewhere reading that in normal mode 120GB
is
> the maximum that is natively supported
... by Windoze, I presume? My Windoze knowledge ends with 98SE before
there were such things as 160Gb drives, and I've never used any of the
NT-based variants.
> There is a cfdisk tab "Maximize" which when highlighted says "Maximize
> disk usage of the current partition (experts only). I don't feel too
> expert today so I think I'll proceed in the spirit of AG Ashcroft's
> quotation about his grandfather's carpentry prowess
Microfots partitions sometimes leave blank space - in chunks of a
cylinder or less - which Microfots fdisk won't allocate. The
"Maximise" option adds this blank space - if it exists - to the
beginning/end of a neighbouring partition. It is always a small
percentage of total disk space, and not really worth bothering with
especially if you're going to run Microfots OSes on the same disk. It
isn't what you need here.
I've got a few text files which explain at great length what this CHS
and LBA shit is all about. They're well out of date because they are
from the time when people were having trouble with drives > 527Mb, but
the principles they explain still hold. You can probably find
something more up to date with Google, but I'll send them to you if
you want. .gz or .bz2?
Next time, get SCSI :-)
Pigeon
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: