mind is to try and tune the default commit
> interval. Currently this is 30 seconds, meaning a transaction will
> happen roughly every 30 seconds (unless there is enough data batched
> that it should happen "NOW", where "NOW" is defined as "during the life
> cycle of some ar
On Mar 2, 2018, at 11:29 AM, Liu Bo <bo.li@oracle.com> wrote:
> On Thu, Mar 01, 2018 at 09:40:41PM +0200, Nikolay Borisov wrote:
>> On 1.03.2018 21:04, Alex Adriaanse wrote:
>>> Thanks so much for the suggestions so far, everyone. I wanted to report
>>>
stem df" output, after rebooting:
Data, single: total=668.01GiB, used=548.25GiB
System, single: total=32.00MiB, used=112.00KiB
Metadata, single: total=15.00GiB, used=9.11GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
We don't run btrfs scrubs. I'm not convinced that duplicat
> On Feb 15, 2018, at 2:42 PM, Nikolay Borisov <nbori...@suse.com> wrote:
>
> On 15.02.2018 21:41, Alex Adriaanse wrote:
>>
>>> On Feb 15, 2018, at 12:00 PM, Nikolay Borisov <nbori...@suse.com> wrote:
>>>
>>> So in all of t
a
"btrfs check --repair" or rebuilding filesystems (both of which require a
significant amount of downtime)?
Thanks,
Alex--
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
it best to give as much detail as possible. Thank you for
your help.
Alex
Output:
uname -a:
Linux TheMatrix 4.13.0-32-generic #35-Ubuntu SMP Thu Jan 25 09:13:46
UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
btrfs --version:
btrfs-progs v4.12
btrfs.static --version:
btrfs-progs v4.15
btrfs filesystem show
ht as well be using a filesystem like XFS. Are
there fixes queued up that will solve the problems listed in the Bugzilla
ticket referenced above? Or is our I/O-intensive workload just not a good fit
for Btrfs?
Thanks,
Alex--
To unsubscribe from this list: send the line "unsubscribe linux-btr
Hi Liu,
On Wed, Mar 22, 2017 at 1:40 AM, Liu Bo <bo.li@oracle.com> wrote:
> On Sun, Mar 19, 2017 at 07:18:59PM +0200, Alex Lyakas wrote:
>> We have a commit_root_sem, which is a read-write semaphore that protects the
>> commit roots.
>> But it is also used to protec
ckage installed.
You can place the makefile anywhere you want, and compile via:
# make -f
Thanks,
Alex.
[1]
obj-m += btrfs.o
# or substitute with hard-coded kernel version
KVERSION = $(shell uname -r)
SRC_DIR=/fs/btrfs
BTRFS_KO=btrfs.ko
# or specify any other output directory
OUT_DIR=/li
sed on one of the latest
kernels, because
here btrfs is part of the larger system, and upgrading the kernel is a
significant effort.
Hence marking the patch as RFC.
Hopefully, this patch still has some value to the community.
Signed-off-by: Alex Lyakas <a...@zadarastorage.com>
diff --git a/fs/bt
teevie 4.7.0-0.bpo.1-amd64 #1 SMP Debian 4.7.8-1~bpo8+1 (2016-10-19)
x86_64 GNU/Linux
% btrfs --version # Installed from Debian's jessie-backports
btrfs-progs v4.7.3
% sudo btrfs fi show
[sudo] password for alex:
Label: '[root]' uuid: 06c6565d-af6c-4123-9e42-3b6281
Hi,
It would be good but perhaps each task should be created via cronjobs
instead of having a script running all the time or one script via one
cronjob
Working in the enterprise environment for a major bank, we quickly
learn that these sort of daily tasks should be split up
Kind Regards,
Alex
Hi All,
Taking a step back as well- there is also the possibility that you
might not need snapshots
I say this as you're a noobie- like me!
If you're a noobie, I assume you're not using it to host some massive
Oracle DB and need all these features
If you're using this for a home media server or
David, Holger,
Thank you for picking up that old patch of mine.
Alex.
On Fri, Jul 29, 2016 at 8:53 PM, Liu Bo <bo.li@oracle.com> wrote:
> On Fri, Jul 29, 2016 at 07:01:50PM +0200, David Sterba wrote:
>> On Thu, Jul 28, 2016 at 11:49:14AM -0700, Liu Bo wrote:
>&
On Mon, 19 Sep 2016 11:15:18 -0400, Theodore Ts'o wrote:
> (I'm not on linux-btrfs@, so please keep me on the cc list. Or perhpas
> better yet, maybe we can move discussion to the linux-fsdevel@
> list.)
I apologize if this doesn't keep you in the CC, as I'm posting via gmane.
> Hi Anand,
>
>
On Mon, 19 Sep 2016 14:08:06 -0400, Zygo Blaxell wrote:
> On Sat, Sep 17, 2016 at 06:37:16AM +0000, Alex Elsayed wrote:
>> > Encryption in ext4 is a per-directory-tree affair. One starts by
>> > setting an encryption policy (using an ioctl() call) for a given
>> >
On Mon, 19 Sep 2016 14:57:33 -0400, Zygo Blaxell wrote:
> On Sat, Sep 17, 2016 at 07:13:45AM +0000, Alex Elsayed wrote:
>> IMO, this is already a flawed framing - in particular, if encrypting at
>> the extent level, one _should not_ be encrypting (or authenticating)
>
On Fri, 16 Sep 2016 23:58:31 -0700, Eric Biggers wrote:
> On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote:
>>
>> This patchset adds btrfs encryption support.
>>
>>
> Hi Anand,
> Note: even better would be an authenticated encryption mode. That isn't
> yet done by ext4 or f2fs --- I
On Sat, 17 Sep 2016 00:38:30 -0400, Zygo Blaxell wrote:
> On Fri, Sep 16, 2016 at 06:49:53AM +0000, Alex Elsayed wrote:
>> The main issue I see is that subvolumes as btrfs has them _do_
>> introduce novel concerns - in particular, how should snapshots interact
>> with keyi
On Fri, 16 Sep 2016 11:12:13 +1000, Dave Chinner wrote:
> On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote:
>>
>> This patchset adds btrfs encryption support.
>>
>> The main objective of this series is to have bugs fixed and stability.
>> I have verified with fstests to confirm that
On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote:
> Thanks for commenting. pls see inline below.
>
> On 09/15/2016 12:53 PM, Alex Elsayed wrote:
>> On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote:
>>
>>> This patchset adds btrfs encryption suppo
On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote:
> This patchset adds btrfs encryption support.
>
> The main objective of this series is to have bugs fixed and stability.
> I have verified with fstests to confirm that there is no regression.
>
> A design write-up is coming next, however
RFC: This patch not for merging, but only for review and discussion.
When mounting, we consider only the primary superblock on each device.
But when writing the superblocks, we might silently ignore errors
from the primary superblock, if we succeeded to write secondary
superblocks. In such case,
, generating more delayed refs.
At which point this recursion stops?
Do we assume that at some point all needed free-space tree blocks have
been COW'ed already, and we do not COW a tree block more than once per
transaction (unless it was written to disk due to memory pressure)?
Thanks!
Alex
Hello Qu, Wang,
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
>
>
> Alex Lyakas wrote on 2016/03/29 19:22 +0200:
>>
>> Greetings Qu Wenruo,
>>
>> I have reviewed the dedup patchset found in the github account you
>> men
Thanks for your comments, Qu.
Alex.
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
>
>
> Alex Lyakas wrote on 2016/03/29 19:22 +0200:
>>
>> Greetings Qu Wenruo,
>>
>> I have reviewed the dedup patchset found in the github a
COW.
Is my understanding correct?
I have also few nitpicks on the code, will reply to relevant patches.
Thanks for doing this work,
Alex.
On Tue, Mar 22, 2016 at 3:35 AM, Qu Wenruo <quwen...@cn.fujitsu.com> wrote:
> This patchset can be fetched from github:
> https://github.co
/file/d/0B9rmyUifdvMLbHBuSWU5dlVKNWc. Due to
this I did not include the chunk tree UUID check. Hoping very much
that fs UUID should always be valid for all tree blocks))
Thanks,
Alex.
On Mon, Feb 22, 2016 at 12:28 PM, Filipe Manana <fdman...@kernel.org> wrote:
> On Mon, Feb 22, 2016 a
Signed-off-by: Alex Lyakas <a...@zadarastorage.com>
---
fs/btrfs/disk-io.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 4545e2e..4420ab2 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -296,52 +
will,
but it is better than to have a silent metadata corruption on disk.
Signed-off-by: Alex Lyakas <a...@zadarastorage.com>
---
fs/btrfs/disk-io.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 4420ab2..c
Qu Wenruo cn.fujitsu.com> writes:
> > - As of now uses "user" keytype, I am still considering/
> >evaluating other key type such as logon.
>
> UI things can always be reconsidered later.
> Never a big problem.
This is not only a UI concern, but an API/ABI concern.
To use eCryptFS as an
Thank you, Filipe, for your review.
On Mon, Feb 22, 2016 at 3:05 AM, Filipe Manana <fdman...@kernel.org> wrote:
> On Sun, Feb 21, 2016 at 3:36 PM, Alex Lyakas <a...@zadarastorage.com> wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
&g
that the extent buffer
doesn't look alright.
The caller up the chain may BUG_ON on this, for example flush_epd_write_bio
will,
but it is better than to have a silent metadata corruption on disk.
Note: this patch has been properly tested on 3.18 kernel only.
Signed-off-by: Alex Lyakas
by __btrfs_end_transaction() that find_free_extent() does after it
completed chunk allocation (although in this case it will use the
transaction that already exists in current->journal_info).
So the deadlock still may happen?
Thanks,
Alex.
>
>
> On Mon, Nov 2, 2015 at 6:52 PM, Chris Mason <c..
anything
preventing that from happening.
Thanks,
Alex.
On Sun, Oct 25, 2015 at 8:51 PM, <fdman...@kernel.org> wrote:
> From: Filipe Manana <fdman...@suse.com>
>
> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
> references implementation in order
the context of chunk allocation, which is the
scenario that the rework was meant to avoid.
Can you please point me at what I am missing?
Thanks,
Alex.
On Wed, Jul 22, 2015 at 1:53 AM, Omar Sandoval <osan...@fb.com> wrote:
> On Mon, Jul 20, 2015 at 02:56:20PM +0100, fdman...@kernel.org
Hi Filipe,
Thank you for the explanation.
On Sun, Dec 13, 2015 at 5:43 PM, Filipe Manana <fdman...@kernel.org> wrote:
> On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas <a...@zadarastorage.com> wrote:
>> Hi Filipe Manana,
>>
>> My understanding of selecting de
Thank you, Filipe. Now it is more clear.
Fortunately, in my kernel 3.18 I do not have do_chunk_alloc() calling
btrfs_create_pending_block_groups(), so I cannot hit this deadlock.
But can hit the issue that this call is meant to fix.
Thanks,
Alex.
On Sun, Dec 13, 2015 at 5:45 PM, Filipe Manana
Hi Liu,
I was studying on how block reservation works, and making some
modifications in reserve_metadata_bytes to understand better what it
does. Then suddenly I saw this problem. I guess it depends on which
value of "flush" parameter is passed to reserve_metadata_bytes.
Alex.
On
n ret;
So it will return -ENOSPC.
Signed-off-by: Alex Lyakas <a...@zadarastorage.com>
Reviewed-by: Josef Bacik <jba...@fb.com>
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 4b89680..1ba3f0d 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4727,7
do_chunk_alloc returns 1 when it succeeds to allocate a new chunk.
But flush_space will not convert this to 0, and will also return 1.
As a result, reserve_metadata_bytes will think that flush_space failed,
and may potentially return this value "1" to the caller (depends how
reserve_metadata_bytes
nd comment on patches.
Alex.
On Thu, Nov 5, 2015 at 3:08 PM, Holger Hoffstätte
<holger.hoffstae...@googlemail.com> wrote:
> On 10/11/15 20:09, Alex Lyakas wrote:
>> Hi Naota,
>>
>> What happens if btrfs_bio_alloc() in submit_extent_page fails? Then we
>> return -ENOME
have attached to this
email.
The VM in question runs Debian Jessie, and has 3 BTRFS filesystems, including
the root filesystem. Details are included below.
Any ideas?
Thanks,
Alex
# uname -a
Linux prod-docker-1-a 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u5
(2015-10-09) x86_64 GNU
);
bio->bi_end_io = end_io_func;
Thanks,
Alex.
On Wed, Jan 7, 2015 at 12:46 AM, Satoru Takeuchi
<takeuchi_sat...@jp.fujitsu.com> wrote:
> Hi Naota,
>
> On 2015/01/06 1:01, Naohiro Aota wrote:
>> After submit_one_bio(), `bio' can go away. However submit_extent_page()
are sure that on the seconds pass there will be no
pending chunks beyond the new size, so we can shrink to new_size
safely. Is my understanding correct?
Thanks,
Alex.
On Tue, Jun 2, 2015 at 3:43 PM, <fdman...@kernel.org> wrote:
> From: Filipe Manana <fdman...@suse.com>
>
> When
to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Alex.
--
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
/0x180
[503553.950878] ---[ end trace c494302704bb5eb1 ]---
[503553.950883] BTRFS: error (device sdb) in cleanup_transaction:1692:
errno=-5 IO failure
[503553.950887] BTRFS info (device sdb): delayed_refs has NO entry
other stuff:
-
20:03 ~ % uname -a
Linux alex-ThinkPad-L530
.
Thanks!
Alex.
[1] In my case, btrfs metadata is ~10GBs and the machine has 8GB of
RAM. Due to this we need to read a lot of ebs from disk, as they are
not in the page cache. Also need to keep in mind that every COW of eb
requires a new slot in the page cache, because we index by bytenr
that we
(judging by btree_inode-i_mapping-nrpages).
But even though the used amount of metadata is less than that, this
re-COW'ing of already-COW'ed blocks seems to cause page-cache
trashing...
Thanks,
Alex.
On Mon, Jul 13, 2015 at 11:27 AM, Filipe David Manana
fdman...@gmail.com wrote:
On Sun, Jul 12, 2015
asking because I am doing some profiling of btrfs metadata work under
heavy loads, and I see that sometimes btrfs COW's almost twice more tree
blocks than the total metadata size.
Thanks,
Alex.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message
Hi Qu,
On Wed, Dec 24, 2014 at 3:09 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Original Message
Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during chunk
recovery if possible
From: Alex Lyakas alex.bt...@zadarastorage.com
To: Qu Wenruo quwen
Hi Qu,
On Tue, Dec 23, 2014 at 7:27 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Original Message
Subject: How btrfs-find-root knows that the block is actually a root?
From: Alex Lyakas alex.bt...@zadarastorage.com
To: linux-btrfs linux-btrfs@vger.kernel.org
Date: 2014年12月
for rebuild_sys_array. Should we also consider
rebuild chunks?
Thanks,
Alex.
--
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
--
To unsubscribe from this list
that if we encounter a block that seems good, we will
skip all other blocks that have lower level. Is this intended?
Thanks,
Alex.
--
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
John Williams wrote:
On Mon, Dec 1, 2014 at 9:42 AM, Austin S Hemmelgarn Except most of
the CPU optimized hashes aren't crypto hashes (other than the
various SHA implementations). Furthermore, I've actually tested the
speed of a generic CRC32c implementation versus SHA-1 using the SHA
Alex Elsayed wrote:
* He was comparing CRC32 (a 32-bit non-cryptographic hash, *via the Crypto
API*) against SHA-1 (a 128-bit cryptographic hash, via the Crypto API),
and SHA-1 _still_ won. CRC32 tends to beat the pants off 128-bit non-
cryptographic hashes simply because those require
John Williams wrote:
On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed eternal...@gmail.com
wrote:
I think there's a fundamental set of points being missed.
That may be true, but it is not me who is missing them.
* The Crypto API can be used to access non-cryptographic hashes. Full
stop
John Williams wrote:
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed eternal...@gmail.com
wrote:
Actually, I said Sure here, but this isn't strictly true. At some
point, you're more memory-bound than CPU-bound, and with CPU intrinsic
instructions (like SPARC and recent x86 have for SHA) you're
John Williams wrote:
On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed eternal...@gmail.com
wrote:
Actually, I said Sure here, but this isn't strictly true. At some
point, you're more memory-bound than CPU-bound, and with CPU intrinsic
instructions (like SPARC and recent x86 have for SHA) you're
John Williams wrote:
On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
My only reasoning is that with this set of hashes (crc32c, adler32, and
md5), the statistical likely-hood of running into a hash collision with
more than one of them at a time is
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
Incidentally, you can be 'skeptical' all you like - per Austin's message
upthread, he was testing the Crypto API. Thus, skeptical as you may be,
hard evidence shows that SHA-1 was equal to or faster
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
Incidentally, you can be 'skeptical' all you like - per Austin's message
upthread, he was testing the Crypto API. Thus, skeptical as you may be,
hard evidence shows that SHA-1 was equal to or faster
John Williams wrote:
On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed eternal...@gmail.com wrote:
hard evidence shows that SHA-1 was equal to or faster than CRC32, which
is unequivocally simpler and faster than CityHash (though CityHash comes
close).
And the CPUs in question
Alex Elsayed wrote:
So CityHash is - at best - half as fast as SHA1 with acceleration.
In fact, on the Apple A7, it would likely be slower than _software_ SHA-1.
Argh, ignore this. The CityHash readme is in bytes/cycle, which I missed on
first readthrough (why on earth they are not using
John Williams wrote:
On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed eternal...@gmail.com wrote:
And I'm not sure what is convoluted or incorrect about saying Look,
empirical evidence!
No empirical evidence of the speed of SpookyHash or CityHash versus
SHA-1 was cited. The only empirical data
John Williams wrote:
On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed eternal...@gmail.com wrote:
There's a thing called the transitive property. When CRC32 is faster than
SpookyHash and CityHash (while admittedly weaker), and SHA-1 on SPARC is
faster than CRC32, there are comparisons that can
Christoph Anton Mitterer wrote:
On Sat, 2014-11-29 at 13:00 -0800, John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com
wrote:
Why not just use the kernel crypto API? Then the user can just specify
any hash the kernel supports.
One reason
Christoph Anton Mitterer wrote:
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See:
TLS BEAST attack).
Well but here we talk about disk encryption... how would the MtE
Alex Elsayed wrote:
Christoph Anton Mitterer wrote:
On Mon, 2014-12-01 at 16:43 -0800, Alex Elsayed wrote:
including that MAC-then-encrypt is fragile
against a number of attacks, mainly in the padding-oracle category (See:
TLS BEAST attack).
Well but here we talk about disk encryption
David Sterba wrote:
On Mon, Nov 24, 2014 at 01:23:05PM +0800, Liu Bo wrote:
This brings a strong-but-slow checksum algorithm, sha256.
Actually btrfs used sha256 at the early time, but then moved to crc32c
for performance purposes.
As crc32c is sort of weak due to its hash collision
John Williams wrote:
On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed eternal...@gmail.com
wrote:
Why not just use the kernel crypto API? Then the user can just specify
any hash the kernel supports.
One reason is that crytographic hashes are an order of magnitude
slower than the fastest non
John Williams wrote:
On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed eternal...@gmail.com
wrote:
I'd suggest looking more closely at the crypto api section of menuconfig
- it already has crc32c, among others. Just because it's called the
crypto api doesn't mean it only has cryptographically
. Unless we crash in
the middle, like you pointed.
I will also look at the new patch.
Thanks!
Alex.
On Thu, Jul 31, 2014 at 3:41 PM, Filipe David Manana fdman...@gmail.com wrote:
On Mon, Jul 28, 2014 at 6:31 PM, Filipe David Manana fdman...@gmail.com
wrote:
On Sat, Jul 19, 2014 at 8:11 PM
: perhaps send should look for ORPHAN_ITEMs and
treat those inodes as deleted?
Thanks,
Alex.
On Tue, Jun 3, 2014 at 2:41 PM, Filipe David Borba Manana
fdman...@gmail.com wrote:
On snapshot creation (either writable or read-only), we do orphan cleanup
against the root of the snapshot. If the cleanup
?usp=sharing
Thanks,
Alex.
On Mon, Apr 21, 2014 at 5:55 PM, Josef Bacik jba...@fb.com wrote:
We have a big problem, but it involves a lot of moving parts, so I'm going
to
explain all of the parts, and then the problem, and then what I am doing to
fix
the problem. I want you guys to check my
. So only if the whole chunk tree grows over 4MB, we
need to create an additional SYSTEM block group, and then we need to
have a second entry in the sys_chunk_array. And so on.
Alex.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0
that fixes this for me:
alex@ubuntu-alex:/mnt/work/alex/linux-stable/source$ git diff -U10
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index d170412..06f876e 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2941,20 +2941,26 @@ again:
goto out
,
Alex.
On Sun, Apr 20, 2014 at 1:00 AM, Michael Welsh Duggan m...@md5i.com wrote:
Assume the following scenario:
There exists a read-only snapshot called a.
A read-write snapshot called b is created from a, and is then modified.
A read-only snapshot of b is created, called c.
A btrfs send
(on't)r!
Qu: is anyone actively using seed devices? I saw one post relatively
recently. I can see Ebonacco and possibly Killermist are.
Kind regards
Alex.
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi all,
Debian testing/Jessie-to-be; except kernels/btrfs-tools are from unstable so
usually couple of weeks later than you/Linus publish.
Linux XX 3.13-1-amd64 #1 SMP Debian 3.13.7-1 (2014-03-25) x86_64
Btrfs-tools v3.12 Debian standard (not particularly messed with looks like)
I've never had
something here?
Thanks,
Alex.
P.S.: by logical I (and hopefully you) mean the extent-tree level
addresses, i.e., if we have a tree block with logical=X, then we also
have an EXTENT_ITEM with key (X, EXTENT_ITEM, nodesize/leafsize).
On Fri, Feb 21, 2014 at 12:15 AM, Filipe David Borba Manana
fdman
, so we would not have found an existing ref head.
Can you pls give a clue on this?
Thanks!
Alex.
On Thu, Jan 23, 2014 at 5:28 PM, Josef Bacik jba...@fb.com wrote:
Currently we have two rb-trees, one for delayed ref heads and one for all of
the
delayed refs, including the delayed ref heads
root;
fail:
- if (leaf) {
+ if (leaf)
btrfs_tree_unlock(leaf);
- free_extent_buffer(leaf);
- }
+ free_extent_buffer(root-node);
+ free_extent_buffer(root-commit_root);
kfree(root);
return ERR_PTR(ret);
Thanks,
Alex
Lennart Poettering wrote:
On Mon, 10.03.14 23:39, Goffredo Baroncelli (kreij...@libero.it) wrote:
Well, the name is property of the admin really. There needs to be a way
how the admin can label his subvolumes, with a potentially localized
name. This makes it unsuitable for our purpose,
,
the transaction commits and we crash, then yes, the allocation is
lost.
Alex.
On Tue, Mar 4, 2014 at 8:04 AM, Miao Xie mi...@cn.fujitsu.com wrote:
On sat, 1 Mar 2014 20:05:01 +0200, Alex Lyakas wrote:
Hi Miao,
On Wed, Jan 15, 2014 at 2:00 PM, Miao Xie mi...@cn.fujitsu.com wrote:
When we mounted
not account for
it (yet). We need to add a delayed reference, which will be run at
transaction commit and update the extent tree. But free-space cache is
also written out during transaction commit. So how the issue happens?
Can you perhaps post a flow of events?
Thanks.
Alex.
In ordered to fix
the chunk mutex.
If yes, allow recursive call but don't attempt to lock/unlock the
chunk_mutex this time
Or some other way?
Thanks!
Alex.
--
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
Hi Josef,
is this the commit to look at:
6df9a95e63395f595d0d1eb5d561dd6c91c40270 Btrfs: make the chunk
allocator completely tree lockless
or some other commits are also relevant?
Alex.
On Tue, Feb 18, 2014 at 6:06 PM, Josef Bacik jba...@fb.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash
not missing anything.
Thanks,
Alex.
On Mon, Jan 6, 2014 at 10:50 AM, Hugo Mills h...@carfax.org.uk wrote:
On Sun, Jan 05, 2014 at 06:26:11PM +, Hugo Mills wrote:
On Sun, Jan 05, 2014 at 05:55:27PM +, Hugo Mills wrote:
The structure for BTRFS_SET_RECEIVED_IOCTL packs differently on 32-bit
Duncan 1i5t5.duncan at cox.net writes:
Alex posted on Tue, 04 Feb 2014 17:19:09 + as excerpted:
I have quite an (overly) complicated setup.
I had to chuckle at that one. Fits my setup to a T, altho they're
different complications than yours. I'll have to remember it the next
Blaz Balon blaz.balon at laly.si writes:
I also had some problems with syslinux.
For me it only works if I put boot folder to root of btrfs.
Didn't have a chance to do more test, but I copied /boot from default
subvolume to subvolume 0 and it boots OK.
Not sure I understand your /boot
Sorry KC:
All my VM's are on syslinux (actually extlinux) and btrfs:
Device Boot Start End Blocks Id System
/dev/vda1 *2048 7938047 3968000 83 Linux
/dev/vda2 7938048 8388607 225280 82 Linux swap / Solaris
root@VM ~ # ll /boot
with 0 and -ENOSPC and re-search for a
free extent in these cases.
Alex.
On Mon, Aug 5, 2013 at 5:25 PM, Filipe David Borba Manana
fdman...@gmail.com wrote:
In extent-tree.c:do_chunk_alloc(), early on we returned 0 (success)
when the target space was full and when chunk allocation is needed
proposed a patch to address the resumability of send-receive
some time ago in this thread:
http://www.spinics.net/lists/linux-btrfs/msg18180.html
However, this changes the current user-kernel protocol used by send,
and overall a big change, which is not easy to integrate.
Alex.
best,
Miguel
Chris Murphy lists at colorremedies.com writes:
Hmm, actually you might have found a bug.
Small typo while we're at it, below should have one l.
kernel-3.13.0-0.rc6.git0.1.fc21.x86_64
btrfs-progs-3.12-1.fc20.x86_64
Chris Murphy
Thank you muchly!
I'm kinda glad because I didn't
Hello
(Using btrfs userland 3.12)
I have my fs set up (below) I borrowed the Ubuntu scheme.
FS_TREE/@/
FS_TREE/@/etc
FS_TREE/@/var
..
get-default is 5 i.e. FS_TREE
AFAICT, perhaps I'm missing the obvious, getting the list of subvolumes only
(no snapshots) is no longer trivial?
# btrfs sub
Chris Murphy lists at colorremedies.com writes:
Specify the mount point for the Btrfs file system and it will list all
subvols on that file system.
Chris Murphy--
Thank you Chris.
When I do that on my version of the 3.12 userland:
# btrfs sub list / -o
returns nothing (with no error),
joystick wrote:
On 06/01/2014 14:11, Alex Elsayed wrote:
joystick wrote:
Just by looking at the Subjects, it seems patch number 0/1 is missing.
It might have not gotten through to the lists, or be a numbering
mistake.
No, the numbering style is ${index}/${total}, where index = 0 is a cover
Kai Krakow wrote:
Aastha Mehta aasth...@gmail.com schrieb:
Rather than a local disk, I have a remote device to which my IO
requests are sent and from which the data is fetched. I need certain
data to be fetched from the remote device after a remount. But somehow
I do not see any request
to be the case.
Thanks,
Alex.
On Mon, Oct 14, 2013 at 7:59 AM, Liu Bo bo.li@oracle.com wrote:
It's unnecessary to do qgroups accounting without enabling quota.
Signed-off-by: Liu Bo bo.li@oracle.com
---
fs/btrfs/ctree.c |2 +-
fs/btrfs/delayed-ref.c | 18 ++
fs
1 - 100 of 334 matches
Mail list logo
