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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 26, 2012 at 04:23:00PM +0100, Helmut Hullen wrote:> 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.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. -- === 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:>> 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>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 26, 2012 at 05:12:00PM +0100, Helmut Hullen wrote:> Hallo, Hugo, > > Du meintest am 26.02.12: > > >> 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.> > 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/sdj1OK, 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.> 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 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. -- === 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:>> My (planned) usual work (once a year or so): >> >> btrfs device add <biggerdevice> <path> >> btrfs filesystem balance <path> >> btrfs device delete <smallerdevice> <path>> 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.>> 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.[...]> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 26, 2012 at 05:57:00PM +0100, Helmut Hullen wrote:> Hallo, Hugo, > > Du meintest am 26.02.12: > > >> My (planned) usual work (once a year or so): > >> > >> btrfs device add <biggerdevice> <path> > >> btrfs filesystem balance <path> > >> btrfs device delete <smallerdevice> <path> > > > 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 ...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.> 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.> >> 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. > > [...] > > > 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.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. -- === 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. ---
Hugo Mills posted on Sun, 26 Feb 2012 16:44:00 +0000 as excerpted:>> 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! -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Hugo, Du meintest am 26.02.12:>>> 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 ...> 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 ...)>> 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.> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Hugo, Du meintest am 26.02.12:> 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.> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 27, 2012 at 07:44:00AM +0100, Helmut Hullen wrote:> Hallo, Hugo, > > Du meintest am 26.02.12: > > > 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).> > 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-- === 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:>>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 26, 2012 at 04:44:00PM +0000, Hugo Mills wrote:> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, David, Du meintest am 27.02.12: [deleting btrfs partition]>> 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:[...]> 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 4611686018427387904My 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Helmut Hullen posted on Mon, 27 Feb 2012 11:27:00 +0100 as excerpted:> Du meintest am 27.02.12: > >>>> 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. > >> 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. 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... -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hallo, Duncan, Du meintest am 27.02.12:>>> 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.> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 27, 2012 at 10:15:00PM +0100, Helmut Hullen wrote:> Du meintest am 27.02.12: > > >>> 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. > > > 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).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. -- === 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 On 2/27/12 10:15 PM, Helmut Hullen wrote:> Hallo, Duncan, > > Du meintest am 27.02.12: > >>>> 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. > >> 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 27, 2012 at 10:15:00PM +0100, Helmut Hullen wrote:> Du meintest am 27.02.12: > > >>> 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. > > > 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).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 labelOS 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. -- === 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:>> 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).> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Feb 26, 2012 at 06:07:31PM +0000, Duncan wrote:> 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 -- Karel Zak <kzak@redhat.com> http://karelzak.blogspot.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Karel Zak posted on Tue, 28 Feb 2012 23:35:57 +0100 as excerpted:> On Sun, Feb 26, 2012 at 06:07:31PM +0000, Duncan wrote: >> 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! =:^)> 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!> 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. =:^) -- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html