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.
Previ
Currently, the following commands succeed.
# cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sda3 partition 8388604 0 -1
/dev/sdc8 partition 9765884 0 -2
On Feb 13, 2013, at 3:17 PM, Dave Chinner 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 mkfs.xfs doesn't nerf
On Feb 13, 2013, at 11:42 PM, Fredrik Tolf wrote:
>
> That's interesting to read. I haven't ever actually experienced missing a bad
> sector reported by a hard drive, though; and not for a lack of experience
> with bad sectors.
That experience is consistent with a consumer drive with an ECC
On Wed, 13 Feb 2013, Chris Murphy wrote:
On Feb 12, 2013, at 11:18 PM, Fredrik Tolf 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 well above that of the
> 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 "u
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 par
Currently, the following commands succeed.
# cat /proc/swaps
FilenameTypeSizeUsed
Priority
/dev/sda3 partition 8388604 0 -1
/dev/sdc8 partition 9765884 0 -2
On 2013/02/14 6:58, Zach Brown wrote:
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 c
On Wed, Feb 13, 2013 at 01:16:55PM +0100, Karel Zak wrote:
> 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
> >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
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 intr
Hi Mark,
On Wed, Feb 13, 2013 at 1:11 PM, Mark Fasheh 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 call btrfs-
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 = send
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 | 11
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
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
finish
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:
>
> https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=commitdiff_plain;h=8fe
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 R
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: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 ignore
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 aga
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
tree_root,
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
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: []
> btrfs_search_old_slot+0x63e/0
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 colle
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 enou
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
On Feb 12, 2013, at 11:18 PM, Fredrik Tolf 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 the drive f
29 matches
Mail list logo
