Re: [PATCH] Btrfs: recheck bio against block device when we map the bio
On 10/20/2012 05:01 AM, Josef Bacik wrote:
> Alex reported a problem where we were writing between chunks on a rbd
> device. The thing is we do bio_add_page using logical offsets, but the
> physical offset may be different. So when we map the bio now check to see
> if the bio is still ok with the physical offset, and if it is not split the
> bio up and redo the bio_add_page with the physical sector. This fixes the
> problem for Alex and doesn't affect performance in the normal case. Thanks,
>
> Reported-and-tested-by: Alex Elder
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/volumes.c | 159 ++-
> 1 files changed, 131 insertions(+), 28 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index a8adf26..eaaf0bf 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -4217,6 +4217,113 @@ static noinline void schedule_bio(struct btrfs_root
> *root,
> &device->work);
> }
>
> +static int bio_size_ok(struct block_device *bdev, struct bio *bio,
> +sector_t sector)
> +{
> + struct bio_vec *prev;
> + struct request_queue *q = bdev_get_queue(bdev);
> + unsigned short max_sectors = queue_max_sectors(q);
> + struct bvec_merge_data bvm = {
> + .bi_bdev = bdev,
> + .bi_sector = sector,
> + .bi_rw = bio->bi_rw,
> + };
> +
> + if (bio->bi_vcnt == 0) {
> + WARN_ON(1);
> + return 1;
> + }
> +
> + prev = &bio->bi_io_vec[bio->bi_vcnt - 1];
I prefer 'last' for this.
Others look good to me :)
Reviewed-by: Liu Bo
thanks,
liubo
> + if ((bio->bi_size >> 9) > max_sectors)
> + return 0;
> +
> + if (!q->merge_bvec_fn)
> + return 1;
> +
> + bvm.bi_size = bio->bi_size - prev->bv_len;
> + if (q->merge_bvec_fn(q, &bvm, prev) < prev->bv_len)
> + return 0;
> + return 1;
> +}
> +
> +static void submit_stripe_bio(struct btrfs_root *root, struct btrfs_bio
> *bbio,
> + struct bio *bio, u64 physical, int dev_nr,
> + int rw, int async)
> +{
> + struct btrfs_device *dev = bbio->stripes[dev_nr].dev;
> +
> + bio->bi_private = bbio;
> + bio->bi_private = merge_stripe_index_into_bio_private(
> + bio->bi_private, (unsigned int)dev_nr);
> + bio->bi_end_io = btrfs_end_bio;
> + bio->bi_sector = physical >> 9;
> +#ifdef DEBUG
> + {
> + struct rcu_string *name;
> +
> + rcu_read_lock();
> + name = rcu_dereference(dev->name);
> + pr_debug("btrfs_map_bio: rw %d, secor=%llu, dev=%lu "
> + "(%s id %llu), size=%u\n", rw,
> + (u64)bio->bi_sector, (u_long)dev->bdev->bd_dev,
> + name->str, dev->devid, bio->bi_size);
> + rcu_read_unlock();
> + }
> +#endif
> + bio->bi_bdev = dev->bdev;
> + if (async)
> + schedule_bio(root, dev, rw, bio);
> + else
> + btrfsic_submit_bio(rw, bio);
> +}
> +
> +static int breakup_stripe_bio(struct btrfs_root *root, struct btrfs_bio
> *bbio,
> + struct bio *first_bio, struct btrfs_device *dev,
> + int dev_nr, int rw, int async)
> +{
> + struct bio_vec *bvec = first_bio->bi_io_vec;
> + struct bio *bio;
> + int nr_vecs = bio_get_nr_vecs(dev->bdev);
> + u64 physical = bbio->stripes[dev_nr].physical;
> +
> +again:
> + bio = btrfs_bio_alloc(dev->bdev, physical >> 9, nr_vecs, GFP_NOFS);
> + if (!bio)
> + return -ENOMEM;
> +
> + while (bvec <= (first_bio->bi_io_vec + first_bio->bi_vcnt - 1)) {
> + if (bio_add_page(bio, bvec->bv_page, bvec->bv_len,
> + bvec->bv_offset) < bvec->bv_len) {
> + u64 len = bio->bi_size;
> +
> + atomic_inc(&bbio->stripes_pending);
> + submit_stripe_bio(root, bbio, bio, physical, dev_nr,
> + rw, async);
> + physical += len;
> + goto again;
> + }
> + bvec++;
> + }
> +
> + submit_stripe_bio(root, bbio, bio, physical, dev_nr, rw, async);
> + return 0;
> +}
> +
> +static void bbio_error(struct btrfs_bio *bbio, struct bio *bio, u64 logical)
> +{
> + atomic_inc(&bbio->error);
> + if (atomic_dec_and_test(&bbio->stripes_pending)) {
> + bio->bi_private = bbio->private;
> + bio->bi_end_io = bbio->end_io;
> + bio->bi_bdev = (struct block_device *)
> + (unsigned long)bbio->mirror_num;
> + bio->bi_sector = logical >> 9;
> + kfree(bbio);
> + bio_endio(bio, -EIO);
> + }
> +}
> +
> int btrfs_map_bio(struct btrfs_root *root, int rw, struct bio *bio,
> int mirror_num, in
Re: Weird Warning
On Fri, Oct 19, 2012 at 3:51 PM, Jérôme Poulin wrote: > After updating to 3.5.5, I get thi on boot and listing some dir freezes. > I don't have anything important on that volume but I'm willing to > debug the problem if needed. Would I need a more recent kernel? Probably worth trying 3.7-rc1, or at least cmason's for-linus (which is 3.6.0 + the btrfs changes that went into 3.7). -- 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: Weird Warning
After updating to 3.5.5, I get thi on boot and listing some dir freezes. I don't have anything important on that volume but I'm willing to debug the problem if needed. Would I need a more recent kernel? [ 128.574596] [ cut here ] [ 128.574652] kernel BUG at /home/blank/debian/kernel/release/linux/linux-3.5.5/fs/btrfs/extent-tree.c:1516! [ 128.574715] invalid opcode: [#1] SMP [ 128.574853] CPU 3 [ 128.574901] Modules linked in: nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc loop coretemp snd_pcm kvm_intel snd_page_alloc snd_timer kvm snd crc32c_intel soundcore iTCO_wdt iTCO_vendor_support microcode dcdbas i7core_edac pcspkr lpc_ich mfd_core edac_core evdev button acpi_power_meter processor thermal_sys ext4 crc16 jbd2 mbcache btrfs crc32c libcrc32c zlib_deflate raid456 async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 ohci_hcd uhci_hcd sd_mod crc_t10dif dm_mod md_mod hid_generic usbhid hid sg sr_mod cdrom ehci_hcd ahci libahci mpt2sas raid_class scsi_transport_sas bnx2 usbcore usb_common libata scsi_mod igb dca [last unloaded: scsi_wait_scan] [ 128.578404] [ 128.578449] Pid: 1995, comm: btrfs-transacti Not tainted 3.5-trunk-amd64 #1 Debian 3.5.5-1~experimental.1 Dell Inc. PowerEdge R310/05XKKK [ 128.578647] RIP: 0010:[] [] lookup_inline_extent_backref+0x17e/0x377 [btrfs] [ 128.578766] RSP: 0018:880138c8d9b0 EFLAGS: 00010246 [ 128.578820] RAX: 0020 RBX: 880134878880 RCX: 2f7c [ 128.578890] RDX: 2ee2 RSI: 2f57 RDI: 88013ae309c8 [ 128.578961] RBP: 2f5f R08: R09: 880138c8d970 [ 128.579031] R10: 0008 R11: 0002 R12: 88013ae309c8 [ 128.579101] R13: 00b2 R14: 0035 R15: [ 128.579172] FS: () GS:88013f26() knlGS: [ 128.579258] CS: 0010 DS: ES: CR0: 8005003b [ 128.579326] CR2: 02139108 CR3: 0160b000 CR4: 07e0 [ 128.579397] DR0: DR1: DR2: [ 128.579467] DR3: DR6: 0ff0 DR7: 0400 [ 128.579538] Process btrfs-transacti (pid: 1995, threadinfo 880138c8c000, task 880138e76800) [ 128.579625] Stack: [ 128.579686] 2ee2 2f47 8801348495a0 0035005e [ 128.579947] 3ae309c8 8801394fd400 2f7c 12f22000 [ 128.580249] a800c2b0 880138c8dae8 88013592c500 8050 [ 128.580509] Call Trace: [ 128.580581] [] ? __btrfs_free_extent+0xc6/0x5bd [btrfs] [ 128.580659] [] ? alloc_reserved_file_extent+0x1e5/0x215 [btrfs] [ 128.580753] [] ? run_clustered_refs+0x6f0/0x77d [btrfs] [ 128.580832] [] ? run_clustered_refs+0x6df/0x77d [btrfs] [ 128.580917] [] ? btrfs_set_token_inode_flags+0x70/0xbe [btrfs] [ 128.581004] [] ? __set_page_dirty_nobuffers+0x16/0xd8 [ 128.581083] [] ? btrfs_run_delayed_refs+0x20a/0x302 [btrfs] [ 128.581177] [] ? btrfs_write_dirty_block_groups+0x2a9/0x497 [btrfs] [ 128.581269] [] ? commit_cowonly_roots+0x107/0x1cd [btrfs] [ 128.581342] [] ? should_resched+0x5/0x23 [ 128.581421] [] ? btrfs_commit_transaction+0x429/0x8ae [btrfs] [ 128.581508] [] ? add_wait_queue+0x3c/0x3c [ 128.581587] [] ? start_transaction+0x256/0x2ae [btrfs] [ 128.581659] [] ? usleep_range+0x3e/0x3e [ 128.581728] [] ? should_resched+0x5/0x23 [ 128.581806] [] ? transaction_kthread+0x15e/0x21b [btrfs] [ 128.581878] [] ? __schedule+0x4c6/0x4e0 [ 128.581956] [] ? try_to_freeze+0x2e/0x2e [btrfs] [ 128.582035] [] ? try_to_freeze+0x2e/0x2e [btrfs] [ 128.582106] [] ? kthread+0x67/0x6f [ 128.582174] [] ? kernel_thread_helper+0x4/0x10 [ 128.582245] [] ? kthread_freezable_should_stop+0x3c/0x3c [ 128.582316] [] ? gs_change+0x13/0x13 [ 128.582383] Code: 48 8b 4c 24 08 48 8b 14 24 4c 01 f1 a8 02 48 8d 6a 7d 48 89 4c 24 30 74 0e 48 8d aa 8f 00 00 00 48 39 cd 76 08 0f 0b a8 01 75 02 <0f> 0b 48 3b 6c 24 30 72 22 41 bc fe ff ff ff 0f 86 42 01 00 00 [ 128.585347] RIP [] lookup_inline_extent_backref+0x17e/0x377 [btrfs] [ 128.585484] RSP [ 128.585561] ---[ end trace 5b4742b10c0f008c ]--- On Fri, Oct 19, 2012 at 4:58 PM, cwillu wrote: > On Fri, Oct 19, 2012 at 2:54 PM, Jérôme Poulin wrote: >> I've got this weird WARNING in my system log on a freshly created FS, >> I'm using ACL with Samba, this is the only difference I could tell >> from any other FSes. It is also using Debian's Wheezy kernel which is >> quite old. Should I just ignore this or update BTRFS module? > > I would strongly recommend updating, even if you hadn't seen any warnings. -- 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: Weird Warning
On Fri, Oct 19, 2012 at 2:54 PM, Jérôme Poulin wrote: > I've got this weird WARNING in my system log on a freshly created FS, > I'm using ACL with Samba, this is the only difference I could tell > from any other FSes. It is also using Debian's Wheezy kernel which is > quite old. Should I just ignore this or update BTRFS module? I would strongly recommend updating, even if you hadn't seen any warnings. -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 1:02 PM, Marguerite Su wrote: > On Sat, Oct 20, 2012 at 2:35 AM, cwillu wrote: >> Without space_cache (once), btrfs has to repopulate that information >> the slow way every mount; with it, it can just load the data from the >> last unmount (modulo some consistency checks). >> >> The setting is sticky, so you don't actually need it in fstab any more >> (although it won't hurt anything either). > > Thanks, cwillu! > > I transfer the message to openSUSE bugzilla and ask them help making > that happen by default in openSUSE. > > Marguerite Apparently mkfs.btrfs does set it by default now, so perhaps your filesystem predates the change, or suse's btrfs-progs is too old. mkfs.btrfs /dev/whatever followed by mounting with no options should print "btrfs: disk space caching is enabled" to dmesg if your mkfs is new enough, if you wish to test. -- 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: recheck bio against block device when we map the bio
Alex reported a problem where we were writing between chunks on a rbd
device. The thing is we do bio_add_page using logical offsets, but the
physical offset may be different. So when we map the bio now check to see
if the bio is still ok with the physical offset, and if it is not split the
bio up and redo the bio_add_page with the physical sector. This fixes the
problem for Alex and doesn't affect performance in the normal case. Thanks,
Reported-and-tested-by: Alex Elder
Signed-off-by: Josef Bacik
---
fs/btrfs/volumes.c | 159 ++-
1 files changed, 131 insertions(+), 28 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index a8adf26..eaaf0bf 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4217,6 +4217,113 @@ static noinline void schedule_bio(struct btrfs_root
*root,
&device->work);
}
+static int bio_size_ok(struct block_device *bdev, struct bio *bio,
+ sector_t sector)
+{
+ struct bio_vec *prev;
+ struct request_queue *q = bdev_get_queue(bdev);
+ unsigned short max_sectors = queue_max_sectors(q);
+ struct bvec_merge_data bvm = {
+ .bi_bdev = bdev,
+ .bi_sector = sector,
+ .bi_rw = bio->bi_rw,
+ };
+
+ if (bio->bi_vcnt == 0) {
+ WARN_ON(1);
+ return 1;
+ }
+
+ prev = &bio->bi_io_vec[bio->bi_vcnt - 1];
+ if ((bio->bi_size >> 9) > max_sectors)
+ return 0;
+
+ if (!q->merge_bvec_fn)
+ return 1;
+
+ bvm.bi_size = bio->bi_size - prev->bv_len;
+ if (q->merge_bvec_fn(q, &bvm, prev) < prev->bv_len)
+ return 0;
+ return 1;
+}
+
+static void submit_stripe_bio(struct btrfs_root *root, struct btrfs_bio *bbio,
+ struct bio *bio, u64 physical, int dev_nr,
+ int rw, int async)
+{
+ struct btrfs_device *dev = bbio->stripes[dev_nr].dev;
+
+ bio->bi_private = bbio;
+ bio->bi_private = merge_stripe_index_into_bio_private(
+ bio->bi_private, (unsigned int)dev_nr);
+ bio->bi_end_io = btrfs_end_bio;
+ bio->bi_sector = physical >> 9;
+#ifdef DEBUG
+ {
+ struct rcu_string *name;
+
+ rcu_read_lock();
+ name = rcu_dereference(dev->name);
+ pr_debug("btrfs_map_bio: rw %d, secor=%llu, dev=%lu "
+"(%s id %llu), size=%u\n", rw,
+(u64)bio->bi_sector, (u_long)dev->bdev->bd_dev,
+name->str, dev->devid, bio->bi_size);
+ rcu_read_unlock();
+ }
+#endif
+ bio->bi_bdev = dev->bdev;
+ if (async)
+ schedule_bio(root, dev, rw, bio);
+ else
+ btrfsic_submit_bio(rw, bio);
+}
+
+static int breakup_stripe_bio(struct btrfs_root *root, struct btrfs_bio *bbio,
+ struct bio *first_bio, struct btrfs_device *dev,
+ int dev_nr, int rw, int async)
+{
+ struct bio_vec *bvec = first_bio->bi_io_vec;
+ struct bio *bio;
+ int nr_vecs = bio_get_nr_vecs(dev->bdev);
+ u64 physical = bbio->stripes[dev_nr].physical;
+
+again:
+ bio = btrfs_bio_alloc(dev->bdev, physical >> 9, nr_vecs, GFP_NOFS);
+ if (!bio)
+ return -ENOMEM;
+
+ while (bvec <= (first_bio->bi_io_vec + first_bio->bi_vcnt - 1)) {
+ if (bio_add_page(bio, bvec->bv_page, bvec->bv_len,
+bvec->bv_offset) < bvec->bv_len) {
+ u64 len = bio->bi_size;
+
+ atomic_inc(&bbio->stripes_pending);
+ submit_stripe_bio(root, bbio, bio, physical, dev_nr,
+ rw, async);
+ physical += len;
+ goto again;
+ }
+ bvec++;
+ }
+
+ submit_stripe_bio(root, bbio, bio, physical, dev_nr, rw, async);
+ return 0;
+}
+
+static void bbio_error(struct btrfs_bio *bbio, struct bio *bio, u64 logical)
+{
+ atomic_inc(&bbio->error);
+ if (atomic_dec_and_test(&bbio->stripes_pending)) {
+ bio->bi_private = bbio->private;
+ bio->bi_end_io = bbio->end_io;
+ bio->bi_bdev = (struct block_device *)
+ (unsigned long)bbio->mirror_num;
+ bio->bi_sector = logical >> 9;
+ kfree(bbio);
+ bio_endio(bio, -EIO);
+ }
+}
+
int btrfs_map_bio(struct btrfs_root *root, int rw, struct bio *bio,
int mirror_num, int async_submit)
{
@@ -4255,40 +4362,36 @@ int btrfs_map_bio(struct btrfs_root *root, int rw,
struct bio *bio,
atomic_set(&bbio->stripes_pending, bbio->num_stripes);
while (dev_nr < total_devs) {
+ dev = bbio->s
[PATCH] Fits: tool to hash a filesystem into a single sum
The tool can also generate a manifest file. Given the manifest file, it
can determine which files are missing or in excess, and inform about
metadata / data checksum mismatches.
It builds for linux and solaris.
Signed-off-by: Arne Jansen
---
It can also be found at
git://git.kernel.org/pub/scm/linux/kernel/git/arne/fits-progs.git
---
Makefile | 12 +-
fssum.c | 638 ++
2 files changed, 649 insertions(+), 1 deletions(-)
create mode 100644 fssum.c
diff --git a/Makefile b/Makefile
index 1c56476..5584f07 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,14 @@
-all: fitsparse
+OS = $(shell uname -s)
+ifeq "$(OS)" "Linux"
+CFLAGS = -D__LINUX__
+else
+CFLAGS = -D__SOLARIS__
+endif
+
+all: fitsparse fssum
fitsparse: fitsparse.c
gcc -Wall fitsparse.c -o fitsparse
+
+fssum: fssum.c
+ gcc -Wall $(CFLAGS) fssum.c -o fssum -lssl -lcrypto
diff --git a/fssum.c b/fssum.c
new file mode 100644
index 000..491baef
--- /dev/null
+++ b/fssum.c
@@ -0,0 +1,638 @@
+/*
+ * Copyright (C) 2012 STRATO AG. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+#ifdef __LINUX__
+#define _BSD_SOURCE
+#define _LARGEFILE64_SOURCE
+#endif
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#ifdef __SOLARIS__
+#include
+#endif
+#include
+#include
+#include
+
+#define CS_SIZE 16
+#define CHUNKS 128
+
+#ifdef __LINUX__
+#if __BYTE_ORDER == __LITTLE_ENDIAN
+#define htonll(x) __bswap_64 (x)
+#endif
+#endif
+
+/* TODO: add hardlink recognition */
+/* TODO: add xattr/acl */
+
+int gen_manifest = 0;
+int in_manifest = 0;
+char *checksum = NULL;
+FILE *out_fp;
+FILE *in_fp;
+
+enum _flags {
+ FLAG_UID,
+ FLAG_GID,
+ FLAG_MODE,
+ FLAG_ATIME,
+ FLAG_MTIME,
+ FLAG_CTIME,
+ FLAG_DATA,
+ NUM_FLAGS
+};
+
+const char flchar[] = "ugoamcd";
+char line[65536];
+
+int flags[NUM_FLAGS] = { 1, 1, 1, 1, 1, 0, 1 };
+
+char *
+getln(char *buf, int size, FILE *fp)
+{
+ char *p;
+ int l;
+
+ p = fgets(buf, size, fp);
+ if (!p)
+ return NULL;
+
+ l = strlen(p);
+ while(l > 0 && (p[l - 1] == '\n' || p[l - 1] == '\r'))
+ p[--l] = 0;
+
+ return p;
+}
+
+void
+parse_flag(int c)
+{
+ int i;
+ int is_upper = 0;
+
+ if (c >= 'A' && c <= 'Z') {
+ is_upper = 1;
+ c += 'a' - 'A';
+ }
+ for (i = 0; flchar[i]; ++i) {
+ if (flchar[i] == c) {
+ flags[i] = is_upper ? 0 : 1;
+ return;
+ }
+ }
+ fprintf(stderr, "unrecognized flag %c\n", c);
+ exit(-1);
+}
+
+void
+parse_flags(char *p)
+{
+ while (*p)
+ parse_flag(*p++);
+}
+
+void
+usage(void)
+{
+ fprintf(stderr, "usage: fssum \n");
+ fprintf(stderr, " options:\n");
+ fprintf(stderr, "-f : write out a full manifest file\n");
+ fprintf(stderr, "-w: send output to file\n");
+ fprintf(stderr,
+ "-r: read checksum or manifest from file\n");
+ fprintf(stderr, "-[ugoamcd] : specify which fields to include in
checksum calculation.\n");
+ fprintf(stderr, " u : include uid\n");
+ fprintf(stderr, " g : include gid\n");
+ fprintf(stderr, " o : include mode\n");
+ fprintf(stderr, " m : include mtime\n");
+ fprintf(stderr, " a : include atime\n");
+ fprintf(stderr, " c : include ctime\n");
+ fprintf(stderr, " d : include file data\n");
+ fprintf(stderr, "-[UGOAMCD] : exclude respective field from
calculation\n");
+ fprintf(stderr, "-n : reset all flags\n");
+ fprintf(stderr, "-N : set all flags\n");
+ fprintf(stderr, "-h : this help\n\n");
+ fprintf(stderr, "The default field mask is ugoamCd. If the
checksum/manifest is read from a\n");
+ fprintf(stderr, "file, the mask is taken from there and the values
given on the command line\n");
+ fprintf(stderr, "are ignored.\n");
+ exit(-1);
+}
+
+static char buf[65536];
+
+typedef struct _sum {
+ MD5_CTX md5;
+ unsigned char
Re: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 2:35 AM, cwillu wrote: > Without space_cache (once), btrfs has to repopulate that information > the slow way every mount; with it, it can just load the data from the > last unmount (modulo some consistency checks). > > The setting is sticky, so you don't actually need it in fstab any more > (although it won't hurt anything either). Thanks, cwillu! I transfer the message to openSUSE bugzilla and ask them help making that happen by default in openSUSE. Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 12:33 PM, Marguerite Su wrote: > On Sat, Oct 20, 2012 at 2:26 AM, cwillu wrote: >> That would work, but it's only necessary to mount with it once (and >> it's probably been done already with /home), hence the -o >> remount,space_cache > > Now my kernel loads in 10s, another 4s for userspace...then -.mount > and all the systemd services. > > It boots like an animal! Without space_cache (once), btrfs has to repopulate that information the slow way every mount; with it, it can just load the data from the last unmount (modulo some consistency checks). The setting is sticky, so you don't actually need it in fstab any more (although it won't hurt anything either). -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 2:26 AM, cwillu wrote: > That would work, but it's only necessary to mount with it once (and > it's probably been done already with /home), hence the -o > remount,space_cache Now my kernel loads in 10s, another 4s for userspace...then -.mount and all the systemd services. It boots like an animal! -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 12:55 AM, cwillu wrote: > It appears space_cache isn't enabled on your rootfs; can you do a > "mount / -o remount,space_cache", sync a couple times, make some > coffee, and then reboot, and see if it's better? > > You should see two instances of "btrfs: disk space caching is enabled" > in your dmesg, one for / and the second for /home. > > Also, make sure to reply-all so that others interested can still follow along. Marvelous! cwillu, you're the most brilliant man I've ever seen in this world! I can't find a most suitable word to say thank you! You saved my life! I mean, 1 year and a half's struggling now comes to an end! Hu! Can you tell me what my problem actually is? do you or do I need a patch of something added to the code base? I mean, I'm an openSUSE Memeber, our distro didn't have my: default,space_cache,comment="systemd.automount" and 0 1 set by default, actually it was: default 0 2 so is there anything I can do to make this happiness come to everyone in my distribution? Hug againnn! Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 11:02 AM, Marguerite Su wrote: > On Sat, Oct 20, 2012 at 12:55 AM, cwillu wrote: >> It appears space_cache isn't enabled on your rootfs; can you do a >> "mount / -o remount,space_cache", sync a couple times, make some >> coffee, and then reboot, and see if it's better? >> >> You should see two instances of "btrfs: disk space caching is enabled" >> in your dmesg, one for / and the second for /home. >> >> Also, make sure to reply-all so that others interested can still follow >> along. > > like this > > UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e /btrfs >defaults,space_cache,comment=systemd.automount 1 0 > > UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /homebtrfs > defaults,space_cache,comment=systemd.automount 1 0 > > in /etc/fstab? That would work, but it's only necessary to mount with it once (and it's probably been done already with /home), hence the -o remount,space_cache -- 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: initramfs take a long time to load[135s]
On Sat, Oct 20, 2012 at 12:55 AM, cwillu wrote: > It appears space_cache isn't enabled on your rootfs; can you do a > "mount / -o remount,space_cache", sync a couple times, make some > coffee, and then reboot, and see if it's better? > > You should see two instances of "btrfs: disk space caching is enabled" > in your dmesg, one for / and the second for /home. > > Also, make sure to reply-all so that others interested can still follow along. like this UUID=9b9aa9d9-760e-445c-a0ab-68e102d9f02e /btrfs defaults,space_cache,comment=systemd.automount 1 0 UUID=559dec06-4fd0-47c1-97b8-cc4fa6153fa0 /homebtrfs defaults,space_cache,comment=systemd.automount 1 0 in /etc/fstab? Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 10:18 AM, Marguerite Su wrote: > On Fri, Oct 19, 2012 at 11:41 PM, cwillu wrote: >> Also, next time just put the output directly in the email, that way >> it's permanently around to look at and search for. > > Hi, > > I did it. here's my dmesg: > I made the snapshot at: > > mount -o rw,defaults,comment=systemd.automount -t btrfs /dev/root /root > > and > > Starting Tell Plymouth To Write Out Runtime Data... > Started Recreate Volatile Files and Directories > > > is it useful this time? More useful every time! Can you post the full output of dmesg, or at least the first couple hundred seconds of it? -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 11:41 PM, cwillu wrote: > Also, next time just put the output directly in the email, that way > it's permanently around to look at and search for. Hi, I did it. here's my dmesg: [ 25.623660] SysRq : Show Blocked State [ 25.623667] taskPC stack pid father [ 25.623682] btrfs-cache-1 D 81608240 0 223 2 0x [ 25.623687] 880036b09a70 0046 00d7 880036b09fd8 [ 25.623691] 0008 880036b09fd8 880036b09fd8 880036b09fd8 [ 25.623695] 81c13420 880036a56840 8800bec13b20 [ 25.623699] Call Trace: [ 25.623713] [] io_schedule+0x8a/0xd0 [ 25.623720] [] sleep_on_page+0x9/0x10 [ 25.623725] [] __wait_on_bit+0x4f/0x80 [ 25.623730] [] wait_on_page_bit+0x6f/0x80 [ 25.623757] [] read_extent_buffer_pages+0x265/0x340 [btrfs] [ 25.623844] [] btree_read_extent_buffer_pages.constprop.119+0xae/0x110 [btrfs] [ 25.623889] [] read_tree_block+0x33/0x50 [btrfs] [ 25.623932] [] read_block_for_search.isra.48+0x165/0x420 [btrfs] [ 25.623957] [] btrfs_next_old_leaf+0x29d/0x4a0 [btrfs] [ 25.623984] [] caching_thread+0x1f2/0x3c0 [btrfs] [ 25.624018] [] worker_loop+0x153/0x560 [btrfs] [ 25.624087] [] kthread+0x85/0x90 [ 25.624093] [] kernel_thread_helper+0x4/0x10 [ 25.624097] mount D 81608240 0 232 1 0x [ 25.624100] 880036ff37a0 0086 81077798 880036ff3fd8 [ 25.624104] 81080557 880036ff3fd8 880036ff3fd8 880036ff3fd8 [ 25.624107] 81c13420 8800b6f4e600 8107380b 8800b6f4e600 [ 25.624111] Call Trace: [ 25.624116] [] rwsem_down_failed_common+0xc5/0x160 [ 25.624122] [] call_rwsem_down_write_failed+0x13/0x20 [ 25.624126] [] down_write+0x1c/0x1d [ 25.624138] [] cache_block_group.isra.44+0x241/0x380 [btrfs] [ 25.624167] [] find_free_extent+0xaea/0xbb0 [btrfs] [ 25.624200] [] btrfs_reserve_extent+0x97/0x1d0 [btrfs] [ 25.624235] [] btrfs_alloc_free_block+0xe2/0x3c0 [btrfs] [ 25.624269] [] __btrfs_cow_block+0x137/0x570 [btrfs] [ 25.624291] [] btrfs_cow_block+0xff/0x250 [btrfs] [ 25.624313] [] btrfs_search_slot+0x429/0x990 [btrfs] [ 25.624340] [] btrfs_lookup_inode+0x25/0xa0 [btrfs] [ 25.624384] [] btrfs_update_delayed_inode+0x76/0x160 [btrfs] [ 25.624484] [] __btrfs_run_delayed_items+0x13e/0x1a0 [btrfs] [ 25.624584] [] btrfs_commit_transaction+0x3b7/0xb40 [btrfs] [ 25.624625] [] __sync_filesystem+0x30/0x60 [ 25.624631] [] __do_remount_sb+0x5b/0x1a0 [ 25.624636] [] do_remount+0xfa/0x160 [ 25.624641] [] do_mount+0x20a/0x260 [ 25.624646] [] sys_mount+0x9a/0xf0 [ 25.624649] [] system_call_fastpath+0x16/0x1b [ 25.624649] [<7f91f7141a3a>] 0x7f91f7141a39 [ 25.624649] Sched Debug Version: v0.10, 3.6.2-2-desktop #1 [ 25.624649] ktime : 25624.659099 [ 25.624649] sched_clk : 7064.337499 [ 25.624649] cpu_clk : 25624.649041 [ 25.624649] jiffies : 4294692919 [ 25.624649] sched_clock_stable : 0 [ 25.624649] [ 25.624649] sysctl_sched [ 25.624649] .sysctl_sched_latency: 12.00 [ 25.624649] .sysctl_sched_min_granularity: 1.50 [ 25.624649] .sysctl_sched_wakeup_granularity : 2.00 [ 25.624649] .sysctl_sched_child_runs_first : 0 [ 25.624649] .sysctl_sched_features : 24119 [ 25.624649] .sysctl_sched_tunable_scaling: 1 (logaritmic) [ 25.624649] [ 25.624649] cpu#0, 1795.416 MHz [ 25.624649] .nr_running: 0 [ 25.624649] .load : 0 [ 25.624649] .nr_switches : 15640 [ 25.624649] .nr_load_updates : 6257 [ 25.624649] .nr_uninterruptible: -3 [ 25.624649] .next_balance : 4294.692918 [ 25.624649] .curr->pid : 0 [ 25.624649] .clock : 25618.786824 [ 25.624649] .cpu_load[0] : 0 [ 25.624649] .cpu_load[1] : 0 [ 25.624649] .cpu_load[2] : 0 [ 25.624649] .cpu_load[3] : 0 [ 25.624649] .cpu_load[4] : 0 [ 25.624649] .yld_count : 0 [ 25.624649] .sched_count : 17355 [ 25.624649] .sched_goidle : 6154 [ 25.624649] .avg_idle : 898778 [ 25.624649] .ttwu_count: 7843 [ 25.624649] .ttwu_local: 6132 [ 25.624649] [ 25.624649] cfs_rq[0]:/ [ 25.624649] .exec_clock: 1882.913755 [ 25.624649] .MIN_vruntime : 0.01 [ 25.624649] .min_vruntime
Re: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 11:41 PM, cwillu wrote: > You need to hit alt-sysrq-w during the slowness you're trying to > instrument; the pastebin is from an hour later. > > Also, next time just put the output directly in the email, that way > it's permanently around to look at and search for. Thanks for teaching me the rules, cwillu! I'll do it right now! Marguerite -- 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: initramfs take a long time to load[135s]
On Fri, Oct 19, 2012 at 9:28 AM, Marguerite Su wrote: > On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason wrote: >> If it isn't the free space cache, it'll be a fragmentation problem. The >> easiest way to tell the difference is to get a few sysrq-w snapshots >> during the boot. > > Hi, Chris, > > with some help from openSUSE community, I learnt what's sysrq > snapshots(alt+printscreen+w in tty1)... > > and here's my log: > > http://paste.opensuse.org/31094916 You need to hit alt-sysrq-w during the slowness you're trying to instrument; the pastebin is from an hour later. Also, next time just put the output directly in the email, that way it's permanently around to look at and search for. -- 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: initramfs take a long time to load[135s]
On Thu, Oct 18, 2012 at 9:28 PM, Chris Mason wrote: > If it isn't the free space cache, it'll be a fragmentation problem. The > easiest way to tell the difference is to get a few sysrq-w snapshots > during the boot. Hi, Chris, with some help from openSUSE community, I learnt what's sysrq snapshots(alt+printscreen+w in tty1)... and here's my log: http://paste.opensuse.org/31094916 can you help look through this? Many thanks! Marguerite -- 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 V2 4/4] Btrfs: cleanup unused arguments
'disk_key' is not used at all.
Signed-off-by: Liu Bo
---
v1->v2: update the functions' caller.
fs/btrfs/ctree.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 235831f..a794c6f 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -772,8 +772,7 @@ tree_mod_log_eb_move(struct btrfs_fs_info *fs_info, struct
extent_buffer *dst,
static noinline void
tree_mod_log_set_node_key(struct btrfs_fs_info *fs_info,
- struct extent_buffer *eb,
- struct btrfs_disk_key *disk_key, int slot, int atomic)
+ struct extent_buffer *eb, int slot, int atomic)
{
int ret;
@@ -1797,7 +1796,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
struct btrfs_disk_key right_key;
btrfs_node_key(right, &right_key, 0);
tree_mod_log_set_node_key(root->fs_info, parent,
- &right_key, pslot + 1, 0);
+ pslot + 1, 0);
btrfs_set_node_key(parent, &right_key, pslot + 1);
btrfs_mark_buffer_dirty(parent);
}
@@ -1841,7 +1840,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
/* update the parent key to reflect our changes */
struct btrfs_disk_key mid_key;
btrfs_node_key(mid, &mid_key, 0);
- tree_mod_log_set_node_key(root->fs_info, parent, &mid_key,
+ tree_mod_log_set_node_key(root->fs_info, parent,
pslot, 0);
btrfs_set_node_key(parent, &mid_key, pslot);
btrfs_mark_buffer_dirty(parent);
@@ -1941,7 +1940,7 @@ static noinline int push_nodes_for_insert(struct
btrfs_trans_handle *trans,
orig_slot += left_nr;
btrfs_node_key(mid, &disk_key, 0);
tree_mod_log_set_node_key(root->fs_info, parent,
- &disk_key, pslot, 0);
+ pslot, 0);
btrfs_set_node_key(parent, &disk_key, pslot);
btrfs_mark_buffer_dirty(parent);
if (btrfs_header_nritems(left) > orig_slot) {
@@ -1994,7 +1993,7 @@ static noinline int push_nodes_for_insert(struct
btrfs_trans_handle *trans,
btrfs_node_key(right, &disk_key, 0);
tree_mod_log_set_node_key(root->fs_info, parent,
- &disk_key, pslot + 1, 0);
+ pslot + 1, 0);
btrfs_set_node_key(parent, &disk_key, pslot + 1);
btrfs_mark_buffer_dirty(parent);
@@ -2878,7 +2877,7 @@ static void fixup_low_keys(struct btrfs_trans_handle
*trans,
if (!path->nodes[i])
break;
t = path->nodes[i];
- tree_mod_log_set_node_key(root->fs_info, t, key, tslot, 1);
+ tree_mod_log_set_node_key(root->fs_info, t, tslot, 1);
btrfs_set_node_key(t, key, tslot);
btrfs_mark_buffer_dirty(path->nodes[i]);
if (tslot != 0)
--
1.7.7.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: [PATCH 4/4] Btrfs: cleanup unused arguments
On 10/19/2012 08:14 PM, Jan Schmidt wrote: > Hi liubo, > > Patches 3 and 4 are looking good. I'm still trying to sort out on the other > two, > as I cannot reproduce your bug with your script, unfortunately. > > After applying all 4 patches, the result doesn't compile, here: > > fs/btrfs/ctree.c: In function 'balance_level': > fs/btrfs/ctree.c:1799: warning: passing argument 3 of > 'tree_mod_log_set_node_key' makes integer from pointer without a cast > fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct > btrfs_disk_key *' > fs/btrfs/ctree.c:1799: error: too many arguments to function > 'tree_mod_log_set_node_key' > fs/btrfs/ctree.c:1844: warning: passing argument 3 of > 'tree_mod_log_set_node_key' makes integer from pointer without a cast > fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct > btrfs_disk_key *' > fs/btrfs/ctree.c:1844: error: too many arguments to function > 'tree_mod_log_set_node_key' > fs/btrfs/ctree.c: In function 'push_nodes_for_insert': > fs/btrfs/ctree.c:1943: warning: passing argument 3 of > 'tree_mod_log_set_node_key' makes integer from pointer without a cast > fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct > btrfs_disk_key *' > fs/btrfs/ctree.c:1943: error: too many arguments to function > 'tree_mod_log_set_node_key' > fs/btrfs/ctree.c:1996: warning: passing argument 3 of > 'tree_mod_log_set_node_key' makes integer from pointer without a cast > fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct > btrfs_disk_key *' > fs/btrfs/ctree.c:1996: error: too many arguments to function > 'tree_mod_log_set_node_key' > fs/btrfs/ctree.c: In function 'fixup_low_keys': > fs/btrfs/ctree.c:2880: warning: passing argument 3 of > 'tree_mod_log_set_node_key' makes integer from pointer without a cast > fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct > btrfs_disk_key *' > fs/btrfs/ctree.c:2880: error: too many arguments to function > 'tree_mod_log_set_node_key' > CC [M] fs/btrfs/sysfs.o > make[2]: *** [fs/btrfs/ctree.o] Error 1 > make[2]: *** Waiting for unfinished jobs > make[1]: *** [fs/btrfs] Error 2 > make[1]: *** Waiting for unfinished jobs > make: *** [fs] Error 2 > oh, I'm so sorry, I forgot to format new patches and sent the wrong version. Sorry for the trouble. thanks, liubo > -Jan > -- > 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: [PATCH 4/4] Btrfs: cleanup unused arguments
Hi liubo, Patches 3 and 4 are looking good. I'm still trying to sort out on the other two, as I cannot reproduce your bug with your script, unfortunately. After applying all 4 patches, the result doesn't compile, here: fs/btrfs/ctree.c: In function 'balance_level': fs/btrfs/ctree.c:1799: warning: passing argument 3 of 'tree_mod_log_set_node_key' makes integer from pointer without a cast fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct btrfs_disk_key *' fs/btrfs/ctree.c:1799: error: too many arguments to function 'tree_mod_log_set_node_key' fs/btrfs/ctree.c:1844: warning: passing argument 3 of 'tree_mod_log_set_node_key' makes integer from pointer without a cast fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct btrfs_disk_key *' fs/btrfs/ctree.c:1844: error: too many arguments to function 'tree_mod_log_set_node_key' fs/btrfs/ctree.c: In function 'push_nodes_for_insert': fs/btrfs/ctree.c:1943: warning: passing argument 3 of 'tree_mod_log_set_node_key' makes integer from pointer without a cast fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct btrfs_disk_key *' fs/btrfs/ctree.c:1943: error: too many arguments to function 'tree_mod_log_set_node_key' fs/btrfs/ctree.c:1996: warning: passing argument 3 of 'tree_mod_log_set_node_key' makes integer from pointer without a cast fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct btrfs_disk_key *' fs/btrfs/ctree.c:1996: error: too many arguments to function 'tree_mod_log_set_node_key' fs/btrfs/ctree.c: In function 'fixup_low_keys': fs/btrfs/ctree.c:2880: warning: passing argument 3 of 'tree_mod_log_set_node_key' makes integer from pointer without a cast fs/btrfs/ctree.c:774: note: expected 'int' but argument is of type 'struct btrfs_disk_key *' fs/btrfs/ctree.c:2880: error: too many arguments to function 'tree_mod_log_set_node_key' CC [M] fs/btrfs/sysfs.o make[2]: *** [fs/btrfs/ctree.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [fs/btrfs] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [fs] Error 2 -Jan -- 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/4] Btrfs: kill unnecessary arguments in del_ptr
The argument 'tree_mod_log' is not necessary since all of callers enable it.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index bbea4fb..235831f 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -38,8 +38,7 @@ static int balance_node_right(struct btrfs_trans_handle
*trans,
struct extent_buffer *dst_buf,
struct extent_buffer *src_buf);
static void del_ptr(struct btrfs_trans_handle *trans, struct btrfs_root *root,
- struct btrfs_path *path, int level, int slot,
- int tree_mod_log);
+ struct btrfs_path *path, int level, int slot);
static void tree_mod_log_free_eb(struct btrfs_fs_info *fs_info,
struct extent_buffer *eb);
struct extent_buffer *read_old_tree_block(struct btrfs_root *root, u64 bytenr,
@@ -1789,7 +1788,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
if (btrfs_header_nritems(right) == 0) {
clean_tree_block(trans, root, right);
btrfs_tree_unlock(right);
- del_ptr(trans, root, path, level + 1, pslot + 1, 1);
+ del_ptr(trans, root, path, level + 1, pslot + 1);
root_sub_used(root, right->len);
btrfs_free_tree_block(trans, root, right, 0, 1);
free_extent_buffer_stale(right);
@@ -1833,7 +1832,7 @@ static noinline int balance_level(struct
btrfs_trans_handle *trans,
if (btrfs_header_nritems(mid) == 0) {
clean_tree_block(trans, root, mid);
btrfs_tree_unlock(mid);
- del_ptr(trans, root, path, level + 1, pslot, 1);
+ del_ptr(trans, root, path, level + 1, pslot);
root_sub_used(root, mid->len);
btrfs_free_tree_block(trans, root, mid, 0, 1);
free_extent_buffer_stale(mid);
@@ -4562,14 +4561,13 @@ int btrfs_insert_item(struct btrfs_trans_handle *trans,
struct btrfs_root
* empty a node.
*/
static void del_ptr(struct btrfs_trans_handle *trans, struct btrfs_root *root,
- struct btrfs_path *path, int level, int slot,
- int tree_mod_log)
+ struct btrfs_path *path, int level, int slot)
{
struct extent_buffer *parent = path->nodes[level];
u32 nritems;
int ret;
- if (tree_mod_log && level) {
+ if (level) {
ret = tree_mod_log_insert_key(root->fs_info, parent, slot,
MOD_LOG_KEY_REMOVE);
BUG_ON(ret < 0);
@@ -4577,7 +4575,7 @@ static void del_ptr(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
nritems = btrfs_header_nritems(parent);
if (slot != nritems - 1) {
- if (tree_mod_log && level)
+ if (level)
tree_mod_log_eb_move(root->fs_info, parent, slot,
slot + 1, nritems - slot - 1);
memmove_extent_buffer(parent,
@@ -4618,7 +4616,7 @@ static noinline void btrfs_del_leaf(struct
btrfs_trans_handle *trans,
struct extent_buffer *leaf)
{
WARN_ON(btrfs_header_generation(leaf) != trans->transid);
- del_ptr(trans, root, path, 1, path->slots[1], 1);
+ del_ptr(trans, root, path, 1, path->slots[1]);
/*
* btrfs_free_extent is expensive, we want to make sure we
--
1.7.7.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 4/4] Btrfs: cleanup unused arguments
'disk_key' is not used at all.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 235831f..7f649d2 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -772,8 +772,7 @@ tree_mod_log_eb_move(struct btrfs_fs_info *fs_info, struct
extent_buffer *dst,
static noinline void
tree_mod_log_set_node_key(struct btrfs_fs_info *fs_info,
- struct extent_buffer *eb,
- struct btrfs_disk_key *disk_key, int slot, int atomic)
+ struct extent_buffer *eb, int slot, int atomic)
{
int ret;
--
1.7.7.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 2/4] Btrfs: reorder tree mod log operations in deleting a pointer
Since we don't use MOD_LOG_KEY_REMOVE_WHILE_MOVING to add nritems
during rewinding, we should insert a MOD_LOG_KEY_REMOVE operation first.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 2858c2f..bbea4fb 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -4569,6 +4569,12 @@ static void del_ptr(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
u32 nritems;
int ret;
+ if (tree_mod_log && level) {
+ ret = tree_mod_log_insert_key(root->fs_info, parent, slot,
+ MOD_LOG_KEY_REMOVE);
+ BUG_ON(ret < 0);
+ }
+
nritems = btrfs_header_nritems(parent);
if (slot != nritems - 1) {
if (tree_mod_log && level)
@@ -4579,10 +4585,6 @@ static void del_ptr(struct btrfs_trans_handle *trans,
struct btrfs_root *root,
btrfs_node_key_ptr_offset(slot + 1),
sizeof(struct btrfs_key_ptr) *
(nritems - slot - 1));
- } else if (tree_mod_log && level) {
- ret = tree_mod_log_insert_key(root->fs_info, parent, slot,
- MOD_LOG_KEY_REMOVE);
- BUG_ON(ret < 0);
}
nritems--;
--
1.7.7.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 1/4] Btrfs: MOD_LOG_KEY_REMOVE_WHILE_MOVING never change node's nritems
Key MOD_LOG_KEY_REMOVE_WHILE_MOVING means that we're doing memmove inside
an extent buffer node, and the node's number of items remains unchanged
(unless we are inserting a single pointer, but we have MOD_LOG_KEY_ADD for
that).
So we don't need to increase node's number of items during rewinding,
otherwise we may get an node larger than leafsize and cause general protection
errors later.
Here is the details,
- If we do memory move for inserting a single pointer, we need to
add node's nritems by one, and we honor MOD_LOG_KEY_ADD for adding.
- If we do memory move for deleting a single pointer, we need to
decrease node's nritems by one, and we honor MOD_LOG_KEY_REMOVE for
deleting.
- If we do memory move for balance left/right, we need to decrease
node's nritems, and we honor MOD_LOG_KEY_REMOVE for balaning.
Signed-off-by: Liu Bo
---
fs/btrfs/ctree.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index b334362..2858c2f 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1142,13 +1142,13 @@ __tree_mod_log_rewind(struct extent_buffer *eb, u64
time_seq,
switch (tm->op) {
case MOD_LOG_KEY_REMOVE_WHILE_FREEING:
BUG_ON(tm->slot < n);
- case MOD_LOG_KEY_REMOVE_WHILE_MOVING:
case MOD_LOG_KEY_REMOVE:
+ n++;
+ case MOD_LOG_KEY_REMOVE_WHILE_MOVING:
btrfs_set_node_key(eb, &tm->key, tm->slot);
btrfs_set_node_blockptr(eb, tm->slot, tm->blockptr);
btrfs_set_node_ptr_generation(eb, tm->slot,
tm->generation);
- n++;
break;
case MOD_LOG_KEY_REPLACE:
BUG_ON(tm->slot >= n);
--
1.7.7.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: [PATCH 2/4] Btrfs-progs: fix irrelevant string in the subvol path
On fri, 19 Oct 2012 14:23:55 +0800, Anand jain wrote:
> From: Anand Jain
>
> btrfs su list -a /btrfs/sv1
> ID 256 gen 6 top level 5 path /sv1
> ID 258 gen 6 top level 5 path /ss1
I don't agree with this patch, because after applying this patch, the output of
'btrfs su list'
is the same as 'btrfs su list'. I hope 'btrfs su list' just list the subvolumes
in the specified
path. In this way, the user can find the path of the subvolume easily (the
specified path + the
path in the result of 'btrfs su list').
Could you make it output the path which is relative to the path that the user
specified?
Thanks
Miao
>
> Signed-off-by: Anand Jain
> ---
> cmds-subvolume.c | 15 +--
> 1 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/cmds-subvolume.c b/cmds-subvolume.c
> index a33c352..f8beecc 100644
> --- a/cmds-subvolume.c
> +++ b/cmds-subvolume.c
> @@ -306,7 +306,7 @@ static int cmd_subvol_list(int argc, char **argv)
> u64 top_id;
> int ret;
> int c;
> - char *subvol;
> + char *subvol, *mnt = NULL;
> int is_tab_result = 0;
> int is_list_all = 0;
> struct option long_options[] = {
> @@ -398,9 +398,18 @@ static int cmd_subvol_list(int argc, char **argv)
> return 13;
> }
>
> - fd = open_file_or_dir(subvol);
> + ret = find_mount_root(subvol, &mnt);
> + if (ret < 0) {
> + fprintf(stderr, "ERROR: find_mount_root failed on %s: "
> + "%s\n", subvol,
> + strerror(-ret));
> + return 12;
> + }
> +
> + fd = open_file_or_dir(mnt);
> if (fd < 0) {
> fprintf(stderr, "ERROR: can't access '%s'\n", subvol);
> + free(mnt);
> return 12;
> }
>
> @@ -412,6 +421,8 @@ static int cmd_subvol_list(int argc, char **argv)
>
> ret = btrfs_list_subvols(fd, filter_set, comparer_set,
> is_tab_result);
> +
> + free(mnt);
> if (ret)
> return 19;
> return 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
Re: [PATCH 0/4] filter snapshot(s) by its parent uuid
On 19/10/12, Miao Xie (mi...@cn.fujitsu.com) wrote: > On fri, 19 Oct 2012 14:23:53 +0800, Anand jain wrote: > > From: Anand Jain > > > > This set of patch will make > > btrfs su list -s > > to list only snapshot(s) of the given subvol. > > > > before: > > btrfs su list -s /btrfs/sv1 > > ... > > with this patch: > > btrfs su list -s /btrfs/sv1 > > ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid > > f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1 > > ID 261 gen 9 cgen 9 top level 5 otime 2012-10-19 13:37:42 uuid > > 44560e56-3879-2146-8b24-e9048871892f path ss3 > > Though the function implemented by your patch is very useful, you change the > semantic of "-s", > I think it is not allowed, or the programs that use "btrfs us list -s" may > fail. >From my perspective as a user I would be grateful if the following changes in syntax for listing subvolumes could be considered: In addition to btrfs subvolume list [-apurts] [-g [+|-]value] [-c [+|-]value] [--sort=gen,ogen,rootid,path] btrfs su list [-apurts] [-g [+|-]value] [-c [+|-]value] [--sort=gen,ogen,rootid,path] List subvolumes (and snapshots) (and Anand's patch to allow /) I believe the following shortcuts may be useful btrfs subvolumes [-apurts] [-g [+|-]value] [-c [+|-]value] [--sort=gen,ogen,rootid,path] [] btrfs sl [-apurts] [-g [+|-]value] [-c [+|-]value] [--sort=gen,ogen,rootid,path] [] Although from a technical perspective 'subvolume list' may be logical, listing subvolumes (plural) seems like a different sort of operation to those relating to a subvolume (singular) for create/alter/show/delete/snapshot operations. -- Rory Campbell-Lange r...@campbell-lange.net -- 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: [RFC v3 00/13] vfs: hot data tracking
On Tue, Oct 16, 2012 at 4:42 AM, Dave Chinner wrote: > On Wed, Oct 10, 2012 at 06:07:22PM +0800, zwu.ker...@gmail.com wrote: >> From: Zhi Yong Wu >> >> NOTE: >> >> The patchset is currently post out mainly to make sure >> it is going in the correct direction and hope to get some >> helpful comments from other guys. >> For more infomation, please check hot_tracking.txt in Documentation >> >> TODO List: > > 1) Fix OOM issues - the hot inode tracking caches grow very large > and don't get trimmed under memory pressure. From slabtop, after > creating roughly 24 million single byte files(*) on a machine with > 8GB RAM: > > OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME > 23859510 23859476 99%0.12K 795317 30 3181268K hot_range_item > 23859441 23859439 99%0.16K 1037367 23 4149468K hot_inode_item > 572530 572530 100%0.55K 817907327160K radix_tree_node > 241706 241406 99%0.22K 14218 17 56872K xfs_ili > 241206 241204 99%1.06K 804023321608K xfs_inode > > The inode tracking is trying to track all 24 million inodes even > though they have been written only once, and there are only 240,000 > inodes in the cache at this point in time. That was the last update > that slabtop got, so it is indicative of the impending OOM situation > that occurred. > >> Changelog from v2: >> 1.) Converted to Radix trees, not RB-tree [Zhiyong, Dave Chinner] >> 2.) Added memory shrinker [Dave Chinner] > > I haven't looked at the shrinker, but clearly it is not working, HI, Dave, Some guys suggest that when inode slab cache is shrinked, the hot_inode[range]_item slab is accordingly also shrinked, this will make hot tracking don't need to register its own shrinker. Do you think of it? If you don't like above idea. Do you have any good suggestion on how to remove hot_inode_item and hot_range_item? > otherwise the above OOM situation would not be occurring. > > Cheers, > > Dave. > > (*) Tested on an empty 17TB XFS filesystem with: > > $ sudo mkfs.xfs -f -l size=131072b,sunit=8 /dev/vdc > meta-data=/dev/vdc isize=256agcount=17, agsize=268435455 > blks > = sectsz=512 attr=2, projid32bit=0 > data = bsize=4096 blocks=4563402735, imaxpct=5 > = sunit=0 swidth=0 blks > naming =version 2 bsize=4096 ascii-ci=0 > log =internal log bsize=4096 blocks=131072, version=2 > = sectsz=512 sunit=1 blks, lazy-count=1 > realtime =none extsz=4096 blocks=0, rtextents=0 > $ sudo mount -o logbsize=256k /dev/vdc /mnt/scratch > $ sudo chmod 777 /mnt/scratch > $ fs_mark -D 1 -S0 -n 10 -s 1 -L 63 -d \ > /mnt/scratch/0 -d /mnt/scratch/1 -d /mnt/scratch/2 -d \ > /mnt/scratch/3 -d /mnt/scratch/4 -d /mnt/scratch/5 -d \ > /mnt/scratch/6 -d /mnt/scratch/7 > . > 0 21601 16679.3 12552262 > 0 22401 15412.4 12588587 > 0 23201 16367.6 14199322 > 0 24001 15680.4 15741205 > > > -- > Dave Chinner > da...@fromorbit.com -- Regards, Zhi Yong Wu -- 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: [RFC v3 11/13] vfs: add 3 new ioctl interfaces
On Tue, Oct 16, 2012 at 11:17 AM, Dave Chinner wrote: > On Wed, Oct 10, 2012 at 06:07:33PM +0800, zwu.ker...@gmail.com wrote: >> From: Zhi Yong Wu >> >> FS_IOC_GET_HEAT_INFO: return a struct containing the various >> metrics collected in btrfs_freq_data structs, and also return a > > I think you mean hot_freq_data :P > >> calculated data temperature based on those metrics. Optionally, retrieve >> the temperature from the hot data hash list instead of recalculating it. > > To get the heat info for a specific file you have to know what file > you want to get that info for, right? I can see the usefulness of > asking for the heat data on a specific file, but how do you find the > hot files in the first place? i.e. the big question the user > interface needs to answer is "what files are hot?". > > Once userspace knows what the hottest files are, it can open them > and query the data via the above ioctl, but expecting userspace to > iterate millions of inodes in a filesystem to find hot files is very > inefficient. > > FWIW, if you were to return file handles to the hottest files, then Good idea. I am not very clear about how to implement it. file handles mean file_handle?? How to return them to the application? via debugfs? How many hottest files should be returned?? Top 100? > the application could open and query them without even needing to > know the path name to them. This woul dbe exceedingly useful for > defragmentation programs, especially as that is the way xfs_fsr > already operates on candidate files.(*) > > IOWs, sometimes the pathname is irrelevant to the operations that > applications want to perform - all they care about having an > efficient method of finding the inode they want and getting a file > descriptor that points to the file. Given the heat map info fits > right in to the sort of operations defrag and data mover tools > already do, it kind of makes sense to optimise the interface towards > those uses > > (*) i.e. finds them via bulkstat which returns handle information > along with all the other inode data, then opens the file by handle > to do the defrag work > >> FS_IOC_GET_HEAT_OPTS: return an integer representing the current >> state of hot data tracking and migration: >> >> 0 = do nothing >> 1 = track frequency of access >> >> FS_IOC_SET_HEAT_OPTS: change the state of hot data tracking and >> migration, as described above. > > I can't see how this is a manageable interface. It is not > persistent, so after every filesystem mount you'd have to set the > flag on all your inodes again. Hence, for the moment, I'd suggest > that dropping per-inode tracking control until all the core issues > are sorted out > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Zhi Yong Wu -- 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 0/4] filter snapshot(s) by its parent uuid
On fri, 19 Oct 2012 14:23:53 +0800, Anand jain wrote: > From: Anand Jain > > This set of patch will make > btrfs su list -s > to list only snapshot(s) of the given subvol. > > before: > btrfs su list -s /btrfs/sv1 > > btrfs su list -s /btrfs > ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid > f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1 > ID 260 gen 8 cgen 8 top level 5 otime 2012-10-18 17:02:20 uuid > ea8fdf85-8d3f-8946-b3af-ede510cdcf19 path ss2 > ID 261 gen 9 cgen 9 top level 5 otime 2012-10-19 13:37:42 uuid > 44560e56-3879-2146-8b24-e9048871892f path ss3 > > with this patch: > btrfs su list -s /btrfs/sv1 > ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid > f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1 > ID 261 gen 9 cgen 9 top level 5 otime 2012-10-19 13:37:42 uuid > 44560e56-3879-2146-8b24-e9048871892f path ss3 Though the function implemented by your patch is very useful, you change the semantic of "-s", I think it is not allowed, or the programs that use "btrfs us list -s" may fail. I think it is better to add a new option. Thanks Miao > > btrfs su list -s /btrfs > ID 258 gen 6 cgen 6 top level 5 otime 2012-10-18 17:01:56 uuid > f648cdda-4efa-6f45-bd6b-041a8ae1538e path ss1 > ID 260 gen 8 cgen 8 top level 5 otime 2012-10-18 17:02:20 uuid > ea8fdf85-8d3f-8946-b3af-ede510cdcf19 path ss2 > ID 261 gen 9 cgen 9 top level 5 otime 2012-10-19 13:37:42 uuid > 44560e56-3879-2146-8b24-e9048871892f path ss3 > > Anand Jain (4): > Btrfs-progs: provide method to check if filter is set > Btrfs-progs: fix irrelevant string in the subvol path > Btrfs-progs: add method to filter snapshots by parent uuid > Btrfs-progs: list only snapshots of the given subvol > > btrfs-list.c | 17 + > btrfs-list.h |3 +++ > cmds-subvolume.c | 39 +-- > 3 files changed, 57 insertions(+), 2 deletions(-) > > -- > 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
[PATCH] Btrfs-progs: add btrfs-show-super tool
Just a small program to print the fields of a super block.
Signed-off-by: Stefan Behrens
---
Makefile | 5 +-
btrfs-show-super.c | 201 +
2 files changed, 205 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index fe2b432..25ac6d6 100644
--- a/Makefile
+++ b/Makefile
@@ -20,7 +20,7 @@ RESTORE_LIBS=-lz
progs = btrfsctl mkfs.btrfs btrfs-debug-tree btrfs-show btrfs-vol btrfsck \
btrfs btrfs-map-logical btrfs-image btrfs-zero-log btrfs-convert \
- btrfs-find-root btrfs-restore btrfstune
+ btrfs-find-root btrfs-restore btrfstune btrfs-show-super
# make C=1 to enable sparse
ifdef C
@@ -73,6 +73,9 @@ btrfs-debug-tree: $(objects) debug-tree.o
btrfs-zero-log: $(objects) btrfs-zero-log.o
$(CC) $(CFLAGS) -o btrfs-zero-log $(objects) btrfs-zero-log.o
$(LDFLAGS) $(LIBS)
+btrfs-show-super: $(objects) btrfs-show-super.o
+ $(CC) $(CFLAGS) -o btrfs-show-super $(objects) btrfs-show-super.o
$(LDFLAGS) $(LIBS)
+
btrfs-select-super: $(objects) btrfs-select-super.o
$(CC) $(CFLAGS) -o btrfs-select-super $(objects) btrfs-select-super.o
$(LDFLAGS) $(LIBS)
diff --git a/btrfs-show-super.c b/btrfs-show-super.c
new file mode 100644
index 000..2e1a368
--- /dev/null
+++ b/btrfs-show-super.c
@@ -0,0 +1,201 @@
+/*
+ * Copyright (C) 2012 STRATO AG. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public
+ * License v2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; if not, write to the
+ * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+ * Boston, MA 021110-1307, USA.
+ */
+
+#define _XOPEN_SOURCE 500
+#define _GNU_SOURCE 1
+#include
+#include
+#include
+#include
+#include
+#include "kerncompat.h"
+#include "ctree.h"
+#include "disk-io.h"
+#include "print-tree.h"
+#include "transaction.h"
+#include "list.h"
+#include "version.h"
+#include "utils.h"
+
+
+static void print_usage(void);
+static void dump_superblock(struct btrfs_super_block *sb);
+int main(int argc, char **argv);
+static void btrfs_print_id(char *prefix, u8 *id, size_t size);
+
+
+static void print_usage(void)
+{
+ fprintf(stderr, "usage: btrfs-show-super [-i super_mirror] dev\n");
+ fprintf(stderr, "\tThe super_mirror number is between 0 and %d.\n",
+ BTRFS_SUPER_MIRROR_MAX - 1);
+ fprintf(stderr, "%s\n", BTRFS_BUILD_VERSION);
+}
+
+int main(int argc, char **argv)
+{
+ int opt;
+ int ret;
+ const char *filename;
+ struct btrfs_super_block sb;
+ int fd = -1;
+ u64 sb_bytenr = btrfs_sb_offset(0);
+
+ while ((opt = getopt(argc, argv, "i:")) != -1) {
+ switch(opt) {
+ case 'i': {
+ int arg = atoi(optarg);
+
+ if (arg < 0 || arg >= BTRFS_SUPER_MIRROR_MAX) {
+ fprintf(stderr,
+ "Illegal super_mirror %d\n",
+ arg);
+ print_usage();
+ exit(1);
+ }
+ sb_bytenr = btrfs_sb_offset(arg);
+ break;
+ }
+ default:
+ print_usage();
+ exit(1);
+ }
+ }
+
+ if (argc != optind + 1) {
+ print_usage();
+ exit(1);
+ }
+
+ filename = argv[optind];
+ fd = open(filename, O_RDONLY, 0666);
+ if (fd < 0) {
+ fprintf(stderr, "Could not open %s\n", filename);
+ goto error;
+ }
+
+ ret = pread64(fd, &sb, sizeof(sb), sb_bytenr);
+ if (ret < sizeof(sb)) {
+ fprintf(stderr, "Failed to read the superblock on %s at %llu\n",
+ filename, (unsigned long long)sb_bytenr);
+ goto error;
+ }
+
+ dump_superblock(&sb);
+
+error:
+ if (fd != -1)
+ close(fd);
+
+ exit(1);
+}
+
+static void dump_superblock(struct btrfs_super_block *sb)
+{
+ printf("bytenr\t%llu\n", (unsigned long long)btrfs_super_bytenr(sb));
+ printf("flags\t0x%llx\n", (unsigned long long)btrfs_super_flags(sb));
+ printf("magic \t0x%llx (little endian)\n",
+ (unsigned long long)sb->magic);
+ btrfs_print_id("fsid\t", sb->fsid, BTRFS_FSID_SIZE);
+ btrfs_print_id("label\t", (u8 *)sb->l
