From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: grub-devel@gnu.org
Subject: Re: Suggestion from a noob
Date: Sat, 29 Jan 2011 01:24:43 +0300 [thread overview]
Message-ID: <4D43422B.60207@gmail.com> (raw)
In-Reply-To: <AANLkTi=RiLJ7QPGd84zrx8RK_CzqpMJ44VOG=OwYOqR=@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]
On 01/28/2011 06:33 PM, hansbkk@gmail.com wrote:
> But what scheme to use for the labels? My
> answer - GRUB2's order, because it's relatively stable (BIOS order,
> right?)
It's nothing but. It depends on the factors like booted disk,
enumeration order, disk latency and connected devices. It's also
different from one mobo to another. It's probably by luck that it looked
like relatively stable for you. Although one objective reason why it
could seem stable is because you probably upgrade you BIOS less than Linux.
There are orders of technical origin based on e.g. disk model and serial
number, which might be more readable for you. But the target usercase is
that user assigns the names based on the description of the contents
that makes sense to him.
> So here's my suggestion - please allow users to actually SET the
> labels right from the grub CLI! I realize the different filesystems have different label structures,
> but if you were able to handle say dos/ntfs plus the top four Linux
> filesystems that should cover 99% of the needs out there.
>
>
Writing to a filesystem is always a potential risk. It has to be
carefully evaluated to find out if it's justified. For some filesystems
it's as easy as writing to a superblock, on the others it's more tricky
because it has mirrored superblocks or handles label somewhere in the
fs. Also if we write anything to fs metadata we have to carefully check
the compatibility to avoid potentially corrupting the fs. It adds some
new points of failure and complexity. Also including just one fs with
such support creates an incencitive to make other fses do the same even
if it's potentially risky.
Filesystems modules are also size-critical so any write support was
intentionally omitted to keep the complexity and risks down.
So a priori I'd say it's a no. You can bring new arguments to persuade
me though.
> Just an idea, if it's a stupid one, please let me know why - and if
> you've got a better suggestion than the above kludge for figuring out
> which disk is which please fill me in!
>
Just name the disks after whatever makes sense t you, not whatever makes
sense to GRUB, it's your disks after all.
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]
next prev parent reply other threads:[~2011-01-28 22:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-28 15:33 Suggestion from a noob hansbkk
2011-01-28 22:24 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2011-01-30 4:11 ` hansbkk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D43422B.60207@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.