Re: misc/021-image-multi-devices fails on latest btrfs-devel/misc-next

[Lakshmipathi.G]

Hi Qu,

I'm using btrfs-progs devel branch. mount command is failing with misc/021.
When I tried to manually mount it. dmesg shows  "unrecognized super
flag: 17179869184"
and interestingly "df -h" shows 16E as available!

https://asciinema.org/a/4JGYg7YGQz1PHtdBRJ6AVw0fh

Let me check further.

Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org


On Fri, Nov 24, 2017 at 9:55 AM, Lakshmipathi.G
 wrote:
> Hi Qu,
>
> I'm using the same instance. Let me check again with and without the
> commits list on Nov-23
> (https://github.com/kdave/btrfs-devel/commits/misc-next) and get back
> with results.
>
> 
> Cheers,
> Lakshmipathi.G
> http://www.giis.co.in http://www.webminal.org
--
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/3] btrfs: Introduce macros to handle bytes and sector conversion

[Qu Wenruo]

On 2017年11月24日 14:53, Nikolay Borisov wrote:
> 
> 
> On 24.11.2017 06:10, Qu Wenruo wrote:
>> Since block I/O is always done in unit of 512 bytes, add BI_SECTOR_SIZE
>> and BI_SECTOR_SHIFT macros and to_sector() and to_bytes() for later
>> use.
>>
>> Although the best position to define such things should be bvec.h, and
>> to_sector() to_bytes() are also defined in device-mapper.h, there are
>> a lot of code defining their own SECTOR_SIZE and to_bytes() in
>> device-mapper is not using u64 (unsigned long long) but unsigned long,
>> which doesn't fit btrfs usage.
>>
>> So define btrfs' own macros and inlined converters.
>>
>> Signed-off-by: Qu Wenruo 
>> ---
>>  fs/btrfs/ctree.h | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>> index 8fc690384c58..8f6f57167661 100644
>> --- a/fs/btrfs/ctree.h
>> +++ b/fs/btrfs/ctree.h
>> @@ -3734,4 +3734,17 @@ static inline int btrfs_is_testing(struct 
>> btrfs_fs_info *fs_info)
>>  #endif
>>  return 0;
>>  }
>> +
>> +#define BI_SECTOR_SHIFT (9)
>> +#define BI_SECTOR_SIZE  (1 << BI_SECTOR_SHIFT)
>> +
>> +static inline u64 to_bytes(sector_t n)
>> +{
>> +return ((u64)n << BI_SECTOR_SHIFT);
>> +}
>> +
>> +static inline sector_t to_sector(u64 n)
>> +{
>> +return (n >> BI_SECTOR_SHIFT);
>> +}
> 
> nit: I don't like the naming, I'd rather have something similar to what
> xfs has for its conversion macros i.e:
> 
> XFS_FSS_TO_BB - filesystem sector to basic block (bb in this case is 512
> bytes)

The problem is, without your explanation, I don't even know this macro
is used to convert sectors to bytes.

> 
> so why not - BTRFS_B_TO_BB or BTRFS_B_TO_S and BTRFS_S_TO_B. Or
> something like that but just to_bytes and to_sector look a bit silly.
> It's not a big paint point but more of a "let's get the good ideas from
> other fsses"

Yep, better ideas are always welcomed.

BTW, the to_bytes() and to_sector() from device-mapper.h is the easier
to understand one I can found in variant headers.
(I don't even need to add any comment, unlike the initials from XFS)

Thanks,
Qu

> 
>>  #endif
>>
> --
> 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
> 



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/3] btrfs: Introduce macros to handle bytes and sector conversion

[Nikolay Borisov]

On 24.11.2017 06:10, Qu Wenruo wrote:
> Since block I/O is always done in unit of 512 bytes, add BI_SECTOR_SIZE
> and BI_SECTOR_SHIFT macros and to_sector() and to_bytes() for later
> use.
> 
> Although the best position to define such things should be bvec.h, and
> to_sector() to_bytes() are also defined in device-mapper.h, there are
> a lot of code defining their own SECTOR_SIZE and to_bytes() in
> device-mapper is not using u64 (unsigned long long) but unsigned long,
> which doesn't fit btrfs usage.
> 
> So define btrfs' own macros and inlined converters.
> 
> Signed-off-by: Qu Wenruo 
> ---
>  fs/btrfs/ctree.h | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
> index 8fc690384c58..8f6f57167661 100644
> --- a/fs/btrfs/ctree.h
> +++ b/fs/btrfs/ctree.h
> @@ -3734,4 +3734,17 @@ static inline int btrfs_is_testing(struct 
> btrfs_fs_info *fs_info)
>  #endif
>   return 0;
>  }
> +
> +#define BI_SECTOR_SHIFT  (9)
> +#define BI_SECTOR_SIZE   (1 << BI_SECTOR_SHIFT)
> +
> +static inline u64 to_bytes(sector_t n)
> +{
> + return ((u64)n << BI_SECTOR_SHIFT);
> +}
> +
> +static inline sector_t to_sector(u64 n)
> +{
> + return (n >> BI_SECTOR_SHIFT);
> +}

nit: I don't like the naming, I'd rather have something similar to what
xfs has for its conversion macros i.e:

XFS_FSS_TO_BB - filesystem sector to basic block (bb in this case is 512
bytes)

so why not - BTRFS_B_TO_BB or BTRFS_B_TO_S and BTRFS_S_TO_B. Or
something like that but just to_bytes and to_sector look a bit silly.
It's not a big paint point but more of a "let's get the good ideas from
other fsses"

>  #endif
> 
--
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

[PATCH] btrfs-progs: mkfs: fix verbose value

[Misono, Tomohiro]

The value of 'verbose' is either 1 (default) or 0 (-q)
and "verbose >= 2" will not be true.

After fix this, we get something like:
 adding device /dev/sde id 2
 adding device /dev/sdf id 3
during mkfs time when multiple devices are used.

Signed-off-by: Tomohiro Misono 
---
 mkfs/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mkfs/main.c b/mkfs/main.c
