On Fri, 20 Jul 2018, Alexander Wetzel wrote:
> [ 979.223808] BTRFS: error (device sdc2) in __btrfs_cow_block:1080: errno=-5
> IO failure
Are there no other messages in syslog? "IO failure" (from
fs/btrfs/super.c:75) sounds like a problem with the underlying device.
Maybe try w/o the "discard"
Hi,
after upgrading this powerpc32 box from 4.10-rc2 to -rc4, the message
below occured a few hours after boot. Full dmesg and .config:
http://nerdbynature.de/bits/4.10-rc4/
Any ideas?
Thanks,
Christian.
Faulting instruction address: 0xc02d4584
Oops: Kernel access of bad area, sig: 11
On Fri, 12 Aug 2016, Russell Coker wrote:
> There are a variety of ways of giving the same result that rm
> doesn't reject. "/*" Wasn't caught last time I checked. See the above
> URL if you want to test out various rm operations as root. ;)
Oh, yes - "rm -r /*" would work, even with a current
On Mon, 8 Aug 2016, Ivan Sizov wrote:
> I'd ran "rm -rf //" by mistake two days ago. I'd stopped it after five
Out of curiosity, what version of coreutils is this? The --preserve-root
option is the default for quite some time now:
> Don't include dirname.h, since system.h does it now.
> (usage,
On Mon, 27 Oct 2014 at 16:35, David Sterba wrote:
Yeah sorry, I sent the v2 too late, here's an incremental that applies
on top of current 3.18-rc
https://patchwork.kernel.org/patch/5160651/
Yup, that fixes it. Thank you! If it's needed:
Tested-by: Christian Kujau li...@nerdbynature.de
Hi,
after upgrading from 3.4.0 to 3.5.0-rc5 on this powerpc machine, the
following is printed during bootup:
[ 18.630750] device fsid ce8c9df5-0a93-47c6-adf6-25084f352a4f devid 1
transid 11061 /dev/hda7
[ 18.637193] btrfs: disk space caching is enabled
[ 18.706423] btrfs: no
On Tue, 3 Jul 2012 at 01:41, Ilya Dryomov wrote:
after upgrading from 3.4.0 to 3.5.0-rc5 on this powerpc machine, the
following is printed during bootup:
[ 18.630750] device fsid ce8c9df5-0a93-47c6-adf6-25084f352a4f devid 1
transid 11061 /dev/hda7
[ 18.637193] btrfs: disk
Resubmitting, as it doesn't seem to be upstream yet.
-
Remove EXPERIMENTAL flag from btrfs and also state that the disk format
has indeed been finalized.
Signed-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/Documentation/filesystems/btrfs.txt
b
Hi,
I've sent this (see below) a while ago, the patch from Miao Xie is from
March even. I still cannot compile btrfs-progs without his fix. Please
include this fix into the repo.
Thanks,
Christian.
Christian Kujau wrote on 2010-04-22 24:50 :
compiling the latest checkout of btrfs-progs-git, I
-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/Documentation/filesystems/btrfs.txt
b/Documentation/filesystems/btrfs.txt
index 64087c3..da67070 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -12,9 +12,9 @@ number of challenges with scaling
Hi,
compiling the latest checkout of btrfs-progs-git, I still get the compiler
error Miao Xie reported[0] in March, along with a patch:
cc1: warnings being treated as errors
btrfs-list.c: In function 'ino_resolve':
btrfs-list.c:511: warning: implicit declaration of function 'strndup'
Hi,
while running some filesystem benchmarks[0] I noticed the following
message in my logs during bonnie++:
device fsid 944150ad12159fd6-cc6b5d7368bfb90 devid 1 transid 7 /dev/md0
INFO: task btrfs-transacti:4083 blocked for more than 120 seconds.
echo 0 /proc/sys/kernel/hung_task_timeout_secs
On Fri, 5 Feb 2010 at 12:01, David Miller wrote:
Can you rerun your test with the following patch applied?
It will obtain more information for the btrfs developers.
Thanks, David! Here it is:
[ 1861.965178] Kernel unaligned access at TPC[10101f18]
btrfs_csum_final+0x38/0x60 [btrfs]
[
On Fri, 5 Feb 2010 at 21:32, David Miller wrote:
My debugging patch didn't work correctly.
Can you try using this one instead?
Hm, now it looks like this, but I don't know how it'd reveal more
information:
[ 210.707051] Kernel unaligned access at TPC[10101f18]
btrfs_csum_final+0x38/0x60
On Sun, 27 Dec 2009 at 14:50, jim owens wrote:
And I don't even care about comparing 2 filesystems, I only care about
timing 2 versions of code in the single filesystem I am working on,
and forgetting about hardware cache effects has screwed me there.
Not me, I'm comparing filesystems - and
On Sun, 27 Dec 2009 at 17:33, ty...@mit.edu wrote:
Yes, but given many of the file systems have almost *exactly* the same
Almost indeed - but curiously enough some filesystem are *not* the same,
although they should. Again: we have 8GB RAM, I'm copying ~3GB of data, so
why _are_ there
On Fri, 25 Dec 2009 at 11:14, ty...@mit.edu wrote:
Did you include the sync in part of what you timed?
In my generic tests[0] I do sync after each of the cp/tar/rm
operations.
Peter was quite
right --- the fact that the measured bandwidth in your cp test is
five times faster than the disk
On Fri, 25 Dec 2009 at 11:33, ty...@mit.edu wrote:
caches, though; if you are going to measure read as well as writes,
then you'll probably want to do something like echo 3
/proc/sys/vm/drop-caches.
Thanks for the hint, I could find sys/vm/drop-caches documented in
Documentation/ but it's
On Fri, 25 Dec 2009 at 10:56, Christian Kujau wrote:
Thanks for the hint, I could find sys/vm/drop-caches documented in
--^ not, was what I meant to say,
but it's all there, as drop_caches in Documentation/sysctl/vm.txt
Christian.
Documentation/ but it's good
I've had the chance to use a testsystem here and couldn't resist running a
few benchmark programs on them: bonnie++, tiobench, dbench and a few
generic ones (cp/rm/tar/etc...) on ext{234}, btrfs, jfs, ufs, xfs, zfs.
All with standard mkfs/mount options and +noatime for all of them.
Here are
Hi,
I could not find this anywhere else reported, so here we go:
creating a new btrfs filesystem (btrfs-progs-unstable from git) and
mounting it succeeds, unmounting however fails with the kernel messages
attached to this mail. After that, I can still read and write to the
btrfs mount, but
On Tue, 5 May 2009, Chris Mason wrote:
Somehow xen is turning a barrier request into an IO error. That's
really quite strange, but you can mount -o nobarrier.
Thanks for the quick reply - yes, that helped. So, is that something I
should report to the Xen folks? These other filesystems I can
22 matches
Mail list logo
