From: Anand Jain
Originally root_times_lock was introduced as part of send/receive
code however newly developed patch to label the subvol reused
the same lock, so renaming it for a meaningful name.
Signed-off-by: Anand Jain
---
fs/btrfs/ctree.c | 16
fs/btrfs/ctree.h
When we're deleting the device we should get it in write mode since
we're going to re-write the super block magic on that device. And it
should fail if the device is read-only.
Signed-off-by: Lukas Czerner
---
fs/btrfs/volumes.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff -
This patch replace the obsolete simple_strto with kstrto
Signed-off-by: Abhijit Pawar
---
fs/9p/v9fs.c |6 +++---
fs/btrfs/ioctl.c |6 +-
fs/cifs/cifs_debug.c |6 --
fs/dlm/config.c | 25 -
fs/dlm/lockspace.c | 20 +++
We should make sure fs_info is not null before we refer to its field.
Add simple check here.
Signed-off-by: Wang Sheng-Hui
---
fs/btrfs/super.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index 915ac14..c6a3633 100644
--- a/fs/btrfs/
We're using a backups server to back up all machines in a LAN. Four 2TB
disks are assembled in a BTRFS RAID array and mounted as /media/backups.
Under this are subvolumes droog, hex, etc, and snapshots
droog_snap-{date1}, hex_snap-{date1}, etc.
Goal is to encrypt backups, but the concern is wit
It works. Nice fix.
Thanks
Anand
On 12/07/2012 03:25 AM, Lukas Czerner wrote:
Currently udev does not know about the device being removed from the
file system. This may result in the situation where we're unable to
mount the file system by UUID or by LABEL because the by-uuid and
by-label lin
# mount /dev/sdb /btrfs
# echo "scsi remove-single-device 1 0 0 0" > /proc/scsi/scsi
# lsscsi
[0:0:0:0]diskATA VBOX HARDDISK1.0 /dev/sda
[2:0:0:0]diskATA VBOX HARDDISK1.0 /dev/sdc
# btrfs su create /btrfs/sv1
Create subvolume '/btrfs/sv1'
ERROR: cannot
On 12/05/2012 09:07 AM, Jim Schutt wrote:
Hi,
I'm hitting a btrfs locking issue with 3.7.0-rc8.
The btrfs filesystem in question is backing a Ceph OSD
under a heavy write load from many cephfs clients.
I reported this issue a while ago:
http://www.spinics.net/lists/linux-btrfs/msg19370.html
wh