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
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
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
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
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,
Kai Krakow wrote:
> Aastha Mehta 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 appearing a
Roger Binns wrote:
> On 27/04/13 14:40, Calvin Walton wrote:
>> Unfortunately, bugfixes in btrfs have tended to be *not* backported;
>> aside from a few special cases, ...
>
> Your efforts to scare me are admirable, but have failed :-)
>
> As btrfs development has progressed, the probability of
Martin wrote:
> Or perhaps include the same Ceph code routines into btrfs?...
That's actually what I was thinking. The CRUSH code is actually already
pretty well factored out - it lives in net/ceph/crush/ in the kernel source
tree, and is treated as part of 'libceph' (which is used by both th
Hugo Mills wrote:
> On Thu, Apr 18, 2013 at 02:45:24PM +0100, Martin wrote:
>> Dear Devs,
>> Note that esata shows just the disks as individual physical disks, 4 per
>> disk pack. Can physical disks be grouped together to force the RAID data
>> to be mirrored across all the nominated groups?
>
>
David Sterba wrote:
> On Tue, Feb 26, 2013 at 01:45:12PM -0800, Alex Elsayed wrote:
>> Hey, I was looking at the wiki 'unclaimed projects' list and I thought
>> I'd take a look at what might be needed to use the swap-over-n{fs,bd}
>> functionality in order to i
Alex Elsayed wrote:
...and a second version, because I forgot to actually remove the calls to
tcm_node in favor of poking configfs like I said.
---cut---
#!/bin/bash
gen_naa() {
local UUID="$( uuidgen -r )"
UUID="${UUID//-/}"
UUID="${UUID:0:9}&quo
Alex Elsayed wrote:
> Roman Mamedov wrote:
>
>> On Wed, 27 Feb 2013 13:23:23 +1100
>> "Fajar A. Nugraha" wrote:
> This could be pretty easily put into a shell script that uses du -b and
> manually pokes configfs instead of calling tcm_node, and it'd b
Roman Mamedov wrote:
> On Wed, 27 Feb 2013 13:23:23 +1100
> "Fajar A. Nugraha" wrote:
>
>> Not to mention the hassle in accessing the data if it resides on a
>> partition inside the file (e.g. you need losetup + kpartx to access it,
>> and you must remember to do the reverse when you're finished
Hey, I was looking at the wiki 'unclaimed projects' list and I thought I'd
take a look at what might be needed to use the swap-over-n{fs,bd}
functionality in order to implement swapfile support. It *looks* like it's
surprisingly uncomplicated - to the point where I suspect I'm missing
something
Remco Hosman - Yerf IT wrote:
> would be really cool if a TRIM to the loopback device would do a 'hole
> punch' on the file
There are patches on the scsi target mailing list to make this happen for
the FILEIO backend. This has the added benefit that if you set it up via
LIO, it appears as a ful
Gareth Pye wrote:
> On Thu, Feb 21, 2013 at 3:46 AM, Matias Bjorling wrote:
>> Recent development in Linux SSD caches, uses a block IO approach to solve
>> caching. The approach assumes that data is stable on disk and evicts data
>> based on LRU, temparature, etc. This is great for read only IO p
Matias Bjorling wrote:
> Here is a short proposal for the hybrid storage cache idea with
> introduction/motivation and a bird's eye view of an approach to implement
> a hybrid storage cache for btrfs. Please note that there is currently no
> available patches. We would like to get as much input be
In using btrfs-restore, I've found that much of the time the interface is a
poor match for what I'm trying to do. It works fine in the simplest cases
where you want to extract everything, but wanting to extract a subset of the
files in a directory is more difficult, and it gets more complicated
Alex Elsayed wrote:
> offset 0x10040 (64K + 64 bytes) there's the string BHRfS (hex 5F 42 48 52
> 66 53 5f). That matches the documentation (the first superblock should be
Ugh, and resending it stripped the underscores. _BHRfS_ is at 0x10040, not
BHRfS (which would be at 0x10
Just realized I messed up sending this to the list.
Roman Mamedov wrote:
> On Mon, 30 Jul 2012 23:26:42 -0400 (EDT)
> serial...@lavabit.com wrote:
>
>> 1) is there a tool to help me recover data from my fs? I don't have a
>> backup of my partition table and so I have about 500GB of space where a
Dan Williams wrote:
> The consensus from LSF was that bcache need not invent a new interface
> when md and dm can both do the job. As mentioned in patch 7 this series
> aims to be a minimal conversion. Other refactoring items like
> deprecating register_lock for mddev->reconfig_mutex are deferre
Alex Elsayed gmail.com> writes:
>
> Chris Mason oracle.com> writes:
> > I think the btrfsck output is missing. It sounds like we'll survive if
> > we just skip this part of the log replay. I'll cook a patch based on
> > the btrfsck output.
>
>
Chris Mason oracle.com> writes:
> I think the btrfsck output is missing. It sounds like we'll survive if
> we just skip this part of the log replay. I'll cook a patch based on
> the btrfsck output.
It was inline in my first message, immediately after the BUG trace.
--
To unsubscribe from this
Chris Mason oracle.com> writes:
>
> Ugh ok. The first thing I'd like to do is give you a patch to
> completely disable the tree log replay and give you the chance to backup
> critical data.
>
> Do you already have a backup of the critical things on this drive? The
> problem you're hitting is
Chris Mason oracle.com> writes:
>
> On Fri, Feb 12, 2010 at 09:04:39PM +0000, Alex Elsayed wrote:
> > I'm getting a rather nasty BUG when I try to mount this filesystem,
> > _including_ when I specify -o ro. I'm unsure what caused it, but the
> > prob
Alex Elsayed gmail.com> writes:
>
> Mike Fedyk mikefedyk.com> writes:
>
> >
> > On Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed gmail.com>
> wrote:
> > > I'm getting a rather nasty BUG when I try to mount this filesystem,
> > > _includi
Mike Fedyk mikefedyk.com> writes:
>
> On Fri, Feb 12, 2010 at 1:04 PM, Alex Elsayed gmail.com>
wrote:
> > I'm getting a rather nasty BUG when I try to mount this filesystem,
> > _including_ when I specify -o ro. I'm unsure what caused it, but the proble
I'm getting a rather nasty BUG when I try to mount this filesystem,
_including_ when I specify -o ro. I'm unsure what caused it, but the problem
manifested after my computer hardlocked while reading my RSS feeds, complete
with flashing lights. After I rebooted it, the screen filled with panic
m
---
Documentation/filesystems/btrfs.txt |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/filesystems/btrfs.txt
b/Documentation/filesystems/btrfs.txt
index 64087c3..29ee7dd 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.
Alex Elsayed wrote:
> H. Peter Anvin wrote:
>> implementation in Java, called "Jerasure".) Implementability using real
>> array instruction sets is key to decent performance.
> Actually, it is made clear in the paper that Jerasure is written as a C
> library,
H. Peter Anvin wrote:
> implementation in Java, called "Jerasure".) Implementability using real
> array instruction sets is key to decent performance.
Actually, it is made clear in the paper that Jerasure is written as a C
library, and Clearsafe is the only Java implementation. Don't let the nam
Alex Elsayed wrote:
> Ric Wheeler wrote:
>
>> On 07/17/2009 11:49 AM, H. Peter Anvin wrote:
>>> Ric Wheeler wrote:
>>>>>
>>>>> The bottom line is pretty much this: the cost of changing the encoding
>>>>> would appear to out
Ric Wheeler wrote:
> On 07/17/2009 11:49 AM, H. Peter Anvin wrote:
>> Ric Wheeler wrote:
The bottom line is pretty much this: the cost of changing the encoding
would appear to outweigh the benefit. I'm not trying to claim the Linux
RAID-6 implementation is optimal, but it is si
Andrey Kuzmin wrote:
> Personally, I don't see any. Porting zfs to Linux will cost (quite)
> some time and effort, but this is peanuts compared to what's needed to
> get btrfs (no offense meant) to maturity level/feature parity with
> zfs. The only thing that could prevent this is CDDL licensing
62 matches
Mail list logo