index e405e5a2..c07cc1e1 100644
--- a/mkfs/main.c
+++ b/mkfs/main.c
@@ -1861,7 +1861,7 @@ int main(int argc, char **argv)
error("unable to add %s to filesystem: %d", file, ret);
goto out;
}
-   if (verbose >= 2) {
+   if (verbose) {
struct btrfs_device *device;
 
device = container_of(fs_info->fs_devices->devices.next,
-- 
2.13.6

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

[PATCH] btrfs-progs: mkfs: check the status of file at mkfs

[Misono, Tomohiro]

Currently, only the status of block devices is checked at mkfs,
but we should also check for regular files whether they are already
formatted or mounted to prevent overwrite accidentally.

Device status is checked by test_dev_for_mkfs().
The part which is not related to block device is split from this
and used for both block device and regular file.

Signed-off-by: Tomohiro Misono 
---
 mkfs/common.c | 46 ++
 mkfs/common.h |  1 +
 mkfs/main.c   |  8 ++--
 3 files changed, 37 insertions(+), 18 deletions(-)

diff --git a/mkfs/common.c b/mkfs/common.c
index 71318b10..5bf56828 100644
--- a/mkfs/common.c
+++ b/mkfs/common.c
@@ -632,23 +632,9 @@ int test_dev_for_mkfs(const char *file, int 
force_overwrite)
error("%s is a swap device", file);
return 1;
}
-   if (!force_overwrite) {
-   if (check_overwrite(file)) {
-   error("use the -f option to force overwrite of %s",
-   file);
-   return 1;
-   }
-   }
-   ret = check_mounted(file);
-   if (ret < 0) {
-   error("cannot check mount status of %s: %s", file,
-   strerror(-ret));
+   ret = test_status_for_mkfs(file, force_overwrite);
+   if (ret)
return 1;
-   }
-   if (ret == 1) {
-   error("%s is mounted", file);
-   return 1;
-   }
/* check if the device is busy */
fd = open(file, O_RDWR|O_EXCL);
if (fd < 0) {
@@ -669,6 +655,34 @@ int test_dev_for_mkfs(const char *file, int 
force_overwrite)
return 0;
 }
 
+/*
+ * check if the file (device) is formatted or mounted
+ */
+int test_status_for_mkfs(const char *file, int force_overwrite)
+{
+   int ret;
+
+   if (!force_overwrite) {
+   if (check_overwrite(file)) {
+   error("use the -f option to force overwrite of %s",
+   file);
+   return 1;
+   }
+   }
+   ret = check_mounted(file);
+   if (ret < 0) {
+   error("cannot check mount status of %s: %s", file,
+   strerror(-ret));
+   return 1;
+   }
+   if (ret == 1) {
+   error("%s is mounted", file);
+   return 1;
+   }
+
+   return 0;
+}
+
 int is_vol_small(const char *file)
 {
int fd = -1;
diff --git a/mkfs/common.h b/mkfs/common.h
index 3757e9e7..f5ee5ee4 100644
--- a/mkfs/common.h
+++ b/mkfs/common.h
@@ -72,6 +72,7 @@ int test_minimum_size(const char *file, u64 min_dev_size);
 int is_vol_small(const char *file);
 int test_num_disk_vs_raid(u64 metadata_profile, u64 data_profile,
u64 dev_cnt, int mixed, int ssd);
+int test_status_for_mkfs(const char *file, int force_overwrite);
 int test_dev_for_mkfs(const char *file, int force_overwrite);
 
 #endif
diff --git a/mkfs/main.c b/mkfs/main.c
index a69a699f..e405e5a2 100644
--- a/mkfs/main.c
+++ b/mkfs/main.c
@@ -1598,8 +1598,12 @@ int main(int argc, char **argv)
while (dev_cnt-- > 0) {
file = argv[optind++];
if (is_block_device(file) == 1)
-   if (test_dev_for_mkfs(file, force_overwrite))
-   goto error;
+   ret = test_dev_for_mkfs(file, force_overwrite);
+   else
+   ret = test_status_for_mkfs(file, force_overwrite);
+
+   if (ret)
+   goto error;
}
 
optind = saved_optind;
-- 
2.13.6

--
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: misc/021-image-multi-devices fails on latest btrfs-devel/misc-next

[Lakshmipathi.G]

Hi Qu,

I'm using the same instance. Let me check again with and without the
commits list on Nov-23
(https://github.com/kdave/btrfs-devel/commits/misc-next) and get back
with results.


Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
--
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

[PATCH 1/3] btrfs: Introduce macros to handle bytes and sector conversion

[Qu Wenruo]

Since block I/O is always done in unit of 512 bytes, add BI_SECTOR_SIZE
and BI_SECTOR_SHIFT macros and to_sector() and to_bytes() for later
use.

Although the best position to define such things should be bvec.h, and
to_sector() to_bytes() are also defined in device-mapper.h, there are
a lot of code defining their own SECTOR_SIZE and to_bytes() in
device-mapper is not using u64 (unsigned long long) but unsigned long,
which doesn't fit btrfs usage.

So define btrfs' own macros and inlined converters.

Signed-off-by: Qu Wenruo 
---
 fs/btrfs/ctree.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8fc690384c58..8f6f57167661 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -3734,4 +3734,17 @@ static inline int btrfs_is_testing(struct btrfs_fs_info 
*fs_info)
 #endif
return 0;
 }
+
+#define BI_SECTOR_SHIFT(9)
+#define BI_SECTOR_SIZE (1 << BI_SECTOR_SHIFT)
+
+static inline u64 to_bytes(sector_t n)
+{
+   return ((u64)n << BI_SECTOR_SHIFT);
+}
+
+static inline sector_t to_sector(u64 n)
+{
+   return (n >> BI_SECTOR_SHIFT);
+}
 #endif
-- 
2.15.0

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

[PATCH 3/3] btrfs: extent-tree: Use round up to replace align macro

[Qu Wenruo]

To save reader seconds before checking if it's rounding up or down.

Signed-off-by: Qu Wenruo 
---
 fs/btrfs/extent-tree.c  | 10 +-
 fs/btrfs/extent_io.c|  8 
 fs/btrfs/file-item.c|  4 ++--
 fs/btrfs/file.c |  6 +++---
 fs/btrfs/inode-map.c|  4 ++--
 fs/btrfs/inode.c| 38 +++---
 fs/btrfs/ioctl.c| 12 ++--
 fs/btrfs/ordered-data.c |  2 +-
 fs/btrfs/send.c | 12 ++--
 fs/btrfs/tree-log.c | 14 +++---
 10 files changed, 55 insertions(+), 55 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 84868f29a666..66a4370c37f9 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2064,7 +2064,7 @@ static int btrfs_issue_discard(struct block_device *bdev, 
u64 start, u64 len,
 {
int j, ret = 0;
u64 bytes_left, end;
-   u64 aligned_start = ALIGN(start, BI_SECTOR_SIZE);
+   u64 aligned_start = round_up(start, BI_SECTOR_SIZE);
 
if (WARN_ON(start != aligned_start)) {
len -= aligned_start - start;
@@ -4290,7 +4290,7 @@ int btrfs_alloc_data_chunk_ondemand(struct btrfs_inode 
*inode, u64 bytes)
int have_pinned_space;
 
/* make sure bytes are sectorsize aligned */
-   bytes = ALIGN(bytes, fs_info->sectorsize);
+   bytes = round_up(bytes, fs_info->sectorsize);
 
if (btrfs_is_free_space_inode(inode)) {
need_commit = 0;
@@ -6089,7 +6089,7 @@ int btrfs_delalloc_reserve_metadata(struct btrfs_inode 
*inode, u64 num_bytes)
if (delalloc_lock)
mutex_lock(>delalloc_mutex);
 
-   num_bytes = ALIGN(num_bytes, fs_info->sectorsize);
+   num_bytes = round_up(num_bytes, fs_info->sectorsize);
 
spin_lock(>lock);
nr_extents = count_max_extents(num_bytes);
@@ -6219,7 +6219,7 @@ void btrfs_delalloc_release_metadata(struct btrfs_inode 
*inode, u64 num_bytes)
u64 to_free = 0;
unsigned dropped;
 
-   num_bytes = ALIGN(num_bytes, fs_info->sectorsize);
+   num_bytes = round_up(num_bytes, fs_info->sectorsize);
spin_lock(>lock);
dropped = drop_outstanding_extent(inode, num_bytes);
 
@@ -7875,7 +7875,7 @@ static noinline int find_free_extent(struct btrfs_fs_info 
*fs_info,
goto loop;
}
 checks:
-   search_start = ALIGN(offset, fs_info->stripesize);
+   search_start = round_up(offset, fs_info->stripesize);
 
/* move on to the next group */
if (search_start + num_bytes >
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 5cf8be481a88..209f011863f4 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2965,7 +2965,7 @@ static int __do_readpage(struct extent_io_tree *tree,
 
iosize = min(extent_map_end(em) - cur, end - cur + 1);
cur_end = min(extent_map_end(em) - 1, end);
-   iosize = ALIGN(iosize, blocksize);
+   iosize = round_up(iosize, blocksize);
if (this_bio_flag & EXTENT_BIO_COMPRESSED) {
disk_io_size = em->block_len;
sector = to_sector(em->block_start);
@@ -3388,7 +3388,7 @@ static noinline_for_stack int 
__extent_writepage_io(struct inode *inode,
BUG_ON(em_end <= cur);
BUG_ON(end < cur);
iosize = min(em_end - cur, end - cur + 1);
-   iosize = ALIGN(iosize, blocksize);
+   iosize = round_up(iosize, blocksize);
sector = to_sector(em->block_start + extent_offset);
bdev = em->bdev;
block_start = em->block_start;
@@ -4219,7 +4219,7 @@ int extent_invalidatepage(struct extent_io_tree *tree,
u64 end = start + PAGE_SIZE - 1;
size_t blocksize = page->mapping->host->i_sb->s_blocksize;
 
-   start += ALIGN(offset, blocksize);
+   start += round_up(offset, blocksize);
if (start > end)
return 0;
 
@@ -4336,7 +4336,7 @@ static struct extent_map *get_extent_skip_holes(struct 
inode *inode,
len = last - offset;
if (len == 0)
break;
-   len = ALIGN(len, sectorsize);
+   len = round_up(len, sectorsize);
em = get_extent(BTRFS_I(inode), NULL, 0, offset, len, 0);
if (IS_ERR_OR_NULL(em))
return em;
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index df17cdced256..7a75ada7a96a 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -956,8 +956,8 @@ void btrfs_extent_item_to_extent_map(struct btrfs_inode 
*inode,
} else if (type == BTRFS_FILE_EXTENT_INLINE) {
size_t size;
size = btrfs_file_extent_inline_len(leaf, slot, fi);
-   extent_end = ALIGN(extent_start + size,
-  

[PATCH 2/3] btrfs: Cleanup open coded sector and bytes convert

[Qu Wenruo]

Signed-off-by: Qu Wenruo 
---
 fs/btrfs/check-integrity.c |  2 +-
 fs/btrfs/compression.c |  7 ---
 fs/btrfs/extent-tree.c | 12 ++--
 fs/btrfs/extent_io.c   | 20 ++--
 fs/btrfs/file-item.c   |  6 +++---
 fs/btrfs/inode.c   | 16 
 fs/btrfs/raid56.c  |  8 
 fs/btrfs/scrub.c   | 18 +-
 fs/btrfs/volumes.c |  6 +++---
 9 files changed, 48 insertions(+), 47 deletions(-)

diff --git a/fs/btrfs/check-integrity.c b/fs/btrfs/check-integrity.c
index 7d5a9b51f0d7..ade257389edc 100644
--- a/fs/btrfs/check-integrity.c
+++ b/fs/btrfs/check-integrity.c
@@ -1636,7 +1636,7 @@ static int btrfsic_read_block(struct btrfsic_state *state,
 
bio = btrfs_io_bio_alloc(num_pages - i);
bio_set_dev(bio, block_ctx->dev->bdev);
-   bio->bi_iter.bi_sector = dev_bytenr >> 9;
+   bio->bi_iter.bi_sector = to_sector(dev_bytenr);
bio_set_op_attrs(bio, REQ_OP_READ, 0);
 
for (j = i; j < num_pages; j++) {
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index 280384bf34f1..3a4e0376fc3c 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -136,7 +136,7 @@ static void end_compressed_bio_read(struct bio *bio)
 
inode = cb->inode;
ret = check_compressed_csum(BTRFS_I(inode), cb,
-   (u64)bio->bi_iter.bi_sector << 9);
+   to_bytes(bio->bi_iter.bi_sector));
if (ret)
goto csum_failed;
 
@@ -480,7 +480,8 @@ static noinline int add_ra_bio_pages(struct inode *inode,
 
if (!em || last_offset < em->start ||
(last_offset + PAGE_SIZE > extent_map_end(em)) ||
-   (em->block_start >> 9) != cb->orig_bio->bi_iter.bi_sector) {
+   (to_sector(em->block_start)) !=
+   cb->orig_bio->bi_iter.bi_sector) {
free_extent_map(em);
unlock_extent(tree, last_offset, end);
unlock_page(page);
@@ -545,7 +546,7 @@ blk_status_t btrfs_submit_compressed_read(struct inode 
*inode, struct bio *bio,
struct page *page;
struct block_device *bdev;
struct bio *comp_bio;
-   u64 cur_disk_byte = (u64)bio->bi_iter.bi_sector << 9;
+   u64 cur_disk_byte = to_bytes(bio->bi_iter.bi_sector);
u64 em_len;
u64 em_start;
struct extent_map *em;
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e2d7e86b51d1..84868f29a666 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2064,11 +2064,11 @@ static int btrfs_issue_discard(struct block_device 
*bdev, u64 start, u64 len,
 {
int j, ret = 0;
u64 bytes_left, end;
-   u64 aligned_start = ALIGN(start, 1 << 9);
+   u64 aligned_start = ALIGN(start, BI_SECTOR_SIZE);
 
if (WARN_ON(start != aligned_start)) {
len -= aligned_start - start;
-   len = round_down(len, 1 << 9);
+   len = round_down(len, BI_SECTOR_SIZE);
start = aligned_start;
}
 
@@ -2106,8 +2106,8 @@ static int btrfs_issue_discard(struct block_device *bdev, 
u64 start, u64 len,
}
 
if (size) {
-   ret = blkdev_issue_discard(bdev, start >> 9, size >> 9,
-  GFP_NOFS, 0);
+   ret = blkdev_issue_discard(bdev, to_sector(start),
+   to_sector(size), GFP_NOFS, 0);
if (!ret)
*discarded_bytes += size;
else if (ret != -EOPNOTSUPP)
@@ -2123,8 +2123,8 @@ static int btrfs_issue_discard(struct block_device *bdev, 
u64 start, u64 len,
}
 
if (bytes_left) {
-   ret = blkdev_issue_discard(bdev, start >> 9, bytes_left >> 9,
-  GFP_NOFS, 0);
+   ret = blkdev_issue_discard(bdev, to_sector(start),
+  to_sector(bytes_left), GFP_NOFS, 0);
if (!ret)
*discarded_bytes += bytes_left;
}
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 7fa50e12f18e..5cf8be481a88 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -2024,7 +2024,7 @@ int repair_io_failure(struct btrfs_fs_info *fs_info, u64 
ino, u64 start,
BUG_ON(mirror_num != bbio->mirror_num);
}
 
-   sector = bbio->stripes[bbio->mirror_num - 1].physical >> 9;
+   sector = to_sector(bbio->stripes[bbio->mirror_num - 1].physical);
bio->bi_iter.bi_sector = sector;
dev = bbio->stripes[bbio->mirror_num - 1].dev;
btrfs_put_bbio(bbio);
@@ -2334,7 +2334,7 @@ struct bio *btrfs_create_repair_bio(struct inode *inode, 

Re: misc/021-image-multi-devices fails on latest btrfs-devel/misc-next

[Qu Wenruo]

On 2017年11月23日 11:16, Lakshmipathi.G wrote:
> Quick update: It continues to fail:
> https://asciinema.org/a/8HAL3uZ4MG7eb5gXnlgq3jm7q

Still fails to reproduce it.

All success across my host and VMs.

And according to your misc-test-result, it seems that your testing
system doesn't cleanup loop devices for 021 well.

I think that's the reason why you always get stuck at misc/021.

Thanks,
Qu

> 
> Cheers,
> Lakshmipathi.G
> http://www.giis.co.in http://www.webminal.org
> 
> 
> On Sat, Nov 18, 2017 at 12:59 PM, Lakshmipathi.G
>  wrote:
>> Hi.
>>
>> Few days back(Nov14th) this(misc/021-image-multi-devices) test script
>> used to pass and seems like its failing
>> now. may be due to recent commits? Logs,screen-casts available here:
>> https://lakshmipathi.github.io/btrfsqa/
>>
>> 
>> Cheers,
>> Lakshmipathi.G
>> http://www.giis.co.in http://www.webminal.org
> --
> 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
> 



signature.asc
Description: OpenPGP digital signature

Re: Issue in recovering and using the mirror superblock

[Qu Wenruo]

On 2017年11月24日 00:31, kol...@caramail.com wrote:
> Hi,
> 
> I am trying to recover from a mistake I made by overwriting the first GBs of 
> my Btrfs /home partition with a non-Btrfs filesystem.

Well, in most case, the chance of recovery is already very low.

The possibility mostly relies on your device extents layout.
If all new data write is overwriting device extents belong to data, then
you will have a high chance to recover.

However this always depends on the fs you're using.

AFAIK, normal traditional fs, like ext*/xfs will build all their block
groups/AGs at mkfs time, and they are not just writing data in the first
several GB, but a lot of small write across the whole disk, which makes
recovery even harder.

> 
> I have already made a .dd image of the partition, and I am using it to try 
> and find the mirror superblock, in particular the one at 256 GB.
> 
> When I run the "btrfs restore" command I get an error message, maybe because 
> the mirror superblock -- I am not sure about the reason.
> 
> Using the dummy run option, from the command line I do
> 
> btrfs restore -D -u 2 /run/media/user01/SamsungHD/sda2.dd 
> /run/media/user01/ToshibaHD/RecoveredData
> 
> The message is get is:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709

Unfortunately, your chunk tree get corrupted, which is the most
important tree for btrfs.
It manages the mapping between btrfs logical address space to device offset.

Without this tree, nothing can really be recovered.

If you're really sure about the overwrite range, you could use
btrfs-dump-super to verify your system chunk mapping (where chunk tree is).

I'd say it's in the overwrite range.

> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> With the -u 1 option (instead of -u 2) I get:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> I have reason to believe that the mirror superblock at 256 GB is intact (I am 
> assuming that only the initial sectors of the partition were overwritten), so 
> I do not understand why it is not being recovered. BTW, the size of the 
> partition is above 300 GBs, so there is supposed to be a mirror superblock at 
> 256 GB.

Btrfs is complex, so complex that the bootstrap depends on several
trees, not only superblock.

To be more specific, btrfs bootstraps involves:

superblock (system chunk array) -> system chunk mapping -> chunk tree ->
metadata chunk mapping -> root tree -> fs tree.

Any corruption (without valid copy) in the chain will cause the mount
failure.
And in your case, system chunk mapping is good (since it's in
superblock) but your chunk tree is corrupted.

So no chance here.

Thanks,
Qu

> 
> Can anyone help me?
> 
> 
> 
> Here is the btrfs info:
> 
> uname -a
> Linux adfa-workstation 4.9.63-1-MANJARO #1 SMP PREEMPT Sat Nov 18 14:12:41 
> UTC 2017 x86_64 GNU/Linux
> 
> btrfs --version
> btrfs-progs v4.13
> 
> Thanks
> 
> Terry
> --
> 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
> 



signature.asc
Description: OpenPGP digital signature

Re: notification about corrupt files from "btrfs scrub" in cron

[Duncan]

ST posted on Thu, 23 Nov 2017 13:47:59 +0200 as excerpted:

>> > I have following cron job to scrub entire root filesystem (total ca.
>> > 7.2TB and 2.3TB of them used) once a week:
>> > /bin/btrfs scrub start -r / > /dev/null
>> > 
>> > Such scrubbing takes ca. 2 hours. How should I get notified that a
>> > corrupt file was discovered? Does this command return some error code
>> > back to cron so it can send an email as usual? Will cron wait 2 hours
>> > to get that code?
>> > 
>> > I tried that command once without "> /dev/null" but got no email
>> > notification about the results (eventhough the check was OK) - why?
>> 
>> See the btrfs-scrub manpage...
>> 
>> Note that normally btrfs scrub start is asynchronous and should return
>> effectively immediately, the only possible errors therefore being for
>> example if the given path doesn't point to a btrfs or btrfs-device
>> (which would return a status code of 1, scrub couldn't be performed),
>> etc.
>> 
>> Status can be checked via btrfs scrub status, and/or, or you can use
>> the btrfs scrub start's -B (don't background) switch, which will cause
>> it to wait until the scrub is finished and print a summary report. 
>> That should allow you to check for a status code of 3, scrub found
>> uncorrectable errors, as well.
> 
> Thank you for the response! Does it mean that if write:
> 
> /bin/btrfs scrub start -r -B /
> 
> cron will hang for 2 hours (is it problematic?) and then send me an
> email with the summary report (even if everything was OK), and if I
> write:
> 
> /bin/btrfs scrub start -r -B / > /dev/null
> 
> after 2 hours it will send an email, only if there was an error with
> whatever error code (1-3)?

I /did/ say see the manpage...  There's a -q/quiet option as well, so 
redirecting to /dev/null isn't necessary.  There are other options you 
might find useful as well, that I didn't mention but that are covered in 
the manpage.  That's why I said see it. =:^)

Tho since you obviously didn't look at it yet, it occurs to me that 
perhaps you need to know /how/ to "see the btrfs-scrub manpage".  Try 
simply "man btrfs-scrub" (without the quotes) at a terminal command-
prompt.  FWIW, you can try simply "man btrfs" to get a more general 
overview as well, or "man 5 btrfs", since there's more than one "btrfs" 
manpage, and the 5 will give you the one from section 5, generally format 
documentation, etc, as opposed to section 1 (user commands) and section 8 
(superuser/admin commands, which is where most btrfs manpages are), which 
will normally appear before a section 5 manpage of the same name.  Of 
course you could try "man man" to get more information about man, as well.

As for cron, note that there's many different implementations that 
presumably act somewhat differently, and many distros don't tend to 
configure cron to directly start most of their stuff anyway, because 
cron, at least originally, would only start scheduled jobs if it (and 
thus the computer) were actually running at the time the job was 
scheduled -- it had no built-in mechanism to check for overdue items and 
run them when it was restarted after being off for awhile.  Because many 
users actually turn their computers off... or suspend or hibernate 
them... when they're not in use, that didn't work so well, so most 
distros I've seen actually have cron run a script say every 10 minutes or 
every hour, that checks if any scheduled jobs have passed their trigger 
time, and starts them if so.

And of course these days, on most distros systemd is taking over 
scheduling tasks with its timers, including one that runs "legacy" cron 
jobs as necessary.

So I'd suggest reading up on whatever your cron implementation happens to 
be, as well.  Maybe start with the manpages...  And then check the 
existing jobs to see what they actually do.  But as Mike says, cron 
typically runs async regardless of the implementation, so it doesn't 
"hang" while running a scheduled job.

And of course, typically when setting up a cron job, admins will normally 
run the command manually to see that it does what they expect and need, 
before scheduling it, and then, when setting it up as a cron job, they 
may first schedule it right away and monitor it to see how things go, 
before setting it up with a more permanent schedule.  IOW, they'll do a 
test run.  That way they know what to expect from the permanently 
scheduled job.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

python-btrfs release v9

[Hans van Kranenburg]

I just tagged v9 of the python btrfs library.

https://github.com/knorrie/python-btrfs

Q: What is python-btrfs?
A: python-btrfs is a python3 implementation of the data structures for
btrfs metadata, and an implementation of the kernel API (via ioctl
calls) that btrfs provides to userland.

Q: Ok, whatever, dude, but what would I need that for?
A: You probably won't need this.

Q: I'm a btrfs developer, what is this?
A: It provides quick hackable ways to inspect a running filesystem. You
can look up things in the current kernel metadata memory, play around
with ioctls, and quickly cobble up scripts for that.

Here's the summary of changes:

python-btrfs v9, Nov 23 2017
  * IOCTLs: IOC_SET_RECEIVED_SUBVOL, IOC_LOGICAL_INO_V2
  * Add crc32c checksum function for data, thanks Nikolay Borisov
  * Recognize zstd compression type
  * Add a tree object pretty printer to dump data for any tree item
  * Examples added:
- Show default subvolume id
- Lookup a block checksum in the checksum tree
- Determine bad free space fragmentation score for block groups
- Set the received_uuid e.a. of a subvolume
- Dump an entire metadata tree using the pretty printer
  * Fixes:
- crc32c: add implicit seed truncation to 32 bits value
  * Small fixes and cosmetic changes

Note: the IOC_SET_RECEIVED_SUBVOL is added 'because we can'. It's not
added because it's a very good to mess around with it except for
educational purpose in a test environment.

As usual, detailed explanations of all changes are in the git commit
messages.

Feedback from Nikolay Borisov pushed me to have a look at how the
checksum storage is done.

My favorite one for this release is the tree object pretty printer,
which allows us to dump a single tree object displaying all its
attributes, but also allows us to stream a search query into it to
output a full dump of a metadata tree. See the examples/dump_tree.py
about this!

Tomorrow I'll update pypi and will prepare debian packages for unstable
and stretch-backports.

-- 
Have fun,
Hans van Kranenburg
--
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: Issue in recovering and using the mirror superblock

[koller]

As an update to my previous email:

I attempted the visual inspection of the second superblock (located at 256 GB) 
inside the .dd image by using

tail -c +$((0x40+1)) /run/media/user01/SamsungHD/sda2.dd |hexdump 
-C|less

and sure enough, it shows that the supeblock is right there, clearly marked by 
the header string “_BHRfS_”, no mistake about it. Of course, this is no 
guarantee that it may not be corrupt. But why should it be? This part of the 
disk was not touched by the overwriting which damaged the partition -- and 
there was never a physical damage to the disk. 
Rather than assuming that there is some problem with this superblock it’s more 
reasonable to assume that there is some issue with the recovery tools I have 
used so far. 

Here is the report of my attempts to use the second superblock by using the 
availble recovery tools:

Both btrfsck and "btrfs rescue super-recover" produced the same error message.


When i ran:

sudo btrfsck -s2 /run/media/user01/SamsungHD/sda2.dd

I got:

using SB copy 2, bytenr 274877906944
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 33D5DCDD wanted 016C
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
bytenr mismatch, want=20971520, have=709
ERROR: cannot read chunk root
ERROR: cannot open file system

As reported in the previous email, when I used btrfs restore I got exactly the 
same error message.


HOWEVER, with "btrfs rescue super-recover" I got a totally different response:

Before Recovering:
[All good supers]:
device name = /run/media/user01/SamsungHD/sda2.dd
superblock bytenr = 67108864

device name = /run/media/user01/SamsungHD/sda2.dd
superblock bytenr = 274877906944

[All bad supers]:

All supers are valid, no need to recover

This message above ("All supers are valid, no need to recover") is also 
problematic, because in actuality the first mirror image at 64 MB is missing (I 
checked with hexdump, and it is not there at the expected location 0x400). 

Anyway, for sure there is some inconsistency between the behavior of the tools 
-- and none of them is helpful! 

I don’t know what to make of all this, but I am still left wondering what to do 
next. I have the second superblock, from which in theory I could restore my 
filesystem (or part of it), but I don’t know how to use it. I need some tools 
that work...

Any ideas?

Thanks








> Sent: Thursday, November 23, 2017 at 6:31 PM
> From: kol...@caramail.com
> To: linux-btrfs@vger.kernel.org
> Subject: Issue in recovering and using the mirror superblock
>
> Hi,
> 
> I am trying to recover from a mistake I made by overwriting the first GBs of 
> my Btrfs /home partition with a non-Btrfs filesystem.
> 
> I have already made a .dd image of the partition, and I am using it to try 
> and find the mirror superblock, in particular the one at 256 GB.
> 
> When I run the "btrfs restore" command I get an error message, maybe because 
> the mirror superblock -- I am not sure about the reason.
> 
> Using the dummy run option, from the command line I do
> 
> btrfs restore -D -u 2 /run/media/user01/SamsungHD/sda2.dd 
> /run/media/user01/ToshibaHD/RecoveredData
> 
> The message is get is:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> With the -u 1 option (instead of -u 2) I get:
> 
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> checksum verify failed on 20971520 found 33D5DCDD wanted 016C
> checksum verify failed on 20971520 found 01FA5E60 wanted 000E
> bytenr mismatch, want=20971520, have=709
> ERROR: cannot read chunk root
> Could not open root, trying backup super
> 
> I have reason to believe that the mirror superblock at 256 GB is intact (I am 
> assuming that only the initial sectors of the partition were overwritten), so 
> I do not understand why it is not being recovered. BTW, the size of the 
> partition is above 300 GBs, so there is supposed to be a mirror superblock at 
> 256 GB.
> 
> Can anyone help me?
> 
> 
> 
> Here is the btrfs 

Re: btrfs-progs-4.13: cmds-inspect-tree-stats.h: No such file or directory

[David Sterba]

On Wed, Nov 22, 2017 at 11:20:52PM -0500, John L. Center wrote:
> On 11/22/2017 11:15 PM, John L. Center wrote:
> > On 09/09/2017 01:48 AM, Uli Heller wrote:
> >> I dowloaded the btrfs-progs-v4.13.tar.xz tarball and tried to build it.
> >> Unfortunately, I get an error about cmds-inspect-tree-stats.h. The 
> >> file seems
> >> to be missing from the tarball, it used to exist in v4.12.
> >>
> >> ...
> >> true -g -Os -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> >> -Werror=format-security -DBTRFS_FLAT_INCLUDES=1 -I. -Ikernel-lib -Itmp 
> >> -include .cc-defines.h -D__CHECKER__ -D__CHECK_ENDIAN__ -Wbitwise 
> >> -Wuninitialized -Wshadow -Wundef -U_FORTIFY_SOURCE btrfs-calc-size.c
> >>  [CC] btrfs-calc-size.o
> >> gcc -g -Os -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> >> -Werror=format-security -DBTRFS_FLAT_INCLUDES=1 -I. -Ikernel-lib -Itmp 
> >> -c btrfs-calc-size.c -o btrfs-calc-size.o  \
> >>
> >> btrfs-calc-size.c:22:37: fatal error: cmds-inspect-tree-stats.h: No 
> >> such file or directory
> >>   #include "cmds-inspect-tree-stats.h"
> >>   ^
> >>
> >> $ LANG=C ls -l btrfs-progs-v4.12/cmds-inspect-tree-stats.h 
> >> btrfs-progs-v4.13/cmds-inspect-tree-stats.h
> >> ls: cannot access btrfs-progs-v4.13/cmds-inspect-tree-stats.h: No such 
> >> file or directory
> >> -rw-rw-r-- 1 uli uli 905 Jul 28 15:29 
> >> btrfs-progs-v4.12/cmds-inspect-tree-stats.h
> >>
> > The issue exists in the new btrfs-progs-v4.14.tar.gz, also.
> > 
> I forgot to mention, it was in btrfs-show-super.c.

Fixed in devel, thanks.
--
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 v2 00/11] Metadata specific accouting and dirty writeout

[David Sterba]

On Wed, Nov 22, 2017 at 04:15:55PM -0500, Josef Bacik wrote:
> These patches are to support having metadata accounting and dirty handling
> in a generic way.  For dirty metadata ext4 and xfs currently are limited by
> their journal size, which allows them to handle dirty metadata flushing in a
> relatively easy way.  Btrfs does not have this limiting factor, we can have as
> much dirty metadata on the system as we have memory, so we have a dummy inode
> that all of our metadat pages are allocated from so we can call
> balance_dirty_pages() on it and make sure we don't overwhelm the system with
> dirty metadata pages.
> 
> The problem with this is it severely limits our ability to do things like
> support sub-pagesize blocksizes.  Btrfs also supports metadata blocksizes > 
> page
> size, which makes keeping track of our metadata and it's pages particularly
> tricky.  We have the inode mapping with our pages, and we have another radix
> tree for our actual metadata buffers.  This double accounting leads to some 
> fun
> shenanigans around reclaim and evicting pages we know we are done using.
> 
> To solve this we would like to switch to a scheme like xfs has, where we 
> simply
> have our metadata structures tied into the slab shrinking code, and we just 
> use
> alloc_page() for our pages, or kmalloc() when we add sub-pagesize blocksizes.
> In order to do this we need infrastructure in place to make sure we still 
> don't
> overwhelm the system with dirty metadata pages.
> 
> Enter these patches.  Because metadata is tracked on a non-pagesize amount we
> need to convert a bunch of our existing counters to bytes.  From there I've
> added various counters for metadata, to keep track of overall metadata bytes,
> how many are dirty and how many are under writeback.  I've added a super
> operation to handle the dirty writeback, which is going to be handled mostly
> inside the fs since we will need a little more smarts around what we 
> writeback.

The text relevant for btrfs should also go to the btree_inode removal
patch changelog. The cover letter gets lost but we still might need to
refer to the overall logic that's going to be changed in that patch.

And possibly more documentation should go to the code itself, there are
some scattered comments in the tricky parts but the overall logic is not
described and the key functions lack comments.

What's your merge plan? There are other subsystem changes needed, before
the btree_inode removal can happen and can be tested within our for-next
branches. The 4.15 target is out of reach, so I assume 4.16 for the
dependencies and 4.17 for the btree_inode. We can of course test them
earlier, but 4.16 does not seem realistic for the whole patchset.

> The last three patches are just there to show how we use the infrastructure in
> the first 8 patches.  The actuall kill btree_inode patch is pretty big,
> unfortunately ripping out all of the pagecache based handling and replacing it
> with the new infrastructure has to be done whole-hog and can't be broken up
> anymore than it already has been without making it un-bisectable.

I don't completely agree that it cannot be split. I went through it a
few times, the patch is too big for review. It mixes the core part and
cleanups that do not necessarily need to be in the patch. I'd like to
see the core part minimized further, at the cost of leaving some dead
code behind (like the old callbacks).
--
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

Issue in recovering and using the mirror superblock

[koller]

Hi,

I am trying to recover from a mistake I made by overwriting the first GBs of my 
Btrfs /home partition with a non-Btrfs filesystem.

I have already made a .dd image of the partition, and I am using it to try and 
find the mirror superblock, in particular the one at 256 GB.

When I run the "btrfs restore" command I get an error message, maybe because 
the mirror superblock -- I am not sure about the reason.

Using the dummy run option, from the command line I do

btrfs restore -D -u 2 /run/media/user01/SamsungHD/sda2.dd 
/run/media/user01/ToshibaHD/RecoveredData

The message is get is:

checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 33D5DCDD wanted 016C
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
bytenr mismatch, want=20971520, have=709
ERROR: cannot read chunk root
Could not open root, trying backup super

With the -u 1 option (instead of -u 2) I get:

checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 33D5DCDD wanted 016C
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
bytenr mismatch, want=20971520, have=709
ERROR: cannot read chunk root
Could not open root, trying backup super
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
checksum verify failed on 20971520 found 33D5DCDD wanted 016C
checksum verify failed on 20971520 found 01FA5E60 wanted 000E
bytenr mismatch, want=20971520, have=709
ERROR: cannot read chunk root
Could not open root, trying backup super

I have reason to believe that the mirror superblock at 256 GB is intact (I am 
assuming that only the initial sectors of the partition were overwritten), so I 
do not understand why it is not being recovered. BTW, the size of the partition 
is above 300 GBs, so there is supposed to be a mirror superblock at 256 GB.

Can anyone help me?



Here is the btrfs info:

uname -a
Linux adfa-workstation 4.9.63-1-MANJARO #1 SMP PREEMPT Sat Nov 18 14:12:41 UTC 
2017 x86_64 GNU/Linux

btrfs --version
btrfs-progs v4.13

Thanks

Terry
--
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: uncorrectable errors in Raid 10

[Steffen Sindzinski]

Hi,

I think just some XWayland Nouveau bug:

Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: TRAP ch 22 
[007d08d000 Xwayland[781]]
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: GPC0/TPC0/TEX: 
8041
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: GPC0/TPC1/TEX: 
8041
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: GPC0/TPC2/TEX: 
8041
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: GPC0/TPC3/TEX: 
8041
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: gr: GPC0/TPC4/TEX: 
8041
Nov 23 12:46:26 bigbox kernel: nouveau :01:00.0: fifo: read fault at 
000586 engine 00 [GR] client 15 [GPC0/PE_4] reason 02 [PTE] on 
channel 22 [007d08d000 Xwayland[781]]



Steffen


Am 23.11.2017 um 13:14 schrieb Qu Wenruo:



On 2017年11月23日 20:02, Steffen Sindzinski wrote:

Hi,

I updated to btrfs-progs v4.14-5-gf09e98a3. Unfortunately after 10h
Gnome desktop / Arch crashed with btrfs check --lowmem unfinished. I
will run it this night again.


Any kernel backtrace about the crash?

IIRC user space program like btrfs check should not trigger a kernel crash.



The result until crash was:

Checking filesystem on /dev/sdd2
UUID: 4fafd0d4-7dd9-4dcc-9a33-5f1ad9555358
ERROR: extent[15923092037632, 73728] referencer count mismatch (root:
260, owner: 3631467, offset: 1019904) wanted: 4, have: 6
ERROR: extent[16078964924416, 69632] referencer count mismatch (root:
260, owner: 4086589, offset: 4296704) wanted: 5, have: 7


This is known bug, please use this branch instead.
https://github.com/adam900710/btrfs-progs/tree/lowmem_fix

Thanks,
Qu



Steffen


Am 22.11.2017 um 17:42 schrieb Chris Murphy:

On Wed, Nov 22, 2017 at 9:38 AM, Steffen Sindzinski
 wrote:

Hello,

I did btrfs check --readonly on both disk without finding any error. To
reconfirm I did a scrub again which still has found 2 uncorrectable
errors.


Try --mode=lowmem option with btrfs-progs 4.3.3 or better 4.14. This
is a new implementation of btrfs check and sometimes it comes up with
different results. It's strange that there's only this error found by
scrub and not by btrfs check which should be fully checking all
metadata for sanity, and in the process it would surely hit a bad
checksum.



--
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: notification about corrupt files from "btrfs scrub" in cron

[Marat Khalili]

On 23/11/17 15:59, Mike Fleetwood wrote:


Cron starts configured jobs at the scheduled time asynchronously.
I.e. It doesn't block waiting for each command to finish.  Cron notices
when the job finishes and any output produced, written to stdout and/or
stderr, by the job is emailed to the user.  So no, a 2 hour job is not a
problem for cron.


Minor additional advice -- prepend you command with:


flock --nonblock /var/run/scrub.lock
to avoid running several scrubs simultaneously in case one takes more 
than 24 hours to finish.



--

With Best Regards,
Marat Khalili

--
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: notification about corrupt files from "btrfs scrub" in cron

[Mike Fleetwood]

On 23 November 2017 at 11:47, ST  wrote:
>
>> > I have following cron job to scrub entire root filesystem (total ca.
>> > 7.2TB and 2.3TB of them used) once a week:
>> > /bin/btrfs scrub start -r / > /dev/null
>> >
>> > Such scrubbing takes ca. 2 hours. How should I get notified that a
>> > corrupt file was discovered? Does this command return some error code
>> > back to cron so it can send an email as usual? Will cron wait 2 hours to
>> > get that code?
>> >
>> > I tried that command once without "> /dev/null" but got no email
>> > notification about the results (eventhough the check was OK) - why?
>>
>> See the btrfs-scrub manpage...
>>
>> Note that normally btrfs scrub start is asynchronous and should return
>> effectively immediately, the only possible errors therefore being for
>> example if the given path doesn't point to a btrfs or btrfs-device (which
>> would return a status code of 1, scrub couldn't be performed), etc.
>>
>> Status can be checked via btrfs scrub status, and/or, or you can use the
>> btrfs scrub start's -B (don't background) switch, which will cause it to
>> wait until the scrub is finished and print a summary report.  That should
>> allow you to check for a status code of 3, scrub found uncorrectable
>> errors, as well.
>
> Thank you for the response! Does it mean that if write:
>
> /bin/btrfs scrub start -r -B /
>
> cron will hang for 2 hours (is it problematic?) and then send me an
> email with the summary report (even if everything was OK), and if I
> write:
>
> /bin/btrfs scrub start -r -B / > /dev/null
>
> after 2 hours it will send an email, only if there was an error with
> whatever error code (1-3)?

Cron starts configured jobs at the scheduled time asynchronously.
I.e. It doesn't block waiting for each command to finish.  Cron notices
when the job finishes and any output produced, written to stdout and/or
stderr, by the job is emailed to the user.  So no, a 2 hour job is not a
problem for cron.

With you redirecting btrfs scrub stdout to /dev/null only any stderr
output will be captured by cron and emailed to you.
(Unfortunately I don't know btrfs scrub well enough to know if it
reports errors to stderr).

Mike
--
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: uncorrectable errors in Raid 10

[Qu Wenruo]

On 2017年11月23日 20:02, Steffen Sindzinski wrote:
> Hi,
> 
> I updated to btrfs-progs v4.14-5-gf09e98a3. Unfortunately after 10h
> Gnome desktop / Arch crashed with btrfs check --lowmem unfinished. I
> will run it this night again.

Any kernel backtrace about the crash?

IIRC user space program like btrfs check should not trigger a kernel crash.

> 
> The result until crash was:
> 
> Checking filesystem on /dev/sdd2
> UUID: 4fafd0d4-7dd9-4dcc-9a33-5f1ad9555358
> ERROR: extent[15923092037632, 73728] referencer count mismatch (root:
> 260, owner: 3631467, offset: 1019904) wanted: 4, have: 6
> ERROR: extent[16078964924416, 69632] referencer count mismatch (root:
> 260, owner: 4086589, offset: 4296704) wanted: 5, have: 7

This is known bug, please use this branch instead.
https://github.com/adam900710/btrfs-progs/tree/lowmem_fix

Thanks,
Qu

> 
> Steffen
> 
> 
> Am 22.11.2017 um 17:42 schrieb Chris Murphy:
>> On Wed, Nov 22, 2017 at 9:38 AM, Steffen Sindzinski
>>  wrote:
>>> Hello,
>>>
>>> I did btrfs check --readonly on both disk without finding any error. To
>>> reconfirm I did a scrub again which still has found 2 uncorrectable
>>> errors.
>>
>> Try --mode=lowmem option with btrfs-progs 4.3.3 or better 4.14. This
>> is a new implementation of btrfs check and sometimes it comes up with
>> different results. It's strange that there's only this error found by
>> scrub and not by btrfs check which should be fully checking all
>> metadata for sanity, and in the process it would surely hit a bad
>> checksum.
>>
>>
> -- 
> 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



signature.asc
Description: OpenPGP digital signature

Re: uncorrectable errors in Raid 10

[Steffen Sindzinski]

Hi,

I updated to btrfs-progs v4.14-5-gf09e98a3. Unfortunately after 10h 
Gnome desktop / Arch crashed with btrfs check --lowmem unfinished. I 
will run it this night again.


The result until crash was:

Checking filesystem on /dev/sdd2
UUID: 4fafd0d4-7dd9-4dcc-9a33-5f1ad9555358
ERROR: extent[15923092037632, 73728] referencer count mismatch (root: 
260, owner: 3631467, offset: 1019904) wanted: 4, have: 6
ERROR: extent[16078964924416, 69632] referencer count mismatch (root: 
260, owner: 4086589, offset: 4296704) wanted: 5, have: 7


Steffen


Am 22.11.2017 um 17:42 schrieb Chris Murphy:

On Wed, Nov 22, 2017 at 9:38 AM, Steffen Sindzinski  wrote:

Hello,

I did btrfs check --readonly on both disk without finding any error. To
reconfirm I did a scrub again which still has found 2 uncorrectable errors.


Try --mode=lowmem option with btrfs-progs 4.3.3 or better 4.14. This
is a new implementation of btrfs check and sometimes it comes up with
different results. It's strange that there's only this error found by
scrub and not by btrfs check which should be fully checking all
metadata for sanity, and in the process it would surely hit a bad
checksum.



--
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: notification about corrupt files from "btrfs scrub" in cron

[ST]

> > I have following cron job to scrub entire root filesystem (total ca.
> > 7.2TB and 2.3TB of them used) once a week:
> > /bin/btrfs scrub start -r / > /dev/null
> > 
> > Such scrubbing takes ca. 2 hours. How should I get notified that a
> > corrupt file was discovered? Does this command return some error code
> > back to cron so it can send an email as usual? Will cron wait 2 hours to
> > get that code?
> > 
> > I tried that command once without "> /dev/null" but got no email
> > notification about the results (eventhough the check was OK) - why?
> 
> See the btrfs-scrub manpage...
> 
> Note that normally btrfs scrub start is asynchronous and should return 
> effectively immediately, the only possible errors therefore being for 
> example if the given path doesn't point to a btrfs or btrfs-device (which 
> would return a status code of 1, scrub couldn't be performed), etc.
> 
> Status can be checked via btrfs scrub status, and/or, or you can use the 
> btrfs scrub start's -B (don't background) switch, which will cause it to 
> wait until the scrub is finished and print a summary report.  That should 
> allow you to check for a status code of 3, scrub found uncorrectable 
> errors, as well.

Thank you for the response! Does it mean that if write:

/bin/btrfs scrub start -r -B /

cron will hang for 2 hours (is it problematic?) and then send me an
email with the summary report (even if everything was OK), and if I
write:

/bin/btrfs scrub start -r -B / > /dev/null

after 2 hours it will send an email, only if there was an error with
whatever error code (1-3)?

Thank you!

--
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: notification about corrupt files from "btrfs scrub" in cron

[Duncan]

ST posted on Wed, 22 Nov 2017 21:54:10 +0200 as excerpted:

> Hello,
> 
> I have following cron job to scrub entire root filesystem (total ca.
> 7.2TB and 2.3TB of them used) once a week:
> /bin/btrfs scrub start -r / > /dev/null
> 
> Such scrubbing takes ca. 2 hours. How should I get notified that a
> corrupt file was discovered? Does this command return some error code
> back to cron so it can send an email as usual? Will cron wait 2 hours to
> get that code?
> 
> I tried that command once without "> /dev/null" but got no email
> notification about the results (eventhough the check was OK) - why?

See the btrfs-scrub manpage...

Note that normally btrfs scrub start is asynchronous and should return 
effectively immediately, the only possible errors therefore being for 
example if the given path doesn't point to a btrfs or btrfs-device (which 
would return a status code of 1, scrub couldn't be performed), etc.

Status can be checked via btrfs scrub status, and/or, or you can use the 
btrfs scrub start's -B (don't background) switch, which will cause it to 
wait until the scrub is finished and print a summary report.  That should 
allow you to check for a status code of 3, scrub found uncorrectable 
errors, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs restore corrupt file

[Duncan]

Jorge Bastos posted on Wed, 22 Nov 2017 19:18:59 + as excerpted:

> Hello,
> 
> While doing btrfs checksum testing I purposely corrupted a file and got
> the expect I/O error when trying to copy it, I also tested btrfs restore
> to see if I could recover a known corrupt file and it did copy it but
> there was no checksum error or warning. I used btrfs restore -v
> 
> Is this expect behavior or should restore warn about checksum failures?
> 
> Kernel used was 4.13.13,  btrfs-progs v4.13.2

AFAIK it's expected.  The purpose of btrfs restore, after all, is to try 
to get at least some files back from a filesystem that is generally 
damaged and unable to mount, so acceptance of some possible damage to 
restored files as a tradeoff for being able to restore them *at* *all* is 
assumed.  It's not /supposed/ to be a substitute for having a proper 
backup in the first place, only something to try in case there was no 
backup and getting back a damaged file is better than getting back no 
file, or in case there was a backup, but it wasn't current, in which case 
the restored files can be verified against the backup, and those that 
differ can be examined to see if the difference is due to legitimate 
change, or corruption.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: btrfs restore corrupt file

[Jorge Bastos]

Thanks for the replies.

Good to know it's working as expected, and I'm glad restore permits
restoring a corrupt file since this may be desirable in some cases,
but agree with Chris that it would be nice to get a warning if
corruption is found or suspected.

Jorge

On Thu, Nov 23, 2017 at 7:43 AM, Qu Wenruo  wrote:
>
>
> On 2017年11月23日 13:25, Chris Murphy wrote:
>> On Wed, Nov 22, 2017 at 12:18 PM, Jorge Bastos  
>> wrote:
>>> Hello,
>>>
>>> While doing btrfs checksum testing I purposely corrupted a file and
>>> got the expect I/O error when trying to copy it, I also tested btrfs
>>> restore to see if I could recover a known corrupt file and it did copy
>>> it but there was no checksum error or warning. I used btrfs restore -v
>>>
>>> Is this expect behavior or should restore warn about checksum failures?
>>>
>>> Kernel used was 4.13.13,  btrfs-progs v4.13.2
>>
>> I think it's expected. "The checks done by restore are less strict"
>> from the man page. Although it'd be nice if -v option at least could
>> flag such files as possibly being corrupt.
>>
> I think people always consider "btrfs restore" as a tool to "restore" data.
>
> The proper name of it should be "salvage" and moved under "btrfs
> rescue", to reduce the confusion.
>
> Thanks,
> Qu
>
--
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

★ lintaowenxue --“2018世界复合材料展览及会议”将于“3月”在“法国巴黎”举行 （地右P1-L-Me）

[linux-btrfs-owner]

尊敬的 lintaowen...@163.com 企业领导/公司负责人/业界专家，您好：
　　
　　
新材料为21世纪三大共性关键技术之一，已成为全球经济迅速增长的源动力和提升核心竞争力的战略焦点。材料作为制造业的基础，特别是新材料研究和产业发展的水平与规模，已经成为衡量一个国家科技进步和综合实力的重要标志。在新材料发展与应用中，复合材料占有相当重要的地位，特别广泛的应用在汽车、交通、风能、航空、航天、兵器、船舶、国防、机械、电子、化工、建筑、农业、渔业、纺织、运动器材等领域，一直是世界各国优先发展和竞争激烈的重要行业。
　　
　　“JEC世界复合材料展览及会议”（JEC world Composites Show & 
Conferences）创办于1963年，每年举办一届，至2017年总共举办了52届，主办单位是法国JEC复合材料发展促进会/JEC集团，中国总展团展商组织单位为映德国际会展集团中国代表处，在北京、上海等地设有分支机构，负责该展会在中国的推广和招商工作（JEC中国总展团报名热线：4000-680-860转8144、5220）。JEC复合材料展已成为世界上历史最悠久、规模最大的复合材料行业专业展览会，展示和反映了当前复合材料行业的最新技术和应用成果。
　　
　　为了增进国内外复合材料行业的交流与合作，同时展示我国复合材料产业的发展与成就，帮助境内企业开拓国内外市场，中国国际复材协会、映德国际会展集团（YOND 
EXPO）中国代表处已近十年组织中国企业参与该展会，为中国复合材料集团、中材科技、中钢集团、中国建材集团、中国商飞、北京玻钢院、上海杰事杰新材料集团、重庆国际复合材料、中南控股集团、秦皇岛耀华玻璃钢、烟台氨纶、天马集团、华东理工大学、哈尔滨工业大学、巨石集团、中冶集团、金光集团、江苏恒神纤维材料、重庆大学、上海玻璃钢研究院、中南大学、哈尔滨玻璃钢研究院等众多行业巨头和知名机构提供了优质高效的境外展贸服务。
　　
　　“JEC world 2018 
第五十三世界复合材料展览及会议”将于“3月06-08日”在“法国巴黎展览会议中心”再度举行，我们诚邀全国各地复合材料及新材料相关单位与业界人士加入咱们的中国总展团前往参展参观。
　　
　　
　　有关参展参观“JEC世界复合材料展”事宜，请联络【中国总展团】组办方—— 
全国统一客服热线：4000-580-850（转5220、8144、）、010—6923-6944； 邮箱/QQ：12809395#qq.com； 
微信： CanZhanXiaoXi（参展消息）、ZhanShangZhiJia（展商之家）； 
微博：http://weibo.com/jecshow（展会）、http://weibo.com/yingdehuizhan（公司）。
　　
　　参加JEC展会是一个复合材料及新材料企业走向国际化的标志和途径！
　　
　　
　　
　　
__
　　
（百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“TD+JEC”至邮箱1055800...@qq.com）

[PATCH] btrfs: Remove redundant FLAG_VACANCY

[Nikolay Borisov]

Commit 9036c10208e1 ("Btrfs: update hole handling v2") added the FLAG_VACANCY
to denote holes, however there was already a consistent way of flagging
extents which represent hole - ->block_start = EXTENT_MAP_HOLE. And also
the only place where this flag is checked is in the fiemap code, but the
block_start value is also checked and every other place in the filesystem
detects holes by using block_start value's. So remove the extra flag. This
survived a full xfstest run

Signed-off-by: Nikolay Borisov 
---
 fs/btrfs/extent_io.c | 4 +---
 fs/btrfs/extent_map.h| 1 -
 fs/btrfs/inode.c | 1 -
 fs/btrfs/tests/inode-tests.c | 5 -
 include/trace/events/btrfs.h | 1 -
 5 files changed, 1 insertion(+), 11 deletions(-)

diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index e6e4ca225aa9..82ae918a85e0 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -4321,10 +4321,8 @@ static struct extent_map *get_extent_skip_holes(struct 
inode *inode,
return em;
 
/* if this isn't a hole return it */
-   if (!test_bit(EXTENT_FLAG_VACANCY, >flags) &&
-   em->block_start != EXTENT_MAP_HOLE) {
+   if (em->block_start != EXTENT_MAP_HOLE)
return em;
-   }
 
/* this is a hole, advance to the next extent */
offset = extent_map_end(em);
diff --git a/fs/btrfs/extent_map.h b/fs/btrfs/extent_map.h
index a67b2def5413..5bafab76a105 100644
--- a/fs/btrfs/extent_map.h
+++ b/fs/btrfs/extent_map.h
@@ -12,7 +12,6 @@
 /* bits for the flags field */
 #define EXTENT_FLAG_PINNED 0 /* this entry not yet on disk, don't free it */
 #define EXTENT_FLAG_COMPRESSED 1
-#define EXTENT_FLAG_VACANCY 2 /* no file extent item found */
 #define EXTENT_FLAG_PREALLOC 3 /* pre-allocated extent */
 #define EXTENT_FLAG_LOGGING 4 /* Logging this extent */
 #define EXTENT_FLAG_FILLING 5 /* Filling in a preallocated extent */
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 0ed8783a3a88..6450eeabaf4e 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -7117,7 +7117,6 @@ struct extent_map *btrfs_get_extent(struct btrfs_inode 
*inode,
em->len = len;
 not_found_em:
em->block_start = EXTENT_MAP_HOLE;
-   set_bit(EXTENT_FLAG_VACANCY, >flags);
 insert:
btrfs_release_path(path);
if (em->start > start || extent_map_end(em) <= start) {
diff --git a/fs/btrfs/tests/inode-tests.c b/fs/btrfs/tests/inode-tests.c
index 3406c0a84a06..1b910cf0c093 100644
--- a/fs/btrfs/tests/inode-tests.c
+++ b/fs/btrfs/tests/inode-tests.c
@@ -288,10 +288,6 @@ static noinline int test_btrfs_get_extent(u32 sectorsize, 
u32 nodesize)
test_msg("Expected a hole, got %llu\n", em->block_start);
goto out;
}
-   if (!test_bit(EXTENT_FLAG_VACANCY, >flags)) {
-   test_msg("Vacancy flag wasn't set properly\n");
-   goto out;
-   }
free_extent_map(em);
btrfs_drop_extent_cache(BTRFS_I(inode), 0, (u64)-1, 0);
 
@@ -1130,7 +1126,6 @@ int btrfs_test_inodes(u32 sectorsize, u32 nodesize)
int ret;
 
set_bit(EXTENT_FLAG_COMPRESSED, _only);
-   set_bit(EXTENT_FLAG_VACANCY, _only);
set_bit(EXTENT_FLAG_PREALLOC, _only);
 
test_msg("Running btrfs_get_extent tests\n");
diff --git a/include/trace/events/btrfs.h b/include/trace/events/btrfs.h
index 5848ae7845da..36fad4599baf 100644
--- a/include/trace/events/btrfs.h
+++ b/include/trace/events/btrfs.h
@@ -192,7 +192,6 @@ DEFINE_EVENT(btrfs__inode, btrfs_inode_evict,
__print_flags(flag, "|",\
{ (1 << EXTENT_FLAG_PINNED),"PINNED"},\
{ (1 << EXTENT_FLAG_COMPRESSED),"COMPRESSED"},\
-   { (1 << EXTENT_FLAG_VACANCY),   "VACANCY"   },\
{ (1 << EXTENT_FLAG_PREALLOC),  "PREALLOC"  },\
{ (1 << EXTENT_FLAG_LOGGING),   "LOGGING"   },\
{ (1 << EXTENT_FLAG_FILLING),   "FILLING"   },\
-- 
2.7.4

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