Subject:
Re: [discuss] Re: Partition HOWTO, first part: Definition-and-naming
From:
Borden Rhodes ####@####.####
Date:
12 Mar 2009 08:48:04 +0000
Message-Id: <432cd8760903120143l12e01cafi64f495d14b5d69ff@mail.gmail.com>
In general: I may be thinking about HOWTOs incorrectly. I understand
that they're not supposed to be textbooks but I believe that they're
supposed to be more than recipes to get specific jobs done. That is,
HOWTOs, in addition to showing how to do something specific, also
provides sufficient theory so the reader understands how something
works, why it works that way, and how they can apply that knowledge to
other problems. My comments are based on this assumption. If it's
wrong, there's not much sense in reading further :)
On 11/03/2009, jdd ####@####.#### wrote:
>
> byte have no meaning when disk is involved. There is no way to write
> only bytes on a disk.
> ...
>
>> heads, cylinders, and then sectors.
>
> I've seen interest in using cylinder fitted partitionning, but not
> plate fitted. I don't want to go into the LBA discussion (or may I do?
> if the HCL is wrong the drive is unusable)
The point I was trying to make here was that I think a good
understanding of hard drive geometry will help the reader understand
partitioning and make better sense of fdisk's output. Even if you
don't refer to heads again, I think it's important to tell the reader
about them to help them form a mental model of a hard disk. I think
it's especially important considering that fdisk uses head information
and one of the objectives is to make people new to partitioning
comfortable with fdisk.
>> Moving along, I would put File Systems under its own heading.
>
> The file system itself is not relevant for the partitionning, any
> (mostly) partition can receive any file system. I added a link to
> Wikipedia. This is only a definition page, I will give example of
> making a file system later.
This is the problem I'm having with that section: for starters, I'm
not quite sure what I'm supposed to gain from it. Yes, there's plenty
of useful information, but it lacks structure. The first bit reads
like a "why partition disks" section (actually, that's a pretty good
section to have). Suddenly, I'm reading about something called a
'file system.' I don't know what it its, what it does, or what it
likes to eat. But now I'm worried because I don't know if it's
something that I *should* know or not. And now I'm getting frustrated
because I don't know if I should know it!
So, in light of your comments, I would take out that whole section on
file systems and leave it for the file systems bit. A reader learning
this for the first time should be fine with waiting to discover file
systems and will probably thank you for only introducing things as you
need them.
> I will try *not* to introduce inodes. I try to give all what is
> necessary to manage partion, no more. Of course it's not easy :-)
Oops, that was my fault for misreading. You were talking about device
nodes and not file inodes. Good idea for keeping that out :)
Unfortunately, now that I've re-read the first paragraph of 'Files and
Nodes,' I have to say that it still doesn't make any sense to me.
I'll have to come back to that later.
(I probably should have added that a lot of these topics I'm learning
about for the first time. Think of me as your target audience :) )
>> Also after a few readings of the brief discussion of File Systems, I
>> could be led to believe that a file system could be created without a
>> partition to live in!
>
> that's true. Most usb keys are not partitionned and this is perfectly
> safe also for hard drives.
Well, I look forward to learning about how that works in the HOWTO :)
> I would like to remove entirely this part, that is really difficult,
> but some apps still use then, specially dealing with true SCSI (not
> SATA nor IDE). This will probably have to be rewritten several times :-(
I know your pain :) I think you have no choice but to take it out
because including it would require (if you don't want to anger your
readers) explaining IDE channels, SCSI wiring, slaves, masters, and
all of that other stuff that doesn't belong in a partitioning HOWTO.
Under what circumstances would fdisk (or any other partition editor)
require people to know low-level device names?
>> Since 'Volume ID' is mentioned in the page, I think it needs to be
>> defined. For someone who doesn't know that it's merely a useless
>> label
>
> it's not useless and is widely used now, but well defined in the fstab
> man page. If I find when writing the rest of the doc that it's
> necessary to define more, I will do, but this page is already very
> long :-(
Ouch. In that case it's doubly important that you define it then.
Unfortunately, referring readers to man pages is a bad idea because,
at least in my experience, we turn to the Internet because the man
pages are too esoteric! We'll have to think of some way to deal with
volume IDs (which, I hope, are not the same as 'volume labels' which I
meant to say were worthless (or so I believe) ).
> I even wonder if the end of this document shouldn't be moved to the
> next one
Probably. Personally, I've never understood why fdisk asks me what
sort of partition I'm making if I need to set up the file system in a
separate command. I've never bothered to try, but what would happen
if I mkfs.ext3 on an NTFS partition?
> thanks for your help, very appreciated
I'm glad you understand that I'm not trying to be a nitpicky jerk. So
far I've been harping but I'm not afraid to pull my proverbial weight
by writing. I just don't want to step on your toes inadvertently in
rewrites.
With regards,
Borden
