Re: fs corruption report

Hi, Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote: > > Thank you! I will try to restore using this patch. > > > > What branch of what btrfs tools git repo should I apply the patch to? > > > > Regards, > > > > Zooko >

[PATCH v2] btrfs-progs: fix page align issue for lzo compress in restore

When runing restore under lzo compression, "bad compress length" problems are encountered. It is because there is a page align problem with the @decompress_lzo, as follows: |--| ||-| |--|...|--| page ^page page

Re: fs corruption report

On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > Hi, > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote: > > > Thank you! I will try to restore using this patch. > > > > > > What branch of what btrfs tools gi

Re: [PATCH v2] btrfs-progs: fix page align issue for lzo compress in restore

Am Montag, 22. September 2014, 16:29:28 schrieb Gui Hecheng: > When runing restore under lzo compression, "bad compress length" > problems are encountered. > It is because there is a page align problem with the @decompress_lzo, > as follows: > |--| ||-| |--|...|--| >

Re: [PATCH v2] btrfs-progs: fix page align issue for lzo compress in restore

On Mon, 2014-09-22 at 10:44 +0200, Marc Dietrich wrote: > Am Montag, 22. September 2014, 16:29:28 schrieb Gui Hecheng: > > When runing restore under lzo compression, "bad compress length" > > problems are encountered. > > It is because there is a page align problem with the @decompress_lzo, > > as

Re: fs corruption report

Am Montag, 22. September 2014, 16:33:56 schrieb Gui Hecheng: > On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > > Hi, > > > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > > On Thu, 2014-09-18 at 12:47 +, Zooko Wilcox-OHearn wrote: > > > > Thank you! I will try to

Re: fs corruption report

On Mon, 2014-09-22 at 10:49 +0200, Marc Dietrich wrote: > Am Montag, 22. September 2014, 16:33:56 schrieb Gui Hecheng: > > On Mon, 2014-09-22 at 10:19 +0200, Marc Dietrich wrote: > > > Hi, > > > > > > Am Freitag, 19. September 2014, 09:30:30 schrieb Gui Hecheng: > > > > On Thu, 2014-09-18 at 12:47

Re: [PATCH 4/4] Default to acting like fsck.

