To complete my previous request, the log of btrfsck 0.20_rc1_p56 which
segfaults :
checking extents
checksum verify failed on 272228352 wanted 119281BE found FFD3
checksum verify failed on 272228352 wanted 119281BE found FFD3
checksum verify failed on 272228352 wanted 119281BE found F
On Wed, Mar 13, 2013 at 02:31:27PM +0900, dima wrote:
> Hello Alex,
>
> On 03/13/2013 01:17 AM, Alex wrote:
> >Hi All,
> >
> >It seems my btrfs file space cache is corrupt; I had to run clear the log
> >through a kernel problem.
> >
> >I've seen messages that the cache is rebuilt automatically, bu
On 03/13/2013 05:53 PM, Hugo Mills wrote:
On Wed, Mar 13, 2013 at 02:31:27PM +0900, dima wrote:
Hello Alex,
On 03/13/2013 01:17 AM, Alex wrote:
Hi All,
It seems my btrfs file space cache is corrupt; I had to run clear the log
through a kernel problem.
I've seen messages that the cache is reb
On Wed, Mar 13, 2013 at 6:07 AM, Jérôme Poulin wrote:
> It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> 2 months for each.
USB flash drives are rubbish for any filesystem except FAT32 and then
still
Le 13/03/2013 11:56, Bart Noordervliet a écrit :
> USB flash drives are rubbish for any filesystem except FAT32 and then
> still only gracefully accept large sequential writes. A few years ago
> I thought it would be a good idea to put the root partition of a few
> of my small Debian servers on USB
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. The last patch
uses the framework to fix the bug(s).
v2->v3:
Accepts David and Eric review, which would result in d
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
---
btrfsctl.c| 2 +-
cmds-device.c | 4 ++--
disk-io.c | 3 ++-
find-root.c | 3 ++-
utils.c | 17 +---
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
Signed-off-by: Anand Jain
---
disk-io.c | 2 +-
find-root.c | 2 +-
volumes.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 796394f..030f080 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -880,7 +880,7 @@ static struct btrfs_fs_info *__open_ctre
Thanks Eric and David.
I have sent out V3 patch-set which will disable access
to backup super-block unless requested by the user.
here below are some test cases and results before and
after this fix.. which finds the patch works awesome.
the original problem which all this start
Creating snapshot passes extent_root to commit its transaction,
but it can lead to the warning of checking root for quota in
the __btrfs_end_transaction() when someone else is committing
the current transaction. Since we've recorded the needed root
in trans_handle, just use it to get rid of the wa
On 3/13/13 12:07 AM, Jérôme Poulin wrote:
> On Tue, Mar 12, 2013 at 10:03 PM, Eric Sandeen wrote:
>> [ 37.176790] BTRFS error (device dm-0) in __btrfs_free_extent:5143: IO
>> failure
>> [ 37.176791] btrfs is forced readonly
>> [ 37.176793] btrfs: run_one_delayed_ref returned -5
>>
>
>
> I
SCRATCH_DEV_POOL processing actually takes the first
device out for SCRATCH_DEV and leaves the rest in
SCRATCH_DEV_POOL.
I'm not totally sold on that behavior, but for now,
at least don't populate SCRATCH_DEV_POOL with newlines.
Cc: linux-btrfs@vger.kernel.org
Signed-off-by: Eric Sandeen
---
co
Run basic btrfs information commands in various ways, performing
sanity tests of: filesystem show, label, sync, and device stats
(sync is included just because it's simple). These are mostly
just smoke tests, although for example show by label & UUID
should verify that the correct fs was shown.
T
On Thu, 14 Mar 2013, Eric Sandeen wrote:
> > It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> > burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> > 2 months for each. ddrescue'ing the SSD would probably give better
> > chances of recovery and give BTR
On Wed, 13 Mar 2013 09:57:03 -0500, Eric Sandeen wrote:
[...]
> +echo "== Show device stats by mountpoint"
> +$BTRFS_UTIL_PROG device stats $SCRATCH_MNT | _filter_btrfs_device_stats
Is the number of devices in SCRATCH_DEV_POOL fixed to 3? Otherwise you
should pipe the device-stats-by-mountpoint th
I missed updating the mkfs.btrfs usage() when I added the
option to force fs overwrite.
Update that, and while we're at it add a long option, since
all other commands have long counterparts.
Signed-off-by: Eric Sandeen
---
diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 41163e0..53
Now that btrfs has an "-f" arg, we can test that it doesn't
improperly overwrite other filesystems in 032 like we do
for xfs.
Signed-off-by: Eric Sandeen
---
diff --git a/032 b/032
index bf88492..89fb225 100755
--- a/032
+++ b/032
@@ -38,12 +38,18 @@ rm -f $seq.full
. ./common.filter
# real
On 3/13/13 10:32 AM, Stefan Behrens wrote:
> On Wed, 13 Mar 2013 09:57:03 -0500, Eric Sandeen wrote:
> [...]
>> +echo "== Show device stats by mountpoint"
>> +$BTRFS_UTIL_PROG device stats $SCRATCH_MNT | _filter_btrfs_device_stats
>
> Is the number of devices in SCRATCH_DEV_POOL fixed to 3? Otherw
Run basic btrfs information commands in various ways, performing
sanity tests of: filesystem show, label, sync, and device stats
(sync is included just because it's simple). These are mostly
just smoke tests, although for example show by label & UUID
should verify that the correct fs was shown.
T
On 03/13/2013 09:57 AM, Eric Sandeen wrote:
SCRATCH_DEV_POOL processing actually takes the first
device out for SCRATCH_DEV and leaves the rest in
SCRATCH_DEV_POOL.
I'm not totally sold on that behavior, but for now,
at least don't populate SCRATCH_DEV_POOL with newlines.
Cc: linux-btrfs@vge
On 3/13/13 12:43 PM, Rich Johnston wrote:
> On 03/13/2013 09:57 AM, Eric Sandeen wrote:
>> SCRATCH_DEV_POOL processing actually takes the first
>> device out for SCRATCH_DEV and leaves the rest in
>> SCRATCH_DEV_POOL.
>>
>> I'm not totally sold on that behavior, but for now,
>> at least don't popul
Looks good Eric, but I will wait for Stefan to look at this version to
make sure all his comments have been addressed, then I will commit this
series. Thanks for the patchset.
Regards
--Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
Run basic btrfs information commands in various ways, performing
sanity tests of: filesystem show, label, sync, and device stats
(sync is included just because it's simple). These are mostly
just smoke tests, although for example show by label & UUID
should verify that the correct fs was shown.
T
On Wed, 13 Mar 2013 13:53:51 -0500, Eric Sandeen wrote:
> Run basic btrfs information commands in various ways, performing
> sanity tests of: filesystem show, label, sync, and device stats
> (sync is included just because it's simple). These are mostly
> just smoke tests, although for example show
Run basic btrfs information commands in various ways, performing
sanity tests of: filesystem show, label, sync, and device stats
(sync is included just because it's simple). These are mostly
just smoke tests, although for example show by label & UUID
should verify that the correct fs was shown.
T
On Wed, Mar 13, 2013 at 08:03:53AM -0600, Russell Coker wrote:
> On Thu, 14 Mar 2013, Eric Sandeen wrote:
> > > It seems the SSD has bad blocks now, BTRFS seems to abuse SSD disks, I
> > > burnt 1 SSD disk and 2 USB flash drive since I'm using BTRFS, in about
> > > 2 months for each. ddrescue'ing
On Fri, Mar 08, 2013 at 06:15:38AM -0700, David Sterba wrote:
> The superblock checksum is not verified upon mount.
>
> Add that check and also reorder existing checks to a more logical
> order.
>
> Current mkfs.btrfs does not calculate the correct checksum of
> super_block and thus a freshly cr
=== Terminal output ===
# mount -o recovery /dev/md0 /mnt/root
mount: wrong fs type, bad option, bad superblock on /dev/md0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# dmesg | tail
[58290.395538]
> The option -m is used to specify the regex string. -c is used to
> specify case insensitive matching. -i was already taken.
I guess that's cool if someone really wanted to use the full power of
regexes.
> In order to restore only a single folder somewhere in the btrfs
> tree, it is unfortunatel
Hi Zach,
Zach Brown wrote:
> > In order to restore only a single folder somewhere in the btrfs
> > tree, it is unfortunately neccessary to construct a slightly
> > nontrivial regex, e.g.:
> >
> > restore -m '^/(|home(|/username(|/Desktop(|/.*$' /dev/sdb2 /output
>
> But that example is just
> > > restore -m '^/(|home(|/username(|/Desktop(|/.*$' /dev/sdb2 /output
> >
> > But that example is just bonkers
>
> I agree ugly, but why bonkers (I understand that to mean silly) ?
Well, I guess I mean that it's so ugly that we can't reasonably expect
people to use it :).
> I like the id
Signed-off-by: Anand Jain
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index a32b96c..3c9eba9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,6 +2,7 @@
*.static.o
.*.o.d
version.h
+version
man/*.gz
btrfs
btrfs.static
--
1.8.1.227.g44fe835
--
To
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. The last patch
uses the framework to fix the bug(s).
v3->v4:
Fixed some warnings introduced by patch #3 below,
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
---
btrfsctl.c| 2 +-
cmds-device.c | 4 ++--
disk-io.c | 3 ++-
find-root.c | 3 ++-
utils.c | 17 +---
Signed-off-by: Anand Jain
---
disk-io.c | 2 +-
find-root.c | 2 +-
volumes.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/disk-io.c b/disk-io.c
index 796394f..c2e1c8a 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -880,7 +880,7 @@ static struct btrfs_fs_info *__open_ctre
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
Of recently and intermittently I am seeing open fail
for /dev/btrfs-control (btrfs is loaded), and there are no
dmesg errors, this may not be a complete help in digging
this issue but something which is necessary.
Thanks
Signed-off-by: Anand Jain
---
utils.c | 3 ++-
1 file changed, 2 insertions
That's because the test shouldn't be in your root in the first place.
The common way of thinking now is to create a btrfs volume with a
structure for holding subvolumes inside of which your system root is a
member. You then mount the system root via -o subvol= and will only
see it and nothing else.
On 3/13/13 10:05 PM, Anand Jain wrote:
So here is what confuses me now. :)
*every* caller of btrfs_read_dev_super() is now called with
0 for the flags variable, so it never reads the backup
under any circumstance.
If it's always called w/ 0, what is the point of the argument?
Is there anothe
On Thu, 14 Mar 2013, Chris Mason wrote:
> Bad key ordering is pretty rare, and it usually means memory
> corruptions. Are you reproducing this on the same machine or a
> different one?
I've attached a kernel message log of mounting it on another system (which
incidentally has ECC RAM) running t
41 matches
Mail list logo
