qgroup code slowing down rebalance
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
During this rebalance, the disks were pretty lightly used. I would see a small burst of tens of MB/s, then it would go back to no activity for a few minutes, small burst, no activity, etc... During the quiet times (for the disk) one processor would be pegged inside the kernel and would have virtually no I/O wait time. Also during this time, the filesystem was pretty unbearably slow. An ls of a small directory would hang for minutes.
A perf profile shows 92% of the cpu time is being spend in btrfs_find_all_roots(), called under this call path:
btrfs_commit_transaction -> btrfs_qgroup_prepare_account_extents -> btrfs_find_all_roots
So I tried disabling quotas by doing:
btrfs quota disable /mnt/foo
which took a few minutes to complete, but once it did, the disks went back up to doing ~200MB/s, the kernel time went down to ~20%, and the system now has lots of I/O wait time. It looks to be behaving nicely.
Is this expected? From my perspective, it makes quotas pretty much unusable at least during a rebalance. I have a full 'perf record' profile with call graphs if it would be helpful.
Dave Hansen wrote on 2016/03/16 13:53 -0700:
Quoted 24 lines
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
During this rebalance, the disks were pretty lightly used. I would see a small burst of tens of MB/s, then it would go back to no activity for a few minutes, small burst, no activity, etc... During the quiet times (for the disk) one processor would be pegged inside the kernel and would have virtually no I/O wait time. Also during this time, the filesystem was pretty unbearably slow. An ls of a small directory would hang for minutes.
A perf profile shows 92% of the cpu time is being spend in
btrfs_find_all_roots(), called under this call path:btrfs_commit_transaction -> btrfs_qgroup_prepare_account_extents -> btrfs_find_all_rootsSo I tried disabling quotas by doing:
btrfs quota disable
/mnt/foo
Quoted 9 lines
which took a few minutes to complete, but once it did, the disks went back up to doing ~200MB/s, the kernel time went down to ~20%, and the system now has lots of I/O wait time. It looks to be behaving nicely.
Is this expected? From my perspective, it makes quotas pretty much unusable at least during a rebalance. I have a full 'perf record' profile with call graphs if it would be helpful.
Thanks for the report.
Again balance, the devil is again(always) in the balance.
To be honest, balance itself is already complicated enough, and not a friendly neighborhood for a lot of function. (Yeah, a lot of dedupe bugs are and can only be triggered by balance, and I can't hate it any more)
Perf record profile will help a lot.
Please upload it if it's OK for you.
Also, the following data would help a lot:
1) btrfs fi df output
To determine the metadata/data ratio
Balancing metadata should be quite slow.
2) btrfs subvolume list output
To determine how many tree blocks are shared against each other More shared tree blocks, slower quota routing is.
Feel free to mask the output to avoid information leaking.
3) perf record for balancing metadata and data respectively Although this is optional. Just to prove some assumption.
btrfs_find_all_roots() is quite a slow operation, and in its worst case (tree blocks are shared by a lot of trees) it may be near O(2^n).
For normal operation, it's pretty hard to trigger so many extents creation/deletion/reference.
Even such case happens, it will cause much much much more IO, making the most time waiting IO other than doing quota accounting.
But for balance, especially for metadata balancing, IO is small but amount of extents is very high, making most the time consumed by find_all_roots().
I can try to make balance to bypass quota routine, but I'm not sure if such operation will open another hole to make quota crazy again, and only much much much more tests can prove it. :(
Thanks,
Qu
Quoted 5 lines · Qu Wenruo
Dave Hansen wrote on 2016/03/16 13:53 -0700:
Quoted 4 lines
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
...
Quoted 2 lines
Perf record profile will help a lot.
Please upload it if it's OK for you.
I'll send it privately.
But, I do see basically the same behavior when balancing data and metadata. I profiled both.
Quoted 4 lines
Also, the following data would help a lot:
1) btrfs fi df output
To determine the metadata/data ratio
Balancing metadata should be quite slow.
Data, RAID1: total=4.53TiB, used=4.53TiB System, RAID1: total=32.00MiB, used=720.00KiB Metadata, RAID1: total=17.00GiB, used=15.77GiB GlobalReserve, single: total=512.00MiB, used=0.00B
Quoted 5 lines
2) btrfs subvolume list output
To determine how many tree blocks are shared against each other More shared tree blocks, slower quota routing is.Feel free to mask the output to avoid information leaking.
Here you go (pasted at the end). You can pretty clearly see that I'm using this volume for incremental backups. My plan was to keep the old snapshots around until the filesystem fills up.
Quoted 5 lines
3) perf record for balancing metadata and data respectively Although this is optional. Just to prove some assumption.
btrfs_find_all_roots()is quite a slow operation, and in its worst case (tree blocks are shared by a lot of trees) it may be near O(2^n).
Yikes! But, that does look to be consistent with what I'm seeing.
Quoted 59 lines
Quoted 59 lines
ID 15183 gen 207620 top level 5 path blackbird_backups.enc
ID 15547 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779116 ID 15548 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779185 ID 15559 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814382 ID 15560 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814540 ID 15561 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814739 ID 15562 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814783 ID 15563 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815180 ID 15564 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815259 ID 15565 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815314 ID 15566 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815948 ID 15567 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816104 ID 15568 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816127 ID 15569 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816213 ID 15570 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816305 ID 15571 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816591 ID 15572 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816622 ID 15573 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816632 ID 15574 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816638 ID 15575 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816837 ID 15576 gen 207620 top level 5 path home-backup-on-btrfs.enc
ID 16634 gen 207620 top level 5 path homes-backup-nimitz-o2.enc
ID 17389 gen 207620 top level 5 path snapshots/root/1456271568
ID 17390 gen 207620 top level 5 path snapshots/root/1456272221
ID 17391 gen 207620 top level 5 path snapshots/root/1456416369
ID 17392 gen 207620 top level 5 path snapshots/root/1456435609
ID 17393 gen 207620 top level 5 path snapshots/root/1456539873
ID 17394 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456553298 ID 17395 gen 207620 top level 5 path snapshots/root/1456553448
ID 17396 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553460 ID 17397 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553461 ID 17398 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602362 ID 17399 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602405 ID 17400 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456602405 ID 17401 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456628682 ID 17402 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456628682 ID 17403 gen 207620 top level 5 path snapshots/root/1456628682
ID 17404 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456675846 ID 17405 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456675846 ID 17406 gen 207620 top level 5 path snapshots/root/1456675846
ID 17407 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456713915 ID 17408 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456720748 ID 17409 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722793 ID 17410 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722812 ID 17411 gen 207620 top level 5 path snapshots/root/1456722812
ID 17412 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456722812 ID 17413 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456731271 ID 17414 gen 207620 top level 5 path snapshots/root/1456731271
ID 17415 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456731271 ID 17416 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456838946 ID 17417 gen 207620 top level 5 path snapshots/root/1456838946
ID 17418 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456838946 ID 17419 gen 207620 top level 5 path snapshots/root/1457127404
ID 17420 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457127404 ID 17421 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1457127404 ID 17422 gen 207620 top level 5 path snapshots/root/1457138948
ID 17423 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457138948 ID 17425 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457451483 ID 17426 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457808380
Dave Hansen wrote on 2016/03/17 09:36 -0700:
Quoted 20 lines · Qu Wenruo
Quoted 5 lines
Dave Hansen wrote on 2016/03/16 13:53 -0700:
Quoted 4 lines
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
...
Quoted 2 lines
Perf record profile will help a lot.
Please upload it if it's OK for you.I'll send it privately.
But, I do see basically the same behavior when balancing data and metadata. I profiled both.
Quoted 4 lines
Also, the following data would help a lot:
1) btrfs fi df output
To determine the metadata/data ratio
Balancing metadata should be quite slow.
Quoted 4 lines
Data, RAID1: total=4.53TiB, used=4.53TiB System, RAID1: total=32.00MiB, used=720.00KiB Metadata, RAID1: total=17.00GiB, used=15.77GiB GlobalReserve, single: total=512.00MiB, used=0.00B
Considering the size and the amount of metadata, even doing a quota rescan will be quite slowing.
Would you please try to do a quota rescan and see the CPU/IO usage?
Quoted 11 lines
Quoted 7 lines
2) btrfs subvolume list output
To determine how many tree blocks are shared against each other More shared tree blocks, slower quota routing is.Feel free to mask the output to avoid information leaking.
Here you go (pasted at the end). You can pretty clearly see that I'm using this volume for incremental backups. My plan was to keep the old snapshots around until the filesystem fills up.
Oh, find_all_roots() nightmare, just as mentioned, it will slow quota rescan too.
Quoted 8 lines
Quoted 6 lines
3) perf record for balancing metadata and data respectively Although this is optional. Just to prove some assumption.
btrfs_find_all_roots()is quite a slow operation, and in its worst case (tree blocks are shared by a lot of trees) it may be near O(2^n).Yikes! But, that does look to be consistent with what I'm seeing.
So, you mean time consumed by find_all_roots() is consistent? Then it must be quite slow for almost all tree blocks...
Anyway, I'd better try to allow balance to by-pass quota accounting.
Thanks,
Qu
Quoted 65 lines
Quoted 60 lines
Quoted 60 lines
ID 15183 gen 207620 top level 5 path blackbird_backups.enc
ID 15547 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779116 ID 15548 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455779185 ID 15559 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814382 ID 15560 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814540 ID 15561 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814739 ID 15562 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455814783 ID 15563 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815180 ID 15564 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815259 ID 15565 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815314 ID 15566 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455815948 ID 15567 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816104 ID 15568 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816127 ID 15569 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816213 ID 15570 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816305 ID 15571 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816591 ID 15572 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816622 ID 15573 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816632 ID 15574 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816638 ID 15575 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1455816837 ID 15576 gen 207620 top level 5 path home-backup-on-btrfs.enc
ID 16634 gen 207620 top level 5 path homes-backup-nimitz-o2.enc
ID 17389 gen 207620 top level 5 path snapshots/root/1456271568
ID 17390 gen 207620 top level 5 path snapshots/root/1456272221
ID 17391 gen 207620 top level 5 path snapshots/root/1456416369
ID 17392 gen 207620 top level 5 path snapshots/root/1456435609
ID 17393 gen 207620 top level 5 path snapshots/root/1456539873
ID 17394 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456553298 ID 17395 gen 207620 top level 5 path snapshots/root/1456553448
ID 17396 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553460 ID 17397 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456553461 ID 17398 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602362 ID 17399 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456602405 ID 17400 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456602405 ID 17401 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456628682 ID 17402 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456628682 ID 17403 gen 207620 top level 5 path snapshots/root/1456628682
ID 17404 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456675846 ID 17405 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456675846 ID 17406 gen 207620 top level 5 path snapshots/root/1456675846
ID 17407 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456713915 ID 17408 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456720748 ID 17409 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722793 ID 17410 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456722812 ID 17411 gen 207620 top level 5 path snapshots/root/1456722812
ID 17412 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456722812 ID 17413 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456731271 ID 17414 gen 207620 top level 5 path snapshots/root/1456731271
ID 17415 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456731271 ID 17416 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1456838946 ID 17417 gen 207620 top level 5 path snapshots/root/1456838946
ID 17418 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1456838946 ID 17419 gen 207620 top level 5 path snapshots/root/1457127404
ID 17420 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457127404 ID 17421 gen 207620 top level 5 path snapshots/home-backup-on-btrfs.enc/1457127404 ID 17422 gen 207620 top level 5 path snapshots/root/1457138948
ID 17423 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457138948 ID 17425 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457451483 ID 17426 gen 207620 top level 5 path snapshots/blackbird_backups.enc/1457808380
Quoted 13 lines · Qu Wenruo
Dave Hansen wrote on 2016/03/17 09:36 -0700:
Quoted 11 lines · Qu Wenruo
Quoted 5 lines
Dave Hansen wrote on 2016/03/16 13:53 -0700:
Quoted 4 lines
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
...
Data, RAID1: total=4.53TiB, used=4.53TiB System, RAID1: total=32.00MiB, used=720.00KiB Metadata, RAID1: total=17.00GiB, used=15.77GiB GlobalReserve, single: total=512.00MiB, used=0.00B
Quoted 4 lines
Considering the size and the amount of metadata, even doing a quota rescan will be quite slowing.
Would you please try to do a quota rescan and see the CPU/IO usage?
I did a quota rescan. It uses about 80% of one CPU core, but also has some I/O wait time and pulls 1-20MB/s of data off the disk (the balance with quotas on was completely CPU-bound, and had very low I/O rates).
It would seem that the "quota rescan" *does* have the same issue as the balance with quotas on, but to a much smaller extent than what I saw with the "balance" operation.
I have a full profile recorded from the "quota rescan", but the most relevant parts are pasted below. Basically btrfs_search_slot() and radix tree lookups are eating all the CPU time, but they're still doing enough I/O to see _some_ idle time on the processor.
Quoted 44 lines
74.55% 3.10% kworker/u8:0 [btrfs] [k] find_parent_nodes
|
---find_parent_nodes
|
|--99.95%-- __btrfs_find_all_roots
| btrfs_find_all_roots
| btrfs_qgroup_rescan_worker
| normal_work_helper
| btrfs_qgroup_rescan_helper
| process_one_work
| worker_thread
| kthread
| ret_from_fork
--0.05%-- [...]
32.14% 4.16% kworker/u8:0 [btrfs] [k] btrfs_search_slot
|
---btrfs_search_slot
|
|--87.90%-- find_parent_nodes
| __btrfs_find_all_roots
| btrfs_find_all_roots
| btrfs_qgroup_rescan_worker
| normal_work_helper
| btrfs_qgroup_rescan_helper
| process_one_work
| worker_thread
| kthread
| ret_from_fork
|
|--11.70%-- btrfs_search_old_slot
| __resolve_indirect_refs
| find_parent_nodes
| __btrfs_find_all_roots
| btrfs_find_all_roots
| btrfs_qgroup_rescan_worker
| normal_work_helper
| btrfs_qgroup_rescan_helper
| process_one_work
| worker_thread
| kthread
| ret_from_fork
--0.39%-- [...]Dave Hansen wrote on 2016/03/18 09:33 -0700:
Quoted 19 lines · Qu Wenruo
Quoted 13 lines
Dave Hansen wrote on 2016/03/17 09:36 -0700:
Quoted 11 lines · Qu Wenruo
Quoted 5 lines
Dave Hansen wrote on 2016/03/16 13:53 -0700:
Quoted 4 lines
I have a medium-sized multi-device btrfs filesystem (4 disks, 16TB total) running under 4.5.0-rc5. I recently added a disk and needed to rebalance. I started a rebalance operation three days ago. It was on the order of 20% done after those three days. :)
...
Data, RAID1: total=4.53TiB, used=4.53TiB System, RAID1: total=32.00MiB, used=720.00KiB Metadata, RAID1: total=17.00GiB, used=15.77GiB GlobalReserve, single: total=512.00MiB, used=0.00BQuoted 4 lines
Considering the size and the amount of metadata, even doing a quota rescan will be quite slowing.
Would you please try to do a quota rescan and see the CPU/IO usage?
Quoted 7 lines
I did a quota rescan. It uses about 80% of one CPU core, but also has some I/O wait time and pulls 1-20MB/s of data off the disk (the balance with quotas on was completely CPU-bound, and had very low I/O rates).
It would seem that the "quota rescan" *does* have the same issue as the balance with quotas on, but to a much smaller extent than what I saw with the "balance" operation.
This is quite expected. Most CPU would be consumed by find_all_roots(), as your subvolume layout is the just the worst case for find_all_roots().
That's to say, remove unneeded snapshots and keep them under a limited amount would be the best case.
Btrfs snapshot is superfast to create, but the design implies a lot of overhead for some minor operation, especially for backref lookup. And unfortunately, quota relies heavily on it.
The only difference that I doesn't expect is IO. As I expected rescan would be much the same with balance, with little IO. Did you run rescan/balance after dropping all the caches?
Although for balance, I would add some patch to make them by-pass quota accounting as them seems to be OK. But for rescan case, AFAIK that's the case.
BTW although it's quite risky, I hope you can run some old kernels and see the performance difference of rescan and balance. For old kernels, I mean 4.1 which is the latest kernel that doesn't use the new quota framework.
I'm very interesting to see if the old but wrong code would have a better or worse performance on balance or rescan.
Thank you very much for all this quota related reports. Qu
Quoted 59 lines
I have a full profile recorded from the "quota rescan", but the most relevant parts are pasted below. Basically
btrfs_search_slot()and radix tree lookups are eating all the CPU time, but they're still doing enough I/O to see _some_ idle time on the processor.Quoted 35 lines
74.55% 3.10% kworker/u8:0 [btrfs] [k] find_parent_nodes | ---find_parent_nodes | |--99.95%-- __btrfs_find_all_roots | btrfs_find_all_roots | btrfs_qgroup_rescan_worker | normal_work_helper | btrfs_qgroup_rescan_helper | process_one_work | worker_thread | kthread | ret_from_fork --0.05%-- [...] 32.14% 4.16% kworker/u8:0 [btrfs] [k] btrfs_search_slot | ---btrfs_search_slot | |--87.90%-- find_parent_nodes | __btrfs_find_all_roots | btrfs_find_all_roots | btrfs_qgroup_rescan_worker | normal_work_helper | btrfs_qgroup_rescan_helper | process_one_work | worker_thread | kthread | ret_from_fork | |--11.70%-- btrfs_search_old_slot | __resolve_indirect_refs | find_parent_nodes | __btrfs_find_all_roots | btrfs_find_all_rootsQuoted 9 lines
| btrfs_qgroup_rescan_worker | normal_work_helper | btrfs_qgroup_rescan_helper | process_one_work | worker_thread | kthread | ret_from_fork --0.39%-- [...]--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html