[PATCH 1/2] btrfs-progs: Allow btrfs_leaf_free_space to accept NULL root

Btrfs_leaf_free_space() function is used to determine the leaf/node size. It's OK to use root->nodesize to determine nodesize, but in fact, extent_buffer->len can also be used to determine the nodesize if caller can ensure it's a tree block. So this patch will add support for NULL root for

[PATCH 2/2] btrfs-progs: debug-tree: Add option to show ondisk block without open_ctree

Add new option '-B' to show tree block without calling open_ctree. It's very useful to debug non-standard super or heavily damaged case. As it needs nodesize, also adds a new option '-n' to specify nodesize. Normal user should avoid calling it on random bytes, as it won't check the validation of

[PATCH] Btrfs: fix race waiting for qgroup rescan worker

From: Filipe Manana We were initializing the completion (fs_info->qgroup_rescan_completion) object after releasing the qgroup rescan lock, which gives a small time window for a rescan waiter to not actually wait for the rescan worker to finish. Example: CPU 1

Re: [PATCH v3] btrfs: qgroup: exit the rescan worker during umount

On Wed, Nov 4, 2015 at 11:56 PM, Justin Maggard wrote: > I was hitting a consistent NULL pointer dereference during shutdown that > showed the trace running through end_workqueue_bio(). I traced it back to > the endio_meta_workers workqueue being poked after it had already

Re: Btrfs/RAID5 became unmountable after SATA cable fault

