er deleted objects, if yes, then how? Thanks in advance!
--
Alex Shashkov
an max_extent_size will
immediately fail. But if we unmount and mount again, we will have
plenty of space.
This happens to me on 4.14, but I think the mainline still has the same logic.
Thanks,
Alex.
one should not be tagged as "stable"? At
least the missing bio_put in free_fs_devices is not an error case,
and would happen every time.
Thanks,
Alex.
Hi Nikolay,
In my kernel (4.14.x) the flag is called EXTENT_BUFFER_DUMMY, and
indeed I see that there is an extra dec-ref for them in
free_extent_buffer().
Thanks for clearing that up,
Alex.
On Wed, Feb 6, 2019 at 4:36 PM Nikolay Borisov wrote:
>
>
>
> On 6.02.19 г. 16:26 ч.,
don't really add any value". But with the extra ref-count, the
extent buffer will not be properly freed and will cause a memory leak,
won't it?
Thanks,
Alex.
On Tue, Nov 6, 2018 at 4:30 PM David Sterba wrote:
>
> On Wed, Aug 15, 2018 at 06:26:50PM +0300, Nikolay Borisov wro
t_empty(&fs_info->pinned_chunks)) {
struct extent_map *em;
em = list_first_entry(&fs_info->pinned_chunks,
struct extent_map, list);
list_del_init(&em->list);
free_extent_map(em);
}
Can you please comment on that?
Thanks,
Alex.
O
write_unlock(&em_tree->lock);
If the "em" was in pending_chunks, it will be deleted from that list
by "remove_extent_mapping". But it looks like in this case we also
need to drop the extra ref on "em", which was held by pending_chunks
list. I don't see it being
g that comes to 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
On Mar 2, 2018, at 11:29 AM, Liu Bo 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
>>> back on this. Last Friday I mad
d mode.
"btrfs filesystem 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
> On Feb 15, 2018, at 2:42 PM, Nikolay Borisov wrote:
>
> On 15.02.2018 21:41, Alex Adriaanse wrote:
>>
>>> On Feb 15, 2018, at 12:00 PM, Nikolay Borisov wrote:
>>>
>>> So in all of the cases you are hitting some form of premature enospc.
>>&
ning 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
way, I hope this all makes sense, and sorry for it being so long,
but thought 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:
bt
ize
things, but if we do that we might 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
Hi Liu,
On Wed, Mar 22, 2017 at 1:40 AM, Liu Bo 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 protect the list of caching blo
was introduced in kernel 3.0 above.
> Arent the btrfs headers should be there ? do they exist in another
> package ? maybe fs-headers or something like that ?
Try using the below simple Makefile[1] to compile btrfs loadable
module. You need to have the kernel-headers package installed.
You
d 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
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.
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-4
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 s
David, Holger,
Thank you for picking up that old patch of mine.
Alex.
On Fri, Jul 29, 2016 at 8:53 PM, Liu Bo 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:
>> > > For reviewers - thi
On Tue, 20 Sep 2016 07:51:52 -0800, Kent Overstreet wrote:
> On Tue, Sep 20, 2016 at 10:23:20AM -0400, Theodore Ts'o wrote:
>> On Tue, Sep 20, 2016 at 03:15:19AM -0800, Kent Overstreet wrote:
>> > Not on the list or I would've replied directly, but on Haswell,
>> > ChaCha20 (in software) is over 2
Taking a stab at a different way of replying, to try and keep Ted in the loop.
On Monday, 19 September 2016 22:50:41 PDT Theodore Ts'o wrote:
> On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote:
> > > > That key is used to protect the contents of the data file, and to
> > > > encrypt fil
On Mon, 19 Sep 2016 20:32:34 -0400, Chris Mason wrote:
> On 09/19/2016 04:58 PM, Alex Elsayed wrote:
>> When someone says "pretty simple" regarding cryptography, it's often
>> neither pretty nor simple :P
>>
>> The issue, here, is that inodes are f
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 keying
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 th
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 support.
>
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 her
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,
locks, 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!
Hello Qu, Wang,
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo 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
>> mentioned. I have several questions
Thanks for your comments, Qu.
Alex.
On Wed, Mar 30, 2016 at 2:34 AM, Qu Wenruo 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
>> mentioned. I h
Hi Qu, Wang,
On Tue, Mar 22, 2016 at 3:35 AM, Qu Wenruo wrote:
> Since we will introduce a new on-disk based dedupe method, introduce new
> interfaces to resume previous dedupe setup.
>
> And since we introduce a new tree for status, also add disable handler
> for it.
>
> Signed-off-by: Wang Xiao
ormal 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 wrote:
> This patchset can be fetched from github:
> https://github.com/adam900710/linux.git wang_dedu
Nicholas,
On Sat, Mar 12, 2016 at 12:19 AM, Nicholas D Steeves wrote:
> On 10 March 2016 at 06:10, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>> Let's return error
/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 wrote:
> On Mon, Feb 22, 2016 at 9:46 AM, Alex Lyakas wr
Signed-off-by: Alex Lyakas
---
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 +296,52 @@ static int
e_bio
will,
but it is better than to have a silent metadata corruption on disk.
Signed-off-by: Alex Lyakas
---
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..cf85714 100644
--- a/fs/
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 exa
Thank you, Filipe, for your review.
On Mon, Feb 22, 2016 at 3:05 AM, Filipe Manana wrote:
> On Sun, Feb 21, 2016 at 3:36 PM, Alex Lyakas wrote:
>> csum_dirty_buffer was issuing a warning in case the extent buffer
>> did not look alright, but was still returning success.
>>
t 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
---
fs/
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 Filipe,
Thank you for the explanation.
On Sun, Dec 13, 2015 at 5:43 PM, Filipe Manana wrote:
> On Sun, Dec 13, 2015 at 10:51 AM, Alex Lyakas wrote:
>> Hi Filipe Manana,
>>
>> My understanding of selecting delayed refs to run or merging them is
>> far from compl
t see anything
preventing that from happening.
Thanks,
Alex.
On Sun, Oct 25, 2015 at 8:51 PM, wrote:
> From: Filipe Manana
>
> In the kernel 4.2 merge window we had a refactoring/rework of the delayed
> references implementation in order to fix certain problems with qgroups.
>
k tree in 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 wrote:
> On Mon, Jul 20, 2015 at 02:56:20PM +0100, fdman...@kernel.org wrote:
&
__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 wrote:
>>
So it will return -ENOSPC.
Signed-off-by: Alex Lyakas
Reviewed-by: Josef Bacik
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 +4727,7 @@ static int flush_space(struct btrfs_
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
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
and comment on patches.
Alex.
On Thu, Nov 5, 2015 at 3:08 PM, Holger Hoffstätte
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 -ENOMEM to the caller, but we do not set *bio_re
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
;actual_count" before accounting it
in "avg_delayed_ref_runtime"?
Thanks,
Alex.
On Thu, Feb 27, 2014 at 5:56 PM, Josef Bacik wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/27/2014 10:38 AM, 钱凯 wrote:
>> I'm a little confused of what "a
);
bio->bi_end_io = end_io_func;
Thanks,
Alex.
On Wed, Jan 7, 2015 at 12:46 AM, Satoru Takeuchi
wrote:
> Hi Naota,
>
> On 2015/01/06 1:01, Naohiro Aota wrote:
>> After submit_one_bio(), `bio' can go away. However submit_extent_page()
>> leave `bio' referable if sub
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, wrote:
> From: Filipe Manana
>
> When we shrink the usable size of a device (its total_byte
wq->normal->max_active = max;
> if (wq->high)
> - workqueue_set_max_active(wq->high->normal_wq, max);
> + wq->high->max_active = max;
> }
>
> void btrfs_set_work_high_priority(struct btrfs_work_struct *work)
> di
180
[503553.950870] [] ret_from_fork+0x42/0x70
[503553.950875] [] ? kthread_create_on_node+0x180/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 stuf
_STATE_UNBLOCKED), and then we can
open a new transaction while the previous is doing
btrfs_write_and_wait_transaction.
That's what I wanted to ask.
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 t
page-cache upto ~6.9GB (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
w
see that this is not the case.
I am 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 "un
Hi Qu,
On Wed, Dec 24, 2014 at 3:09 AM, Qu Wenruo wrote:
>
> Original Message
> Subject: Re: [PATCH] btrfs-progs: rebuild missing block group during chunk
> recovery if possible
> From: Alex Lyakas
> To: Qu Wenruo
> Date: 2014年12月24日 00:49
>>
>
rec->type_flags, chunk_rec->length,
> @@ -6241,7 +6248,8 @@ static int check_chunk_refs(struct chunk_record
> *chunk_rec,
> int check_chunks(struct cache_tree *chunk_cache,
> struct block_group_tree *block_group_cache,
> struct device_ext
Hi Qu,
On Tue, Dec 23, 2014 at 7:27 AM, Qu Wenruo wrote:
>
> Original Message
> Subject: How btrfs-find-root knows that the block is actually a root?
> From: Alex Lyakas
> To: linux-btrfs
> Date: 2014年12月22日 22:57
>>
>> Greetings,
>
this line:
level = h_level;
This means 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 m
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 attac
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 enc
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
>> wrote:
>> > Why not just use the kernel crypto API? Then the user can just specify
>> > any hash the kernel su
John Williams wrote:
> On Mon, Dec 1, 2014 at 4:15 PM, Alex Elsayed 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 co
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:46 PM, Alex Elsayed 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 Ci
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
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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 que
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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
John Williams wrote:
> On Mon, Dec 1, 2014 at 3:05 PM, Alex Elsayed 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
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn
> 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 infinitesimally small co
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed
> 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 SPA
John Williams wrote:
> On Mon, Dec 1, 2014 at 12:08 PM, Alex Elsayed
> 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 SPA
Alex Elsayed wrote:
> John Williams wrote:
>> Again, irrelevant. The Spooky2, CityHash256, and Murmur3 hashes that I
>> am talking about can and do take advantage of CPU architecture. For
>> 128- and 256-bit hashes, one (or more) of those three will be
>> significantly
John Williams wrote:
> On Mon, Dec 1, 2014 at 11:28 AM, Alex Elsayed
> 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-cr
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 t
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
John Williams wrote:
> On Sat, Nov 29, 2014 at 1:07 PM, Alex Elsayed
> 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
John Williams wrote:
> On Sat, Nov 29, 2014 at 12:38 PM, Alex Elsayed
> 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
>
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 col
. 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 wrote:
> On Mon, Jul 28, 2014 at 6:31 PM, Filipe David Manana
> wrote:
>> On Sat, Jul 19, 2014 at 8:11 PM, Alex Lyakas
>&
ully.
But most important: 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
wrote:
> On snapshot creation (either writable or read-only), we do orphan cleanup
> against
at
> the end of it (sys_chunk_array), which allows you to find the blocks
> for the chunk tree and work out this mapping, which allows you to find
> everything else. I'm not 100% certain of the actual format of that
> array -- it's declared as u8 [2048], so I'm guessing there
?usp=sharing
Thanks,
Alex.
On Mon, Apr 21, 2014 at 5:55 PM, Josef Bacik 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
inode itself gets created. The patch 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 @@ a
ot;), thus
avoiding many additional comparisons that some other tool like rsync
would have done.
Thanks,
Alex.
On Sun, Apr 20, 2014 at 1:00 AM, Michael Welsh Duggan wrote:
> Assume the following scenario:
> There exists a read-only snapshot called a.
> A read-write snapshot called b i
d not need to do join_transaction/end_transaction leading to
recursive run_delayed_refs call.
Alex.
On Fri, Mar 7, 2014 at 3:01 AM, Josef Bacik wrote:
> Zach found this deadlock that would happen like this
>
> btrfs_end_transaction <- reduce trans->use_count to 0
&
Hi Josef,
how about aborting the transaction also in place that you print:
"umm, got %d back from search, was looking for %llu"
You abort in case ret<0, otherwise the code just proceeds with
extent_slot = path->slots[0];
which can't be right in that case.
Thanks,
Alex.
On M
t bad timing my end
it seems .. tl;d(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
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 s
.
Am I missing 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
deleted
the ref head, 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 wrote:
> Currently we have two rb-trees, one for delayed ref heads and one for all of
> the
> delayed refs, includi
10 +1354,10 @@ struct btrfs_root *btrfs_create_tree(struct
btrfs_trans_handle *trans,
return root;
fail:
- if (leaf) {
+ if (leaf)
btrfs_tree_unlock(leaf);
- free_extent_buffer(leaf);
- }
+ free_extent_buffer(root->node);
+
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
1 - 100 of 377 matches
Mail list logo
