btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
Hi All, I'm trying to repair a broken fs using btrfsck and am hitting a failed assertion. I'd appreciate any suggestions for what to do next. Is there any thing I can do to help fix this bug? Any other information from my FS which would help? If the FS could be salvaged that would be a bonus, but I'm more interested in providing a useful bug report before wiping the disk. My versions are: - OS - CentOS 6.3 - Kernel - 3.7.1-2 from http://elrepo.org/tiki/kernel-ml - btrfs-progs - v0.20-rc1-37-g91d9eec. Built today from git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git The failure is: # ./btrfsck --repair /dev/md4 enabling repair mode checking extents leaf parent key incorrect 183603200 bad block 183603200 leaf parent key incorrect 183640064 bad block 183640064 warning, start mismatch 152387469312 762175488 block 152387469312 rec extent_item_refs 1, passed 1 warning, start mismatch 449606139904 427217858560 block 427217858560 rec extent_item_refs 1, passed 1 ref mismatch on [32215040 4096] extent item 30, found 31 btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed. Aborted If i run btrfsck in non-repair mode I get: # ./btrfsck /dev/md4 checking extents leaf parent key incorrect 183603200 bad block 183603200 leaf parent key incorrect 183640064 bad block 183640064 warning, start mismatch 152387469312 762175488 checksum verify failed on 34390753280 wanted 26D779EB found 40 checksum verify failed on 34390753280 wanted 26D779EB found 40 block 152387469312 rec extent_item_refs 1, passed 1 warning, start mismatch 449606139904 427217858560 block 427217858560 rec extent_item_refs 1, passed 1 ref mismatch on [32215040 4096] extent item 30, found 31 Backref 32215040 parent 427255582720 root 427255582720 not found in extent tree backpointer mismatch on [32215040 4096] ... [snipped several thousand lines similar to the previous three] ... ref mismatch on [477808889856 4096] extent item 11, found 12 Backref 477808889856 parent 427202011136 root 427202011136 not found in extent tree backpointer mismatch on [477808889856 4096] Errors found in extent allocation tree checking fs roots root 256 inode 140337 errors 400 root 256 inode 169441 errors 400 root 256 inode 169442 errors 400 root 256 inode 1843202 errors 400 warning line 1789 found 651533594626 bytes used err is 1 total csum bytes: 624739028 total tree bytes: 11639873536 total fs tree bytes: 10394214400 btree space waste bytes: 2925577458 file data blocks allocated: 741854191616 referenced 741832200192 Btrfs v0.20-rc1-37-g91d9eec] -- 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: btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
On Thu, Jan 03, 2013 at 05:26:38AM -0700, Richard Cooper wrote: > Hi All, > > I'm trying to repair a broken fs using btrfsck and am hitting a failed > assertion. I'd appreciate any suggestions for what to do next. Is there any > thing I can do to help fix this bug? Any other information from my FS which > would help? If the FS could be salvaged that would be a bonus, but I'm more > interested in providing a useful bug report before wiping the disk. > Well good news is that its the allocator failing to find space for a new block, and the allocator in btrfs-progs is under-tested, so it's likely just an internal bug and something we can fix. Can you do btrfs fi show /dev/md4 (not mounted) and post that so we can be sure there's actually enough space. And I'll look at the allocator code in the meantime and see if theres something obvious wrong. Thanks, Josef -- 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
Libified btrfs utils?
Is it possible that you deliver btrfs management utilities come in a C library form? It is always good to have a C API and CLI utility separation. Take libparted as an example. How much more functionality is in gparted than the (standard) cli parted? Writting tools by direct access to an API is much more elegant for a programmer. Please, consider my suggestion. Many would appreciate it, i am sure... Especially people like me that want to write GUI frontends. Best regards, Georgios Tsalikis -- 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
Option LABEL
Hallo, linux-btrfs, please delete the option "-L" (for labelling) in "mkfs.btrfs", in some configurations it doesn't work as expected. My usual way: mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... One call for some devices. Wenn I add the option "-L mylabel" then each device gets the same label, and therefore some other programs can't find the (one) device with the defined label. Especially blkid findfs LABEL=mylabel don't work. file -s /dev/sdb (etc.) shows the label (and the problem). Other tries: mkfs.btrfs -L mylabel /dev/sdb creates a new btrfs filesystem and overwrites prior tries. What works: btrfs filesystem label /dev/sdb mylabel 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: Option LABEL
On Thu, Jan 03, 2013 at 04:14:00PM +0100, Helmut Hullen wrote: > Hallo, linux-btrfs, > > please delete the option "-L" (for labelling) in "mkfs.btrfs", in some > configurations it doesn't work as expected. > > My usual way: > > mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... > > One call for some devices. > Wenn I add the option "-L mylabel" then each device gets the same label, > and therefore some other programs can't find the (one) device with the > defined label. I'm sure we've been over this territory before. Devices are not labelled; filesystems are labelled. You are labelling the whole filesystem, which exists over several devices, so the same label will be attached to every device in the filesystem. > Especially > > blkid > findfs LABEL=mylabel > > don't work. How do you mean, "don't work"? What are they showing, and what do you think should they be showing? It looks like both of them print an arbitrary device node of the devices that the FS lives on. Given that both of these tools probably expect a one-to-one relationship between a block device and a filesystem, this is not unreasonable. > file -s /dev/sdb (etc.) > > shows the label (and the problem). > > Other tries: > > mkfs.btrfs -L mylabel /dev/sdb > > creates a new btrfs filesystem and overwrites prior tries. Yes, because you've just created a new filesystem. That's what mkfs.btrfs does, same as every other mkfs -- it creates a new filesystem, destroying what was there before. This is unsurprising. Hugo. > What works: > > btrfs filesystem label /dev/sdb mylabel -- === 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 --- What part of "gestalt" don't you understand? --- signature.asc Description: Digital signature
Re: Determining subvolumes
On Wed, Dec 26, 2012 at 01:55:13PM +, Hugo Mills wrote: > On Wed, Dec 26, 2012 at 08:38:54AM -0500, Gene Czarcinski wrote: > > I know that I can find out what btrfs "volumes" are on a system with > > the command: > > btrfs fi show > > > > I can also check if a partition of disk is a btrfs volume with the command: > > blkid -o value -s TYPE /dev/ > > > > And, if I mount that btrfs volume with something like: > > mount -t btrfs /dev/ /mnt/btrfs > > > > The, I can get a list of btrfs subvolumes on that volume with the command: > > btrfs subvolume list /mnt/btrfs > > > > My question: Is there a way of finding out what subvolumes are > > defined on a btrfs volume without mounting the volume? > >No. (Well, in theory the code is possible, but there's nothing I'm > aware of that will do it) It is possible to work with the filesystem offline, but lots of the useful code is written only in kernel module (and accessed via ioctl() calls from userspace). Listing the subvolumes consists of: * opening the filesystem (open_ctree_fs_info) * search root tree for all ROOT_ITEM (via btrfs_search_slot) and also the found items recursively * resolve the full path for each given root id (normally done via BTRFS_IOC_INO_LOOKUP) - btrfs_search_path_in_tree could be used almost verbatim (is not present in progs) The existing functions to list subvolumes would need enhancing to work both online and offline (eg. the filtering and printing code coud be shared). I don't know how far we should go to allow friendly access to an offline volume. For debugging purposes it's usually enough to grep through output of btrfs-debug-tree. Simple tasks like listing subvolumes or manipulating default subvolume do not sound like a bad use case. 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: [PATCH 1/8] Btrfs: remove deprecated comments
On Thu, Dec 27, 2012 at 05:01:17PM +0800, Liu Bo wrote: > commit d53ba47484ed6245e640ee4bfe9d21e9bfc15765 > (Btrfs: use commit root when loading free space cache) has remove > the deadlock check, and the related comments can be removed as well. > > Signed-off-by: Liu Bo 1-8 Reviewed-by: David Sterba I'd prefer some cover letter next time as you mix cleanups and speed optimizations (a short description stating that would suffice regarding this patch series) or send them in separate series. thanks, 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: >> please delete the option "-L" (for labelling) in "mkfs.btrfs", in >> some configurations it doesn't work as expected. >> >> My usual way: >> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... >> >> One call for some devices. >> Wenn I add the option "-L mylabel" then each device gets the same >> label, and therefore some other programs can't find the (one) device >> with the defined label. >I'm sure we've been over this territory before. Devices are not > labelled; filesystems are labelled. You are labelling the whole > filesystem, which exists over several devices, so the same label will > be attached to every device in the filesystem. But for what purpose offers "mkfs.btrfs" this option? >> Especially >> >> blkid >> findfs LABEL=mylabel >> >> don't work. >How do you mean, "don't work"? What are they showing, and what do > you think should they be showing? Without this double-labelled (?) devices "blkid" shows all devices with (if defined) their labels. When I define the same label for more than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output for any of the devices. "findfs": with double-labelled devices "findfs" doesn't find any label. > It looks like both of them print an > arbitrary device node of the devices that the FS lives on. Given that > both of these tools probably expect a one-to-one relationship between > a block device and a filesystem, this is not unreasonable. May be that "this is not unreasonable". But when "mkfs.btrfs" offers the "label" option I don't expect this behaviour. I had mentioned this problem more than a year ago, it still exists. 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: Libified btrfs utils?
On Thu, Jan 03, 2013 at 05:25:20PM +0200, Georgios Tsalikis wrote: > Is it possible that you deliver btrfs management utilities come in a C > library form? It is always good to have a C API and CLI utility separation. > Take libparted as an example. How much more functionality is in gparted than > the (standard) cli parted? Writting tools by direct access to an API is much > more elegant for a programmer. Please, consider my suggestion. Many would > appreciate it, i am sure... Especially people like me that want to write GUI > frontends. Thanks for the suggestion, this has been asked for in the past and is listed under projects: https://btrfs.wiki.kernel.org/index.php/Project_ideas#Provide_a_library_covering_.27btrfs.27_functionality 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: btrfsck: extent-tree.c:2549: btrfs_reserve_extent: Assertion `!(ret)' failed.
On 3 Jan 2013, at 15:06, Josef Bacik wrote: > On Thu, Jan 03, 2013 at 05:26:38AM -0700, Richard Cooper wrote: >> Hi All, >> >> I'm trying to repair a broken fs using btrfsck and am hitting a failed >> assertion. I'd appreciate any suggestions for what to do next. Is there >> anything I can do to help fix this bug? Any other information from my FS >> which would help? If the FS could be salvaged that would be a bonus, but I'm >> more interested in providing a useful bug report before wiping the disk. >> > > Well good news is that its the allocator failing to find space for a new > block, > and the allocator in btrfs-progs is under-tested, so it's likely just an > internal bug and something we can fix. Can you do btrfs fi show /dev/md4 (not > mounted) and post that so we can be sure there's actually enough space. # ./btrfs fi show /dev/md4 Label: none uuid: 5be10dea-64c1-474e-b640-987b25af3c27 Total devices 1 FS bytes used 606.79GB devid1 size 16.36TB used 627.04GB path /dev/md4 Thanks for looking at this. -- 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: Option LABEL
On Thu, Jan 03, 2013 at 05:29:00PM +0100, Helmut Hullen wrote:
> Hallo, Hugo,
>
> Du meintest am 03.01.13:
>
> >> please delete the option "-L" (for labelling) in "mkfs.btrfs", in
> >> some configurations it doesn't work as expected.
> >>
> >> My usual way:
> >>
> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ...
> >>
> >> One call for some devices.
> >> Wenn I add the option "-L mylabel" then each device gets the same
> >> label, and therefore some other programs can't find the (one) device
> >> with the defined label.
>
> >I'm sure we've been over this territory before. Devices are not
> > labelled; filesystems are labelled. You are labelling the whole
> > filesystem, which exists over several devices, so the same label will
> > be attached to every device in the filesystem.
>
> But for what purpose offers "mkfs.btrfs" this option?
So that you don't have to run the label command immediately after
making the filesystem. Most mkfs implementations for different
filesystems have something similar, usually with the -L option.
> >> Especially
> >>
> >> blkid
> >> findfs LABEL=mylabel
> >>
> >> don't work.
>
> >How do you mean, "don't work"? What are they showing, and what do
> > you think should they be showing?
>
> Without this double-labelled (?) devices "blkid" shows all devices with
"Double-labelled"? The filesystem has one label, belonging to the
filesystem. I don't see where the "double-labelling" comes in.
> (if defined) their labels. When I define the same label for more than 1
> device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output
> for any of the devices.
This is a fault in the version of blkid you're running, then.
There's nothing to stop me from labelling two ext2 filesystems with
the same label. If blkid can't handle that, then it's got problems
beyond btrfs. On my main machine, it seems to work correctly:
$ sudo blkid
/dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs"
/dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs"
/dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs"
/dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs"
/dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs"
/dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs"
/dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs"
My blkid version:
blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)
> "findfs": with double-labelled devices "findfs" doesn't find any label.
On my system, the filesystem with label "media" exists on
/dev/sd{a,b,c,e,p,q,r,s}:
$ sudo blkid -L media
/dev/sdb
$ sudo findfs LABEL=media
/dev/sdb
In each case, it's giving me the path of a block device node which
I can use to mount the filesystem. As far as I know, this is the
correct and expected behaviour.
> > It looks like both of them print an
> > arbitrary device node of the devices that the FS lives on. Given that
> > both of these tools probably expect a one-to-one relationship between
> > a block device and a filesystem, this is not unreasonable.
>
> May be that "this is not unreasonable". But when "mkfs.btrfs" offers the
> "label" option I don't expect this behaviour.
You're running mkfs. Why would you expect running mkfs *not* to
make a new filesystem? This is the behaviour on all other mkfses.
From the man page:
DESCRIPTION
mkfs.btrfs is used to create a btrfs filesystem (usually in a disk par‐
tition, or an array of disk partitions). device is the special file
corresponding to the device (e.g /dev/sdXX ). If multiple devices
are specified, btrfs is created spanning across the specified devices.
i.e. it's a tool to create a filesystem.
> I had mentioned this problem more than a year ago, it still exists.
It's not a problem. Everything is working as expected and as
designed.
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
--- You're never alone with a rubber duck... ---
signature.asc
Description: Digital signature
Re: GPF in read_extent_buffer while scrubbing on 3.7.0-rc8-00014-g27d7c2a
Hi Mathieu, Sorry for the late reply. I had quite a good reproducer once for what I suspect may be your problem here - but it suddenly stopped reproducing the problem and I still haven't figured out why. (see https://patchwork.kernel.org/patch/1773611/ if you're interested) Can you please give the following patch a try and report back if it helps you (apply on top of cmason/for-linus, 57ba86c)? If it doesn't, you've got three choices: a) forget about the problem b) send me a dump of your whole file system (space can be provided) c) receive debug patches, apply them and send me the output Thanks, -Jan -->8- diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 65f0367..d51185e 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3324,8 +3324,6 @@ int close_ctree(struct btrfs_root *root) btrfs_dev_replace_suspend_for_unmount(fs_info); - btrfs_scrub_cancel(fs_info); - /* wait for any defraggers to finish */ wait_event(fs_info->transaction_wait, (atomic_read(&fs_info->defrag_running) == 0)); @@ -3392,6 +3390,7 @@ int close_ctree(struct btrfs_root *root) btrfs_stop_workers(&fs_info->caching_workers); btrfs_stop_workers(&fs_info->readahead_workers); btrfs_stop_workers(&fs_info->flush_workers); + btrfs_scrub_cancel(fs_info); #ifdef CONFIG_BTRFS_FS_CHECK_INTEGRITY if (btrfs_test_opt(root, CHECK_INTEGRITY)) -- 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: Option LABEL
common labels work for me on my 3 way raid volumes. there's been no problem.
what might be a problem is when i do mount LABEL=foo, btrfs dev scan
is not automatic on failure.
On Thu, Jan 3, 2013 at 9:01 AM, Hugo Mills wrote:
> On Thu, Jan 03, 2013 at 05:29:00PM +0100, Helmut Hullen wrote:
>> Hallo, Hugo,
>>
>> Du meintest am 03.01.13:
>>
>> >> please delete the option "-L" (for labelling) in "mkfs.btrfs", in
>> >> some configurations it doesn't work as expected.
>> >>
>> >> My usual way:
>> >>
>> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ...
>> >>
>> >> One call for some devices.
>> >> Wenn I add the option "-L mylabel" then each device gets the same
>> >> label, and therefore some other programs can't find the (one) device
>> >> with the defined label.
>>
>> >I'm sure we've been over this territory before. Devices are not
>> > labelled; filesystems are labelled. You are labelling the whole
>> > filesystem, which exists over several devices, so the same label will
>> > be attached to every device in the filesystem.
>>
>> But for what purpose offers "mkfs.btrfs" this option?
>
>So that you don't have to run the label command immediately after
> making the filesystem. Most mkfs implementations for different
> filesystems have something similar, usually with the -L option.
>
>> >> Especially
>> >>
>> >> blkid
>> >> findfs LABEL=mylabel
>> >>
>> >> don't work.
>>
>> >How do you mean, "don't work"? What are they showing, and what do
>> > you think should they be showing?
>>
>> Without this double-labelled (?) devices "blkid" shows all devices with
>
>"Double-labelled"? The filesystem has one label, belonging to the
> filesystem. I don't see where the "double-labelling" comes in.
>
>> (if defined) their labels. When I define the same label for more than 1
>> device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output
>> for any of the devices.
>
>This is a fault in the version of blkid you're running, then.
> There's nothing to stop me from labelling two ext2 filesystems with
> the same label. If blkid can't handle that, then it's got problems
> beyond btrfs. On my main machine, it seems to work correctly:
>
> $ sudo blkid
> /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs"
> /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs"
> /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs"
> /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs"
> /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs"
> /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs"
> /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35"
> UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs"
>
>My blkid version:
>
> blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)
>
>> "findfs": with double-labelled devices "findfs" doesn't find any label.
>
>On my system, the filesystem with label "media" exists on
> /dev/sd{a,b,c,e,p,q,r,s}:
>
> $ sudo blkid -L media
> /dev/sdb
> $ sudo findfs LABEL=media
> /dev/sdb
>
>In each case, it's giving me the path of a block device node which
> I can use to mount the filesystem. As far as I know, this is the
> correct and expected behaviour.
>
>> > It looks like both of them print an
>> > arbitrary device node of the devices that the FS lives on. Given that
>> > both of these tools probably expect a one-to-one relationship between
>> > a block device and a filesystem, this is not unreasonable.
>>
>> May be that "this is not unreasonable". But when "mkfs.btrfs" offers the
>> "label" option I don't expect this behaviour.
>
>You're running mkfs. Why would you expect running mkfs *not* to
> make a new filesystem? This is the behaviour on all other mkfses.
>
>From the man page:
>
> DESCRIPTION
>mkfs.btrfs is used to create a btrfs filesystem (usually in a disk par‐
>tition, or an array of disk partitions). device is the special file
>corresponding to the device (e.g /dev/sdXX ). If multiple devices
>are specified, btrfs is created spanning across the specified devices.
>
> i.e. it's a tool to create a filesystem.
>
>> I had mentioned this problem more than a year ago, it still exists.
>
>It's not a problem. Everything is working as expected and as
> designed.
>
>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
> --- You're never alone with a rubber duck... ---
--
To
Re: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: >> But for what purpose offers "mkfs.btrfs" this option? >So that you don't have to run the label command immediately after > making the filesystem. Most mkfs implementations for different > filesystems have something similar, usually with the -L option. But other filesystems don't put the label onto more than 1 device. There's the problem for/with btrfs. The label has to be unique for the whole machine. >> Without this double-labelled (?) devices "blkid" shows all devices >> with >"Double-labelled"? The filesystem has one label, belonging to the > filesystem. I don't see where the "double-labelling" comes in. As I described: mkfs.btrfs -d raid0 -m raid1 -l mylabel /dev/sdb /dev/sdc /dev/sdd labels all three devices with the same name, and then programs like "blkid" or "findfs" don't find any label (for all labelled devices, not only for btrfs devices). And as I have written before: file -s /dev/sdb file -s /dev/sdc file -s /dev/sdd shows for each of these devices the same label. -- When I run mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd and then btrfs filesystem label /dev/sdb mylabel then only "/dev/sdb" shows this label (as long as none of the 3 devices is mounted). When I then run mount LABEL=mylabel /mnt/btr then all works fine. And then (after mounting) blkid /dev/sdb blkid /dev/sdc blkid /dev/sdd show the same label. blkid without any device seems to hang - may be I haven't waited long enough. >> (if defined) their labels. When I define the same label for more >> than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. >> No output for any of the devices. >This is a fault in the version of blkid you're running, then. here: "blkid from until-linux 2.21.2 (libblkid 2.21.0, 25-May-2012)". And older versions. > There's nothing to stop me from labelling two ext2 filesystems with > the same label. That part is right: I can label more than 1 device with the same name, not only under btrfs. But then (I had written this problem) programs like "blkid" don't find any labelled device. > If blkid can't handle that, then it's got problems > beyond btrfs. On my main machine, it seems to work correctly: > $ sudo blkid > /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" > /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" > /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" > /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" > /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs" > /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs" > /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs" Is "media" mounted? >My blkid version: > blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011) It's older than my actual version, but I had found this problem more than a year ago. 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: Option LABEL
On Thu, Jan 3, 2013 at 11:57 AM, Helmut Hullen wrote: > But other filesystems don't put the label onto more than 1 device. > There's the problem for/with btrfs. Other filesystems don't exist on more than one device, so of course they don't put a label on more than one device. -- 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: Option LABEL
Hallo, cwillu, Du meintest am 03.01.13: >> But other filesystems don't put the label onto more than 1 device. >> There's the problem for/with btrfs. > Other filesystems don't exist on more than one device, so of course > they don't put a label on more than one device. Yes, I know. And let me repeat the problem: programs like "blkid" don't work if more than 1 device has the same label. 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: Option LABEL
On Thu, Jan 03, 2013 at 06:57:00PM +0100, Helmut Hullen wrote: > Du meintest am 03.01.13: > >> But for what purpose offers "mkfs.btrfs" this option? > > >So that you don't have to run the label command immediately after > > making the filesystem. Most mkfs implementations for different > > filesystems have something similar, usually with the -L option. > > But other filesystems don't put the label onto more than 1 device. > There's the problem for/with btrfs. Aargh. How many times do I have to say this? Devices are not given labels. *Filesystems* are given labels. > The label has to be unique for the whole machine. Wrong. You can have several filesystems on a machine with the same label. It doesn't mean that they're easily managable, but there's nothing that will stop it from happening. If you want a unique label for a *device*, take a look at the symlinks in /dev/disk/by-id, and the udev rules that generate them. Trying to use filesystem labels to give unique and stable device IDs is the wrong tool for the job. > >> Without this double-labelled (?) devices "blkid" shows all devices > >> with > > >"Double-labelled"? The filesystem has one label, belonging to the > > filesystem. I don't see where the "double-labelling" comes in. > > As I described: > > mkfs.btrfs -d raid0 -m raid1 -l mylabel /dev/sdb /dev/sdc /dev/sdd > > labels all three devices with the same name, and then programs like > "blkid" or "findfs" don't find any label (for all labelled devices, not > only for btrfs devices). > > And as I have written before: > > file -s /dev/sdb > file -s /dev/sdc > file -s /dev/sdd > > shows for each of these devices the same label. As I said above, you're expecting something which just isn't true. Filesystems have labels, not devices. If you want to have unique labels on devices, then you're going to have to write some udev rules to generate them for you, and then refer to /dev/helmuts-devices/foo (or whatever you want to call them). Mucking around with filesystem labels is not going to give you a unique label for a device, because the system simply doesn't work like that. > -- > > When I run > > mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd > > and then > > btrfs filesystem label /dev/sdb mylabel > > then only "/dev/sdb" shows this label (as long as none of the 3 devices > is mounted). This is probably a (minor) bug. You should be getting all of the devices with the same label here (since it's the same filesystem). I suspect that it's down to the label command only updating one superblock when used offline, or possibly some kind of caching thing. Does running btrfs dev scan immediately after the label command make a difference? > When I then run > > mount LABEL=mylabel /mnt/btr > > then all works fine. And then (after mounting) > > blkid /dev/sdb > blkid /dev/sdc > blkid /dev/sdd > > show the same label. This last result is the correct behaviour. All the devices of the filesystem show the filesystem's label. > blkid > > without any device seems to hang - may be I haven't waited long enough. It took a little while for it to run on my machine, but no more than a couple of minutes at the outside. > >> (if defined) their labels. When I define the same label for more > >> than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. > >> No output for any of the devices. > > >This is a fault in the version of blkid you're running, then. > > here: "blkid from until-linux 2.21.2 (libblkid 2.21.0, 25-May-2012)". > And older versions. > > > There's nothing to stop me from labelling two ext2 filesystems with > > the same label. > > That part is right: I can label more than 1 device with the same name, > not only under btrfs. *Filesystem*, not *device*. You label *filesystems*. > But then (I had written this problem) programs like "blkid" don't find > any labelled device. It terminates with no output? Or you get bored of waiting and hit ^C first? If the former, that's a problem with blkid. If the latter... it's probably not a problem. > > If blkid can't handle that, then it's got problems > > beyond btrfs. On my main machine, it seems to work correctly: > > > $ sudo blkid > > /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" > > /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" > > /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" > > /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" > > /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="90469059-f012-4b6e-9233-8c591c
Re: [PATCH] Btrfs: fix a deadlock on chunk mutex
Hi Josef, Thanks for the patch - sorry for the long delay in testing... On 12/18/2012 06:52 AM, Josef Bacik wrote: > On Wed, Dec 12, 2012 at 06:52:37PM -0700, Liu Bo wrote: >> An user reported that he has hit an annoying deadlock while playing with >> ceph based on btrfs. >> >> Current updating device tree requires space from METADATA chunk, >> so we -may- need to do a recursive chunk allocation when adding/updating >> dev extent, that is where the deadlock comes from. >> >> If we use SYSTEM metadata to update device tree, we can avoid the recursive >> stuff. >> > > This is going to cause us to allocate much more system chunks than we used to > which could land us in trouble. Instead let's just keep us from re-entering > if > we're already allocating a chunk. We do the chunk allocation when we don't > have > enough space for a cluster, but we'll likely have plenty of space to make an > allocation. Can you give this patch a try Jim and see if it fixes your > problem? > Thanks, > > Josef > With your patch applied to 3.7.1, I get the following on one of my servers running Ceph OSDs. The end effect is that some of my ceph client writes hang. [ 1440.335752] [ cut here ] [ 1440.340602] WARNING: at fs/btrfs/super.c:246 __btrfs_abort_transaction+0x60/0x110 [btrfs]() [ 1440.349117] Hardware name: X8DTH-i/6/iF/6F [ 1440.353252] Modules linked in: btrfs zlib_deflate ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr ipv6 dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath scsi_dh vhost_net macvtap macvlan tun uinput sg joydev sd_mod iTCO_wdt iTCO_vendor_support hid_generic button ata_piix libata coretemp kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode mpt2sas scsi_transport_sas raid_class scsi_mod serio_raw pcspkr mlx4_ib ib_sa ib_mad ib_core mlx4_en mlx4_core cxgb4 i2c_i801 i2c_core lpc_ich mfd_core ehci_hcd uhci_hcd ioatdma i7core_edac dm_mod edac_core nfsv4 auth_rpcgss nfsv3 nfs_acl nfsv2 nfs lockd sunrpc fscache broadcom tg3 hwmon bnx2 igb dca e1000 [ 1440.419398] Pid: 48686, comm: ceph-osd Not tainted 3.7.1-6-gc794580 #484 [ 1440.426614] Call Trace: [ 1440.429083] [] warn_slowpath_common+0x94/0xc0 [ 1440.435110] [] warn_slowpath_fmt+0x46/0x50 [ 1440.440894] [] __btrfs_abort_transaction+0x60/0x110 [btrfs] [ 1440.448135] [] __btrfs_alloc_chunk+0x6cd/0x750 [btrfs] [ 1440.454941] [] btrfs_alloc_chunk+0x5e/0x90 [btrfs] [ 1440.461382] [] ? check_system_chunk+0x71/0x130 [btrfs] [ 1440.468188] [] do_chunk_alloc+0x2ec/0x370 [btrfs] [ 1440.474562] [] ? btrfs_reduce_alloc_profile+0xa9/0x120 [btrfs] [ 1440.482050] [] btrfs_check_data_free_space+0x13c/0x2b0 [btrfs] [ 1440.489558] [] btrfs_delalloc_reserve_space+0x20/0x60 [btrfs] [ 1440.497013] [] __btrfs_buffered_write+0x15e/0x350 [btrfs] [ 1440.504095] [] btrfs_file_aio_write+0x209/0x320 [btrfs] [ 1440.511000] [] ? __btrfs_direct_write+0x130/0x130 [btrfs] [ 1440.518062] [] do_sync_readv_writev+0x94/0xe0 [ 1440.524105] [] do_readv_writev+0xe3/0x1e0 [ 1440.529792] [] ? fget_light+0x122/0x170 [ 1440.535275] [] vfs_writev+0x46/0x60 [ 1440.540412] [] sys_writev+0x5f/0xc0 [ 1440.545547] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 1440.551987] [] system_call_fastpath+0x16/0x1b [ 1440.558016] ---[ end trace 764e83a458dabca6 ]--- [ 1440.562662] BTRFS warning (device dm-32): __btrfs_alloc_chunk:3488: Aborting unused transaction(error 28). [ 1440.595987] BTRFS warning (device dm-32): find_free_extent:5871: Aborting unused transaction(Object already exists). [ 1440.606542] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1440.614382] IP: [] map_private_extent_buffer+0xe/0xf0 [btrfs] [ 1440.621704] PGD 6138e8067 PUD 56749f067 PMD 0 [ 1440.626190] Oops: [#1] SMP [ 1440.629442] Modules linked in: btrfs zlib_deflate ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ib_addr ipv6 dm_mirror dm_region_hash dm_log dm_round_robin dm_multipath scsi_dh vhost_net macvtap macvlan tun uinput sg joydev sd_mod iTCO_wdt iTCO_vendor_support hid_generic button ata_piix libata coretemp kvm crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul microcode mpt2sas scsi_transport_sas raid_class scsi_mod serio_raw pcspkr mlx4_ib ib_sa ib_mad ib_core mlx4_en mlx4_core cxgb4 i2c_i801 i2c_core lpc_ich mfd_core ehci_hcd uhci_hcd ioatdma i7core_edac dm_mod edac_core nfsv4 auth_rpcgss nfsv3 nfs_acl nfsv2 nfs lockd sunrpc fscache broadcom tg3 hwmon bnx2 igb dca e1000 [ 1440.694855] CPU 16 [ 1440.696784] Pid: 48687, comm: ceph-osd Tainted: GW 3.7.1-6-gc794580 #484 Supermicro X8DTH-i/6/iF/6F/X8DTH [ 1440.707803] RIP: 0010:[] [] map_private_extent_buffer+0xe/0xf0 [btrfs] [ 1440.717544] RSP: 0018:880b740db9f8 EFLAGS: 00010292 [ 1440.722841] RAX: RBX: RCX: 880b740dba28 [ 1440.729947] RDX: 0004 RSI
Re: fsck.btrfs
> > 1. Would btrfsck be the appropriate program to run at bootup? If it > > is, with what parameters? > >No, it's not necessary to run an fs checker on every boot. You can > either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to > /bin/true. For what it's worth, I gather that the XFS guys used to do the latter and that it broke something. Somewhere. I have no idea what. Hence fsck.xfs(8) which has perhaps the greatest description in its man page. - z -- 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: But for what purpose offers "mkfs.btrfs" this option? >>>So that you don't have to run the label command immediately >>>after making the filesystem. >> But other filesystems don't put the label onto more than 1 device. >> There's the problem for/with btrfs. >Aargh. How many times do I have to say this? >Devices are not given labels. >*Filesystems* are given labels. And "mkfs.btrfs" combines working with devices and working with a filesystem. blkid /dev/sdb shows (if set) the label of a device (among other data). >> The label has to be unique for the whole machine. >Wrong. You can have several filesystems on a machine with the same > label. On my machines that doesn't work when I use programs like "blkid" or "findfs". They don't work when there is more than 1 device with the same label. That's no special btrfs problem, that happens with (p.e.) ext4fs too. > It doesn't mean that they're easily managable, but there's > nothing that will stop it from happening. >If you want a unique label for a *device*, take a look at the > symlinks in /dev/disk/by-id, and the udev rules that generate them. Sorry - I don't use "udev" (I've told it long time ago). And I still believe that "btrfs" doesn't depend on "udev". > Trying to use filesystem labels to give unique and stable device IDs > is the wrong tool for the job. I beg to differ. On my machines it's the simpliest way, and it's a sure way. [...] >As I said above, you're expecting something which just isn't true. > Filesystems have labels, not devices. If you want to have unique > labels on devices, then you're going to have to write some udev rules > to generate them for you, and then refer to /dev/helmuts-devices/foo > (or whatever you want to call them). And how is the way for a system which doesn't use "udev"? Labelling via "btrfs filesystem label " works well. 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: Option LABEL
Device can mean more than one thing, physical device, partition, md device, logical volume, etc. Label is more narrowly defined to that of filesystems. MBR has no mechanism for labeling the disk itself or the partitions. So /dev/sda cannot have a label or a name. Whereas with GPT, there is a field for each partition to have a name, completely independent of the file system used. So if you really want physical devices given a name, the closest thing you have to that is GPT. On Jan 3, 2013, at 12:08 PM, hul...@t-online.de (Helmut Hullen) wrote: > Labelling via "btrfs filesystem label " works well. It's a bug. I'm able to reproduce it as well. The command language itself indicates its the fs that's to be labeled. "device" in this case maps a /dev/X device to a fs UUID. It always should apply to the file system. If you want to name your partitions, use GPT. Chris Murphy-- 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: Option LABEL
On Thu, Jan 03, 2013 at 08:08:00PM +0100, Helmut Hullen wrote: > Hallo, Hugo, > > Du meintest am 03.01.13: > > But for what purpose offers "mkfs.btrfs" this option? > > >>>So that you don't have to run the label command immediately > >>>after making the filesystem. > > > >> But other filesystems don't put the label onto more than 1 device. > >> There's the problem for/with btrfs. > > >Aargh. How many times do I have to say this? > > >Devices are not given labels. > >*Filesystems* are given labels. > > And "mkfs.btrfs" combines working with devices and working with a > filesystem. As do all mkfs implementations. They write a filesystem to a device (or devices), and optionally give the filesystem a label. They don't put labels on devices, except incidentally where each filesystem exists on one or more devices. > blkid /dev/sdb > > shows (if set) the label of a device (among other data). No, it shows the label of the filesystem that lives on that device. Other devices may have another part of the same filesystem on them, and will show the same label. I repeat: devices do not have labels. > >> The label has to be unique for the whole machine. > > >Wrong. You can have several filesystems on a machine with the same > > label. > > On my machines that doesn't work when I use programs like "blkid" or > "findfs". They don't work when there is more than 1 device with the same > label. That's no special btrfs problem, that happens with (p.e.) ext4fs > too. OK, and that's a blkid problem, not a btrfs problem. > > It doesn't mean that they're easily managable, but there's > > nothing that will stop it from happening. > > >If you want a unique label for a *device*, take a look at the > > symlinks in /dev/disk/by-id, and the udev rules that generate them. > > Sorry - I don't use "udev" (I've told it long time ago). And I still > believe that "btrfs" doesn't depend on "udev". No, btrfs doesn't depend on udev. However, trying to make a unique device label out of a filesystem label won't work. This isn't a bug, it's not something that was ever guaranteed, it's just the wrong approach. You need to find another one -- see below for the options that I can see. > > Trying to use filesystem labels to give unique and stable device IDs > > is the wrong tool for the job. > > I beg to differ. On my machines it's the simpliest way, and it's a sure > way. No, because *it* *doesn't* *work*. This is not a bug. This is how things have always behaved -- you're relying on an assumption (one FS per device) which simply isn't true any longer. You may think it's simpler, but that's because your assumptions are incorrect. The world does not work the way you think it does. I'm sorry this makes things hard for you, but what you're asking for is not in scope for a filesystem -- any filesystem. > [...] > > > >As I said above, you're expecting something which just isn't true. > > Filesystems have labels, not devices. If you want to have unique > > labels on devices, then you're going to have to write some udev rules > > to generate them for you, and then refer to /dev/helmuts-devices/foo > > (or whatever you want to call them). > > And how is the way for a system which doesn't use "udev"? There isn't one ready-made. Your options are: * run udev * write something which uses (e.g.) SMART information on block devices to extract a unique ID, and convert that into a stable device label (which is effectively what udev does) * find some piece of the device which isn't going to be overwritten by partition tables, GPTs, filesystems, or other kinds of metadata, and write your label into there; again, you will need to develop your own tool for reading/writing this information > Labelling via "btrfs filesystem label " works well. Clearly it doesn't, because you're having problems with it. The behaviour where only one device in the FS gets the label, immediately after a btrfs label command, is a bug -- *all* of the devices in the FS should get the label. You're trying to rely on the behaviour of a bug, not on the designed behaviour of the system. You need to find some other way of doing this. btrfs is working as it should, and I'm afraid you're using the wrong tools for the job you're trying to do. 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 --- O tempura! O moresushi! --- signature.asc Description: Digital signature
Re: Option LABEL
On Jan 3, 2013, at 12:18 PM, Chris Murphy wrote: > > On Jan 3, 2013, at 12:08 PM, hul...@t-online.de (Helmut Hullen) wrote: > >> Labelling via "btrfs filesystem label " works well. > > It's a bug. I'm able to reproduce it as well. The command language itself > indicates its the fs that's to be labeled. "device" in this case maps a > /dev/X device to a fs UUID. It always should apply to the file system. If you > want to name your partitions, use GPT. OK on a Fedora 18 test system with kernel 3.6.11-3 and btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64 I'm getting different results. File system is never mounted for this test. # mkfs.btrfs -L test /dev/sd[bc] # btrfs fi label /dev/sdb test # btrfs fi label /dev/sdc test # btrfs fi label /dev/sdc test2 # btrfs fi label /dev/sdc test2 # btrfs fi label /dev/sdb test2 So 'btrfs fi label' relabeling with an unmounted system changes the file system label metadata on all member devices, according to btrfs fi label. Now when I use file: # file -s /dev/sdb /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize 4096, leafsize 4096) # file -s /dev/sdc /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize 4096, leafsize 4096) Again it correctly reports the label, even though I had only changed the label on sdc (which actually is improper language, I changed the label on the file system implied by device sdc which also extends to device sdb). And then for blkid: # blkid /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs" /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs" So again, the correct filesystem label is returned, for this unmounted file system. Chris Murphy -- 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: fsck.btrfs
On Jan 3, 2013, at 1:08 PM, Zach Brown wrote: >>> 1. Would btrfsck be the appropriate program to run at bootup? If it >>> is, with what parameters? >> >> No, it's not necessary to run an fs checker on every boot. You can >> either turn off the checks in fstab, or symlink /sbin/fsck.btrfs to >> /bin/true. > > For what it's worth, I gather that the XFS guys used to do the latter > and that it broke something. Somewhere. I have no idea what. > Yeah, lost in the mists of time by now. Seems like maybe by now system installers should set up fstab correctly for a journaling ds, but since ext[34] wants boot-time fsck despite journaling, maybe it's best to provide a fsck.$FS even if it's a no-op. > Hence fsck.xfs(8) which has perhaps the greatest description in its man > page. > \o/ -Eric > - z > -- > 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: Option LABEL
Hallo, Chris, Du meintest am 03.01.13: > Device can mean more than one thing, physical device, partition, md > device, logical volume, etc. > Label is more narrowly defined to that of filesystems. > MBR has no mechanism for labeling the disk itself or the partitions. > So /dev/sda cannot have a label or a name. Sure? btrfs filesystem label /dev/sdb mylabel works, and then btrfs filesystem label /dev/sdb shows "mylabel". Also: findfs LABEL=mylabel shows "/dev/sdb" blkid /dev/sdb shows (among other data) "LABEL=mylabel" Except for the "btrfs" command: same behaviour as with other filesystems. Especially with CDs and DVDs (which normally don't use 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: Option LABEL
Hallo, Hugo, Du meintest am 03.01.13: [...] >>> Trying to use filesystem labels to give unique and stable device >>> IDs is the wrong tool for the job. >> I beg to differ. On my machines it's the simpliest way, and it's a >> sure way. >No, because *it* *doesn't* *work*. This is not a bug. This is how > things have always behaved -- you're relying on an assumption (one FS > per device) which simply isn't true any longer. No - I don't rely on such an assumption. In the special case I'm just working with I want to use the whole disk only for btrfs. In other cases I work with partitions, and there is just the same problem: at least "blkid" and "findfs" don't work when more than 1 device has the same label (p.e. /dev/sda3 and /dev/sdc5). >> And how is the way for a system which doesn't use "udev"? >There isn't one ready-made. Your options are: > * run udev > * write something which uses (e.g.) SMART information on block >devices to extract a unique ID, and convert that into a stable >device label (which is effectively what udev does) Sorry - I don't need the "unique ID" for the machines. I can use (p.e.) e2label /dev/sda3 Var for labelling an ext2/3/4 partition. Works like a charm, especially for USB disks. > * find some piece of the device which isn't going to be overwritten >by partition tables, GPTs, filesystems, or other kinds of > metadata,and write your label into there; again, you will need to > developyour own tool for reading/writing this information Sorry - that's not necessary. When I connect the disk then I can search with "findfs" without having mounted any partition. >> Labelling via "btrfs filesystem label " works well. >Clearly it doesn't, because you're having problems with it. No - not at all! I've only problems when I use the "-L" option of "mkfs.btrfs" together with more than 1 device in the "mkfs.btrfs" command. >The > behaviour where only one device in the FS gets the label, immediately > after a btrfs label command, is a bug -- *all* of the devices in the > FS should get the label. You're trying to rely on the behaviour of a > bug, not on the designed behaviour of the system. What works: Building the filesystem with "mkfs.btrfs", without the "-L" option Then (p.e.) btrfs filesystem label (unmounted system) Then I can check the existence (not only for btrfs formatted disks) with findfs LABEL= && mount LABEL= As mentioned: works not only with btrfs, works fine especially for USB disks. I don't need any UUID etc. for this way of identyfying. I don't need to change the mount directive when I change a smaller disk to a bigger disk. 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: Option LABEL
Hallo, Chris,
Du meintest am 03.01.13:
> So 'btrfs fi label' relabeling with an unmounted system changes the
> file system label metadata on all member devices, according to btrfs
> fi label. Now when I use file:
On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd)
btrfs fi label /dev/sdb mylabel
only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and
"/dev/sdd" remain without label.
> # file -s /dev/sdb
> /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize
> 4096, leafsize 4096)
> # file -s /dev/sdc
> /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize
> 4096, leafsize 4096)
> Again it correctly reports the label, even though I had only changed
> the label on sdc (which actually is improper language, I changed the
> label on the file system implied by device sdc which also extends to
> device sdb).
Strange.
Actually the btrfs system is mounted and has to run a job with needs
about 5 days - I may not stop it.
But before the first mounting of the system only "/dev/sdb" showed the
label. Maybe with the first mounting the label spreads over all disks.
>
> And then for blkid:
> # blkid
> /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717"
> UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs"
> /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717"
> UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs"
Strange - in another way.
Here "blkid" (without any device) hangs. See the attachment ("strace
blkid").
Viele Gruesse!
Helmut
execve("/sbin/blkid", ["blkid"], [/* 47 vars */]) = 0
brk(0) = 0x805
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40024000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=55572, ...}) = 0
mmap2(NULL, 55572, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
close(3)= 0
open("/lib/libblkid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0A\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=163440, ...}) = 0
mmap2(NULL, 162160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x40033000
mmap2(0x40059000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26) = 0x40059000
close(3)= 0
open("/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\16\0\0004\0\0\0"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=13244, ...}) = 0
mmap2(NULL, 16004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x4005b000
mmap2(0x4005e000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x4005e000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\227\1\0004\0\0\0"..., 512) =
512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1790836, ...}) = 0
mmap2(NULL, 1591836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x4005f000
mprotect(0x401dd000, 4096, PROT_NONE) = 0
mmap2(0x401de000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17e) = 0x401de000
mmap2(0x401e1000, 10780, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401e1000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401e4000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401e5000
set_thread_area({entry_number:-1 -> 6, base_addr:0x401e4bc0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
mprotect(0x401de000, 8192, PROT_READ) = 0
mprotect(0x40021000, 4096, PROT_READ) = 0
munmap(0x40025000, 55572) = 0
brk(0) = 0x805
brk(0x8071000) = 0x8071000
getuid32() = 0
geteuid32() = 0
getgid32() = 0
getegid32() = 0
prctl(PR_GET_DUMPABLE) = 1
getuid32() = 0
geteuid32() = 0
getgid32() = 0
getegid32() = 0
prctl(PR_GET_DUMPABLE) = 1
open("/etc/blkid.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("/run/blkid/blkid.tab", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
fcntl64(3, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40025000
_llseek(3, 0, [0],
Re: Option LABEL
On Jan 3, 2013, at 12:59 PM, Helmut Hullen wrote: >> MBR has no mechanism for labeling the disk itself or the partitions. >> So /dev/sda cannot have a label or a name. > > > Sure? Yes. MBR itself has no place holder to encode a disk name or partition name. http://en.wikipedia.org/wiki/Master_boot_record GPT does allow for partition names, offset 56. http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries > btrfs filesystem label /dev/sdb mylabel That is a file system label. Hence the command "filesystem label". > On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) > >btrfs fi label /dev/sdb mylabel > > only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and > "/dev/sdd" remain without label. If I create a two device btrfs file system without a label, and then relabel it, all device members are relabeled - but again this is the wrong language. The devices do not have labels, it's the file system that has the label. > for labelling an ext2/3/4 partition. Works like a charm, especially for > USB disks. Again, even with ext[234] you are not labeling a partition. You are labeling a file system. In fact if I use LVM to place /dev/sda /dev/sdb /dev/sdc into a VG, then export that whole VG as one LV, then format it ext4 with label "hellokitty" again that file system is labeled "hellokitty" which spans three devices. The devices are not what's named. Same for md and dmraid devices. Somehow in your mind you're OK abstracting the LV as a kind of "device" but you're unwilling to consider a Btrfs file system a kind of "device" also. In the case of ext4 on LVM, you're totally OK ignoring the fact that /dev/sda, /dev/sdb, /dev/sdc all have the same label in effect. But somehow it gets your goat when Btrfs is doing the same thing. Because it's the *filesystem* that's labelled. Chris Murphy-- 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: Option LABEL
On Thu, Jan 03, 2013 at 09:28:00PM +0100, Helmut Hullen wrote:
> Hallo, Chris,
>
> Du meintest am 03.01.13:
>
> > So 'btrfs fi label' relabeling with an unmounted system changes the
> > file system label metadata on all member devices, according to btrfs
> > fi label. Now when I use file:
>
> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd)
>
> btrfs fi label /dev/sdb mylabel
>
> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and
> "/dev/sdd" remain without label.
This is a bug.
> > # file -s /dev/sdb
> > /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize
> > 4096, leafsize 4096)
> > # file -s /dev/sdc
> > /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize
> > 4096, leafsize 4096)
>
> > Again it correctly reports the label, even though I had only changed
> > the label on sdc (which actually is improper language, I changed the
> > label on the file system implied by device sdc which also extends to
> > device sdb).
>
> Strange.
> Actually the btrfs system is mounted and has to run a job with needs
> about 5 days - I may not stop it.
>
> But before the first mounting of the system only "/dev/sdb" showed the
> label. Maybe with the first mounting the label spreads over all disks.
Probably.
> > And then for blkid:
>
> > # blkid
> > /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717"
> > UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs"
> > /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717"
> > UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs"
>
> Strange - in another way.
>
> Here "blkid" (without any device) hangs. See the attachment ("strace
> blkid").
[snip]
> stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
> open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4
> fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0
> fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
> uname({sys="Linux", node="izar", ...}) = 0
> ioctl(4, BLKGETSIZE64, 0x8050d5c) = 0
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4, 0x80517a4, 1024)= -1 EIO (Input/output error)
> _llseek(4, 0, [0], SEEK_SET)= 0
> read(4,
This is waiting for /dev/fd0 to return some data. I guess it'll
give up after a few times round (8? 10?) and return some results.
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
--- Putting U back in Honor, Valor, and Trth ---
signature.asc
Description: Digital signature
Re: Option LABEL
On Jan 3, 2013, at 2:23 PM, Hugo Mills wrote: > On Thu, Jan 03, 2013 at 09:28:00PM +0100, Helmut Hullen wrote: >> >> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >> >>btrfs fi label /dev/sdb mylabel >> >> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and >> "/dev/sdd" remain without label. > > This is a bug. It's a bug that appears to be fixed. I inadvertently tested it first on CentOS 6.0 which has quite an older kernel and btrfsprogs. And Fedora 18 of course has a much newer kernel and btrfs-progs so I have no idea when in between those two this was fixed. Helmut what kernel and btrfs-progs or distribution are you using? I think newer progs fixes this. >> >> But before the first mounting of the system only "/dev/sdb" showed the >> label. Maybe with the first mounting the label spreads over all disks. > > Probably. Not in my case with F18. I never mounted it once and immediately all commands saw the file system label change. Chris Murphy -- 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: Option LABEL
Hallo, Chris, Du meintest am 03.01.13: >>> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >>> >>>btrfs fi label /dev/sdb mylabel >>> >>> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" >>> and "/dev/sdd" remain without label. >> This is a bug. > It's a bug that appears to be fixed. I inadvertently tested it first > on CentOS 6.0 which has quite an older kernel and btrfsprogs. And > Fedora 18 of course has a much newer kernel and btrfs-progs so I have > no idea when in between those two this was fixed. > Helmut what kernel and btrfs-progs or distribution are you using? I > think newer progs fixes this. Kernel 3.4.6 (self made), btrfs-progs downloaded and compiled 2 days ago (Mason version, not Mills version). I've just brewed Kernel 3.6.11 but I have to wait some days (backing up some Tbytes of data) before I can test btrfs with this newer kernel. But looking for btrfs in the ChangeLog files for kernels 3.4 to 3.6 doesn't show any entry which might be related to the above error. (Kernels 3.4.3, 3.4.5, 3.4.8, 3.5.1, 3.5.4) 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: Option LABEL
Hallo, Hugo,
Du meintest am 03.01.13:
>> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd)
>>
>> btrfs fi label /dev/sdb mylabel
>>
>> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc"
>> and "/dev/sdd" remain without label.
>This is a bug.
Hmmm - I'll test it on another system.
>> Strange - in another way.
>>
>> Here "blkid" (without any device) hangs. See the attachment ("strace
>> blkid").
> [snip]
>> stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0),
>> ...}) = 0 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4
>> fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0
>> fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
>> uname({sys="Linux", node="izar", ...}) = 0
>> ioctl(4, BLKGETSIZE64, 0x8050d5c) = 0
>> _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4, 0x80517a4, 1024)= -1 EIO (Input/output
>> error) _llseek(4, 0, [0], SEEK_SET)= 0
>> read(4,
>This is waiting for /dev/fd0 to return some data. I guess it'll
> give up after a few times round (8? 10?) and return some results.
I've waited 10 minutes ...
I know a similar behaviour p.e. when I run
btrfs-show
Then btrfs seems to test all block devices in "/dev" (no "udev" system)
and then tells most times
failed to read /dev/: No such device or address
But those (unnecessary) messages come quick, with only some seconds
delay.
-
The above log file comes from a machine without floppy disk (a laptop).
Running "blkid" on an elder tower (with installed and usable floppy
disk) also checks for "/dev/fd0" and then tells "ok".
Tomorrow I'll test this behaviour on another laptop. Could be a "blkid"
error.
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
