Thanks Austin for commenting.
Yes to most of it. And probably I should have titled known-issues
to known-bugs, which I meant to fix before final integration.
In general:
Its good to explore options of both compression+encryption OR an
algorithm engine which can automatically do both because
On 03/02/2016 02:23 AM, Chris Mason wrote:
On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote:
On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote:
We'll definitely move in line with the common API over time. Thanks
Anand for starting this!
I'd prefer that we keep it
Hi,
Clean tested working pulls CPUs and QTYs in stock.
115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690
Brand new sealed IP phones and QTYs in stock.
55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640
U
Austin S. Hemmelgarn wrote on 2016/03/01 11:41 -0500:
On 2016-03-01 11:08, Anand Jain wrote:
This patchset adds btrfs encryption support.
While I think this is a great feature to have, I personally think we're
better off waiting for the ext4/F2FS encryption API's to get pushed up
to the VFS l
On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/01 20:11 -0500:
> >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
> >>
> >>
> >>Chris Mason wrote on 2016/03/01 11:06 -0500:
> >>>On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
Chris Mason wrote on 2016/03/01 20:11 -0500:
On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
Chris Mason wrote on 2016/03/01 11:06 -0500:
On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
Hi Chris,
On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote:
>
>
> Chris Mason wrote on 2016/03/01 11:06 -0500:
> >On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> >>Hi Chris,
> >>
> >>On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> >>>The following changes sin
Anand Jain wrote on 2016/03/02 00:08 +0800:
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the production data yet.
Example usage:
Create an encrypted subvolume:
btrfs subvol create -e /btrfs/sv1
Paraphrase: <-
Chris Mason wrote on 2016/03/01 11:06 -0500:
On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
Hi Chris,
On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
Merge branch 'for-next' o
On Sat, Jun 20, 2015 at 12:44:51AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> After commit 4f764e515361 ("Btrfs: remove deleted xattrs on fsync log
> replay"), we can end up in a situation where during log replay we end up
> deleting xattrs that were never deleted when their file
When I've been converting from RAID1 to RAID5 I've been getting
stripes that only contain 1G regardless of how wide the stripe is. So
when I've done a large convert I've had to limit the blocks and then
do a balance of the target profile and repeat till finished.
Has anyone else seen similar?
On
John Smith posted on Tue, 01 Mar 2016 15:24:04 +0100 as excerpted:
> what is the status of btrfs raid5 in kernel 4.4? Thank you
That is a very good question. =:^)
The answer, to the best I can give it, is, btrfs raid56 mode has no known
outstanding bugs specific to it at this time (unless a de
Carlos Ortega posted on Tue, 01 Mar 2016 14:11:32 -0500 as excerpted:
> am I going crazy or was the "--fancy" option introduced after
> btrfs-progs rev 3.19.1? And if so, what rev?
lxc-ls in btrfs-progs? Not in any btrfs-progs that I'm aware of.
Maybe in some lxc-progs package or the like.
An
Qu Wenruo posted on Tue, 01 Mar 2016 15:24:03 +0800 as excerpted:
>
> Marc Haber wrote on 2016/03/01 07:54 +0100:
>> On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
>>> Didn't see the attachment though, seems to be filtered by maillist
>>> police.
>>
>> Trying again.
>
> OK, I got th
am I going crazy or was the "--fancy" option introduced after
btrfs-progs rev 3.19.1? And if so, what rev?
Thanks
--
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/majordom
On Tue, Mar 01, 2016 at 09:59:27AM -0800, Christoph Hellwig wrote:
> On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote:
> > We'll definitely move in line with the common API over time. Thanks
> > Anand for starting this!
> >
> > I'd prefer that we keep it per-subvolume for now, just bec
On Tue, Mar 01, 2016 at 11:46:16AM -0500, Chris Mason wrote:
> We'll definitely move in line with the common API over time. Thanks
> Anand for starting this!
>
> I'd prefer that we keep it per-subvolume for now, just because
> subvolumes are so cheap and because it seems like a better collection
On 2016-03-01 11:46, Chris Mason wrote:
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote:
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the produc
On Tue, Mar 01, 2016 at 05:29:52PM +0100, Tomasz Torcz wrote:
> On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
> > This patchset adds btrfs encryption support.
> >
> > Warning:
> > The code is in prototype/experimental stage and is not suitable
> > for the production data yet.
>
>
On 2016-03-01 11:08, Anand Jain wrote:
This patchset adds btrfs encryption support.
While I think this is a great feature to have, I personally think we're
better off waiting for the ext4/F2FS encryption API's to get pushed up
to the VFS layer in mainline, and then use those for the user facing
On 03/01/16 16:45, Holger Hoffstätte wrote:
> On 03/01/16 14:41, Alexander Fougner wrote:
>> All zero-sized allocations are false positives, except the
Right, I've now also reviewed them all and they are all guarded
by other conditions or plain wrong - very likely because this
particular warning i
On Wed, Mar 02, 2016 at 12:08:09AM +0800, Anand Jain wrote:
> This patchset adds btrfs encryption support.
>
> Warning:
> The code is in prototype/experimental stage and is not suitable
> for the production data yet.
Can you share some design documents? Will it be compatible
with existing encr
On Tue, Mar 01, 2016 at 11:19:34AM -0500, Carlos Ortega wrote:
> I'd like to confirm that btrfs raid actually works. My filesystem
> looks like it's a simple concatenation judging from its size in df -k
> output. btrfs filesystem df says it's a raid10, I just don't
> completely trust it. Also I'
I'd like to confirm that btrfs raid actually works. My filesystem
looks like it's a simple concatenation judging from its size in df -k
output. btrfs filesystem df says it's a raid10, I just don't
completely trust it. Also I'm stuck at version 3.19.1, I can't go
higher.
Can someone confirm that
On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote:
> Hi Chris,
>
> On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> > The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
> >
> > Merge branch 'for-next' of
> > git://git.kernel.org/pub/sc
Make few subvol related functions usable outside of
subvol command set.
Signed-off-by: Anand Jain
---
Makefile.in | 2 +-
cmds-qgroup.c| 1 +
cmds-send.c | 12 +
cmds-subvolume.c | 102 +++--
subvolume.c | 152 ++
***
*** Warning: Experimental code.
***
Adds encryption support. The branch is based on v4.5-rc6.
Signed-off-by: Anand Jain
---
fs/btrfs/Makefile | 2 +-
fs/btrfs/btrfs_inode.h | 2 +
fs/btrfs/compression.c | 53 -
fs/btrfs/compression.h | 1 +
fs/btrfs/ctree.h | 11 +-
f
*** Warning: Experimental cli and codes ***
This is the btrfs-progs part of btrfs encryption. The branch
is based on btrfs-progs v4.4.1.
Depends on keyctl-utils and libscrypt packages.
Signed-off-by: Anand Jain
---
Makefile.in | 5 +-
btrfs-list.c | 33 +
cmds-subvolume.c | 107
This patchset adds btrfs encryption support.
Warning:
The code is in prototype/experimental stage and is not suitable
for the production data yet.
Example usage:
Create an encrypted subvolume:
btrfs subvol create -e /btrfs/sv1
Paraphrase: <-
Review encryption status
btrfs subvol show /btrf
Hi,
thanks for taking a look. I hadn't actually delved in too deeply yet.
On 03/01/16 14:41, Alexander Fougner wrote:
> All zero-sized allocations are false positives, except the
> btrfs-image.c. This can be fixed by placing the num_threads at the top
> instead of after calloc().
Well..I steppe
Hi,
what is the status of btrfs raid5 in kernel 4.4? Thank you
--
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
Hey all,
Just wanted to follow up with this for anyone experiencing the same issue.
First, I tried Qu's suggestion, of re-balancing to single, then
re-balancing to RAID 6. I noticed when I completed the conversion to
single, that a few drives didn't receive an identical amount of data.
Balancing
On Mon, Feb 29, 2016 at 10:56 PM, Stanislav Brabec wrote:
> On Feb 26, 2016 at 23:00 valdis.kletni...@vt.edu wrote:
>>
>> On Fri, 26 Feb 2016 22:00:44 +0100, Stanislav Brabec said:
>>
>>> Well, it seems to be safe, even if the loop device was not allocated by
>>> mount(8) itself, as
>>> ioctl(fd,
2016-03-01 13:44 GMT+01:00 Holger Hoffstätte
:
> Hi,
>
> With btrfs-progs needing & getting some more love I decided to run today's
> master through clang's very awesome static analyzer [1] to see what a more
> complete data flow analysis than gcc's -Wall yields. The results can be
> found at [2] a
Hi,
With btrfs-progs needing & getting some more love I decided to run today's
master through clang's very awesome static analyzer [1] to see what a more
complete data flow analysis than gcc's -Wall yields. The results can be
found at [2] and are somewhat reason for concern. =:)
Please note that
Hi Chris,
On Fri, Feb 26, 2016 at 01:22:00PM +, fdman...@kernel.org wrote:
> The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b:
>
> Merge branch 'for-next' of
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6
> (2016-02-24 10:21:44 -0
Qu Wenruo wrote on 2016/03/01 15:24 +0800:
Marc Haber wrote on 2016/03/01 07:54 +0100:
On Tue, Mar 01, 2016 at 08:45:21AM +0800, Qu Wenruo wrote:
Didn't see the attachment though, seems to be filtered by maillist
police.
Trying again.
OK, I got the attachment.
And, surprisingly, btrfs
As one user in mail list report reproducible balance ENOSPC error, it's
better to add more debug info for enospc_debug mount option.
Reported-by: Marc Haber
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent-tree.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a
38 matches
Mail list logo
