On Feb 12, 2013, at 11:18 PM, Fredrik Tolf fred...@dolda2000.com wrote:
smartctl -l scterc /dev/sdX
Warning: device does not support SCT Error Recovery Control command
Doesn't seem that way to me; partly because of the SMART data, and partly
because of the errors that were logged as
On 12.02.2013 08:25, shyam btrfs wrote:
Hi Arne, Jan,
I am using btrfs directly from Linux 3.8rc5 (commit
949db153b6466c6f7cad5a427ecea94985927311). I am trying to use qgroups
functionality with a basic random-write workload, it constantly
keeps leaking memory within few minutes of IO,
On 12.02.2013 08:31, shyam btrfs wrote:
Also immediately after this problem, its impossible to mount the
filesystem. it consistently fails with
no luck here either. I tried a sync-heavy workload and crashed it
in the middle. mount took a while but succeeded.
Maybe your debug tree contains
Hi Arne,
I realize my first mail that had logs as attachment didnt show up. I
uploaded the logs at
https://docs.google.com/file/d/0B1JpdTsfQ1vgVTkwRHJjcHplZlk/edit?usp=sharing
This has the debug-tree when btrfs cannot mount (i.e. after the
crash). Also there are meminfo/slabinfo that I kept
On 12.02.2013 08:31, shyam btrfs wrote:
Also immediately after this problem, its impossible to mount the
filesystem. it consistently fails with
[ 2092.254428] BUG: unable to handle kernel NULL pointer dereference
at 03c4
[ 2092.255945] IP: [a033d0be]
On Tue, Feb 12, 2013 at 04:42:25PM -0500, Chris Mason wrote:
On Tue, Feb 12, 2013 at 02:05:35PM -0700, Richard W.M. Jones wrote:
Yes, this is inside a very recent KVM (qemu 1.3.0), using virtio-scsi
as the backing disk.
Ok, can you please run this on your virtio device file? It will
When replaying a log tree with qgroups enabled, tree_mod_log_rewind does a
sanity-check of the number of items against the maximum possible number.
It calculates that number with the nodesize of fs_root. Unfortunately
fs_root is not yet set at this stage. So instead use the nodesize from
Hi Shyam,
I sent a patch to the list
[PATCH] Btrfs: fix crash in log replay with qgroups enabled
that hopefully addresses this problem. As I haven't been able to
reproduce it, I also haven't been able to test it.
Could be please see if it fixes your problem and makes the filesystem
mountable
On Wed, Feb 13, 2013 at 11:41:08AM +0100, Lukáš Czerner wrote:
However
mkfs.btrfs /dev/sda
mkfs.ext4 -F /dev/sda
works well, however I am not sure why that is. Is that some kind of
mount(8) magic ?
This is bug in libmount. Fixed in upstream tree. The libmount in some
cases ignores the
On Wed, February 13, 2013 at 12:20 (+0100), Arne Jansen wrote:
When replaying a log tree with qgroups enabled, tree_mod_log_rewind does a
sanity-check of the number of items against the maximum possible number.
It calculates that number with the nodesize of fs_root. Unfortunately
fs_root is
On Wed, Feb 13, 2013 at 11:00:33AM +, Richard W.M. Jones wrote:
Will try the btrfsprogs patch next.
I applied this patch:
https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=commitdiff_plain;h=8fe354744cd7b5c4f7a3314dcdbb5095192a032f
to the version of btrfs-progs in Fedora
On Wed, Feb 13, 2013 at 06:10:44AM -0700, Richard W.M. Jones wrote:
On Wed, Feb 13, 2013 at 11:00:33AM +, Richard W.M. Jones wrote:
Will try the btrfsprogs patch next.
I applied this patch:
Miao made the ordered operations stuff run async, which introduced a
deadlock where we could get somebody (sync) racing in and committing the
transaction while a commit was already happening. The new committer would
try and flush ordered operations which would hang waiting for the commit to
Hi there,
after my filesystem is broken (I have no idea why, because last shut
down was nomal) I tried to repair it with btrfsck (
Btrfs v0.20-rc1-56-g6cd836d). But unfortunately the process breaks with:
parent transid verify failed on 29896704 wanted 392661 found 395689
parent transid verify
Hi,
The last few days I have been playing around with Chris Mason's
raid56-experimental branch (Thanks!) and discovered two minor issues.
Thanks,
Andreas
Andreas Philipp (2):
Minor format cleanup.
Correct allowed raid levels on balance.
fs/btrfs/ctree.h | 4 ++--
fs/btrfs/volumes.c |
On Tue, Feb 12, 2013 at 07:35:31PM -0800, Filipe Brandenburger wrote:
Hi David,
I really have concerns about the libification, in particular this commit:
6fc8b21 btrfs-progs: libify some parts of btrfs-progs
The relevant snippets that concern me below:
+libbtrfs_headers =
Hi Mark,
On Wed, Feb 13, 2013 at 1:11 PM, Mark Fasheh mfas...@suse.de wrote:
On Tue, Feb 12, 2013 at 07:35:31PM -0800, Filipe Brandenburger wrote:
Another reason of my concerns is that I've been trying to work on
exporting the equivalent of ioctl.h, with the constants and structs
needed to
With more than one btrfs volume mounted, it can be very difficult to find
out which volume is hitting an error. btrfs_error() will print this, but
it is currently rigged as more of a fatal error handler, while many of
the printk()s are currently for debugging and yet-unhandled cases.
This may
why it failed. But it might not be able to because /proc/swaps is
fundamentally unreliable.
Then, how should we do?I have no idea...
Hmm. I think I'd do something like:
- First always open with O_EXCL. If it succeeds then there's no reason
to check /proc/swaps at all. (Maybe it
Sorry, please ignore this.
I will send again later.
-Tsutomu
On 2013/02/14 11:53, Tsutomu Itoh wrote:
Currently, the following commands succeed.
# cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sda3
I think realpath() is unnecessary if it checks it by using only
stat() information. (if do not compare path)
Am I misunderstanding anything?
Sure, that'd be fine, but then you'd want to try unescaping the paths
before stati()ng them.
- z
--
To unsubscribe from this list: send the line
On Wed, 13 Feb 2013, Chris Murphy wrote:
On Feb 12, 2013, at 11:18 PM, Fredrik Tolf fred...@dolda2000.com wrote:
That's not typical for actual media problems, in my experience. :)
Quite typical, because these drives don't support SCTERC which almost
certainly means their error timeouts are
On Feb 13, 2013, at 3:17 PM, Dave Chinner da...@fromorbit.com wrote:
it is the responsibility of filesystem
tools to behave sanely, not for the rest of the world to have to
work around the dangerous behaviour of a specific filesystems'
toolset.
I appreciate this, and in particular that
On Thu, 14 Feb 2013, Chris Murphy wrote:
So the question is whether the cable problem has actually been fixed, and if
you're still getting ICRC errors from the kernel.
I'm not getting any block-layer errors from the kernel. The errors I posted
originally are the only ones I'm getting.
24 matches
Mail list logo
