Hi David,
On 01/22/2014 02:16 AM, David Sterba wrote:
On Thu, Jan 16, 2014 at 10:32:38AM +0800, Miao Xie wrote:
Your fix makes sure that the deleted root will not get cleaned and stays
during the send. Only after it finishes it will be cleaned. Now, what if
send fails or is interrupted? There's
The send operation processes inodes by their ascending number, and assumes
that any rename/move operation can be successfully performed (sent to the
caller) once all previous inodes (those with a smaller inode number than the
one we're currently processing) were processed.
This is not true when an
Regression test for btrfs' incremental send feature:
1) Create several nested directories;
2) Create a read only snapshot;
3) Change the parentship of some of the deepest directories in a reverse
way, so that parents become children and children become parents;
4) Create another read only sn
On Tue, Jan 21, 2014 at 11:36:38PM +, Filipe David Borba Manana wrote:
> The buffer size argument passed to snprintf must account for the
> trailing null byte added by snprintf, and it returns a value >= then
> sizeof(buffer) when the string can't fit in the buffer.
>
> Since our buffer has a
On Sat, Jan 18, 2014 at 12:50:54PM +, Toggenburger Lukas wrote:
> Hello Tomasz
>
> > Have you considered per-file/per-directory selection of raid level?
>
> Sounds great, I haven't thought about it before.
>
> Do you or someone else know what the current state of development is?
> Is someone
I could still see the bug (below) with 3.13 and tried to apply the patch.
It did apply:
patching file fs/btrfs/ctree.c
Hunk #1 succeeded at 39 with fuzz 2.
Hunk #2 succeeded at 475 (offset 1 line).
Hunk #3 succeeded at 485 (offset 1 line).
Hunk #4 succeeded at 505 (offset 1 line).
Hunk #5 succeed
On Sun, Jan 19, 2014 at 09:44:39PM -0800, Roger Binns wrote:
> If you are more interested in the theoretical side then looking into
> compression would be interesting. ie how close to the theoretical best
> compression are we. Various filesystems like btrfs and NTFS make all
> sorts of compromise
On Wed, Jan 22, 2014 at 12:07 PM, Tomasz Chmielewski wrote:
> I could still see the bug (below) with 3.13 and tried to apply the patch.
>
> It did apply:
>
> patching file fs/btrfs/ctree.c
> Hunk #1 succeeded at 39 with fuzz 2.
> Hunk #2 succeeded at 475 (offset 1 line).
> Hunk #3 succeeded at 485
On Tue, Jan 21, 2014 at 04:52:00PM +, Hugo Mills wrote:
> On Tue, Jan 21, 2014 at 07:25:43AM -0500, Austin S Hemmelgarn wrote:
> > > Maybe this happens already: Might a similar effect be automatically
> > > achieved by tracking per-device I/O load averages and distributing
> > > reads based on
On Wed, Jan 22, 2014 at 01:20:10PM +0100, David Sterba wrote:
> I haven't done any extensive testing, only streaming writes, and the
> heuristic just batched writes by a given threshold before switching to
> another mirror. Load balancing was done without any logic that would
> look at actual IO l
On Wed, Jan 22, 2014 at 04:44:14PM +0800, Wang Shilong wrote:
> >So we disagree, I see a reason for the deletion protection and will do
> >the patch myself. Let's see if we can get more user feedback then.
> >
> >I'm NAKing this patch in current state, if it helps anything.
> Both ways are ok for m
On Tue, Jan 21, 2014 at 12:40:48PM +0100, Koen De Wit wrote:
> +btrfs subvol delete $SUBVOL1 >/dev/null 2>&1
> +btrfs subvol delete $SUBVOL2 >/dev/null 2>&1
Please use $BTRFS_UTIL_PROG instead of 'btrfs' and don't shorten the
command names, ie 'subvolume'.
> +cp --reflink $TESTDIR1/file1 $SUBVOL1
On Wed, Jan 22, 2014 at 01:05:33PM +0100, David Sterba wrote:
> On Sat, Jan 18, 2014 at 12:50:54PM +, Toggenburger Lukas wrote:
> > Hello Tomasz
> >
> > > Have you considered per-file/per-directory selection of raid level?
> >
> > Sounds great, I haven't thought about it before.
> >
> > Do y
This testscript creates reflinks to files on different subvolumes,
overwrites the original files and reflinks, and moves reflinked files
between subvolumes.
Signed-off-by: Koen De Wit
Reviewed-by: David Sterba
---
v1: Resend (originally submitted as test 302, btrfs/316)
v2: - use $BTRFS_UTIL_PRO
Graham Fleming posted on Tue, 21 Jan 2014 10:03:26 -0800 as excerpted:
> I want to keep playing around with BTRFSS RAID 5 and testing with it...
> assuming I have a drive with bad blocks, or let's say some inconsistent
> parity am I right in assuming that a) a btrfs scrub operation will not
> fix
Jim Salter posted on Tue, 21 Jan 2014 12:18:01 -0500 as excerpted:
> Would it be reasonably accurate to say "btrfs' RAID5 implementation is
> likely working well enough and safe enough if you are backing up
> regularly and are willing and able to restore from backup if necessary
> if a device fail
Hans-Kristian Bakke posted on Tue, 21 Jan 2014 23:09:58 +0100 as
excerpted:
> 2. There is no uninstall target in the btrfs-tools Makefile. How am I
> supposed to uninstall btrfs-progs if wanting to go back to older
> versions (or newer)?
As I run gentoo not debian, I won't try to answer the other
How do I get around this. The drive /dev/sdf has bad sectors.
Label: Store_01 uuid: ae612523-63cf-4860-a2cb-83a26d907e43
Total devices 5 FS bytes used 7.51TiB
devid1 size 0.00 used 77.00GiB path /dev/sdf
devid3 size 1.82TiB used 1.41TiB path /dev/sdd
devid4 size 2.73T
On Tue, 2014-01-21 at 17:08 +, Duncan wrote:
> Graham Fleming posted on Tue, 21 Jan 2014 01:06:37 -0800 as excerpted:
>
> > Thanks for all the info guys.
> >
> > I ran some tests on the latest 3.12.8 kernel. I set up 3 1GB files and
> > attached them to /dev/loop{1..3} and created a BTRFS RAI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/01/14 04:12, David Sterba wrote:
> I have done some work here, so far it's stalled due to more important
> work.
>
> https://btrfs.wiki.kernel.org/index.php/Project_ideas#Compression_enhancements
>
> Do you have other suggestions beyond what's
On Wed, Jan 22, 2014 at 12:45 PM, Chris Mason wrote:
> On Tue, 2014-01-21 at 17:08 +, Duncan wrote:
>> Graham Fleming posted on Tue, 21 Jan 2014 01:06:37 -0800 as excerpted:
>>
>> > Thanks for all the info guys.
>> >
>> > I ran some tests on the latest 3.12.8 kernel. I set up 3 1GB files and
>
On Wed, 2014-01-22 at 13:06 -0800, ronnie sahlberg wrote:
> On Wed, Jan 22, 2014 at 12:45 PM, Chris Mason wrote:
> > On Tue, 2014-01-21 at 17:08 +, Duncan wrote:
> >> Graham Fleming posted on Tue, 21 Jan 2014 01:06:37 -0800 as excerpted:
> >>
> >> > Thanks for all the info guys.
> >> >
> >> >
On Wed, Jan 22, 2014 at 1:16 PM, Chris Mason wrote:
> On Wed, 2014-01-22 at 13:06 -0800, ronnie sahlberg wrote:
>> On Wed, Jan 22, 2014 at 12:45 PM, Chris Mason wrote:
>> > On Tue, 2014-01-21 at 17:08 +, Duncan wrote:
>> >> Graham Fleming posted on Tue, 21 Jan 2014 01:06:37 -0800 as excerpted
On Jan 22, 2014, at 11:41 AM, G. Michael Carter wrote:
> How do I get around this. The drive /dev/sdf has bad sectors.
>
> Label: Store_01 uuid: ae612523-63cf-4860-a2cb-83a26d907e43
>Total devices 5 FS bytes used 7.51TiB
>devid1 size 0.00 used 77.00GiB path /dev/sdf
size 0.00 use
When we have two adjacent extents in relink_extent_backref,
we try to merge them. When we use btrfs_search_slot to locate the
slot for the current extent, we shouldn't set "ins_len = 1",
because we will merge it into the previous extent rather than
insert a new item. Otherwise, we may happen to cre
I'm sending this on to the btrfs developers to see if they can help.
On Tue, 2014-01-21 at 11:00 +0200, Giorgos Pallas wrote:
[...]
> I just installed 3.12-amd64 stock kernel. It booted OK, I opened a konsole
> and just tried to installed the kernel headers. Just as aptitude tried to
> start down
There is a race condition between resolving indirect ref and root deletion,
and we should gurantee that root can not be destroyed to avoid accessing
broken tree here.
Here we fix it by holding @subvol_srcu, and we will release it as soon
as we have held root node lock.
Signed-off-by: Wang Shilong
We can only tolerate ENOENT here, for other errors, we should
return directly.
Signed-off-by: Wang Shilong
---
fs/btrfs/backref.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index fd9ae72..3512437 100644
--- a/fs/btrfs/
In case this may help: Today the hard disk has reported unreadable
sectors, so the issue reported could be related to some kind of emerging
disk failure.
Giorgos
On 23/01/2014 07:47 πμ, Ben Hutchings wrote:
I'm sending this on to the btrfs developers to see if they can help.
On Tue, 2014-0
On Thu, Jan 23, 2014 at 01:41:09PM +0800, Gui Hecheng wrote:
> When we have two adjacent extents in relink_extent_backref,
> we try to merge them. When we use btrfs_search_slot to locate the
> slot for the current extent, we shouldn't set "ins_len = 1",
> because we will merge it into the previous
Hi David,
On 01/21/2014 11:56 PM, David Sterba wrote:
Commit "Btrfs-progs: make send/receive compatible with older kernels"
adds code that will become deprecated, let's clearly mark it in the
sources.
CC: Stefan Behrens
CC: Wang Shilong
Signed-off-by: David Sterba
---
send-utils.c | 28 +
31 matches
Mail list logo
