A little question about mount -o read_mirror_policy=.
How would this work with RAID1 over 3 or 4 HDD's?
In particular, if the desired block is not available on device .
Could i repeat this option like the device-option to specify a
order/priority like this:
mount -o read_mirror_policy=
On 31.01.2018 08:16, Qu Wenruo wrote:
> Cleanup the following things:
> 1) open coded SZ_16M round up
> 2) use min() to replace open-coded size comparison
> 3) code style
>
> Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/volumes.c
On 31.01.2018 07:56, Qu Wenruo wrote:
> When checking the minimal nr_devs, there is one dead and meaningless
> condition:
>
> if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) {
>
>
> This condition is meaningless, @devs_increment has
On 31.01.2018 04:28, Anand Jain wrote:
> v3->v2:
> rename device_sort() to device_cmp().
> v1->v2:
> No code change. Change log updated to include the type
> of problem that this consistency would help. And
> I don't see patch 2/2 in the ML. So trying to resend.
>
> By maintaining the
Cleanup the following things:
1) open coded SZ_16M round up
2) use min() to replace open-coded size comparison
3) code style
Signed-off-by: Qu Wenruo
---
fs/btrfs/volumes.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/volumes.c
When checking the minimal nr_devs, there is one dead and meaningless
condition:
if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) {
This condition is meaningless, @devs_increment has nothing to do with
@sub_stripes.
In fact, in
Add opened device to the tail of dev_alloc_list instead of head, so that
it maintains the same order as dev_list.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
On 01/31/2018 02:40 AM, fdman...@kernel.org wrote:
From: Filipe Manana
When we are replacing a missing device we mount the filesystem with the
degraded mode option in which case we are allowed to have a btrfs device
structure without a backing device member (its bdev
In function leaf_data_end, root is just used to get fs_info,
so change the parameter of this function from btrfs_root to
btrfs_fs_info.
And also make it consistent with kernel.
Changelog:
v3->v2:
Add const to parameter leaf of function btrfs_item_offset_nr
to keep type consistent with
Do a cleanup. Also make it consistent with kernel.
Use fs_info instead of root for BTRFS_MAX_INLINE_DATA_SIZE, since
maybe in some situation we do not know root, but just know fs_info.
Changelog:
v2->v1:
Change macro to inline function to be consistent with kernel.
And change the function body to
Do a cleanup. Also make it consistent with kernel.
Use fs_info instead of root for BTRFS_NODEPTRS_PER_BLOCK, since
maybe in some situation we do not know root, but just know fs_info.
Changelog:
v2->v1:
To be consistent with kernel, change macro to inline function.
Signed-off-by: Gu Jinxiang
Do a cleanup. Also make it consistent with kernel.
Use fs_info instead of root for BTRFS_LEAF_DATA_SIZE, since
maybe in some situation we do not know root, but just know fs_info.
Signed-off-by: Gu Jinxiang
Reviewed-by: Qu Wenruo
---
cmds-check.c
Although skinny_metadata's type is int, its value just can be 0/1.
And if condition be true only when skinny_metadata equals 1,
so in if's executive part, set skinny_metadata to 1 is redundancy.
Remove it.
Signed-off-by: Gu Jinxiang
Reviewed-by: Qu Wenruo
---
Do a cleanup.
Function btrfs_alloc_extent is no longer be used.
So let's remove it.
Signed-off-by: Gu Jinxiang
Reviewed-by: Qu Wenruo
---
ctree.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/ctree.h b/ctree.h
index 679bbc9..41b14b5 100644
---
Patch 1~4 and 7: clean up use of btrfs_root.
Beside it, syncs code with kernel.
Patch 5: remove redundancy value assignment.
Patch 6: remove no longer be used function define.
Changelog:
v2->v1:
Patch 2,4: To be consistent with kernel, change macro to inline function.
Patch 3:
Do a cleanup. Also make it consistent with kernel.
Use fs_info instead of root for BTRFS_MAX_XATTR_SIZE, since
maybe in some situation we do not know root, but just know fs_info.
Changelog:
v2->v1:
To be consistent with kernel, change macro to inline function.
Signed-off-by: Gu Jinxiang
There are 2 fsck tests with the same number 027:
tree-reloc-tree
bad-extent-inline-ref-type
And we also have a hole in 015, so just rename tree-reloc-tree to 015,
to get rid of the duplicated test number and fill in the hole.
Signed-off-by: Qu Wenruo
---
.../{027-tree-reloc-tree
v3->v2:
rename device_sort() to device_cmp().
v1->v2:
No code change. Change log updated to include the type
of problem that this consistency would help. And
I don't see patch 2/2 in the ML. So trying to resend.
By maintaining the device order (some) consistency it makes reproducing
the
By maintaining the device order consistency it makes reproducing
the problems related to missing chunk in the degraded mode much more
consistent. So fix this by sorting the devices by devid within the
kernel. So that we know which device is assigned to the struct
fs_info::latest_bdev when all the
+static int device_sort(void *priv, struct list_head *a, struct list_head *b)
I'll rename that to devid_cmp as it's the comparator and not really a
sorting function.
Ok. I will make that change in v3.
Thanks,
Anand
--
To unsubscribe from this list: send the line "unsubscribe
On 2018年01月31日 06:33, Howard McLauchlan wrote:
> Presently, failing a primary super block write but succeeding in at
> least one super block write in general will appear to users as if
> nothing important went wrong. However, upon unmounting and re-mounting,
> the file system will be in a rolled
Presently, failing a primary super block write but succeeding in at
least one super block write in general will appear to users as if
nothing important went wrong. However, upon unmounting and re-mounting,
the file system will be in a rolled back state. This was discovered
with a BCC program that
Ack. Should I expect this in a future pull request, or take it directly?
There's no hurry about this, since none of the existing users of that
function actually do anything but test the return value against zero,
and nobody saves it into anything but a "bool" (which has magical
casting properties
On 2018-01-30 14:50, Tomasz Pala wrote:
On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote:
I personally think the degraded mount option is a mistake as this
assumes that a lightly degraded system is not able to work which is false.
If the system can mount to some working state
From: Jeff Layton
As Linus points out:
The inode_cmp_iversion{+raw}() functions are pure and utter crap.
Why?
You say that they return 0/negative/positive, but they do so in a
completely broken manner. They return that ternary value as the
sequence
Finally restored by merging the last snapshot with what btrfs restore gave me
-- surprisingly almost the whole bunch of it :-)
Thanks for helping!
Cheers,
Marco
Qu Wenruo wrote on 2018-01-30 02:24:
>
>
> On 2018年01月30日 02:16, ^m'e wrote:
>> Thanks!
>>
>> Got these
>>
>> # ./btrfs.static
On Tue, Jan 30, 2018 at 08:46:32 -0500, Austin S. Hemmelgarn wrote:
>> I personally think the degraded mount option is a mistake as this
>> assumes that a lightly degraded system is not able to work which is false.
>> If the system can mount to some working state then it should mount
>>
On Tue, 2018-01-30 at 17:50 +, Trond Myklebust wrote:
> On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote:
> > From: Jeff Layton
> >
> > As Linus points out:
> >
> > The inode_cmp_iversion{+raw}() functions are pure and utter crap.
> >
> > Why?
> >
> >
Just one final word, as all was already said:
On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote:
>> In other words, is it:
>> - the systemd that threats btrfs WORSE than distributed filesystems, OR
>> - btrfs that requires from systemd to be threaded BETTER than other fss?
> Or
On Tue, Jan 30, 2018 at 11:30:31 -0500, Austin S. Hemmelgarn wrote:
>> - crypto below software RAID means double-encryption (wasted CPU),
> It also means you leak no information about your storage stack. If
JBOD
> you're sufficiently worried about data protection that you're using
>
From: Filipe Manana
When we are replacing a missing device we mount the filesystem with the
degraded mode option in which case we are allowed to have a btrfs device
structure without a backing device member (its bdev member is NULL) and
therefore we can't dereference that
On Tue, 2018-01-30 at 12:31 -0500, Jeff Layton wrote:
> From: Jeff Layton
>
> As Linus points out:
>
> The inode_cmp_iversion{+raw}() functions are pure and utter crap.
>
> Why?
>
> You say that they return 0/negative/positive, but they do so in a
>
On Tue, Jan 30, 2018 at 4:05 AM, Jeff Layton wrote:
>
> My intent here was to have this handle wraparound using the same sort of
> method that the time_before/time_after macros do. Obviously, I didn't
> document that well.
Oh, the intent was clear. The implementation was
On 2018-01-30 10:09, Tomasz Pala wrote:
On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote:
Yes. They are stupid enough to fail miserably with any more complicated
setups, like stacking volume managers, crypto layer, network attached
storage etc.
I think you mean any setup
On Tue, Jan 30, 2018 at 16:09:50 +0100, Tomasz Pala wrote:
>> BCP for over a
>> decade has been to put multipathing at the bottom, then crypto, then
>> software RAID, than LVM, and then whatever filesystem you're using.
>
> Really? Let's enumerate some caveats of this:
>
> - crypto below
On Tue, Jan 30, 2018 at 07:05:48AM -0500, Jeff Layton wrote:
>
> I want to make sure I understand what's actually broken here thoug. Is
> it only broken when the two values are more than 2**63 apart, or is
> there something else more fundamentally wrong here?
The other problem is that returning
On Tue, Jan 30, 2018 at 10:05:34 -0500, Austin S. Hemmelgarn wrote:
>> Instead, they should move their legs continuously and if the train is > not
>> on the station yet, just climb back and retry.
> No, that's really not a good analogy given the fact that that check for
> the presence of a
On Mon, Jan 29, 2018 at 21:44:23 -0700, Chris Murphy wrote:
> Btrfs is orthogonal to systemd's willingness to wait forever while
> making no progress. It doesn't matter what it is, it shouldn't wait
> forever.
It times out after 90 seconds (by default) and then it fails the mount
entirely.
> It
On Mon, Jan 29, 2018 at 14:00:53 -0500, Austin S. Hemmelgarn wrote:
> We already do so in the accepted standard manner. If the mount fails
> because of a missing device, you get a very specific message in the
> kernel log about it, as is the case for most other common errors (for
> uncommon
On Mon, Jan 29, 2018 at 08:42:32 -0500, Austin S. Hemmelgarn wrote:
>> Yes. They are stupid enough to fail miserably with any more complicated
>> setups, like stacking volume managers, crypto layer, network attached
>> storage etc.
> I think you mean any setup that isn't sensibly layered.
No, I
On 2018-01-30 08:46, Tomasz Pala wrote:
On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote:
Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF
THIS_. It's functionally no different than prefacing an attempt to send
a signal to a process by checking if the
On 30.01.2018 16:34, David Sterba wrote:
> On Fri, Jan 12, 2018 at 04:21:05PM +0200, Nikolay Borisov wrote:
>> @@ -6062,19 +6062,19 @@ int btrfs_delalloc_reserve_metadata(struct
>> btrfs_inode *inode, u64 num_bytes)
>> * If we have a transaction open (can happen if we call truncate_block
On Fri, Jan 12, 2018 at 04:21:05PM +0200, Nikolay Borisov wrote:
> @@ -6062,19 +6062,19 @@ int btrfs_delalloc_reserve_metadata(struct
> btrfs_inode *inode, u64 num_bytes)
>* If we have a transaction open (can happen if we call truncate_block
>* from truncate), then we need
Essentially duplicate the error handling from the above block which
handles the !PageUptodate(page) case and additionally clear
EXTENT_BOUNDARY.
Signed-off-by: Nikolay Borisov
Reviewed-by: Josef Bacik
---
Put description of the intended changes.
On Mon, Jan 22, 2018 at 02:49:36PM -0800, Anand Jain wrote:
> By maintaining the device order consistency it makes reproducing
> the problems related to missing chunk in the degraded mode much more
> consistent. So fix this by sorting the devices by devid within the
> kernel. So that we know which
On Mon, Jan 22, 2018 at 02:49:35PM -0800, Anand Jain wrote:
> Could you pls consider this for 4.16 ?
Sorry, the patches are not fixes and I'll probably not add them to 4.16
and they missed the first pull. But I will add them to misc-next so they
still help debugging and any fix that you come up
On Wed, Jan 24, 2018 at 10:38:51AM -0500, Josef Bacik wrote:
> On Tue, Jan 23, 2018 at 02:46:53PM +0200, Nikolay Borisov wrote:
> > Instead of manually fiddling with the state of the task
> > (RUNNING->INTERRUPTIBLE->RUNNING) again just use
> > schedule_timeout_interruptible
> > which adjusts the
On Fri, Jan 26, 2018 at 09:31:06AM -0500, Josef Bacik wrote:
> On Thu, Jan 25, 2018 at 02:56:18PM +0800, Qu Wenruo wrote:
> > When inspecting the error message with real corruption, the "root=%llu"
> > always shows "1" (root tree), instead of correct owner.
> >
> > The problem is that we are
Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced
btrfs_free_stale_device which iterates the device lists for all
registered btrfs filesystems and deletes those devices which aren't
mounted. In a btrfs_devices structure has only 1 device attached to it
and it is unused then
On Mon, Jan 29, 2018 at 10:06:52PM +0800, Qu Wenruo wrote:
>
>
> On 2018年01月29日 21:53, Nikolay Borisov wrote:
> > Running generic/019 with qgroups on the scratch device enabled is
> > almost guaranteed to trigger the BUG_ON in btrfs_free_tree_block. It's
> > supposed to trigger only on -ENOMEM,
On Mon, Jan 22, 2018 at 10:11:44AM +0200, Nikolay Borisov wrote:
> > @@ -4731,6 +4740,12 @@ static int __btrfs_alloc_chunk(struct
> > btrfs_trans_handle *trans,
> >
> > if (ndevs < devs_increment * sub_stripes || ndevs < devs_min) {
> > ret = -ENOSPC;
> > + if
On Mon, Jan 29, 2018 at 08:05:42 -0500, Austin S. Hemmelgarn wrote:
> Seriously, _THERE IS A RACE CONDITION IN SYSTEMD'S CURRENT HANDLING OF
> THIS_. It's functionally no different than prefacing an attempt to send
> a signal to a process by checking if the process exists, or trying to
> see
On 2018-01-29 16:54, waxhead wrote:
Austin S. Hemmelgarn wrote:
On 2018-01-29 12:58, Andrei Borzenkov wrote:
29.01.2018 14:24, Adam Borowski пишет:
...
So any event (the user's request) has already happened. A rc
system, of
which systemd is one, knows whether we reached the "want root
On Thu, Jan 25, 2018 at 11:02:49AM -0700, Liu Bo wrote:
> Fstests generic/475 provides a way to fail metadata reads while
> checking if checksum exists for the inode inside run_delalloc_nocow(),
> and csum_exist_in_range() interprets error (-EIO) as inode having
> checksum and makes its caller
On Mon, 2018-01-29 at 13:50 -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote:
> >
> > This pile of patches is a rework of the inode->i_version field. We have
> > traditionally incremented that field on every inode data or metadata
> > change.
Signed-off-by: Qu Wenruo
Reviewed-by: Anand Jain
Reviewed-by: Nikolay Borisov
---
v2:
Added tags.
---
fs/btrfs/volumes.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
Function __get_raid_index() is used to convert block group flags into
raid index, which can be used to get various info directly from
btrfs_raid_array[].
Refactor this function a little:
1) Rename to btrfs_bg_flags_to_raid_index()
Double underline prefix is normally for internal functions,
On 2018年01月30日 16:16, Nikolay Borisov wrote:
>
>
> On 30.01.2018 09:40, Qu Wenruo wrote:
>> Function __get_raid_index() is used to convert block group flags into
>> raid index, which can be used to get various info directly from
>> btrfs_raid_array[].
>>
>> Refactor this function a little:
>>
On 01/30/2018 05:12 PM, Nikolay Borisov wrote:
On 30.01.2018 08:28, Anand Jain wrote:
Drop optimal argument from the function find_live_mirror()
as we can deduce it in the function itself.
Signed-off-by: Anand Jain
---
fs/btrfs/volumes.c | 8
1 file
On 2018年01月30日 16:18, Nikolay Borisov wrote:
>
>
> On 30.01.2018 09:40, Qu Wenruo wrote:
>> That function is only used inside extent-tree.c.
>>
>> Signed-off-by: Qu Wenruo
>> ---
>> fs/btrfs/ctree.h | 1 -
>> fs/btrfs/extent-tree.c | 3 ++-
>> 2 files changed, 2
On 30.01.2018 08:28, Anand Jain wrote:
> Drop optimal argument from the function find_live_mirror()
> as we can deduce it in the function itself.
>
> Signed-off-by: Anand Jain
> ---
> fs/btrfs/volumes.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
On 30.01.2018 09:40, Qu Wenruo wrote:
> Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
> ---
> fs/btrfs/volumes.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index
On 30.01.2018 09:40, Qu Wenruo wrote:
> That function is only used inside extent-tree.c.
>
> Signed-off-by: Qu Wenruo
> ---
> fs/btrfs/ctree.h | 1 -
> fs/btrfs/extent-tree.c | 3 ++-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/ctree.h
On 01/30/2018 03:40 PM, Qu Wenruo wrote:
Signed-off-by: Qu Wenruo
Reviewed-by: Anand Jain
Thanks, Anand
---
fs/btrfs/volumes.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index
On 30.01.2018 09:40, Qu Wenruo wrote:
> Function __get_raid_index() is used to convert block group flags into
> raid index, which can be used to get various info directly from
> btrfs_raid_array[].
>
> Refactor this function a little:
>
> 1) Rename to btrfs_bg_flags_to_raid_index()
>Double
On 01/30/2018 03:40 PM, Qu Wenruo wrote:
Function __get_raid_index() is used to convert block group flags into
raid index, which can be used to get various info directly from
btrfs_raid_array[].
Refactor this function a little:
1) Rename to btrfs_bg_flags_to_raid_index()
Double underline
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index e9c31b567a9c..6e1128aa29d6 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7346,7 +7346,8 @@ wait_block_group_cache_done(struct
btrfs_block_group_cache *cache)
return ret;
}
-int
Hi all,
While trying umount a single btrfs volume i get stuck and get a call kernel
trace.
My kernel is 4.14.13 (archlinux).
Unable to umount, tried to killed command, no way...
what should i do ? Thanks.
# btrfs fi df /mnt/vol3
Data, single: total=25.97GiB, used=6.84GiB
System, DUP:
68 matches
Mail list logo