On Sun, Feb 17, 2019 at 09:13:32PM +0800, Ming Lei wrote:
> On Fri, Feb 15, 2019 at 10:59:47AM -0700, Jens Axboe wrote:
> > On 2/15/19 10:14 AM, Bart Van Assche wrote:
> > > On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> > >> On 2/15/19 4:13 AM, Ming Lei wrote:
> > >>> This patchset brings
Some more important insights: The switch to read-only mode may not
only happen on boot but also during working. I got the system running
and then tried again to compile our project with IntelliJ. Result is
basically the same as described in 1st mail. Compile aborts with some
unclear error. But when
On 2/18/19 1:00 PM, Qu Wenruo wrote:
On 2019/2/11 下午10:23, Qu Wenruo wrote:
[snip]
Looking at the dev
docs and the description for 'offset' field in btrfs_file_extent_item I
can sort of deduce that this field will only be different than null if
this reference is for an extent which is shar
We have internal report of strange transaction abort due to EUCLEAN
without any error message.
Since error message inside verify_level_key() is only enabled for
CONFIG_BTRFS_DEBUG, the error message won't output for most distro.
This patch will make the error message mandatory, so when problem
ha
Patchset can be fetched from github:
https://github.com/adam900710/linux/tree/write_time_tree_checker
Which is based on v5.0-rc1 tag.
Also there is no conflict rebasing the patchset to misc-next.
This patchset has the following 3 features:
- Tree block validation output enhancement
* Output vali
Do proper cleanup if we hit any error in extent_write_locked_range(),
and check the return value of flush_write_bio().
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent_io.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index
Since __extent_writepage() will no longer return >0 value,
(ret == AOP_WRITEPAGE_ACTIVATE) will never be true.
Kill that dead branch.
Signed-off-by: Qu Wenruo
Reviewed-by: Johannes Thumshirn
---
fs/btrfs/extent_io.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/btrfs/extent_io.c b
Just add one extra line to show when the corruption is detected.
Currently only read time detection is possible.
The planned distinguish line would be:
read time:
block=X read time tree block corruption detected
write time:
block=X write time tree block corruption de
There is no need to forward declare flush_write_bio(), as it only
depends on submit_one_bio().
Both of them are pretty small, just move them to kill the forward
declaration.
Signed-off-by: Qu Wenruo
Reviewed-by: Nikolay Borisov
Reviewed-by: Johannes Thumshirn
---
fs/btrfs/extent_io.c | 66 +++
There are at least 2 reports about memory bit flip sneaking into on-disk
data.
Currently we only have a relaxed check triggered at
btrfs_mark_buffer_dirty() time, as it's not mandatory and only for
CONFIG_BTRFS_FS_CHECK_INTEGRITY enabled build, it doesn't help user to
detect such problem.
This pa
In btree_write_cache_pages(), we can only get @ret <= 0.
Add an ASSERT() for it just in case.
Then instead of submitting the write bio even we got some error, check
the return value first.
If we have already hit some error, just clean up the corrupted or
half-baked bio, and return error.
If there
Signed-off-by: Qu Wenruo
Reviewed-by: Johannes Thumshirn
---
fs/btrfs/extent_io.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 1572e892ec7b..480e138051f0 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io
We have a BUG_ON() in flush_write_bio() to handle the return value of
submit_one_bio().
Move the BUG_ON() one level up to all its callers.
This patch will introduce temporary variable, @flush_ret to keep code
change minimal in this patch. That variable will be cleaned up when
enhancing the error
Since now flush_write_bio() could return error, kill the BUG_ON() first.
Then don't call flush_write_bio() unconditionally, instead we check the
return value from __extent_writepage() first.
If __extent_writepage() fails, we do cleanup, and return error without
submitting the possible corrupted o
This function needs some extra check on locked pages and eb.
For error handling we need to unlock locked pages and the eb.
Also add comment for possible return values of lock_extent_buffer_for_io().
There is a rare >0 return value branch, where all pages get locked
while write bio is not flushed
Do proper cleanup if we hit any error in extent_writepages(),
and check the return value of flush_write_bio().
Signed-off-by: Qu Wenruo
---
fs/btrfs/extent_io.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 480e1380
On 2019/2/11 下午10:23, Qu Wenruo wrote:
> [snip]
Looking at the dev
docs and the description for 'offset' field in btrfs_file_extent_item I
can sort of deduce that this field will only be different than null if
this reference is for an extent which is shared between 2 snapshot
On Sun, Feb 17, 2019 at 06:42:59PM -0500, Ric Wheeler wrote:
> On 2/17/19 4:09 PM, Dave Chinner wrote:
> >On Sun, Feb 17, 2019 at 03:36:10PM -0500, Ric Wheeler wrote:
> >>One proposal for btrfs was that we should look at getting discard
> >>out of the synchronous path in order to minimize the slowd
On 2019/2/18 上午8:07, Carlos Medrano wrote:
> Greetings Mailing List,
>
> Is it normal for btrfs subvolume list -d to show id 5 as deleted? E.g.
>
> [crlsmdrn@server001 ~]$ sudo btrfs subvol list -d /
> ID 5 gen 707098 top level 0 path DELETED
This is fixed by commit f4a82d9e6754 ("btrfs-progs:
On 2019/2/18 上午9:33, nstgc...@gmail.com wrote:
> Hello,
>
> I have an issue that I first experienced a few years back which was
> never resolved. The timing was really bad so I just scrapped the
> effected volume and made another, but I'd like to actually fix it now.
>
> My system went down as
Hello,
I have an issue that I first experienced a few years back which was
never resolved. The timing was really bad so I just scrapped the
effected volume and made another, but I'd like to actually fix it now.
My system went down as the result of what I assume to be a kernel
panic. After rebooti
Greetings Mailing List,
Is it normal for btrfs subvolume list -d to show id 5 as deleted? E.g.
[crlsmdrn@server001 ~]$ sudo btrfs subvol list -d /
ID 5 gen 707098 top level 0 path DELETED
[crlsmdrn@server001 ~]$
Some background information:
This is a home server running 2 10 tb disks in a btrf
On 2/17/19 4:09 PM, Dave Chinner wrote:
On Sun, Feb 17, 2019 at 03:36:10PM -0500, Ric Wheeler wrote:
One proposal for btrfs was that we should look at getting discard
out of the synchronous path in order to minimize the slowdown
associated with enabling discard at mount time. Seems like an
obvio
On Sun, Feb 17, 2019 at 03:36:10PM -0500, Ric Wheeler wrote:
> One proposal for btrfs was that we should look at getting discard
> out of the synchronous path in order to minimize the slowdown
> associated with enabling discard at mount time. Seems like an
> obvious win for "hint" like operations l
On Sun, Feb 17, 2019 at 9:55 AM Adam Borowski wrote:
>
> On Sun, Feb 17, 2019 at 06:35:25PM +0200, Boaz Harrosh wrote:
> > On 15/02/19 00:06, Dave Chinner wrote:
> > > So you're adding an interface that allows users to change the create
> > > time of files without needing any privileges?
>
> > > I
One proposal for btrfs was that we should look at getting discard out of the
synchronous path in order to minimize the slowdown associated with enabling
discard at mount time. Seems like an obvious win for "hint" like operations like
discard.
I do wonder where we stand now with the cost of the
On Sun, Feb 17, 2019 at 06:35:25PM +0200, Boaz Harrosh wrote:
> On 15/02/19 00:06, Dave Chinner wrote:
> > So you're adding an interface that allows users to change the create
> > time of files without needing any privileges?
> > Inode create time is forensic metadata in XFS - information we use
On 15/02/19 00:06, Dave Chinner wrote:
> On Thu, Feb 14, 2019 at 02:00:07AM -0800, Omar Sandoval wrote:
>> From: Omar Sandoval
>>
>> Hi,
>>
>> Since statx was added in 4.11, userspace has had an interface for
>> reading btime (file creation time), but no way to set it. This RFC patch
>> series add
Tried zero-log. After reboot the system booted again. But all
sub-volumes are mounted read-only.
This should be the relevant dmesg excerpt (note to last lines, there
it mentions forced to ro mode)
[ 51.356769] WARNING: CPU: 3 PID: 54 at fs/btrfs/extent-tree.c:6822
__btrfs_free_extent.isra.25+0x
On Fri, Feb 15, 2019 at 10:59:47AM -0700, Jens Axboe wrote:
> On 2/15/19 10:14 AM, Bart Van Assche wrote:
> > On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> >> On 2/15/19 4:13 AM, Ming Lei wrote:
> >>> This patchset brings multi-page bvec into block layer:
> >>
> >> Applied, thanks Ming. Le
On Fri, Feb 15, 2019 at 09:14:15AM -0800, Bart Van Assche wrote:
> On Fri, 2019-02-15 at 08:49 -0700, Jens Axboe wrote:
> > On 2/15/19 4:13 AM, Ming Lei wrote:
> > > This patchset brings multi-page bvec into block layer:
> >
> > Applied, thanks Ming. Let's hope it sticks!
>
> Hi Jens and Ming,
>
On Fri, Feb 15, 2019 at 03:51:26PM +0100, Christoph Hellwig wrote:
> I still don't understand why mp_bvec_last_segment isn't simply
> called bvec_last_segment as there is no conflict. But I don't
> want to hold this series up on that as there only are two users
> left and we can always just fix it
32 matches
Mail list logo
