gpt's -s parameter

[John Nemeth]

As some people may have noticed, I've been working on fixing
up gpt(8) lately. One of the things I've done is to change various
parameters to accept "human numbers". These are numbers like "1M",
"200K", "5.2G", etc. I've been pondering what to do with the -s
parameter. This parameter is for specifying a partition size in
terms of the number of sectors. Most people would expect that if
they were to specify "-s 1M" they would get a partition that would
hold 1 MiB of data. But, what they would get is 1 Mi sectors,
which with a conventional disk with 512 byte sectors, they would
actually get a partition that would hold 512 MiB of data.

The meaning of the -s parameter can't be changed at this point
since gpt(8) has been part of NetBSD since late 2006 and first
appeared in NetBSD 4.0. One solution I've been considering is to
introduce a new -S parameter that would take a size in terms of
bytes, and would calculate the appropriate number of sectors based
on the device's sector size. However, I'm wondering if having both
-s and -S would cause confusion (the program wouldn't accept both).
What are people's thoughts on this?

[Brett Lymn]

Post by John Nemeth
The meaning of the -s parameter can't be changed at this point
since gpt(8) has been part of NetBSD since late 2006 and first
appeared in NetBSD 4.0. One solution I've been considering is to
introduce a new -S parameter that would take a size in terms of
bytes, and would calculate the appropriate number of sectors based
on the device's sector size. However, I'm wondering if having both
-s and -S would cause confusion (the program wouldn't accept both).
What are people's thoughts on this?

I think there is ample precedence for doing this - knowing what the
difference between -s and -S is what a man page is for.

[John Nemeth]

On Nov 22, 8:46am, dieter roelants wrote:
} On Fri, Nov 22, 2013 at 5:46 AM, John Nemeth <***@cue.bc.ca> wrote:
}
} > As some people may have noticed, I've been working on fixing
} > up gpt(8) lately. One of the things I've done is to change various
} > parameters to accept "human numbers". These are numbers like "1M",
} > "200K", "5.2G", etc. I've been pondering what to do with the -s
} > parameter. This parameter is for specifying a partition size in
} > terms of the number of sectors. Most people would expect that if
} > they were to specify "-s 1M" they would get a partition that would
} > hold 1 MiB of data. But, what they would get is 1 Mi sectors,
} > which with a conventional disk with 512 byte sectors, they would
} > actually get a partition that would hold 512 MiB of data.
} >
} > The meaning of the -s parameter can't be changed at this point
} > since gpt(8) has been part of NetBSD since late 2006 and first
} > appeared in NetBSD 4.0. One solution I've been considering is to
} > introduce a new -S parameter that would take a size in terms of
} > bytes, and would calculate the appropriate number of sectors based
} > on the device's sector size. However, I'm wondering if having both
} > -s and -S would cause confusion (the program wouldn't accept both).
} > What are people's thoughts on this?
}
} What about changing -s to use sectors if no unit is given or unit is "s",
} and use {kilo,mega,...}bytes otherwise? It's what disklabel does too, no?

That is a possibility, but it would be more work to code.
Right now, I just pass the whole string to dehumanize_number() and
I'm done. To do this, I would have to parse the string first.

}-- End of excerpt from dieter roelants

[Manuel Bouyer]

Post by John Nemeth
As some people may have noticed, I've been working on fixing
up gpt(8) lately. One of the things I've done is to change various
parameters to accept "human numbers". These are numbers like "1M",
"200K", "5.2G", etc. I've been pondering what to do with the -s
parameter. This parameter is for specifying a partition size in
terms of the number of sectors. Most people would expect that if
they were to specify "-s 1M" they would get a partition that would
hold 1 MiB of data. But, what they would get is 1 Mi sectors,
which with a conventional disk with 512 byte sectors, they would
actually get a partition that would hold 512 MiB of data.
The meaning of the -s parameter can't be changed at this point
since gpt(8) has been part of NetBSD since late 2006 and first
appeared in NetBSD 4.0. One solution I've been considering is to
introduce a new -S parameter that would take a size in terms of
bytes, and would calculate the appropriate number of sectors based
on the device's sector size. However, I'm wondering if having both
-s and -S would cause confusion (the program wouldn't accept both).
What are people's thoughts on this?

I think that's fine if -s accepts only plain numbers (that is, if I
type "-s 1M" I get an error).

[dieter roelants]

