extent_io.c:__extent_writepage_io has this code:
if (!compressed)
...
else if (compressed)
Signed-off-by: Diego Calleja
---
fs/btrfs/extent_io.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1ff438fd5bc2
El martes, 23 de julio de 2019 9:57:21 (CEST) Qu Wenruo escribió:
> + * A <- tree root, level 2
> + * / \
> + * B C<- tree nodes, level 1
> + */ \ / \
> + *D E F G <- tree leaves, level 0
> + *
> + * 1) Basic dropping.
> + *All above tree blocks are owned exclus
El miércoles, 15 de mayo de 2019 19:27:21 (CEST) David Sterba escribió:
> Once the code is ready for more checksum algos, we'll pick candidates
> and my idea is to select 1 fast (not necessarily strong, but better
> than crc32c) and 1 strong (but slow, and sha256 is the candidate at the
> moment)
El miércoles, 7 de marzo de 2018 19:24:53 (CET) Hugo Mills escribió:
>On multi-device filesystems, the two are not necessarily the same.
Ouch. FWIW, I was moved to do this because I saw this conversation on
IRC which made me think that people aren't understanding what the
message means:
sda2): errors: write 0, read 1, flush 0, corrupt 0,
generation 0
Signed-off-by: Diego Calleja
---
fs/btrfs/volumes.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2ceb924ca0d6..52fee5bb056f 100644
--- a/fs/btrfs/volumes.c
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(&workspace->sample[i], &zero, sizeof(zero)))
> + return false;
Instead of just checking for 0, wouldn't i
In the latest git, with KASAN enabled:
[ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at addr
8803801a76fc
[ 180.560151] Read of size 4 by task localStorage DB/924
[ 180.560160] CPU: 0 PID: 924 Comm: localStorage DB Not tainted
4.11.0-rc6-g39da7c509acf #19
[ 180.5
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 2016-08-02/serverX/syslog
ce.
--
-- Use of a keyboard or mouse may be linked to serious injuries or disorders.
diego dot torres at gmail dot com - Madrid / Spain
--
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 ht
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, t
[repost, since the previous mail was rejected by vger.kernel.org]
I got these messages in my dmesg:
[ 2587.841376] BTRFS error (device sdc1): partial page write in btrfs
with offset 0 and length 8392704
[ 2588.814182] BTRFS critical (device sdc1): bad ordered accounting
left 0 size 4096
With no
013140 00013140
Apr 22 13:49:39 ysmha01 kernel: 880303301fd8 00013140
88046988a340 88046bb69360
snip..
When the oops happens, then the mount point becomes unusable. What
would be the best path to recovery from here?
What other information may I provi
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
El Martes, 11 de diciembre de 2012 17:50:00 Stefan Behrens escribió:
> This is the user mode part of the device replace patch series.
>
> The command group "btrfs replace" is added with three commands:
> - btrfs replace start srcdev|srcdevid targetdev [-Bfr] mount_point
> - btrfs replace status mo
On Viernes, 10 de agosto de 2012 15:51:07 Jan Schmidt escribió:
> From: Arne Jansen
>
> Signed-off-by: Jan Schmidt
> Signed-off-by: Arne Jansen
> ---
> This is the rebased version of Arne's qgroup patch set. He's the
> original author, which is why I'm sending with his author tag.
A small sugg
[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 lis
ff
"pages" is not always freed. Fix it removing the unnecesary additional return.
Signed-off-by: Diego Calleja
---
fs/btrfs/ioctl.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: li
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 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.ht
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 xt_tcpud
On Lunes, 17 de Enero de 2011 22:13:01 Chris Mason escribió:
> Li Zefan also added readonly snapshot support, and I'll have the
> corresponding btrfs-progs changes integrated this week.
I think you forgot this.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body o
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 y
On Viernes, 21 de Enero de 2011 10:54:00 Helmut Hullen escribió:
> And I never have seen somethin like "Changelog" - that would be fine
> too.
Check the wiki, I keep that updated:
https://btrfs.wiki.kernel.org/index.php/Main_Page#News
--
To unsubscribe from this list: send the line "unsubscrib
> Even with cheap drives, a filesystem shouldn't die. With stuff like ZFS, you
> can use all sorts of crap and still live with it. Btrfs should follow that
> track.
Sadly that's not true, a bit of cooperation of the hardware is needed.
Both Btrfs and ZFS need to be sure that certain operations
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
On Miércoles, 28 de Julio de 2010 00:00:18 bchoc...@gmail.com escribió:
> With Btrfs's COW approach, an external cache (where data is moved to
> SSD, rather than just cached there) makes a lot of sense. Though these
As I understand it, what your proyect intends to do is to move "hot"
data to a SSD
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 40-
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 bar
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 Lunes 19 Octubre 2009 12:36:13 Andi Drebes escribió:
> However, is there any interest in patches fixing these problems? If yes: what
> would be the best strategy? Should we start fixing this "layer by layer" --
> the low-level functions first and the high-level functions later on? Or
> should
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)
num_stripes
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
t
On Wednesday 07 October 2009 16:33:09 Chris Mason escribió:
> Ok, in this case you ended up with raid0 on the data. If you:
>
> mkfs.btrfs -d raid1 /dev/loop0 /dev/loop1 you'll get data raid1.
I got a BUG...but it may be a different bug. Unlike the last time,
I didn't even need to zero one of th
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 cop
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
--- linux/fs/btrfs/dir-item.c.BAK 2009-10-06 19:00:48.887361896 +0200
+++ linux/fs/btrfs/dir-item.c 2009-10-06 19:01
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
326
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:
'found' is always 0 at that point, so the test is redundant.
Signed-off-by: Diego Calleja
---
fs/btrfs/extent_io.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: linux/fs/btrfs/extent_io.c
===
--- lin
comp_keys is duplicating what is done in btrfs_comp_cpu_keys, so just
call it.
Signed-off-by: Diego Calleja
---
fs/btrfs/ctree.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
Index: linux/fs/btrfs/ctree.c
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.
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:
http://btrfs.box
El Thu, 29 Jan 2009 11:54:20 -0500, Chris Mason
escribió:
> The unstable tree hasn't been updated yet, I want to keep it compiling
You forgot to update the unstable-standalone tree (or its going to be
discontinued?)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
t
IMHO it's a good thing to add __must_check in new code where it has sense.
Index: btrfs-unstable-standalone/ctree.c
===
--- btrfs-unstable-standalone.orig/ctree.c 2008-12-29 21:57:15.366588465
+0100
+++ btrfs-unstable-standalon
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 succesf
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
"d
Commit 3e6053d76dcbd92b2f9f4ad5ece9bce83149523e adds a gfp_mask parameter
to blkdev_issue_discard, which breaks compilation in btrfs if BIO_RW_DISCARD
is config'ed in:
/home/diego/kernel/btrfs-unstable-standalone/extent-tree.c:1896: error:
too few arguments to function 'blkdev_issue_d
hi
doing a defragmentation on a full disk ( fs_mark -d test -s 20480 -D
64 -t 8 -F ) btrfsctl return with segmentation fault, the filesystem
becomes unresponsive and dmesg show this kernel BUG:
[16790.147270] space info full 1
[39828.979719] space info full 4
[39828.979725] allocation failed flags
50 matches
Mail list logo
