Thanks for the review Eric, this patch has been committed.
--Rich
commit 0efd4f4d483a725212f531bc2ed964de2766b1cd
Author: Rich Johnston
Date: Wed Apr 3 17:31:49 2013 +
xfstests: cleanup duplicates in all tests
There are duplicate blank lines, comment hash and lines
containin
Hi,
default mkfs, mount with noatime, top commit 5710a6f8bb040fd034217c
(current next master).
091 crashes reproducibly after a few seconds with:
[ 104.492115] [ cut here ]
[ 104.496025] kernel BUG at fs/btrfs/extent_io.c:1798!
[ 104.496025] invalid opcode: [#1] S
On Wed, Apr 03, 2013 at 03:07:04AM -0600, Miao Xie wrote:
> It is very likely that there are several blocks in bio, it is very
> inefficient if we get their csums one by one. This patch improves
> this problem by getting the csums in batch.
>
> According to the result of the following test, the ex
In trying to track down a weird tree log problem I wanted to make sure that the
free space cache was actually valid, which we currently have no way of doing.
So this patch adds a bunch of support for the free space cache code and then a
checker to fsck. Basically we go through and if we can actual
This:
# mkfs.btrfs /dev/sdb{1,2} ; wipefs -a /dev/sdb1; mount /dev/sdb2 /mnt/test
would lead to a blkdev open/close mismatch when the mount fails, and
a permanently busy (opened O_EXCL) sdb2:
# wipefs -a /dev/sdb2
wipefs: error: /dev/sdb2: probing initialization failed: Device or resour
While trying to track down a tree log replay bug I noticed that fsck was always
complaining about nbytes not being right for our fsynced file. That is because
the new fsync stuff doesn't wait for ordered extents to complete, so the inodes
nbytes are not necessarily updated properly when we log it.
I've been trying to figure out the btrfs I/O stack to try to understand
why, sometimes (but not always), after a failure to read a (data
non-replicated) block from the disk, the file being accessed becomes
permanently locked, and the filesystem, unmountable.
Sometimes (but not always) it's possibl
This:
# mkfs.btrfs /dev/sdb{1,2} ; wipefs -a /dev/sdb1; mount /dev/sdb2 /mnt/test
would lead to a blkdev open/close mismatch when the mount fails, and
a permanently busy (opened O_EXCL) sdb2:
# wipefs -a /dev/sdb2
wipefs: error: /dev/sdb2: probing initialization failed: Device or resour
On 4/3/13, Chris Murphy wrote:
>
> On Mar 29, 2013, at 9:42 AM, Mitch Harder
> wrote:
>
>> On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy
>> wrote:
>>>
>>> mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by
>>> 3.9.0 and only 3.9.0 (so far). And while there's no error making
--
mkfs.btrfs /dev/dm-4 -f
mkfs.ext4 /dev/dm-4 <-- corrupt the primary SB
--
as of now
--
btrfs fi label /dev/dm-4 "test"
btrfs fi label /dev/dm-4
test
--
is successful since its using backup super block
by default, is this fine ?
Thanks, Anand
--
To unsubscribe from this list: send
On Apr 4, 2013, at 11:00 AM, Mitch Harder wrote:
>
> I disagree with cwillu regarding the default setting for extended inode refs.
>
> While the extended inode refs are a great addition and solve a long
> standing problem, it appears only the 3.9.0_rc kernel consistently
> works with extended i
When logging changed extents I was logging ram_bytes as the current length,
which isn't correct, it's supposed to be the ram bytes of the original extent.
This is for compression where even if we split the extent we need to know the
ram bytes so when we uncompress the extent we know how big it will
> It's because btrfs_open_devices() may open some devices, and still
> return failure. So the error unwinding needs to close any open
> devices in fs_devices before returning.
Yeah, looks like.
> Note, __btrfs_open_devices is weird; it seems to return success or
> failure based on the outcome of
On 4/4/13 1:46 PM, Zach Brown wrote:
>> It's because btrfs_open_devices() may open some devices, and still
>> return failure. So the error unwinding needs to close any open
>> devices in fs_devices before returning.
>
> Yeah, looks like.
>
>> Note, __btrfs_open_devices is weird; it seems to retu
> I guess I had a feeling that in something like a degraded mount scenario
> you might live with failures. But I guess that is initiated on the mount
> commandline, i.e. "mount this subset; it's degraded" not "mount these devices,
> and if some fail that's cool."
>
> Right?
Maybe? Who knows.
-
Quoting Eric Sandeen (2013-04-04 15:45:28)
> On 4/4/13 1:46 PM, Zach Brown wrote:
> >> It's because btrfs_open_devices() may open some devices, and still
> >> return failure. So the error unwinding needs to close any open
> >> devices in fs_devices before returning.
> >
> > Yeah, looks like.
> >
This:
# mkfs.btrfs /dev/sdb{1,2} ; wipefs -a /dev/sdb1; mount /dev/sdb2 /mnt/test
would lead to a blkdev open/close mismatch when the mount fails, and
a permanently busy (opened O_EXCL) sdb2:
# wipefs -a /dev/sdb2
wipefs: error: /dev/sdb2: probing initialization failed: Device or resour
We need a mechanism to tell when to use the backup super_block.
To do this it needs a frame-work, and the patch #1 and #2 below
provides the same without change in the logic.
Its been found and posted to the list that check_mounted
needs access to the backup-sb and find-root as well. so
patch #3 p
Introduce flag BTRFS_SCAN_REGISTER to replace the parameter run_ioctl
which controls calling the function btrfs_register_one_device().
Signed-off-by: Anand Jain
---
cmds-device.c | 4 ++--
disk-io.c | 3 ++-
find-root.c | 3 ++-
utils.c | 20 +++-
utils.h |
As of now btrfs_read_dev_super() reads the backup super block
by default and calling function has no control. However in the
following patch we would see that is undesirable.
So with the flag BTRFS_SCAN_BACKUP_SB the calling function
can now indicate if btrfs_read_dev_super should scan for
the back
except for check_mounted
Signed-off-by: Anand Jain
---
disk-io.c | 2 +-
find-root.c | 2 +-
utils.c | 2 +-
volumes.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 82c3b66..589b37a 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -881,7 +88
since idea is to scan and report all the sb in the
dev, we should let it so look for backup SB by setting
the flag BTRFS_SCAN_BACKUP_SB
Signed-off-by: Anand Jain
---
find-root.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/find-root.c b/find-root.c
index 27512df..e4ad6
check_mounted would need to check backup SB to see if the
device is mounted to accommodate the situation when the
primary SB is corrupted (even in multi dev btrfs).
so we need flag to communicate to btrfs_read_dev_super
to check backup SB.
this patch will just introduce the flag with access
to bac
Hi David, all
kindly review/accept this patch set to fix various
bugs as in the patch.
This patch set is on top David's integration-20130321
branch and would apply nicely on top the backup sb
fixes which was sent separately.
Thanks
Anand
Anand Jain (9):
reproducing steps:
mkfs.btrfs /dev/dm-2 -f
mount /dev/dm-2 /btrfs
umount /btrfs
btrfs check /dev/dm-2 --repair
mount /dev/dm-2 /btrfs
btrfs: mismatching generation and generation_v2 found in root item. This root
was probably mounted with an older kernel. Resetting all new fields.
btrfs
In the cases where one of the disk is not suitable for
btrfs, then we would fail the mkfs, however we determine
that after we have written btrfs to the preceding disks.
At this time if user changes mind for not to use btrfs
will left with no choice.
So this patch will check if all the provided dis
and get_btrfs_mount has replaced it
Signed-off-by: Anand Jain
---
utils.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/utils.c b/utils.c
index 21483b8..9c5dbf4 100644
--- a/utils.c
+++ b/utils.c
@@ -976,41 +976,6 @@ out_mntloop_err:
return ret;
A trivial fix: To match the events inside to what
being printed out
before:
::
adding device /dev/dm-3 id 2
adding device /dev/dm-4 id 3
adding device /dev/dm-5 id 4
fs created label (null) on /dev/dm-2
nodesize 4096 leafsize 4096 sectorsize 4096 size 213.20GB
Btrfs v0.20-rc1-235-gdd21bc1
---
a very trivial fix
Signed-off-by: Anand Jain
---
cmds-scrub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmds-scrub.c b/cmds-scrub.c
index 5922361..ebb0dc9 100644
--- a/cmds-scrub.c
+++ b/cmds-scrub.c
@@ -1465,7 +1465,7 @@ out:
}
static const char * const cmd_scrub_s
Having no balance running/ paused/completed is a normal
situation, so the current output message should be positive
with return val zero.
As of now:
Signed-off-by: Anand Jain
---
cmds-balance.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/cmds-balance.c b/cmds-balanc
when we have to report no such file error for
/dev/btrfs-control we could confirm if btrfs kernel
module is loaded and report it and skip registration
where appropriate
Further this patch pretty prints the dev scan results.
Signed-off-by: Anand Jain
---
cmds-device.c | 56 ++
as of now in replace command target dev is being checked
for mounted and for existing fs, however there is newly
introduced __test_dev_for_mkfs in mkfs.c which is suitable
for this job, and further it also checks if dev can be
opened for with O_EXCL. Its better to use __test_dev_for_mkfs
So for th
Trivial patch:
./btrfs-progs/btrfs-select-super -s 0 /dev/sdc
using SB copy 0, bytenr 65536
No valid Btrfs found on /dev/sdc
Open ctree failed
The line 'using..' is confusing which gives an
indication that command is successful
This patch will avoid that when command fails
Signed-off-by: Anand J
33 matches
Mail list logo