Post by John Nemeth
As some people may have noticed, I've been working on fixing
up gpt(8) lately. One of the things I've done is to change various
parameters to accept "human numbers". These are numbers like "1M",
"200K", "5.2G", etc. I've been pondering what to do with the -s
parameter. This parameter is for specifying a partition size in
terms of the number of sectors. Most people would expect that if
they were to specify "-s 1M" they would get a partition that would
hold 1 MiB of data. But, what they would get is 1 Mi sectors,
which with a conventional disk with 512 byte sectors, they would
actually get a partition that would hold 512 MiB of data.
The meaning of the -s parameter can't be changed at this point
since gpt(8) has been part of NetBSD since late 2006 and first
appeared in NetBSD 4.0. One solution I've been considering is to
introduce a new -S parameter that would take a size in terms of
bytes, and would calculate the appropriate number of sectors based
on the device's sector size. However, I'm wondering if having both
-s and -S would cause confusion (the program wouldn't accept both).
What are people's thoughts on this?

What about changing -s to use sectors if no unit is given or unit is "s",
and use {kilo,mega,...}bytes otherwise? It's what disklabel does too, no?

kind regards
dieter

[Magnus Eriksson]

One solution I've been considering is to introduce a new -S parameter
that would take a size in terms of bytes, and would calculate the
appropriate number of sectors based on the device's sector size.
However, I'm wondering if having both -s and -S would cause confusion
(the program wouldn't accept both).

It seems to me that having both -s(ectors) and -S(ize) would be a good
solution, as long as the man page is clear on the distinction. Or maybe
something like '-ss' for "size in sectors" vs. '-sb' for "size in bytes"
would be even easier to remember.

Are you thinking of giving an explicit error message in case both are
given? It might be nice to spell it out - something like "specify size in
sectors or bytes, not both" perhaps.


(And for what it's worth, I would expect that passing '-s 1M' should still
mean a sector count and not silently change the interpretation.)


Magnus

[John Nemeth]

On Nov 24, 5:30am, Magnus Eriksson wrote:
} On Thu, 21 Nov 2013, John Nemeth wrote:
}
} > One solution I've been considering is to introduce a new -S parameter
} > that would take a size in terms of bytes, and would calculate the
} > appropriate number of sectors based on the device's sector size.
} > However, I'm wondering if having both -s and -S would cause confusion
} > (the program wouldn't accept both).
}
} It seems to me that having both -s(ectors) and -S(ize) would be a good
} solution, as long as the man page is clear on the distinction. Or maybe
} something like '-ss' for "size in sectors" vs. '-sb' for "size in bytes"
} would be even easier to remember.

I would rather not introduce multi-character options just for
this one thing.

} Are you thinking of giving an explicit error message in case both are
} given? It might be nice to spell it out - something like "specify size in
} sectors or bytes, not both" perhaps.

It would only allow one of the options to be specified.

} (And for what it's worth, I would expect that passing '-s 1M' should still
} mean a sector count and not silently change the interpretation.)

Somebody else in this thread has asked for this to happen.

}-- End of excerpt from Magnus Eriksson

[Alan Barrett]

Post by John Nemeth
The meaning of the -s parameter can't be changed at this point

The meaning of -s followed by a plain integer can't be changed,
but the meaning of -s followed by something with a suffix can be
changed without breaking backward compatibility. Unfortunately,
dehumanize_number(3) does not make it easy for the caller to tell
whether or not there was a suffix, or what the suffix was.

--apb (Alan Barrett)

[John Nemeth]

On Nov 25, 11:35am, Alan Barrett wrote:
} On Thu, 21 Nov 2013, John Nemeth wrote:
} > The meaning of the -s parameter can't be changed at this point
}
} The meaning of -s followed by a plain integer can't be changed,
} but the meaning of -s followed by something with a suffix can be
} changed without breaking backward compatibility. Unfortunately,

After the discussion here, I'm thinking of doing this.

} dehumanize_number(3) does not make it easy for the caller to tell
} whether or not there was a suffix, or what the suffix was.

I've come up with an idea that should make the change relatively
painless.

}-- End of excerpt from Alan Barrett

[Hauke Fath]

Post by John Nemeth
As some people may have noticed, I've been working on fixing
up gpt(8) lately.

I haven't, but: Thanks! I looked into supporting bootable RAID1 for gpt
recently, but ran out of time before acquiring sufficient clue.

On a related issue: Are you looking at gpt partition alignment (or planning
to)? fdisk(8) and sysinst(8) align to 1 MiB now, given a big enough disk.
ISTR gpt(8) doesn't do that yet?

hauke


--
"It's never straight up and down" (DEVO)

[John Nemeth]

On Nov 25, 8:42pm, Hauke Fath wrote:
} At 20:46 Uhr -0800 21.11.2013, John Nemeth wrote:
} > As some people may have noticed, I've been working on fixing
} >up gpt(8) lately.
}
} I haven't, but: Thanks! I looked into supporting bootable RAID1 for gpt
} recently, but ran out of time before acquiring sufficient clue.
}
} On a related issue: Are you looking at gpt partition alignment (or planning
} to)? fdisk(8) and sysinst(8) align to 1 MiB now, given a big enough disk.
} ISTR gpt(8) doesn't do that yet?

gpt(8) doesn't particularly concern itself with disk layout
or partition alignment. That's for the user/caller to determine.
However, the "add" subcommand does take a "-a <N>" option now which
will align the new partition to "<N>". The new "resize" subcommand
also takes a "-a <N>" option which will make the partition a multiple
of "<N>". If the start of the partition was already aligned, this
will keep it aligned.

}-- End of excerpt from Hauke Fath

[Hauke Fath]

Post by John Nemeth
gpt(8) doesn't particularly concern itself with disk layout
or partition alignment. That's for the user/caller to determine.

I respectfully disagree - whipping out the pocket calculator for
partitioning is too 20th century for my liking, given all this unused raw
computing power right in front of me. :)

Post by John Nemeth
However, the "add" subcommand does take a "-a <N>" option now which
will align the new partition to "<N>". The new "resize" subcommand
also takes a "-a <N>" option which will make the partition a multiple
of "<N>". If the start of the partition was already aligned, this
will keep it aligned.

This, on the other hand, will fit the bill nicely, thanks.

I think NetBSD partitioning (related) tools - fdisk, disklabel, gpt,
raidframe, lvm, zfs, what have you - should guarantee proper alignment,
without the sysadmin having to jump through fiery hoops with a HP16C
between their teeth.

hauke



--
"It's never straight up and down" (DEVO)