On 21 September 2014 13:59, Tobias Geerinckx-Rice wrote: > On 21 September 2014 03:01, Dimitri John Ledkov wrote: >> >> Inspect arguments, if we are not called as btrfs, then assume we are >> called to act like fsck. > [...] >> - if (!strcmp(bname, "btrfsck")) { >> + if (strcmp(bname,

[PATCH v3] btrfs-progs: fix page align issue for lzo compress in restore

When runing restore under lzo compression, "bad compress length" problems are encountered. It is because there is a page align problem with the @decompress_lzo, as follows: |--| ||-| |--|...|--| page ^page page

Re: device delete progress

On Sun, Sep 21, 2014 at 08:34:33AM +, Duncan wrote: > Russell Coker posted on Sun, 21 Sep 2014 12:09:11 +1000 as excerpted: > > > We need to have a way to determine the progress of a device delete > > operation. > > Also for a balance of a RAID-1 that has more than 2 devices it would be > > go

Re: XFS Tests for Btrfs

On 14-09-22 04:17 AM, Qu Wenruo wrote: > > Original Message > Subject: Re: XFS Tests for Btrfs > From: nick > To: Qu Wenruo > Date: 2014年09月19日 18:49 >> >> On 14-09-18 10:46 PM, Qu Wenruo wrote: >>> Original Message >>> Subject: Re: XFS Tests for Btrfs >>> F

Re: Performance Issues

On Fri, Sep 19, 2014 at 01:34:38PM +, Holger Hoffstätte wrote: > On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote: > > > I have a particularly uncomplicated setup (a desktop PC with a hard > > disk) and I'm seeing particularly slow performance from btrfs. A `git > > status` in the linux

Re: [PATCH 3/4] btrfs: export __btrfs_set_prop

On Fri, Sep 19, 2014 at 05:52:17PM +0900, Satoru Takeuchi wrote: > @@ -99,7 +99,7 @@ find_prop_handler(const char *name, > return NULL; > } > > -static int __btrfs_set_prop(struct btrfs_trans_handle *trans, > +int __btrfs_set_prop(struct btrfs_trans_handle *trans, It's common for static h

Re: Unable to mount multiple subvolumes of a single disk

Am 17.09.2014 um 15:21 schrieb Chris Mason: > No problem, the original patch looked right to me too. We're getting > closer to rc6, I think at this point I'll revert the original patch > until the next merge window. Then we can step back and nail down > exactly what is going on. running git-sou

Re: [PATCH 2/4] Fixes FTBFS with --no-add-needed.

On Sun, Sep 21, 2014 at 02:01:20AM +0100, Dimitri John Ledkov wrote: > --- a/Makefile > +++ b/Makefile > @@ -26,7 +26,7 @@ TESTS = fsck-tests.sh convert-tests.sh > INSTALL = install > prefix ?= /usr/local > bindir = $(prefix)/bin > -lib_LIBS = -luuid -lblkid -lm -lz -llzo2 -L. > +lib_LIBS = -luu

Re: Performance Issues

On Mon, 22 Sep 2014 13:59:03 +0200, David Sterba wrote: > On Fri, Sep 19, 2014 at 01:34:38PM +, Holger Hoffstätte wrote: >> >> I'd also love a technical explanation why this happens and how it could >> be fixed. Maybe it's just a consequence of how the metadata tree(s) >> are laid out on disk

Re: [PATCH 3/4] Fixing unaligned memory accesses.

On Sun, Sep 21, 2014 at 02:01:21AM +0100, Dimitri John Ledkov wrote: > From: Shawn Landen > > Bug-Debian: http://bugs.debian.org/656955 The bug seems old (2012) and agains 0.19. We've fixed a few unaligned access bugs in the meantime. Can you please retest with 3.16? > --- a/ctree.h > +++ b/ctr

Re: [PATCH 4/4] Default to acting like fsck.

On Mon, Sep 22, 2014 at 09:58:34AM +0100, Dimitri John Ledkov wrote: > On 21 September 2014 13:59, Tobias Geerinckx-Rice > wrote: > > On 21 September 2014 03:01, Dimitri John Ledkov wrote: > >> > >> Inspect arguments, if we are not called as btrfs, then assume we are > >> called to act like fsck.

Re: Performance Issues

On Mon, Sep 22, 2014 at 12:37:59PM +, Holger Hoffstätte wrote: > Thanks Dave - that confirms everything I (unscientifically ;) observed so > far, since I also tried to use "find" to warm up (in the hope it would > cache the relevant metadata blocks), but running with strace showed that > it doe

Re: [PATCH v3] btrfs-progs: fix page align issue for lzo compress in restore

On Mon, Sep 22, 2014 at 04:58:26PM +0800, Gui Hecheng wrote: > So we check page alignment every time before we are going to > fetch the next @len and after the former piece of data is decompressed. > If the current page that we reach has less than 4 bytes left, > then we should fetch the next @len

Re: fs corruption report

I guess I'll wait until there's a git repo (maybe one of these branches https://github.com/kdave/btrfs-progs/branches/active ?) with the fix integrated and then I'll test "btrfs restore" using that. Thanks! Regards, Zooko -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" i

Btrfs-progs release 3.16.1

Hi, this is is a minor release collecting a few bugfixes and enhancements. User visible changes: * the 'uknown' blockgroup in 'fi df' is properly named 'GlobalReserve' * -R option for listing received UUID Other updates: * library version defines * static build is fixed * build without document

Re: Btrfs-progs release 3.16.1

On 09/22/2014 11:24 AM, David Sterba wrote: > Hi, > > this is is a minor release collecting a few bugfixes and enhancements. > User visible changes: > > * the 'uknown' blockgroup in 'fi df' is properly named 'GlobalReserve' > * -R option for listing received UUID > > Other updates: > > * librar

[PATCH 1/2] Btrfs: add missing end_page_writeback on submit_extent_page failure

If submit_extent_page() fails in write_one_eb(), we end up with the current page not marked dirty anymore, unlocked and marked for writeback. But we never end up calling end_page_writeback() against the page, which will make calls to filemap_fdatawait_range (e.g. at transaction commit time) hang fo

[PATCH 2/2] Btrfs: be aware of btree inode write errors to avoid fs corruption

While we have a transaction ongoing, the VM might decide at any time to call btree_inode->i_mapping->a_ops->writepages(), which will start writeback of dirty pages belonging to btree nodes/leafs. This call might return an error or the writeback might finish with an error before we attempt to commit

Re: device delete progress

David Sterba posted on Mon, 22 Sep 2014 11:49:55 +0200 as excerpted: > The upcomming 3.17 release should contain all the 'new df' patches that > were unfortunatelly delayed. There are some minor issues to be fixed but > I hope it'll be ready close to the kernel 3.17 release. Will that fix my "unk

Re: device delete progress

Duncan posted on Mon, 22 Sep 2014 16:29:26 + as excerpted: > David Sterba posted on Mon, 22 Sep 2014 11:49:55 +0200 as excerpted: > >> The upcomming 3.17 release should contain all the 'new df' patches that >> were unfortunatelly delayed. There are some minor issues to be fixed >> but I hope

Corrupted metadata. 'btrfs check' fails repair due to an assertion failure: '!(root->ref_cows && trans->transid != root->last_trans)'

Also filed on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=85011 My log files are spammed with these messages until the drive is full: Sep 22 21:27:38 nasbak kernel: [ 1911.486180] BTRFS critical (device sdg): corrupt leaf, bad key order: block=13415158087680,root=1, slot=7 Sep 22 21:27:

Re: [PATCH] Btrfs-progs: super-recover: fix double free fs_devices memory

On 9/18/14 4:01 AM, Wang Shilong wrote: > super-recover collects btrfs devices infomation using existed > functions scan_one_devices(). > > Problem is fs_devices is freed twice in close_ctree() and > free_recover_superblock() for super correction path. > > Fix this problem by checking whether fs_

Re: general thoughts and questions + general and RAID5/6 stability?

Am 20.09.2014 um 11:32 schrieb Duncan: > What I do as part of my regular backup regime, is every few kernel cycles > I wipe the (first level) backup and do a fresh mkfs.btrfs, activating new > optional features as I believe appropriate. Then I boot to the new > backup and run a bit to test it,

[no subject]

Your mailbox is almost full. 20GB23GB Your mailbox needed to update now (Click Update) Update it now,and Increase your Mail Quota. IT Services Help Desk -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the bo

Re: [PATCH v3] btrfs-progs: fix page align issue for lzo compress in restore

On Mon, 2014-09-22 at 15:41 +0200, David Sterba wrote: > On Mon, Sep 22, 2014 at 04:58:26PM +0800, Gui Hecheng wrote: > > So we check page alignment every time before we are going to > > fetch the next @len and after the former piece of data is decompressed. > > If the current page that we reach ha

Sparse Warnings about locks in extent-tree.c

Hello Btfs Developers, I am new so am unsure of how to fix this but we are hitting some sparse warnings about unlock/lock is having a wrong count when exiting certain functions in extent-tree.c. I will paste the warnings below for you guys. Hope this is of help. Cheers, Nick fs/btrfs/extent-tr

[PATCH v4] btrfs-progs: fix page align issue for lzo compress in restore

When runing restore under lzo compression, "bad compress length" problems are encountered. It is because there is a page align problem with the @decompress_lzo, as follows: |--| ||-| |--|...|--| page ^page page

[PATCH v4 12/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/testmgr.c

From: Jan-Simon Möller Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by

[PATCH v4 10/12] crypto: LLVMLinux: Remove VLAIS usage from libcrc32c.c

From: Jan-Simon Möller Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by

[PATCH v4 11/12] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: B

[PATCH v4 04/12] crypto: LLVMLinux: Remove VLAIS from crypto/mv_cesa.c

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: B

[PATCH v4 09/12] crypto: LLVMLinux: Remove VLAIS usage from crypto/hmac.c

From: Jan-Simon Möller Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by

[PATCH v4 08/12] crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt

From: Jan-Simon Möller Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by

[PATCH v4 03/12] crypto: LLVMLinux: Remove VLAIS from crypto/ccp/ccp-crypto-sha.c

From: Jan-Simon Möller Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by

[PATCH v4 07/12] crypto: LLVMLinux: Remove VLAIS from crypto/.../qat_algs.c

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: B

[PATCH v4 01/12] crypto: LLVMLinux: Add macro to remove use of VLAIS in crypto code

From: Behan Webster Add a macro which replaces the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This macro instead allocates the appropriate amount of memory using an char array. The new code can be compiled with both gcc and clang. struct shash_desc contain

[PATCH v4 06/12] crypto: LLVMLinux: Remove VLAIS from crypto/omap_sham.c

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: B

[PATCH v4 02/12] btrfs: LLVMLinux: Remove VLAIS

From: Vinícius Tinti Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch instead allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed

[PATCH v4 05/12] crypto: LLVMLinux: Remove VLAIS from crypto/n2_core.c

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. This patch allocates the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. The new code can be compiled with both gcc and clang. Signed-off-by: B

[PATCH v4 00/12] LLVMLinux: Patches to enable the kernel to be compiled with clang/LLVM

From: Behan Webster Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99 compliant equivalent. These patches allocate the appropriate amount of memory using a char array using the SHASH_DESC_ON_STACK macro. There are places in the kernel whose maintainers have previously take

[PATCH] btrfs: Make btrfs handle security mount options internally to avoid losing security label.

[BUG] Originally when mount btrfs with "-o subvol=" mount option, btrfs will lose all security lable. And if the btrfs fs is mounted somewhere else, due to the lost of security lable, SELinux will refuse to mount since the same super block is being mounted using different security lable. [REPRODUC

Re: Sparse Warnings about locks in extent-tree.c

On Mon, Sep 22, 2014 at 09:57:35PM -0400, nick wrote: > Hello Btfs Developers, > I am new so am unsure of how to fix this but we are hitting some sparse > warnings about unlock/lock is having > a wrong count when exiting certain functions in extent-tree.c. I will paste > the warnings below for y