LABEL only 1 device
Hallo, linux-btrfs,
maybe it's a big error using the commmand
mkfs.btrfs -L xyz /dev/sdx1 /dev/sdy1 /dev/sdz1
(and so labelling many partitions) because each device/partition gets the same label.
Mounting seems to be no problem, but (p.e.) "delete" doesn't kill the btrfs informations shown with (p.e.) "blkid /dev/sdy1", especially it doesn't delete the label.
Viele Gruesse!
Helmut
Quoted 4 lines · Helmut Hullen
Hallo, linux-btrfs,
maybe it's a big error using the commmand
Quoted 8 lines
mkfs.btrfs -L xyz
/dev/sdx1/dev/sdy1/dev/sdz1(and so labelling many partitions) because each device/partition gets the same label.
Mounting seems to be no problem, but (p.e.) "delete" doesn't kill the btrfs informations shown with (p.e.) "blkid
/dev/sdy1", especially it doesn't delete the label.
What do you mean by "delete" here?
The label is a *filesystem* label, not a label for the block
device(s) it lives on, so it doesn't make much sense to talk about putting an FS label on only one of the devices that the FS is on.
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- "I am the author. You are the audience. I outrank you!" --- Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 5 lines
Quoted 3 lines
Mounting seems to be no problem, but (p.e.) "delete" doesn't kill the btrfs informations shown with (p.e.) "blkid
/dev/sdy1", especially it doesn't delete the label.What do you mean by "delete" here?
btrfs device delete <device> <path>
Quoted 3 lines
The label is a *filesystem* label, not a label for the block
device(s) it lives on, so it doesn't make much sense to talk about putting an FS label on only one of the devices that the FS is on.
My (planned) usual work (once a year or so):
btrfs device add <biggerdevice> <path> btrfs filesystem balance <path> btrfs device delete <smallerdevice> <path>
And the "devices" are (p.e.) /dev/sdj1, /dev/sdk1 etc. (partitions on a device).
Therefor I can see some informations via (p.e.)
blkid /dev/sdj1
I prefer LABELling the devices/partitions, and then I'd seen that the option "-L" makes problems when I use it for more than 1 device/ partition.
With other file systems there's no real problem with the same label for several partitions - it doesn't work. But btrfs bundles these partitions (perhaps sometimes/most times regardless of the labels of the other partitions).
Viele Gruesse!
Helmut
Quoted 11 lines · Helmut Hullen
Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 5 lines
Quoted 3 lines
Mounting seems to be no problem, but (p.e.) "delete" doesn't kill the btrfs informations shown with (p.e.) "blkid
/dev/sdy1", especially it doesn't delete the label.What do you mean by "delete" here?
btrfs device delete <device> <path>
OK.
Quoted 10 lines
Quoted 3 lines
The label is a *filesystem* label, not a label for the block
device(s) it lives on, so it doesn't make much sense to talk about putting an FS label on only one of the devices that the FS is on.My (planned) usual work (once a year or so):
btrfs device add <biggerdevice> <path> btrfs filesystem balance <path> btrfs device delete <smallerdevice> <path>
Quoted 6 lines
And the "devices" are (p.e.)
/dev/sdj1,/dev/sdk1etc. (partitions on a device).Therefor I can see some informations via (p.e.)
blkid
/dev/sdj1
OK, the real problem you're seeing is that when btrfs removes a
device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and /dev/zero.
Quoted 3 lines
I prefer LABELling the devices/partitions, and then I'd seen that the option "-L" makes problems when I use it for more than 1 device/ partition.
As far as I know, you can't label partitions or devices. Labels are
a filesystem thing, and are stored in a FS-dependent manner. There's a confusion that historically it's been a one-to-one mapping, so people get *very* sloppy about the distinction (particularly since there's no real way of referring to a filesystem independently of the block device(s) it's resident on).
Quoted 4 lines
With other file systems there's no real problem with the same label for several partitions - it doesn't work. But btrfs bundles these partitions (perhaps sometimes/most times regardless of the labels of the other partitions).
I say again, partitions are not labelled. *Filesystems* are
labelled. I think that with a GPT you can refer to the disk itself and its partitions by a UUID each, but I'm not 100% certain.
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- emacs: Emacs Makes A Computer Slow. --- Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 6 lines
Quoted 5 lines
My (planned) usual work (once a year or so):
btrfs device add <biggerdevice> <path> btrfs filesystem balance <path> btrfs device delete <smallerdevice> <path>
Quoted 6 lines
OK, the real problem you're seeing is that when btrfs removes a
device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and/dev/zero.
Ok - I'll try again (not today ...).
If I remember correct in early times deleting only the first block of the partition didn't reach ...
My last try with "delete" let me believe that btrfs had deleted the "critical" informations; I had tested it with "blkid". But looking into the first sector of the partition may be more reliable.
Quoted 3 lines
Quoted 3 lines
I prefer LABELling the devices/partitions, and then I'd seen that the option "-L" makes problems when I use it for more than 1 device/ partition.
[...]
Quoted 3 lines
I say again, partitions are not labelled. *Filesystems* are
labelled. I think that with a GPT you can refer to the disk itself and its partitions by a UUID each, but I'm not 100% certain.
My last try:
mkfs.btrfs -d raid0 -m raid1 /dev/sdk1 /dev/sdl1 /dev/sdm1
mkfs.btrfs -L SCSI /dev/sdk1
seemed to work.
mount LABEL=SCSI /mnt/btr
worked as expected, the bundle of 3 partitions was mounted. And only "/ dev/sdk1" got this label, no other partition.
Viele Gruesse!
Helmut
Quoted 17 lines · Helmut Hullen
Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 6 lines
Quoted 5 lines
My (planned) usual work (once a year or so):
btrfs device add <biggerdevice> <path> btrfs filesystem balance <path> btrfs device delete <smallerdevice> <path>
Quoted 6 lines
OK, the real problem you're seeing is that when btrfs removes a
device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and/dev/zero.
Quoted 3 lines
Ok - I'll try again (not today ...).
If I remember correct in early times deleting only the first block of the partition didn't reach ...
No, it won't -- the first superblock on btrfs is at 64k into the
device. Most filesystems do something similar, because there's other things that occasionally put metadata in the first part of the device, so it avoids having the FS's superblock overwritten accidentally.
Quoted 18 lines
My last try with "delete" let me believe that btrfs had deleted the "critical" informations; I had tested it with "blkid". But looking into the first sector of the partition may be more reliable.
Quoted 3 lines
Quoted 3 lines
I prefer LABELling the devices/partitions, and then I'd seen that the option "-L" makes problems when I use it for more than 1 device/ partition.
[...]
Quoted 3 lines
I say again, partitions are not labelled. *Filesystems* are
labelled. I think that with a GPT you can refer to the disk itself and its partitions by a UUID each, but I'm not 100% certain.My last try:
mkfs.btrfs -d raid0 -m raid1
/dev/sdk1/dev/sdl1/dev/sdm1
Quoted 8 lines
mkfs.btrfs -L SCSI
/dev/sdk1seemed to work.
mount LABEL=SCSI
/mnt/btrworked as expected, the bundle of 3 partitions was mounted. And only "/ dev/sdk1" got this label, no other partition.
That's because you've just destroyed part of the original
filesystem that was on /dev/sd[klm]1 and created a new single-device filesystem on /dev/sdk1.
mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS. It *cannot* be used to change the label of an existing FS. If you want to do that, use "btrfs filesystem label".
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- emacs: Emacs Makes A Computer Slow. --- Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
What you need to do is, immediately after
removing a device from the FS, zero the first part of the partition with dd and/dev/zero.Ok - I'll try again (not today ...).
If I remember correct in early times deleting only the first block of the partition didn't reach ...
Quoted 5 lines
No, it won't -- the first superblock on btrfs is at 64k into the
device. Most filesystems do something similar, because there's other things that occasionally put metadata in the first part of the device, so it avoids having the FS's superblock overwritten accidentally.
Ok - but deleting the first 100 kByte or the first 1 MByte does reach? Last times I'd run a job which deleted all (but that's nasty for disks with much more than 100 GByte ...)
Quoted 9 lines
Quoted 8 lines
mkfs.btrfs -L SCSI
/dev/sdk1seemed to work.
mount LABEL=SCSI
/mnt/btrworked as expected, the bundle of 3 partitions was mounted. And only "/ dev/sdk1" got this label, no other partition.
Quoted 7 lines
That's because you've just destroyed part of the original
filesystem that was on /dev/sd[klm]1 and created a new single-device filesystem on/dev/sdk1.mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS. It *cannot* be used to change the label of an existing FS. If you want to do that, use "btrfs filesystem label".
Hmmmm - I'll try ...
Thank you!
-------------------------------------
Label: 'SCSI' uuid: 8e287956-d73f-46cb-8938-b00315c596c6
Total devices 1 FS bytes used 92.00KB devid 1 size 136.73GB used 2.04GB path /dev/sdj1
Label: 'Scsi' uuid: b59caf71-1a38-47cc-bad3-c2d87357c971
Total devices 3 FS bytes used 9.09GB devid 2 size 136.73GB used 4.01GB path /dev/sdl1 devid 3 size 68.37GB used 5.01GB path /dev/sdm1 devid 1 size 16.96GB used 5.02GB path /dev/sdk1
Btrfs Btrfs v0.19
looks good ...
Viele Gruesse!
Helmut
Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 3 lines
mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS. It *cannot* be used to change the label of an existing FS.
The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition.
Quoted 1 line
If you want to do that, use "btrfs filesystem label".
And that seems to work as I expected - fine.
Adding a device works, deleting a device works. Fine! Now I'll try the job with my Terabyte disks.
(Yes - I have backups ...)
Viele Gruesse!
Helmut
Quoted 10 lines · Helmut Hullen
Hallo, Hugo,
Du meintest am 26.02.12:
Quoted 3 lines
mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS. It *cannot* be used to change the label of an existing FS.The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition.
I've said this several times: Your expectations are wrong. You
don't label partitions. You label filesystems. You are using the wrong tool (filesystems labels) for the job (uniquely identifying partitions).
Quoted 11 lines
Quoted 1 line
If you want to do that, use "btrfs filesystem label".
And that seems to work as I expected - fine.
Adding a device works, deleting a device works. Fine! Now I'll try the job with my Terabyte disks.
(Yes - I have backups ...)
Viele Gruesse!
Helmut
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Be pure. Be vigilant. Behave. --- Hallo, Hugo,
Du meintest am 27.02.12:
Quoted 10 lines
Quoted 7 lines
Quoted 4 lines
mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS. It *cannot* be used to change the label of an existing FS.The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition.
I've said this several times: Your expectations are wrong. You
don't label partitions.
Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").
Viele Gruesse!
Helmut
Helmut Hullen posted on Mon, 27 Feb 2012 11:27:00 +0100 as excerpted:
Quoted 8 lines
Du meintest am 27.02.12:
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
mkfs.btrfs creates a new filesystem. The -L option sets the label
for the newly-created FS.The safest way may be deleting this option ... it seems to work as expected only when I create a new FS on 1 disk/partition.
Quoted 6 lines
Quoted 2 lines
I've said this several times: Your expectations are wrong. You
don't label partitions.Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").
AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem.
Quoted 1 line
From the manpages:
mkfs.btrfs (aka mkbtrfs):
-L, --label name
Specify a label for the filesystem.
mkfs.ext2/3/4 (aka mke2fs):
-L new-volume-label
Set the volume label for the filesystem to new-volume-label. The maximum length of the volume label is 16 bytes.
e2label:
e2label will display or change the filesystem label on the ext2, ext3, or ext4 filesystem located on device.
mkreiserfs:
-l | --label LABEL
Sets the volume label of the filesystem. LABEL
can at most be 16 characters long; if it is longer than 16 characters, mkreiserfs will truncate it.
reiserfstune:
-l | --label LABEL
Set the volume label of the filesystem. LABEL can be at most 16 characters long; if it is longer than 16 characters, reiserfstune will truncate it.
The mkswap manpage does make things a bit more confusing, until you realize that the "device" they're referencing is a "swap device", which can be a file, not just a "block device".
mkswap sets up a Linux swap area on a device or in a file.
[...]
-L, --label label
Specify a label for the device, to allow swapon by label.
fstab indicates the filesystem label:
The first field (fs_spec).
This field describes the block special device or remote filesystem to be mounted.
For ordinary mounts it will hold (a link to) a block special device node (as created by mknod(8)) for the device to be mounted, like /dev/cdrom' or /dev/sdb7'. [...]
Instead of giving the device explicitly, one may indicate the (ext2 or xfs) filesystem that is to be mounted by its UUID or volume label (cf. e2label(8) or xfs_admin(8)), writing LABEL=<label> or UUID=<uuid>, e.g., `LABEL=Boot'[.] This will make the system more robust: adding or removing a SCSI disk changes the disk device name but not the filesystem volume label.
mount seems to be confused, using label in both the filesystem and device context (it also discusses selinux labels, etc, which are of course different). I'm not going to quote it here as the bits discussing label are dispersed and getting context clear on all of them would take a lot of space. Searching the manpage for "label" (case insensitive search) works, tho, again noting that it uses "label" in selinux and other contexts as well.
In another post I mentioned that gpt partitions do have "names", which /could/ function similarly to labels, tho Linux including the mount command generally ignores them at present. From the gdisk (part of gptfdisk) manpage (the cgdisk and sgdisk manpages, same package, are similarly worded, including the note on the distinction between gpt partition name and filesystem label):
c Change the GPT name of a partition. This name is encoded
as a UTF-16 string, but proper entry and display of anything beyond basic ASCII values requires suitable locale and font support. For the most part, Linux ignores the partition name, but it may be important in some OSes. GPT fdisk sets a default name based on the partition type code. Note that the GPT partition name is different from the filesystem name, which is encoded in the filesystem's data structures.
Note especially that last sentence, above.
So a filesystem label is just that, a /filesystem/ label. That there's normally a 1:1 correspondence between filesystem and the block device(s) it's on is simply an accident. But it's NOT an accident when a btrfs filesystem label applies to ALL the devices that compose the filesystem, since it's a FILESYSTEM label, NOT a PARTITION label. As the gptfdisk manpages make clear, partition names/labels, where they exist as in gpt based partitioning, are quite distinct from the filesystem names/labels.
However, the above manpage research does point out that while usage is generally quite consistent, the mkswap and mount manpages usage is ambiguous, and should be made more clear.
Perhaps later today I'll file bugs...
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Hallo, Duncan,
Du meintest am 27.02.12:
Quoted 19 lines
Quoted 7 lines
Quoted 2 lines
I've said this several times: Your expectations are wrong. You
don't label partitions.Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem.
From the manpages:
mkfs.btrfs (aka mkbtrfs):
-L, --label name
Specify a label for the filesystem.
Quoted 6 lines
mkfs.ext2/3/4 (aka mke2fs):
-L new-volume-label
Set the volume label for the filesystem to new-volume-label. The maximum length of the volume label is 16 bytes.
But there's a small difference:
mke2fs -L MyLabel /dev/sdn4
only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit).
mkfs.btrfs -L MyLabel /dev/sdn4
not only sets/changes the label but also (re-)creates a btrfs filesystem, using the default parameters.
I had to learn this difference ...
Viele Gruesse!
Helmut
Quoted 28 lines · Helmut Hullen
Du meintest am 27.02.12:
Quoted 19 lines
Quoted 7 lines
Quoted 2 lines
I've said this several times: Your expectations are wrong. You
don't label partitions.Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem.
From the manpages:
mkfs.btrfs (aka mkbtrfs):
-L, --label name
Specify a label for the filesystem.Quoted 6 lines
mkfs.ext2/3/4 (aka mke2fs):
-L new-volume-label
Set the volume label for the filesystem to new-volume-label. The maximum length of the volume label is 16 bytes.
Quoted 6 lines
But there's a small difference:
mke2fs -L MyLabel
/dev/sdn4only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit).
That feels really weird. It wouldn't ever occur to me to look at a
mkfs tool to relabel a filesystem without destroying the data on it. I view this behaviour as a bug.
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Great oxymorons of the world, no. 6: Mature Student --- Hi Helmut,
are you sure that 'mkfs.ext2/3/4 -L "label" /dev/xxx' doesn't create a new fs?
Afaik to change a label of a given (ext2/3/4) filesystem you should use tune2fs.
I don't have a linux system available right now but this is what I would expect and what would make a lot more sense then changing a label via mkfs.ext2/3/4. If you are correct with that labeling thing then the btrfs way makes like 1000x more sense then the way ext2/3/4 does it.
mkfs should only be used for creating filesystems. For changing existing fs tools like tune2fs, btrfs etc. should be used.
Regards,
Felix
Quoted 50 lines · Helmut Hullen
Hallo, Duncan,
Du meintest am 27.02.12:
Quoted 19 lines
Quoted 7 lines
Quoted 2 lines
I've said this several times: Your expectations are wrong. You
don't label partitions.Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem.
From the manpages:
mkfs.btrfs (aka mkbtrfs):
-L, --label name
Specify a label for the filesystem.Quoted 6 lines
mkfs.ext2/3/4 (aka mke2fs):
-L new-volume-label
Set the volume label for the filesystem to
new-volume-label. The maximum length of the
volume label is 16 bytes.But there's a small difference:
mke2fs -L MyLabel
/dev/sdn4only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit).
mkfs.btrfs -L MyLabel
/dev/sdn4not only sets/changes the label but also (re-)creates a btrfs filesystem, using the default parameters.
I had to learn this difference ...
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 28 lines · Helmut Hullen
Du meintest am 27.02.12:
Quoted 19 lines
Quoted 7 lines
Quoted 2 lines
I've said this several times: Your expectations are wrong. You
don't label partitions.Yes - now I know.
But I'm afraid other people also expect wrong - when I use mkfs.ext[234] then this option works (in another way than with "mkfs.btrfs").AFAIK, it works in the same way... that is, it labels the, in that case, ext2/3/4 filesystem, in this case (mkfs.btrfs), btrfs filesystem.
From the manpages:
mkfs.btrfs (aka mkbtrfs):
-L, --label name
Specify a label for the filesystem.Quoted 6 lines
mkfs.ext2/3/4 (aka mke2fs):
-L new-volume-label
Set the volume label for the filesystem to new-volume-label. The maximum length of the volume label is 16 bytes.
Quoted 6 lines
But there's a small difference:
mke2fs -L MyLabel
/dev/sdn4only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit).
OK, I have just tried this out. It does set the filesystem label.
It also wipes the filesystem, as I expected it to. You clearly aren't doing this on existing filesystems with data in them.
hrm@ruth:~ $ sudo mke2fs /dev/loop0
mke2fs 1.42 (29-Nov-2011)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
5120 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
hrm@ruth:~ $ sudo mount /dev/loop0 /mnt
hrm@ruth:~ $ sudo dd if=/dev/urandom of=/mnt/foo bs=1M count=5 5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 1.74158 s, 3.0 MB/s hrm@ruth:~ $ ls /mnt
foo lost+found
hrm@ruth:~ $ sudo umount /mnt
hrm@ruth:~ $ sudo mke2fs -L newlabel /dev/loop0 mke2fs 1.42 (29-Nov-2011)
Filesystem label=newlabel
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
25688 inodes, 102400 blocks
5120 blocks (5.00%) reserved for the super user First data block=1
Maximum filesystem blocks=67371008
13 block groups
8192 blocks per group, 8192 fragments per group
1976 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
hrm@ruth:~ $ sudo mount /dev/loop0 /mnt
hrm@ruth:~ $ ls /mnt
lost+found
hrm@ruth:~ $
Hugo.
Signature · 3 lines
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Great oxymorons of the world, no. 6: Mature Student --- Hallo, Hugo,
Du meintest am 27.02.12:
Quoted 10 lines
Quoted 6 lines
But there's a small difference:
mke2fs -L MyLabel
/dev/sdn4only sets/changes the label (ok - it tests the type of the partition and refuses labeling if the type doesn't fit).
OK, I have just tried this out. It does set the filesystem label.
It also wipes the filesystem, as I expected it to. You clearly aren't doing this on existing filesystems with data in them.
I should have tested it ... sorry.
I've always labeled my ext[234] partitions with "e2label".
And because I hadn't found such a simple command for btrfs I took "mkfs.btrfs -L" instead of "btrfs fi label <mountpoint>".
Viele Gruesse!
Helmut
Hugo Mills posted on Sun, 26 Feb 2012 16:44:00 +0000 as excerpted:
Quoted 10 lines
Quoted 3 lines
I prefer LABELling the devices/partitions, and then I'd seen that the option "-L" makes problems when I use it for more than 1 device/ partition.
As far as I know, you can't label partitions or devices. Labels are
a filesystem thing, and are stored in a FS-dependent manner. There's a confusion that historically it's been a one-to-one mapping, so people get *very* sloppy about the distinction (particularly since there's no real way of referring to a filesystem independently of the block device(s) it's resident on).
With legacy MBR-based partitioning, that is correct, devices don't have a label, filesystems do. Take an md/raid1 device for instance, and put a filesystem on it. It's the filesystem that gets the label when mkfs (make filesystem) is done, putting the same label on the filesystem on all the md/raid1 component devices since it's mirrored (raid-1-ed) to all of them.
However, GPT-based partitioning *DOES* have partition level labels available. I'm not sure if for instance parted exposes that functionality, but gptfdisk, which I use, certainly does. That's useful with partitioned md/raid, since the filesystem on the partition gets a different label than the gpt-partition itself, which has a different label than all the underlying physical device partitions that compose the md/raid1.
Unfortunately, since gpt is reasonably new in terms of filesystem and partitioning tools, there isn't really anything (mount, etc) that makes /use/ of that label yet, tho gptfdisk does display it, let you modify it, etc, so it's easier to keep track at that level of whether you're operating on what you intended to operate on, as long as you keep the physical device partition labels distinct from the partitioned md/raid device labels, from the filesystem labels as created by mkfs. (I have a consistent scheme I use, so they are distinct here.)
FWIW, gpt was designed by Intel and others to be used by EFI, but BIOS based devices support it as well, as do grub2, grub-legacy (with patches applied), and the kernel (with the related kernel config options enabled). Since it does away with the primary/secondary/logical partition distinction, has dual-copy checksummmed partition tables, and has partition labels, plus the fact that it supports 2+TiB drives, it's gradually replacing MBR even on BIOS systems, but it's a slow process as MBR has been around for decades!
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 3 lines · Duncan
Unfortunately, since gpt is reasonably new in terms of filesystem and partitioning tools, there isn't really anything (mount, etc) that makes /use/ of that label yet,
udev exports GPT labels and uuids by symlinks, see
ls /dev/disk/by-partlabel/
ls /dev/disk/by-partuuid/
you can use these links in your fstab. And if I good remember kernel supports PARTUUID for root= command line option.
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Karel Zak posted on Tue, 28 Feb 2012 23:35:57 +0100 as excerpted:
Quoted 9 lines · Duncan
Quoted 3 lines
Unfortunately, since gpt is reasonably new in terms of filesystem and partitioning tools, there isn't really anything (mount, etc) that makes /use/ of that label yet,
udev exports GPT labels and uuids by symlinks, see
ls
/dev/disk/by-partlabel/
ls/dev/disk/by-partuuid/
So it does. =:^) I knew about the /dev/disk/by-*/ dirs in general and had no doubt browsed past them before without actually noting the significance, but hadn't actually noticed the by-part* until you pointed it out specifically. Either that or exporting these is relatively new to udev, tho it's probably been there and I simply didn't see it.
Either way, thanks! =:^)
Quoted 1 line
you can use these links in your fstab.
Yes. Now that I know they are there, using them in fstab makes sense, since I remember seeing the note in the mount manpage that it uses the udev symlinks internally already, so whatever udev does in this regard should "just work" with mount, and thus in fstab.
Useful indeed! It seems modern Linux (or more properly, a modern udev and mount, along with the kernel of course) has rather more use for partition- labels than I was aware and thus than I was giving it credit for! =:^)
Thanks!
Quoted 2 lines
And if I good remember kernel
supports PARTUUID for root= command line option.
That wouldn't surprise me at all.
That leaves grub2 (and other bootloaders). I already know grub2 prefers UUIDs to /dev/* device names. But I don't know if it handles labels, either the gpt-partlabel or the fs-label version. I'll have to try that too. Fortunately for me my device ordering is quite stable (and I hand- edit grub.cfg, no mkgrub-config here), so that "just works". But UUIDs are designed for computer use, not human use, while labels work well for both, so if grub2 handles labels and I can use either fs or partition/ device labels there too, I'll be a happy camper indeed! =:^)
But just knowing mount/fstab supports partlabels is going to be a boon for me! My current setup (pending multi-way raid1 mirroring, and perhaps a bit more stability, in btrfs) has multiple partitions and partitioned md/raids, with working and backup copies of nearly all of them. When I update the backup, I often mkfs and start with a clean filesystem, then copy all the data over from the working copy. The mkfs step of course changes filesystem UUID and my labeling scheme includes the date the filesystem and backup image was made, so it changes too. So while I've been using (filesystem) labels in fstab for some time, I've had to update them when I update my backups.
Now I should be able to use the partlabels in fstab instead, and those only change if I repartition, a much less frequent occurrence, meaning I can update my backups without having to update the fstab for mounting them, at the same time. =:^)
Signature · 3 lines
Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Quoted 6 lines · Hugo Mills
OK, the real problem you're seeing is that when btrfs removes a
device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and/dev/zero.
A correction here: if the device being removed is writable, the superblock is cleared so it's not recognized as a part of any other fs:
int btrfs_rm_device(struct btrfs_root *root, char *device_path)
...
/*
* at this point, the device is zero sized. We want to
* remove it from the devices list and zero out the old super
*/
if (clear_super) {
/* make sure this device isn't detected as part of
* the FS anymore
*/
memset(&disk_super->magic, 0, sizeof(disk_super->magic));
set_buffer_dirty(bh);
sync_dirty_buffer(bh);
}Doing this manually means zeroing 4k block at all offsets up to partition size:
Superblock 0 offset 65536 Superblock 1 offset 67108864 Superblock 2 offset 274877906944 Superblock 3 offset 1125899906842624 Superblock 4 offset 4611686018427387904
david
Hallo, David,
Du meintest am 27.02.12:
[deleting btrfs partition]
Quoted 10 lines
Quoted 6 lines
OK, the real problem you're seeing is that when btrfs removes a
device from the filesystem, that device is not modified in any way. This means that the old superblock is left behind on it, containing the FS label information. What you need to do is, immediately after removing a device from the FS, zero the first part of the partition with dd and/dev/zero.A correction here: if the device being removed is writable, the superblock is cleared so it's not recognized as a part of any other fs:
[...]
Quoted 8 lines
Doing this manually means zeroing 4k block at all offsets up to partition size:
Superblock 0 offset 65536
Superblock 1 offset 67108864
Superblock 2 offset 274877906944
Superblock 3 offset 1125899906842624
Superblock 4 offset 4611686018427387904
My actual experiments:
dd if=/dev/zero of=/dev/sdxn bs=16M count=1
seems to be enough. Perhaps deleting the first 16 MByte is too much.
Viele Gruesse!
Helmut