Nishant Agrawal | 31 Oct 20:23 2014
Picon

Compile BtrFS as kernel module

Hi,

I want to compile btrfs as kernel module with special debug prints. Can 
anyone help me with the instructions to do that?

I tried to do online search but I couldn't find anything.

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

David Sterba | 31 Oct 19:40 2014
Picon

[PATCH] btrfs: fix typos in btrfs_check_super_valid

Copy&paste errors in some messages and add few more missing macro
accessors.

Signed-off-by: David Sterba <dsterba <at> suse.cz>
---

This is for 3.18-rc, a fixup to "btrfs: use macro accessors in superblock
validation checks"

 fs/btrfs/disk-io.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 1bf9f897065d..7af9a1978a2f 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
 <at>  <at>  -3839,12 +3839,12  <at>  <at>  static int btrfs_check_super_valid(struct btrfs_fs_info *fs_info,
 	 */
 	if (!IS_ALIGNED(btrfs_super_root(sb), 4096))
 		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
-				sb->root);
+				btrfs_super_root(sb));
 	if (!IS_ALIGNED(btrfs_super_chunk_root(sb), 4096))
-		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
-				sb->chunk_root);
+		printk(KERN_WARNING "BTRFS: chunk_root block unaligned: %llu\n",
+				btrfs_super_chunk_root(sb));
 	if (!IS_ALIGNED(btrfs_super_log_root(sb), 4096))
