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
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
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
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
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
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
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
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
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...
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
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
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
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)
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
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:
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
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
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
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
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
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
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
>
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:
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
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
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
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
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
28 matches
Mail list logo