Nikolai Grigoriev posted on Tue, 26 Aug 2014 19:39:08 -0400 as excerpted:
> Kernel: 3.8.13-35.3.5.el6uek.x86_64 #2 SMP Fri Aug 8 21:58:11 PDT 2014
> x86_64 x86_64 x86_64 GNU/Linux
> Btrfs v0.20-rc1
I've no answer for your question, but you know how old both your kernel
and btrfs-progs versions
On Fri, May 30, 2014 at 03:16:10PM +0800, Qu Wenruo wrote:
> btrfs_punch_hole() will truncate unaligned pages or punch hole on a
> already existed hole.
> This will cause unneeded zero page or holes splitting the original huge
> hole.
>
> This patch will skip already existed holes before any page
On Tue, Aug 26, 2014 at 11:30:01AM -0400, Chris Mason wrote:
>
>
> On 08/26/2014 11:15 AM, Liu Bo wrote:
> > An user reported this, it is because that lseek's SEEK_SET/SEEK_CUR/SEEK_END
> > allow a negative value for @offset, but btrfs's SEEK_DATA/SEEK_HOLE don't
> > prepare for that and convert
On Wed, Aug 27, 2014 at 9:19 AM, Liu Bo wrote:
> On Fri, May 30, 2014 at 03:16:10PM +0800, Qu Wenruo wrote:
>> btrfs_punch_hole() will truncate unaligned pages or punch hole on a
>> already existed hole.
>> This will cause unneeded zero page or holes splitting the original huge
>> hole.
>>
>> This
Am Dienstag, 15. Juli 2014, 11:01:25 schrieb Hugo Mills:
> On Tue, Jul 15, 2014 at 11:09:53AM +0200, Martin Steigerwald wrote:
> > Hello!
> >
> > This is with 3.16-rc4 – stepped back to this one after having two hangs in
> > one day with 3.16-rc5, see other thread started by me:
> >
> > martin@me
On Wed, Aug 27, 2014 at 09:41:14AM +0100, Filipe David Manana wrote:
> On Wed, Aug 27, 2014 at 9:19 AM, Liu Bo wrote:
> > On Fri, May 30, 2014 at 03:16:10PM +0800, Qu Wenruo wrote:
> >> btrfs_punch_hole() will truncate unaligned pages or punch hole on a
> >> already existed hole.
> >> This will ca
Hi!
Now I get this with 3.17-rc2:
merkaba:~> LANG=C df -hT / /home
Filesystem Type Size Used Avail Use% Mounted on
/dev/dm-5 btrfs 30G 17G 23G 43% /
/dev/dm-0 btrfs 160G 129G 59G 69% /home
/: 17+23 = 40 GiB, compressed 10 GiB away with lzo?
/home: 59+129 = 188 GiB,
On 08/27/2014 04:37 AM, Liu Bo wrote:
> On Tue, Aug 26, 2014 at 11:30:01AM -0400, Chris Mason wrote:
>>
>>
>> On 08/26/2014 11:15 AM, Liu Bo wrote:
>>> An user reported this, it is because that lseek's SEEK_SET/SEEK_CUR/SEEK_END
>>> allow a negative value for @offset, but btrfs's SEEK_DATA/SEEK_HOL
On Aug 27, 2014, at 5:45 AM, Martin Steigerwald wrote:
> Hi!
>
> Now I get this with 3.17-rc2:
>
> merkaba:~> LANG=C df -hT / /home
> Filesystem Type Size Used Avail Use% Mounted on
> /dev/dm-5 btrfs 30G 17G 23G 43% /
> /dev/dm-0 btrfs 160G 129G 59G 69% /home
>
>
Good questions, should have included that info in the OP.
The current versions I can get, but I'm frankly terrified to try to
roll back to prior versions to "test" this, since back in that land be
monsters with deadlocks preventing degraded volumes from being fixed
and other challenges I wasn't qu
From: Arvin Schnell
commit 46de1a6ec3dbb0db203baa6c46cb64ba9b000ea2 changed the
parameters of btrfs_read_and_process_send_stream(). This breaks
snapper compilation. We can include version defines usable for the C
preprocessor.
Version 0.1.0: API up to and including 46de1a6ec3dbb0db2 (3.14.x)
V
Kill the BUG_ON.
Signed-off-by: David Sterba
---
disk-io.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/disk-io.c b/disk-io.c
index 8db0335bc81b..7ddd4b90836f 100644
--- a/disk-io.c
+++ b/disk-io.c
@@ -152,7 +152,8 @@ int readahead_tree_block(struct btrfs_root *root, u64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
Two days ago I mistakenly deleted a directory on a btrfs file system. As
soon as I realized, I cleanly unmounted the partition, and have not
touched it since then. I have no snapshot and no backup; I was on
vacations with my laptop, and the d
On Wed, Aug 27, 2014 at 07:47:45PM +0200, David Sterba wrote:
> Kill the BUG_ON.
>
> Signed-off-by: David Sterba
> ---
> disk-io.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/disk-io.c b/disk-io.c
> index 8db0335bc81b..7ddd4b90836f 100644
> --- a/disk-io.c
> +++ b
The autodefrag code skips defrag when two extents are adjacent. But one
big advantage for autodefrag is cutting down on the number of small
extents, even when they are adjacent. This commit changes it to defrag
all small extents.
This is especially useful when trying to use compression on slowl
Duncan <1i5t5.duncan cox.net> writes:
>
> Nikolai Grigoriev posted on Tue, 26 Aug 2014 19:39:08 -0400 as excerpted:
>
> > Kernel: 3.8.13-35.3.5.el6uek.x86_64 #2 SMP Fri Aug 8 21:58:11 PDT 2014
> > x86_64 x86_64 x86_64 GNU/Linux
>
> > Btrfs v0.20-rc1
>
> I've no answer for your question, but y
Also, here's the strace of the fallocate call:
http://sprunge.us/QXFN
On Wed, Aug 27, 2014 at 10:39 AM, G. Richard Bellamy
wrote:
> Good questions, should have included that info in the OP.
>
> The current versions I can get, but I'm frankly terrified to try to
> roll back to prior versions to "t
And the strace of fallocate execution against a zero-length file I
created with touch:
http://sprunge.us/BRML
You can see in the strace that fallocate thinks it worked (= 0), but
here's the file post-execution:
2014-08-27 15:49:45
root@eanna i ~ # ls -alh test.test
-rw--- 1 root root 0 Aug 27
There are two things going wrong here.
1. The "open" command fallocate is using isn't passing along the
O_CREAT flag properly.
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-utils/fallocate.c#n368
CODE: fd = open(filename, O_RDWR | (!dig && !mode ? O_CREAT : 0), 0644);
STRACE
On Wed, 27 Aug 2014 15:58:49 -0700, G. Richard Bellamy wrote:
> [..snip..]
I can use fallocate on btrfs as you tried in your first post, with or
without --keep-size, and it does the right things without errors. Running
kernel 3.14+ (patched btrfs), util-linux-2.24.2 on Gentoo.
> There are two
When entering the next level node, the @next_leaf in restore forgets to
start at the first slot. Just reset it to the first one.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmds-restore.c b/cmds-restore.c
index e94592c..918f1fb 100644
--- a/c
The printf of @offset enlightens the user little.
And the restore cmd is not a debugging tool, so just
remove the debug-info-like printf.
Signed-off-by: Gui Hecheng
---
cmds-restore.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/cmds-restore.c b/cmds-restore.c
index 918f1fb..648fbc9 1006
Steps to reproduce:
# mkfs.btrfs -f
# mount -o compress-force=lzo
# for ((i=0;i<4000;i++)); do
echo -n 'A' >> /inline_data
done
# umount
# valgrind --tool=memcheck --leak-check=full\
btrfs restore
output:
On Mon, 2014-08-25 at 05:08 +, Zooko Wilcox-OHearn wrote:
> Dear people of linux-btrfs:
>
> Thank you for btrfs! It is a beautiful thing. I say that in spite of
> the fact that it seems to have failed and eaten some of my data.
>
> I'm writing with two purposes: to get help and advice in reco
BTW，there is a develop branch from the btrfs-progs's maintainer David:
http://github.com/kdave/btrfs-progs.git
Maybe you'd like to try it, it may make some differences.
-Gui
On Mon, 2014-08-25 at 05:08 +, Zooko Wilcox-OHearn wrote:
> Dear people of linux-btrfs:
>
> Thank you for btrfs! It i
ent version is here:
git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20140827
And current stable went to v3.16 in master branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
I'd probably try 3.16 first? *shrug* At least do a btrfs check only without
--repair
26 matches
Mail list logo