-		printk(KERN_WARNING "BTRFS: tree_root block unaligned: %llu\n",
+		printk(KERN_WARNING "BTRFS: log_root block unaligned: %llu\n",
(Continue reading)

Josef Bacik | 31 Oct 19:01 2014

[GIT PULL] Various btrfsck updates

Please pull

https://github.com/josefbacik/btrfs-progs.git for-kdave

This is all the work from fixing a random IRC users broken file system.  This
also includes two patches that were not picked up previously for some reason,
and includes 4 new test images.  The test images may not make it to the list,
but they are in the git tree (they are patch 02/11 and 11/11).  Thanks,

Josef

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

Rich Turner | 31 Oct 17:23 2014

which subvolume is mounted?

let’s first assume the contents of /etc/fstab are either not used or invalid in mounting the subvolumes.
given the following ‘df’ command, how do i know which subvolume of the btrfs filesystem on /dev/sda3
is mounted at each mount point (/, /var, /opt, /home)? i would have expected to see the mount option used to
define the subvolume (subvolid or subvol option) in /proc/mounts.

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/sda3        6839296 1698564   4903212  26% /
devtmpfs          501464       0    501464   0% /dev
tmpfs             507316       0    507316   0% /dev/shm
tmpfs             507316    6720    500596   2% /run
tmpfs             507316       0    507316   0% /sys/fs/cgroup
/dev/sda3        6839296 1698564   4903212  26% /var
/dev/sda3        6839296 1698564   4903212  26% /opt
/dev/sda3        6839296 1698564   4903212  26% /home
/dev/sda1         517868   93040    424828  18% /boot

# btrfs subvolume list -a --sort=+rootid /
ID 257 gen 7800 top level 5 path <FS_TREE>/root
ID 258 gen 4127 top level 5 path <FS_TREE>/home
ID 259 gen 7801 top level 5 path <FS_TREE>/var
ID 260 gen 7795 top level 5 path <FS_TREE>/opt

# uname -a
Linux turner11.storix 3.10.0-123.el7.x86_64 #1 SMP Mon May 5 11:16:57 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

# btrfs --version
Btrfs v3.12

# btrfs fi show
(Continue reading)

Josef Bacik | 31 Oct 16:58 2014

[PATCH] Btrfs: don't take the chunk_mutex/dev_list mutex in statfs

Our gluster boxes get several thousand statfs() calls per second, which begins
to suck hardcore with all of the lock contention on the chunk mutex and dev list
mutex.  We don't really need to hold these things, if we have transient
weirdness with statfs() because of the chunk allocator we don't care, so remove
this locking.

We still need the dev_list lock if you mount with -o alloc_start however, which
is a good argument for nuking that thing from orbit, but that's a patch for
another day.  Thanks,

Signed-off-by: Josef Bacik <jbacik <at> fb.com>
---
 fs/btrfs/super.c | 69 ++++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 45 insertions(+), 24 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 54bd91e..2c9ba11 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
 <at>  <at>  -1644,8 +1644,20  <at>  <at>  static int btrfs_calc_avail_data_space(struct btrfs_root *root, u64 *free_bytes)
 	int i = 0, nr_devices;
 	int ret;

+	/*
+	 * We aren't under the device list lock, so this is racey-ish, but good
+	 * enough for our purposes.
+	 */
 	nr_devices = fs_info->fs_devices->open_devices;
-	BUG_ON(!nr_devices);
+	if (!nr_devices) {
(Continue reading)

Josef Bacik | 31 Oct 14:49 2014

[PATCH] Btrfs: move read only block groups onto their own list V2

Our gluster boxes were spending lots of time in statfs because our fs'es are
huge.  The problem is statfs loops through all of the block groups looking for
read only block groups, and when you have several terabytes worth of data that
ends up being a lot of block groups.  Move the read only block groups onto a
read only list and only proces that list in
btrfs_account_ro_block_groups_free_space to reduce the amount of churn.  Thanks,

Signed-off-by: Josef Bacik <jbacik <at> fb.com>
---
V1->V2:
-list_for_each_entry was using the wrong ->member name.

 fs/btrfs/ctree.h       |  4 ++++
 fs/btrfs/extent-tree.c | 36 +++++++++++++-----------------------
 2 files changed, 17 insertions(+), 23 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index d557264e..438f087 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
 <at>  <at>  -1170,6 +1170,7  <at>  <at>  struct btrfs_space_info {
 	struct percpu_counter total_bytes_pinned;

 	struct list_head list;
+	struct list_head ro_bgs;

 	struct rw_semaphore groups_sem;
 	/* for block groups in our same type */
 <at>  <at>  -1305,6 +1306,9  <at>  <at>  struct btrfs_block_group_cache {

(Continue reading)

Lakshmi_Narayanan_Du | 31 Oct 11:56 2014
Picon

request for info on the list of parameters to tweak for PCIe SSDs

Hi,

Could you kindly help us with the list of all the btrfs  file system parameters , that can be tweaked for the
best performance of the PCIe based SSDs ?

Thanks,
Lakshmi
NrybXǧv^)޺{.n+{n߲)w*jgݢj/zޖ2ޙ&)ߡaGhj:+vw٥
Lakshmi_Narayanan_Du | 31 Oct 11:35 2014
Picon

request for info on the list of parameters to tweak for PCIe SSDs

Hi,

Could you kindly help us with the list of all the xfs  file system parameters , that can be tweaked for the best
performance of the PCIe based SSDs ?

Thanks,
Lakshmi
Tobias Holst | 31 Oct 01:29 2014
Picon

filesystem corruption

Hi

I was using a btrfs RAID1 with two disks under Ubuntu 14.04, kernel
3.13 and btrfs-tools 3.14.1 for weeks without issues.

Now I updated to kernel 3.17.1 and btrfs-tools 3.17. After a reboot
everything looked fine and I started some tests. While running
duperemover (just scanning, not doing anything) and a balance at the
same time the load suddenly went up to >30 and the system was not
responding anymore. Everyhting working with the filesystem stopped
responding. So I did a hard reset.

I was able to reboot, but on the login prompt nothing happened but a
kernel bug. Same back in kernel 3.13.

Now I started a live system (Ubuntu 14.10, kernel 3.16.x, btrfs-tools
3.14.1), and mounted the btrfs filesystem. I can browse through the
files but sometimes, especially when accessing my snapshots or trying
to create a new snapshot, the kernel bug appears and the filesystem
hangs.

It shows this:
Oct 31 00:09:14 ubuntu kernel: [  187.661731] ------------[ cut here
]------------
Oct 31 00:09:14 ubuntu kernel: [  187.661770] WARNING: CPU: 1 PID:
4417 at /build/buildd/linux-3.16.0/fs/btrfs/relocation.c:924
build_backref_tree+0xcab/0x1240 [btrfs]()
Oct 31 00:09:14 ubuntu kernel: [  187.661772] Modules linked in:
nls_iso8859_1 dm_crypt gpio_ich coretemp lpc_ich kvm_intel kvm
dm_multipath scsi_dh serio_raw xgifb(C) bnep rfcomm bluetooth
(Continue reading)

Noah Massey | 31 Oct 01:21 2014
Picon

fstrim on BTRFS

Hello,

I am looking for some clarification on TRIM / SSD maintenance.
The wiki [1] suggests periodic fstrim, but fstrim does not discard
unallocated blocks[2].
Which makes sense, given that mkfs issues a device wide trim, so they
shouldn't have data.

But it seems like both a balance, and a pending patch
( 47ab2a6 Btrfs: remove empty block groups automatically )
can deallocate block groups without TRIM, leading to the SSD retaining
data it doesn't need to.

Is there a bitter way to trigger a more thorough discard than
fallocate, rm, fstrim, balance -dusage=0 ?
And are there plans to support trimming unallocated space, or is this
not possible with current FS format?

Thank you,
Noah

[1] https://btrfs.wiki.kernel.org/index.php/FAQ#Does_Btrfs_support_TRIM.2Fdiscard.3F
[2] https://www.mail-archive.com/linux-btrfs <at> vger.kernel.org/msg14195.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tim Cuthbertson | 31 Oct 00:06 2014
Picon

3.17.2 kernel patches for btrfs

Does the new Linux 3.17.2 kernel have sufficient patches to safely use
btrfs with subvolume snapshots and incremental send/receive? I ask
because 3.17.1 was released just before the btrfs patches for these
issues, so I have been waiting for 3.17.2. However, from reading the
kernel changelog, it appears that most of the included btrfs patches
were from July, August, and September, still too early for the btrfs
fixes I need. Thank you.

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


Gmane