Re: LABEL only 1 device

2012-02-29 Thread Duncan
Karel Zak posted on Tue, 28 Feb 2012 23:35:57 +0100 as excerpted:

 On Sun, Feb 26, 2012 at 06:07:31PM +, 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-28 Thread Karel Zak
On Sun, Feb 26, 2012 at 06:07:31PM +, 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  k...@redhat.com
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread Hugo Mills
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. ---  


signature.asc
Description: Digital signature


Re: LABEL only 1 device

2012-02-27 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread David Sterba
On Sun, Feb 26, 2012 at 04:44:00PM +, 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread Helmut Hullen
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 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
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread Duncan
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 

Re: LABEL only 1 device

2012-02-27 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread Hugo Mills
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 ---   


signature.asc
Description: Digital signature


Re: LABEL only 1 device

2012-02-27 Thread Felix Blanke

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 majord...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-27 Thread Hugo Mills
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 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.

-- 
=== 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 ---   


signature.asc
Description: Digital signature


Re: LABEL only 1 device

2012-02-27 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-26 Thread Hugo Mills
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! --- 


signature.asc
Description: Digital signature


Re: LABEL only 1 device

2012-02-26 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-26 Thread Hugo Mills
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/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.

 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. ---   


signature.asc
Description: Digital signature


Re: LABEL only 1 device

2012-02-26 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-26 Thread Duncan
Hugo Mills posted on Sun, 26 Feb 2012 16:44:00 + 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-26 Thread Helmut Hullen
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.

H - I'll try ...

Thank you!

-

Label: 'SCSI'  uuid: 8e287956-d73f-46cb-8938-b00315c596c6
Total devices 1 FS bytes used 92.00KB
devid1 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
devid2 size 136.73GB used 4.01GB path /dev/sdl1
devid3 size 68.37GB used 5.01GB path /dev/sdm1
devid1 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: LABEL only 1 device

2012-02-26 Thread Helmut Hullen
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html