From: Michail Brzitwa <michail@brzitwa.de>
To: linux-kernel@vger.kernel.org
Cc: Andries.Brouwer@cwi.nl
Subject: Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Date: Fri, 16 Mar 2001 03:37:12 +0100 [thread overview]
Message-ID: <20010316033712.A11658@ichabod.han.de> (raw)
In-Reply-To: <mng==UTC200103152331.AAA2159588.aeb@vlet.cwi.nl>
In article <mng==UTC200103152331.AAA2159588.aeb@vlet.cwi.nl> you wrote:
> The real problem is that our disks usually do not have a volume label.
> Outside of all file systems.
> The "signatures" that we rely on today are located in different places,
> so that a filesystem can have several valid signatures at the same time.
> And we first know where to look when we know the type already.
>
> Design a Linux partition table format, where a partition descriptor
> has fields start, end, fstype, fslabel, and the whole disk has a vollabel.
> Put it in sector 0-N for an all-Linux disk, and in sectors pointed at
> by a classical DOS-type partition table entry when the disk is shared.
I don't understand that. Do you propose something like *BSD or Solaris
disklabels? In that case a whole new set of user utilities would be
needed to create your new tables as well as maintaining the old style
partition tables.
The process of copying or moving fs around disks seems to be quite common
as tools like partition magic or parted suggest. Your idea would make
that process more difficult and less user-friendly. It should imho always
be simple to backup an fs to tape from a dying disk and restore it to
a new one without losing the label etc.
Perhaps putting this kind of information into a generalized start sector
for all Linux fs would be a better idea (is that what you meant?). Copying
an fs would again be as easy as using dd or cp. Of course this means
that most Linux fs types including swap partitions should leave this
start sector alone. A common mkfs would create that leading block after
the mkfs.<fs type> successfully created the fs meta-contents.
It would be optimal imho if the partition table entry contains the start
sector and size only, and all other information like type, uuid, label
etc. is within the fs disk space. No out-of-band fs information anymore.
The disk volume label should be located outside all fs as you mentioned
but separated from the actual fs labels.
--
Michail Brzitwa <michail@brzitwa.de> +49-511-343215
next parent reply other threads:[~2001-03-16 2:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mng==UTC200103152331.AAA2159588.aeb@vlet.cwi.nl>
2001-03-16 2:37 ` Michail Brzitwa [this message]
2001-03-15 23:31 [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20 Andries.Brouwer
2001-03-16 0:51 ` Andreas Dilger
2001-03-16 13:57 ` Mikael Pettersson
2001-03-16 1:08 ` Alexander Viro
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=20010316033712.A11658@ichabod.han.de \
--to=michail@brzitwa.de \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox