Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 7:39 AM, 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

Re: [RFC] Preliminary BTRFS Encryption

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

Re: [PATCH v6 1/6] fstests: common: Introduce _post_mount_hook for btrfs

On Wed, Sep 14, 2016 at 09:55:22AM +0800, Qu Wenruo wrote: > Introduce _post_mount_hook(), which will be executed after mounting > scratch/test. > > It's quite useful for fs(OK, only btrfs yet, again) which needs to > use ioctl other than mount option to enable some of its feature. Just

Re: stability matrix (was: Is stability a joke?)

Hey. As for the stability matrix... In general: - I think another column should be added, which tells when and for   which kernel version the feature-status of each row was    revised/updated the last time and especially by whom.   If a core dev makes a statement on a particular feature, this  

[PATCH] Btrfs: kill BUG_ON in run_delayed_tree_ref

In a corrupted btrfs image, we can come across this BUG_ON and get an unreponsive system, but if we return errors instead, its caller can handle everything gracefully by aborting the current transaction. Signed-off-by: Liu Bo --- fs/btrfs/extent-tree.c | 8 +++- 1 file

Re: Is stability a joke?

On 2016-09-15 11:07, Nicholas D Steeves wrote: On Mon, Sep 12, 2016 at 01:31:42PM -0400, Austin S. Hemmelgarn wrote: In general yes in this case, but performance starts to degrade exponentially beyond a certain point. The difference between (for example) 10 and 20 snapshots is not as much as

Re: Is stability a joke?

On Mon, Sep 12, 2016 at 07:36:57PM +0200, Zoiled wrote: > Ok good to know , however from the Debian wiki as well as the link to the > mailing list only LZO compression are mentioned (as far as I remember) and I > have no idea myself how much difference there is between LZO and the ZLIB > code, I

Re: Is stability a joke?

On Mon, Sep 12, 2016 at 01:31:42PM -0400, Austin S. Hemmelgarn wrote: > In general yes in this case, but performance starts to degrade exponentially > beyond a certain point. The difference between (for example) 10 and 20 > snapshots is not as much as between 1000 and 1010. The problem here is

Re: Is stability a joke?

On Mon, Sep 12, 2016 at 08:20:20AM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-11 09:02, Hugo Mills wrote: > >On Sun, Sep 11, 2016 at 02:39:14PM +0200, Waxhead wrote: > >>Martin Steigerwald wrote: > >>>Am Sonntag, 11. September 2016, 13:43:59 CEST schrieb Martin Steigerwald: > >>Thing is:

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

k to work for a while longer until > a > long term fix becomes available. The only way to know for sure is to > test it. But it's completely sane to just switch to XFS and get back > to work also. > > Current > https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201 >

[PATCH] Btrfs: add error handling for extent buffer in print tree

Somehow we missed btrfs_print_tree when last time we updated error handling for read_extent_block(). This keeps us from getting a NULL pointer panic when btrfs_print_tree's read_extent_block() fails. Signed-off-by: Liu Bo --- fs/btrfs/print-tree.c | 7 +++ 1 file

[PATCH] Btrfs: memset to avoid stale content in btree node block

During updating btree, we could push items between sibling nodes/leaves, for leaves data sections starts reversely from the end of the block while for nodes we only have key pairs which are stored one by one from the start of the block. So we could do try to push key pairs from one node to the

[PATCH] Btrfs: improve check_node to avoid reading corrupted nodes

We need to check items in a node to make sure that we're reading a valid one, otherwise we could get various crashes while processing delayed_refs. Signed-off-by: Liu Bo --- fs/btrfs/disk-io.c | 32 1 file changed, 28 insertions(+), 4

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

o work also. Current https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20160914.n.0/compose/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20160914.n.0.iso.n.0.iso Use 'dd if=ISO of=USBstick bs=256K' that will boot anything, BIOS or UEFI. At the menu, choose Troubleshoot

Re: [RFC] Preliminary BTRFS Encryption

> Am 14.09.2016 um 09:02 schrieb Anand Jain : > > > > Wilson, > > Thanks for commenting. Pls see inline below.. > >> On 09/14/2016 12:42 AM, Wilson Meier wrote: >> Hi Anand, >> >> these are great news! Thanks for yor work. I'm looking forward to use the >>

Re: Mixing partitioned and non-partitioned discs in a RAID?

Am Tue, 13 Sep 2016 04:07:37 + (UTC) schrieb Duncan <1i5t5.dun...@cox.net>: > Kai Krakow posted on Tue, 13 Sep 2016 00:21:10 +0200 as excerpted: > > > Am Sun, 21 Aug 2016 02:19:33 + (UTC) > > schrieb Duncan <1i5t5.dun...@cox.net>: > > > >> Chris Murphy posted on Sat, 20 Aug 2016

Re: [PATCH] Btrfs: kill BUG_ON in do_relocation

On Wed, Sep 14, 2016 at 01:31:31PM -0400, Josef Bacik wrote: > On 09/14/2016 01:29 PM, Chris Mason wrote: > > > > > > On 09/14/2016 01:13 PM, Josef Bacik wrote: > > > On 09/14/2016 12:27 PM, Liu Bo wrote: > > > > While updating btree, we try to push items between sibling > > > > nodes/leaves in

Re: [PATCH] Btrfs: kill BUG_ON in do_relocation

On Wed, Sep 14, 2016 at 01:13:34PM -0400, Josef Bacik wrote: > On 09/14/2016 12:27 PM, Liu Bo wrote: > > While updating btree, we try to push items between sibling > > nodes/leaves in order to keep height as low as possible. > > But we don't memset the original places with zero when > > pushing

Re: [PATCH] Btrfs: kill BUG_ON in do_relocation

On 09/14/2016 01:29 PM, Chris Mason wrote: On 09/14/2016 01:13 PM, Josef Bacik wrote: On 09/14/2016 12:27 PM, Liu Bo wrote: While updating btree, we try to push items between sibling nodes/leaves in order to keep height as low as possible. But we don't memset the original places with zero

Re: [PATCH] Btrfs: kill BUG_ON in do_relocation

On 09/14/2016 01:13 PM, Josef Bacik wrote: On 09/14/2016 12:27 PM, Liu Bo wrote: While updating btree, we try to push items between sibling nodes/leaves in order to keep height as low as possible. But we don't memset the original places with zero when pushing items so that we could end up

Re: [PATCH] Btrfs: kill BUG_ON in do_relocation

On 09/14/2016 12:27 PM, Liu Bo wrote: While updating btree, we try to push items between sibling nodes/leaves in order to keep height as low as possible. But we don't memset the original places with zero when pushing items so that we could end up leaving stale content in nodes/leaves. One may

Re: [PATCH] Btrfs: return gracefully from balance if fs tree is corrupted

On 09/14/2016 11:51 AM, Liu Bo wrote: When relocating tree blocks, we firstly get block information from back references in the extent tree, we then search fs tree to try to find all parents of a block. However, if fs tree is corrupted, eg. if there're some missing items, we could come across

[PATCH] Btrfs: kill BUG_ON in do_relocation

While updating btree, we try to push items between sibling nodes/leaves in order to keep height as low as possible. But we don't memset the original places with zero when pushing items so that we could end up leaving stale content in nodes/leaves. One may read the above stale content by

[PATCH] Btrfs: return gracefully from balance if fs tree is corrupted

When relocating tree blocks, we firstly get block information from back references in the extent tree, we then search fs tree to try to find all parents of a block. However, if fs tree is corrupted, eg. if there're some missing items, we could come across these WARN_ONs and BUG_ONs. This makes

Re: [PATCH 0/3] block: Improve bio_set_op_attrs() robustness

On 09/14/2016 02:42 AM, Bart Van Assche wrote: Hi Jens, bio_set_op_attrs() does not yet check whether the "op_flags" field overflows into the "op" field. Since adding support for SMR requires to introduce more REQ_* flags I think it is important to have such a check. Hence this patch series.

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

Hi Josef, Em Ter, 2016-09-13 às 17:01 -0400, Josef Bacik escreveu: > I just started paying attention to this, the last kernel I saw you > were running  > was 4.7.  Have you tried a recent kernel, like chris's tree? > > > git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git >

Re: BTRFS constantly reports "No space left on device" even with a huge unallocated space

On 9/13/16 10:24 PM, Josef Bacik wrote: > On 09/08/2016 07:02 PM, Jeff Mahoney wrote: >> On 9/8/16 2:49 PM, Jeff Mahoney wrote: >>> On 9/8/16 2:24 PM, Ronan Arraes Jardim Chagas wrote: Hi all! Em Seg, 2016-09-05 às 16:49 +0800, Qu Wenruo escreveu: > Just like what Wang has

Re: [PATCH] Btrfs: remove BUG_ON in start_transaction

On 09/13/2016 10:15 PM, Liu Bo wrote: Since we could get errors from the concurrent aborted transaction, the check of this BUG_ON in start_transaction is not true any more. Say, while flushing free space cache inode's dirty pages, btrfs_finish_ordered_io -> btrfs_join_transaction_nolock

Re: [PATCH] Btrfs: fix memory leak in do_walk_down

On 09/14/16 04:02, Liu Bo wrote: > The extent buffer 'next' needs to be free'd conditionally. > > Signed-off-by: Liu Bo > --- > fs/btrfs/extent-tree.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c > index

Re: [PATCH] Btrfs: Free fs_info->eb_info only when it holds a valid pointer

On 09/14/2016 06:28 AM, Chandan Rajendra wrote: The following command line sequence causes a NULL pointer dereference, mount /dev/loop0 /mnt/dir1 mount /dev/loop0 /mnt/dir2 [ 159.964194] BUG: unable to handle kernel NULL pointer dereference at 0070 [ 159.965147] IP: []

Re: Filesystem forced to readonly after use

On 2016-09-13 16:39, Cesar Strauss wrote: On 13-09-2016 16:49, Austin S. Hemmelgarn wrote: I'd be kind of curious to see the results from btrfs check run without repair, but I doubt that will help narrow things down any further. Attached. As of right now, the absolute first thing I'd do is

Re: Unable to repair "bad key order": Cyclic bad block flip-flop

On Dienstag, 13. September 2016 08:39:27 CEST Qu Wenruo wrote: > You could try using backup roots to avoid corrupted tree root. > And it may also fix your extent tree. > --- > # btrfs-show-super -f > ... > backup_roots[4]: > backup 0: > backup_tree_root: 31932416

[PATCH] Btrfs: Free fs_info->eb_info only when it holds a valid pointer

The following command line sequence causes a NULL pointer dereference, mount /dev/loop0 /mnt/dir1 mount /dev/loop0 /mnt/dir2 [ 159.964194] BUG: unable to handle kernel NULL pointer dereference at 0070 [ 159.965147] IP: [] list_lru_destroy+0x8/0x20 [ 159.965147] PGD 0 [

Contact Rev. JOHN B. WATSON for your payment of US$2,000,000.00

Dear Beloved Friend, I believe that you have not forgotten me, although it was indeed a very long time we communicate last. Well, this is to thank you for your past effort to assist me in moving out late Mr. Alvin Peter's funds out from the Bank East Asia New York at that time, I understand

Re: [PATCH 3/3] block: Improve bio_set_op_attrs() robustness

On Wed, Sep 14, 2016 at 10:46:22AM +0200, Bart Van Assche wrote: > Since REQ_OP_BITS == 3 and __REQ_NR_BITS == 30 it is not that hard > to pass an op_flags argument to bio_set_op_attrs() that is larger > than the number of bits reserved for the op_flags argument. Complain > if this happens.

Re: [PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

Ok, looks fine after reading the next patch: Reviewed-by: Christoph Hellwig -- 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

Re: [PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

On Wed, Sep 14, 2016 at 10:45:36AM +0200, Bart Van Assche wrote: > Introduce the bio_flags() macro. Ensure that the second argument of > bio_set_op_attrs() only contains flags and no operation. This patch > does not change any functionality. > > Signed-off-by: Bart Van Assche

Re: [PATCH 1/3] block: Document that bio_op() uses the data type of bio.bi_opf

Looks good, Reviewed-by: Christoph Hellwig -- 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

[PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

Introduce the bio_flags() macro. Ensure that the second argument of bio_set_op_attrs() only contains flags and no operation. This patch does not change any functionality. Signed-off-by: Bart Van Assche Cc: Mike Christie Cc: Chris Mason

[PATCH 1/3] block: Document that bio_op() uses the data type of bio.bi_opf

Make it clear that the sizeof(unsigned int) expression in BIO_OP_SHIFT refers to the bi_opf member of struct bio. Signed-off-by: Bart Van Assche Cc: Mike Christie Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Damien

[PATCH 3/3] block: Improve bio_set_op_attrs() robustness

Since REQ_OP_BITS == 3 and __REQ_NR_BITS == 30 it is not that hard to pass an op_flags argument to bio_set_op_attrs() that is larger than the number of bits reserved for the op_flags argument. Complain if this happens. Additionally, ensure that negative arguments trigger a complaint (1 << ... is

[PATCH 0/3] block: Improve bio_set_op_attrs() robustness

Hi Jens, bio_set_op_attrs() does not yet check whether the "op_flags" field overflows into the "op" field. Since adding support for SMR requires to introduce more REQ_* flags I think it is important to have such a check. Hence this patch series. Please consider these patches for inclusion in

Re: [PATCH 3/3] block: Improve bio_set_op_attrs() robustness

On Wed, Sep 14, 2016 at 10:46:22AM +0200, Bart Van Assche wrote: > Since REQ_OP_BITS == 3 and __REQ_NR_BITS == 30 it is not that hard > to pass an op_flags argument to bio_set_op_attrs() that is larger > than the number of bits reserved for the op_flags argument. Complain > if this happens.

Re: [PATCH 2/3] block, dm-crypt, btrfs: Introduce bio_flags()

On Wed, Sep 14, 2016 at 10:45:36AM +0200, Bart Van Assche wrote: > Introduce the bio_flags() macro. Ensure that the second argument of > bio_set_op_attrs() only contains flags and no operation. This patch > does not change any functionality. > > Signed-off-by: Bart Van Assche

Re: [PATCH 1/3] block: Document that bio_op() uses the data type of bio.bi_opf

On Wed, Sep 14, 2016 at 10:44:12AM +0200, Bart Van Assche wrote: > Make it clear that the sizeof(unsigned int) expression in BIO_OP_SHIFT > refers to the bi_opf member of struct bio. > > Signed-off-by: Bart Van Assche > Cc: Mike Christie > Cc:

Re: [PATCH 02/13] btrfs: Do per-chunk check for mount time check

On 09/13/2016 05:49 AM, Hugo Mills wrote: What happened to these patches? (Particularly the per-chunk degraded checks). Per-chunk degraded-check patch helps to workaround the issue. Which is needed to test hotspare support. The final fix for the same is.. [RFC] btrfs: create

Re: [RFC] Preliminary BTRFS Encryption

Wilson, Thanks for commenting. Pls see inline below.. On 09/14/2016 12:42 AM, Wilson Meier wrote: Hi Anand, these are great news! Thanks for yor work. I'm looking forward to use the encryption. I would like to ask a few question regarding the feature set. 1. is encryption of an existing,