On 2015-11-04 23:06, Duncan wrote: (Tho I should mention, while not on zfs, I've actually had my own problems with ECC RAM too. In my case, the RAM was certified to run at speeds faster than it was actually reliable at, such that actually stored data, what the ECC protects, was fine, the data

Re: [PATCH 1/2] btrfs-progs: Allow btrfs_leaf_free_space to accept NULL root

On Thu, Nov 05, 2015 at 04:32:59PM +0800, Qu Wenruo wrote: > Btrfs_leaf_free_space() function is used to determine the leaf/node > size. > It's OK to use root->nodesize to determine nodesize, but in fact, > extent_buffer->len can also be used to determine the nodesize if caller > can ensure it's a

Re: [PATCH 2/2] btrfs-progs: debug-tree: Add option to show ondisk block without open_ctree

On Thu, Nov 05, 2015 at 04:33:00PM +0800, Qu Wenruo wrote: > Add new option '-B' to show tree block without calling open_ctree. > It's very useful to debug non-standard super or heavily damaged case. > > As it needs nodesize, also adds a new option '-n' to specify nodesize. > > Normal user

Re: [PATCH] btrfs: clear bio reference after submit_one_bio()

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_ret to NULL. And > if *bio_ret was non-NULL upon entry into submit_extent_page, then we > had submitted this bio

Re: Unable to allocate for space usage in particular btrfs volume

On Thu, Nov 05, 2015 at 10:44:51AM +, OmegaPhil wrote: > So a couple of gig still unaccountable but irrelevant. Thanks, problem > solved! Although hopefully checksumming will be allowed on nocow files > in the future as thats currently 17% of all data unprotected and will > get worse...

[GIT PULL] Btrfs fixes

From: Filipe Manana Hi Chris, please consider the following fixes for the 4.4 merge window (they were all previously sent to the mailing list already). One fixes a sleep inside atomic context issue, introduced by one patch in the integration-4.4 branch. Another two fix races

[PATCH] Btrfs: fix sleeping inside atomic context in qgroup rescan worker

From: Filipe Manana We are holding a btree path with spinning locks and then we attempt to clone an extent buffer, which calls kmem_cache_alloc() and this function can sleep, causing the following trace to be reported on a debug kernel: [107118.218536] BUG: sleeping function

Re: [PATCH v2] btrfs: test unmount during quota rescan

On Thu, Nov 5, 2015 at 12:50 AM, Justin Maggard wrote: > This test case tests if we are able to unmount a filesystem while > a quota rescan is running. Up to now (4.3) this would result > in a kernel NULL pointer dereference. > > Fixed by patch (btrfs: qgroup: exit the

Re: Unable to allocate for space usage in particular btrfs volume

On 05/11/15 04:18, Duncan wrote: > OmegaPhil posted on Wed, 04 Nov 2015 21:53:09 + as excerpted: > >> The volume doesn't change hugely over time, so it really ought not to >> have broken so quickly - a quick rundown of the storage usage: >> >> 36% general (small files, some smallish videos)

Possible project idea

I'd been looking at the wiki page with project ideas, and I realized that there were no listed ideas that suggested the adding support for arbitrary erasure coding methods. Ceph for example has an option that allows you to set arbitrary erasure coding such that you use n devices to store the

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

On Wed, Nov 04, 2015 at 09:01:36AM +0800, Qu Wenruo wrote: > > > Mark Fasheh wrote on 2015/11/03 11:26 -0800: > >On Mon, Nov 02, 2015 at 09:34:24AM +0800, Qu Wenruo wrote: > >> > >> > >>Stefan Priebe wrote on 2015/11/01 21:49 +0100: > >>>Hi, > >>> > >>>this one:

[PATCH 3/3] btrfs: qgroup: account shared subtree during snapshot delete

Commit 0ed4792 ('btrfs: qgroup: Switch to new extent-oriented qgroup mechanism.') removed our qgroup accounting during btrfs_drop_snapshot(). Predictably, this results in qgroup numbers going bad shortly after a snapshot is removed. Fix this by adding a dirty extent record when we encounter

[PATCH 2/3] btrfs: Add qgroup tracing

This patch adds tracepoints to the qgroup code on both the reporting side (insert_dirty_extents) and the accounting side. Taken together it allows us to see what qgroup operations have happened, and what their result was. Signed-off-by: Mark Fasheh --- fs/btrfs/qgroup.c

[PATCH 0/3] btrfs: update qgroups in drop snapshot, V2

Hi, The following 3 patches fix a regression introduced in Linux 4.2 where btrfs_drop_snapshot() wasn't updating qgroups, resulting in them going bad. The original e-mail pointing this out is below: http://www.spinics.net/lists/linux-btrfs/msg46093.html The first patch is from Josef and fix

[PATCH 1/3] Btrfs: use btrfs_get_fs_root in resolve_indirect_ref

From: Josef Bacik The backref code will look up the fs_root we're trying to resolve our indirect refs for, unfortunately we use btrfs_read_fs_root_no_name, which returns -ENOENT if the ref is 0. This isn't helpful for the qgroup stuff with snapshot delete as it won't be able to

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On 9/30/15 3:57 PM, Roman Lebedev wrote: > Hello. > > My / is btrfs. > To do some my local stuff more cleanly i wanted to use overlayfs, > but it didn't quite work. > > Simple non-automatic sequence to reproduce the issue: > mkdir lower upper work merged > mount -t overlay overlay

Re: Btrfs/RAID5 became unmountable after SATA cable fault

Duncan wrote: Austin S Hemmelgarn posted on Wed, 04 Nov 2015 13:45:37 -0500 as excerpted: On 2015-11-04 13:01, Janos Toth F. wrote: But the worst part is that there are some ISO files which were seemingly copied without errors but their external checksums (the one which I can calculate with

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

On Fri, Nov 06, 2015 at 09:02:13AM +0800, Qu Wenruo wrote: > >The same exact code ran in either case before and after your patches, so my > >guess is that the issue is actually inside the qgroup code that shouldn't > >have been run. I wonder if we even just filled up his memory but never >

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Mark Fasheh wrote on 2015/11/05 11:23 -0800: On Wed, Nov 04, 2015 at 09:01:36AM +0800, Qu Wenruo wrote: Mark Fasheh wrote on 2015/11/03 11:26 -0800: On Mon, Nov 02, 2015 at 09:34:24AM +0800, Qu Wenruo wrote: Stefan Priebe wrote on 2015/11/01 21:49 +0100: Hi, this one:

Re: Regression in: [PATCH 4/4] btrfs: qgroup: account shared subtree during snapshot delete

Mark Fasheh wrote on 2015/11/05 19:15 -0800: On Fri, Nov 06, 2015 at 09:02:13AM +0800, Qu Wenruo wrote: The same exact code ran in either case before and after your patches, so my guess is that the issue is actually inside the qgroup code that shouldn't have been run. I wonder if we even just

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On 11/5/15 10:18 PM, Al Viro wrote: > On Thu, Nov 05, 2015 at 09:57:35PM -0500, Jeff Mahoney wrote: > >> So now file_operations callbacks can't assume that file->f_path.dentry >> belongs to the same file system that implements the callback. More than >> that, any code that could ultimately get a

Re: kernel BUG when fsync'ing file in a overlayfs merged dir, located on btrfs

On Thu, Nov 05, 2015 at 09:57:35PM -0500, Jeff Mahoney wrote: > So now file_operations callbacks can't assume that file->f_path.dentry > belongs to the same file system that implements the callback. More than > that, any code that could ultimately get a dentry that comes from an > open file

Urgent Business Proposal‏‏

Attached is the full details of the Business Proposal view it and get back to me immediately for more details. Project Investment Deal.pdf Description: Adobe PDF document

Re: [GIT PULL] Btrfs fixes

On Thu, Nov 05, 2015 at 11:20:37AM +, fdman...@kernel.org wrote: > From: Filipe Manana > > Hi Chris, > > please consider the following fixes for the 4.4 merge window (they were > all previously sent to the mailing list already). > > One fixes a sleep inside atomic