El 2014-10-14 18:54, Robert White escribió:
Howdy,
So I run several gentoo systems and I upgraded two of them to kernel
3.17.0
One using BTRFS for root.
One using ext3 for root (via the ext4 driver)
_Both_ systems exhibited strange behavior (long pauses and then hangs
requiring hard-power)
When we have one device we don't call register device.
(in fact not mandatory, but to make it consistent)
And when we have more than one we call register device.
reproducer:
Nothing in the kernel device list
cat /proc/fs/btrfs/devlist | egrep fsid | wc -l
0
mkfs.btrfs will automatically call
As of now commands mentioned below (with in [..]) are calling call
register-device
ioctl BTRFS_IOC_SCAN_DEV for all the devices in the system.
Some issues with it:
BTRFS_IOC_SCAN_DEV: ioctl is a write operation, we don't want command like
btrfs-debug-tree threads to do that..
eg:
We are passing device path to be registered with in kernel,
so we need to open with RW
Signed-off-by: Anand Jain anand.j...@oracle.com
---
utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index dd4ee52..78cb93f 100644
--- a/utils.c
+++ b/utils.c
@@
cmd_scan_dev() has it own code to register device (calling ioctl
BTRFS_IOC_SCAN_DEV),
apparently it could use btrfs_register_one_device().
Signed-off-by: Anand Jain anand.j...@oracle.com
---
cmds-device.c | 33 ++---
utils.c | 8 +---
utils.h | 2 +-
btrfs_scan_lblikd is called by most the device related command functions.
And btrfs_scan_lblkid is most expensive function and it becomes more expensive
as number of devices in the system increase.
This patch will:
move out calling register_one_device with in btrfs_scan_lblkid()
and so
Juan Orti Alcaine posted on Wed, 15 Oct 2014 09:08:14 +0200 as excerpted:
I've also experienced Btrfs corruptions with 3.17.0
I do readonly snapshots every hour of all the subvolumes, so I have
hundreds of snapshots.
That's a known issue with read-only snapshots in 3.17.0. There's quite a
On 2014-10-14 18:25, Robert White wrote:
I've got no idea if this is possible given the current storage layout,
but it would be Really Nice™ if there were a way to have a single
subvolume exist in more than one place in hirearchy. I know this can be
faked via mount tricks (bind or use of
On 10/15/2014 03:08 AM, Juan Orti Alcaine wrote:
El 2014-10-14 18:54, Robert White escribió:
Howdy,
So I run several gentoo systems and I upgraded two of them to kernel
3.17.0
One using BTRFS for root.
One using ext3 for root (via the ext4 driver)
_Both_ systems exhibited strange behavior
El 2014-10-15 15:46, Josef Bacik escribió:
On 10/15/2014 03:08 AM, Juan Orti Alcaine wrote:
I've also experienced Btrfs corruptions with 3.17.0 (Fedora 21 alpha).
It has happened two times, each one after a clean reinstall and a wipe
of the old fs. In less than a day, both installations got
On 10/15/2014 10:05 AM, Juan Orti Alcaine wrote:
El 2014-10-15 15:46, Josef Bacik escribió:
On 10/15/2014 03:08 AM, Juan Orti Alcaine wrote:
I've also experienced Btrfs corruptions with 3.17.0 (Fedora 21 alpha).
It has happened two times, each one after a clean reinstall and a wipe
of the old
El 2014-10-15 16:30, Josef Bacik escribió:
On 10/15/2014 10:05 AM, Juan Orti Alcaine wrote:
El 2014-10-15 15:46, Josef Bacik escribió:
On 10/15/2014 03:08 AM, Juan Orti Alcaine wrote:
I've also experienced Btrfs corruptions with 3.17.0 (Fedora 21
alpha).
It has happened two times, each one
Revisit of a previous issue. Summary, single drive btrfs has lots of
data. Made a RAID1 with another drive of just the metadata. Was in
that state for less than 12 hours-ish, removed the second drive and
now cannot get to any data on the original drive.
Single drive btrfs was made on Ubuntu with
On Tue, Oct 14, 2014 at 10:18:09PM +0200, Fabian Frederick wrote:
On 14 October 2014 at 21:15 Zach Brown z...@zabbo.net wrote:
On Tue, Oct 14, 2014 at 07:46:14PM +0200, Fabian Frederick wrote:
use function defined in include/linux/highmem.h
Note that this reverts 2 last function
This reverts commit 9c3b306e1c9e6be4be09e99a8fe2227d1005effc.
Switching only one commit root during a transaction is wrong because it leads
the fs into an inconsistent state. All commit roots should be switched at once,
at transaction commit time, otherwise backref walking can often miss
Regression test for a btrfs issue where creation of readonly snapshots caused
the filesystem to get into an inconsistent state.
This regression was introduced in the 3.17 kernel and fixed by reverting the
following linux kernel commit:
Btrfs: race free update of commit root for ro snapshots
On 10/15/2014 02:37 PM, Filipe Manana wrote:
Regression test for a btrfs issue where creation of readonly snapshots caused
the filesystem to get into an inconsistent state.
This regression was introduced in the 3.17 kernel and fixed by reverting the
following linux kernel commit:
Btrfs:
On 10/15/2014 04:30 AM, Austin S Hemmelgarn wrote:
On 2014-10-14 18:25, Robert White wrote:
I've got no idea if this is possible given the current storage layout,
but it would be Really Nice™ if there were a way to have a single
subvolume exist in more than one place in hirearchy. I know this
On Wed, Oct 15, 2014 at 10:30 AM, Josef Bacik jba...@fb.com wrote:
We've found it, the Fedora guys are reverting the bad patch now, we'll get
the fix sent back to stable shortly. Sorry about that.
After reverting this commit, can the bad snapshots be
deleted/repaired/etc without wiping and
On 10/15/2014 03:30 PM, Rich Freeman wrote:
On Wed, Oct 15, 2014 at 10:30 AM, Josef Bacik jba...@fb.com wrote:
We've found it, the Fedora guys are reverting the bad patch now, we'll get
the fix sent back to stable shortly. Sorry about that.
After reverting this commit, can the bad snapshots
The following commit:
btrfs-progs: fsck: remove unfriendly BUG_ON() for searching tree failure
f495a2ac66116f0a1b15e73380c8cbca6e0a4ca0
introduced a regression, detected through xfstests/btrfs/054, where
previously a negative return value (-1) was used to mean a particular
root didn't
On Wed, Oct 15, 2014 at 10:58:40PM +0100, Filipe Manana wrote:
This affects only the 3.17 release candidates (3.16 and older releases
don't have this issue).
Thank you, I'm adding this to the branch and tagging rc4.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
Revisit of a previous issue. Summary, single drive btrfs has lots of
data. Made a RAID1 with another drive of just the metadata. Was in
that state for less than 12 hours-ish, removed the second drive and
now cannot get to any data on the original drive.
Single drive btrfs was made on Ubuntu with
On Wed, Oct 15, 2014 at 2:37 PM, Filipe Manana fdman...@gmail.com
wrote:
This reverts commit 9c3b306e1c9e6be4be09e99a8fe2227d1005effc.
Switching only one commit root during a transaction is wrong because
it leads
the fs into an inconsistent state. All commit roots should be
switched at
In one of Dave's cleanup commits he forgot to call btrfs_end_io_wq_exit on
unload, which makes us unable to unload and then re-load the btrfs module. This
fixes the problem. Thanks,
Signed-off-by: Josef Bacik jba...@fb.com
---
fs/btrfs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi.
I applied the patch to 3.17.1 but although I haven't seen any
corrupted ro snapshot yet it's still impossible to do btrfs send. As
soon as I start btrfs send I still get
ERROR: send ioctl failed with -12: Cannot allocate memory
even if I redirect btrfs send's output to a file (instead of
On Wed, Oct 15, 2014 at 11:42 PM, john terragon jterra...@gmail.com wrote:
Hi.
I applied the patch to 3.17.1 but although I haven't seen any
corrupted ro snapshot yet it's still impossible to do btrfs send. As
soon as I start btrfs send I still get
ERROR: send ioctl failed with -12: Cannot
coverity warned that the return code from sscanf() assigned to 'i'
wasn't checked before being assigned again. Check it.
Signed-off-by: Zach Brown z...@zabbo.net
---
utils.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index c2f30d4..51e55be 100644
Hi gang,
Here's another set of coverity fixes for btrfs-progs against David's
integration-20141007 branch.
I got tired of adding error checking after a few so I moved on to the
other warnings. Maybe we should subscribe linux-btrfs to the reports
that coverity can send out?
- z
--
To
btrfs_setup_all_roots() had some copy and pasted code for trying to
setup a root and then creating a blank node if that failed. The copy
for the csum_root created the blank node in the extent_root.
So we create a function to use a consistent root.
Signed-off-by: Zach Brown z...@zabbo.net
---
coverity barked out a warning that btrfs-map-logical was storing but
ignoring errors from read_extent_from_disk(). So don't ignore 'em. I
made extent reading errors fatal to match the fatal errors from mapping
mirrors above.
And while we're at it have read_extent_from_disk() return -errno
coverity pointed out that unknown flag printing in show super had some
dead code. It turns out that first was reset when the first flag was
tested, not when it was output. We only want to clear it if the first
matching bit is output. If there are no matching bits then we'll want
to output the
The following commit:
btrfs-progs: fsck: remove unfriendly BUG_ON() for searching tree failure
f495a2ac66116f0a1b15e73380c8cbca6e0a4ca0
introduced a regression, detected through xfstests/btrfs/054, where
previously a negative return value (-1) was used to mean a particular
root didn't
-It's not a brand new fs. It has been created four or five days ago
with btrfs-progs 3.16.2 (in fact it was created because of the dead
unremovable ro snapshots in the previous fs)
-the snapshot in question has been created after applying the patch
(and it has not become corrupted so far)
-not
Hi David and Chris,
(2014/09/29 18:36), David Sterba wrote:
On Fri, Sep 19, 2014 at 05:45:49PM +0900, Satoru Takeuchi wrote:
In the current implementation, compression property == has
the two different meanings: one is with BTRFS_INODE_NOCOMPRESS,
and the other is without this flag.
So, even
The following kernel commit introduced the bug:
51f395ad btrfs: Use right extent length when inserting overlap extent map.
When btrfs commit race with btrfs_get_extent(), merge_extent_mapping()
may build up a new extent which length overflows and cause extent map
insert fail, causing the caller
The @btrfs_ioctl_get_dev_stats fails to pad to 1k as descripted,
actually it valuates to 1032 bytes.
The corresponding userspace change follows this change.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
include/uapi/linux/btrfs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The @btrfs_ioctl_get_dev_stats fails to pad to 1k as descripted,
actually it valuates to 1032 bytes.
Correct it following the kernel patch.
Signed-off-by: Gui Hecheng guihc.f...@cn.fujitsu.com
---
ioctl.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ioctl.h b/ioctl.h
index
Problem:
# mkfs.btrfs -f /dev/sda1
# btrfs dev add /dev/sda1 /dir -f == dir is not a mntpnt
btrfs dev add just report invalid ioctl but it has already made
changes to /dev/sda1 with @btrfs_prepare_device(), so the fs on
/dev/sda1 is damaged.
We could check whether /dev/sda1 is
39 matches
Mail list logo
