El miércoles, 23 de agosto de 2017 2:26:48 (CEST) Timofey Titovets escribió:
> + for (i = 0; i < workspace->sample_size; i += sizeof(zero)) {
> + if (memcmp(>sample[i], , sizeof(zero)))
> + return false;
Instead of just checking for 0, wouldn't it be a better
El sábado, 6 de agosto de 2016 0:45:13 (CEST) Tomasz Chmielewski escribió:
> And, miracle cure O_o
>
> # file ./2016-08-02/serverX/syslog.log
> ERROR: cannot read `./2016-08-02/serverX/syslog.log' (Input/output
> error)
>
> # echo 3 > /proc/sys/vm/drop_caches
>
> # file
El jueves, 12 de mayo de 2016 8:46:00 (CEST) Nikolaus Rath escribió:
> *ping*
>
> Anyone any idea?
All I can say is that I've had the same problem in the past. In my
case, the problematic files where active torrents. The interesting
thing is that I was able to read them correctly up to a point,
El Domingo, 10 de marzo de 2013 12:23:56 Martin Steigerwald escribió:
Any other idea to make it less cryptic?
I would vote for optionally allowing to expand the codes into
something more verbose and self-documented, ie:
1CmS1P - 1Copy-manyStripes-1Parity
--
To unsubscribe from this list: send
On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió:
From: Arne Jansen sensi...@gmx.net
Signed-off-by: Jan Schmidt list.bt...@jan-o-sch.net
Signed-off-by: Arne Jansen sensi...@gmx.net
---
This is the rebased version of Arne's qgroup patch set. He's the
original author, which is
[resend, for some reason kmail formatted the previous message with html]
On Martes, 5 de junio de 2012 09:50:56 Alexander E. Patrakov escribió:
Result: boot from ext4 takes less than 15 seconds, while boot from
btrfs takes 9 minutes (or 5 minutes if I disable readahead - the data
file is not
On Viernes, 7 de Octubre de 2011 21:10:33 Asdo escribió:
failures, but you can always mount by rolling back to a previous
uberblock, showing an earlier view of the filesystem, which would be
consistent.
This is already available in Btrfs, command btrfsck -s.
--
To unsubscribe from this list:
[81075c7d] kthread+0x8d/0xa0
[816af5f4] kernel_thread_helper+0x4/0x10
[] 0x
pages is not always freed. Fix it removing the unnecesary additional return.
Signed-off-by: Diego Calleja dieg...@gmail.com
---
fs/btrfs/ioctl.c |4 +---
1 file
On Sábado, 27 de Agosto de 2011 00:33:51 Diego Calleja escribió:
On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió:
Do you have autodefrag enabled?
Yes
It seems that this problem has already been solved by Konstantin
Khlebnikov, he posted a patch on 17 August
[PATCH] btrfs
On Viernes, 26 de Agosto de 2011 22:59:54 Mitch Harder escribió:
Do you have autodefrag enabled?
Yes
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
This is what I got in my dmesg...I have lots of these warnings, didn't
notice it until now.
[ 235.705766] [ cut here ]
[ 235.705772] WARNING: at fs/inode.c:1309 iput+0x1ed/0x210()
[ 235.705773] Hardware name:
[ 235.705774] Modules linked in: ipt_REJECT
On Miércoles, 26 de Enero de 2011 11:13:20 Erik Logtenberg escribió:
Diego, pls don't read anything negative in my comments, I enjoy and
respect your work very much! If you could find time to add those latest
changes to the wiki, it would be greatly appreciated.
Thanks for your suggestion,
On Lunes, 16 de Agosto de 2010 17:45:29 Chris Ball escribió:
Note that Btrfs does not yet have a fsck tool that can fix errors.
While Btrfs is stable on a stable machine, it is currently possible
to corrupt a filesystem irrecoverably if your machine crashes or
loses power. This
On Viernes, 6 de Agosto de 2010 14:21:44 Ulrich Hecht escribió:
ioctl(d, BTRFS_IOC_COMPR_SIZE, size);
I wonder...it's not possible to fit this into FIEMAP somehow? I
though that FIEMAP has been designed with compressed data in
mind.
--
To unsubscribe from this list: send the line unsubscribe
Hi, I'm using KVM, and the virtual disk (a 20 GB file using the raw
qemu format according to virt-manager and, of course, placed on a btrfs
filesystem, running the latest mainline git) is awfully slow, no matter
what OS is running inside the VM. The PCBSD installer says it's copying
data at a
On Viernes, 26 de Febrero de 2010 20:09:15 Chris Mason escribió:
My would be the super block, it is updated more often and so more likely
to get stuck in the array's cache.
IIRC, this is exactly the same problem that ZFS users have been
hitting. Some users got cheap disks that don't honour
On Jueves 22 Octubre 2009 12:15:59 Andi Drebes escribió:
I'd really appreciate to see a TODO section somewhere in the wiki. [..]
There's one (needs updating):
http://btrfs.wiki.kernel.org/index.php/Development_timeline
Also, http://btrfs.wiki.kernel.org/index.php/Project_ideas has some ideas.
On Wednesday 07 October 2009 05:17:54 Chris Mason escribió:
Thanks, I'll try to reproduce. Which raid level did you use for data?
If not raid1, could you try with raid1? ;)
I'm not sure, since the utils won't tell. I mkfs'ed and mounted one of the 3.5GB
files with no special options, and
On Wednesday 07 October 2009 21:45:29 Chris Mason escribió:
I'm afraid this is good old enospc. Balancing still needs some work to
be completely safe.
I've tried using less data and raid1, but I can't reproduce it.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the
By the way, i think it'd be useful if debug-tree would tell which policy
the fs is applying to each chunk. Something like this:
item 4 key (FIRST_CHUNK_TREE CHUNK_ITEM 8379826176) itemoff 3495
itemsize 112
chunk length 319881216 owner 2 type 17 (data on RAID1)
I was playing with btrfs with 2 files of 3.5 GB (using loop), I completely
zeroed one of the files. As expected, I had checksum failures, and I run
btrfs-vol -b just to see what happened, and I got this (using -rc3):
[25765.340492] btrfs csum failed ino 260 off 122880 csum 2566472073 private
We should always check btrfs_alloc_path(). Some places BUG(),
others return -ENOMEM, btrfs_insert_dir_item() seems like it can return
safely.
Signed-off-by: Diego Calleja dieg...@gmail.com
--- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200
+++ linux/fs/btrfs/dir-item.c
You probably should have CC'ed the btrfs mailing list
(I already did in this mail)
On Sábado 01 Agosto 2009 11:50:08 Thomas Meyer escribió:
kernel BUG at fs/btrfs/disk-io.c:2221!
invalid opcode: [#1] PREEMPT SMP
last sysfs file: /sys/block/sdc/sdc1/start
CPU 1
Modules linked in:
On Miércoles 25 Febrero 2009 22:07:33 Steven Pratt escribió:
All in all good progress. Results and graphs can be found here:
http://btrfs.boxacle.net/repository/raid/history/History.html
Some graphs seem to be broken...btrfs gets a transparent color.
For example here:
On Miércoles 25 Febrero 2009 23:55:08 Steven Pratt escribió:
Unless I am missing something, what you are referring to is a simple
wraping/alignment issue in the key on the long name on the experimental
btrfs. It is the Brown bar. Let me know if this is not the issue.
doh, you're right.
There are some places that don't check at all btrfs_alloc_path() failures,
I added BUG_ON's for all of them, as many other codepaths that don't know
how to handle the failures seem to do.
In case of not applying this patch, I must notice that there's one real
bugfix that should be applied, it's a
El Tue, 9 Dec 2008 13:09:51 -0500, Lee Trager [EMAIL PROTECTED] escribió:
It does seem that doing it with volumes would limit user control and add
lots of complexity to such a simple task.
IMHO, WRT compression it's the contrary. Compression on a per-file basis has
never been very succesful
I got this lockdep warning while running tiobench on a clean btrfs filesystem
with the latest code available (commit 2c41b36dd2f9fb5dee150f20c84895496e0642f2)
But it was a purely read-only workload: only root could write to the
filesystem and I was running tiobench as an user, which was spitting
28 matches
Mail list logo
