Am Mon, 10 Apr 2017 15:43:57 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 14:18, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 13:13:39 -0400
> > schrieb "Austin S. Hemmelgarn" :
> >
> >> On 2017-04-10 12:54, Kai Krakow wrote:
> [...]
> [...]
> >> [...]
> >> [...]
> [...]
>
Am Tue, 11 Apr 2017 01:45:32 +0200
schrieb "Janos Toth F." :
> >> The command-line also rejects a number of perfectly legitimate
> >> arguments that BTRFS does understand too though, so that's not much
> >> of a test.
> >
> > Which are those? I didn't encounter any...
>
> I think this bug sti
Create test case '026-wrong-dir-inode-isize'.
Create becon files '.lowmem_repairable' under tests/fsck-test/016 and 026.
Now 'make test-fsck' will test lowmem repairable test cases if
TEST_ENABLE_OVERRIDE=true.
Signed-off-by: Su Yue
---
.../fsck-tests/016-wrong-inode-nbytes/.lowmem_repairable |
The series include following contents:
1) Repair wrong nbytes of file inode item.
After traversal of extents in one file, we should get the actual nbytes
of the file. If nbytes in the file inode differs from the actual value,
set the value to actual one.
The wrong nbytes of file in
Enable btrfsck option '--repair' with option '--mode=lowmem'.
Now lowmem mode only repairs wrong nbytes, dir isize.
Signed-off-by: Su Yue
---
cmds-check.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index 6ab18b26..da5fe75f 100644
--- a/cm
After checking one inode item, we should get the actual nbytes of the
inode item.
Introduce function 'repair_inode_nbytes_lowmem' to set nbytes in struct
btrfs_inode_item to the actual nbytes. After call of the function, the
wrong nbytes should have been corrected.
Signed-off-by: Su Yue
---
cmds
After traversal of whole directory, we should get the actual isize.
Introduce function 'repair_dir_isize_lowmem' to set isize in the directory
inode item to actual size. After call of the function, the wrong dir isize
should have been corrected.
Signed-off-by: Su Yue
---
cmds-check.c | 68 +
From: Qu Wenruo
Since lowmem mode can repair certain corruptions (mostly in fs tree),
insert a beacon into each fsck test cases to allow some of them be
tested for lowmem mode.
With this patch, fsck option override will check the beacon file
".lowmem_repairbale" in the same directory of the test
At 04/11/2017 10:20 AM, Qu Wenruo wrote:
At 04/10/2017 11:34 PM, David Sterba wrote:
On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote:
On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote:
Hi,
Recent btrfs/137 test case makes me wonder what's the designed
behavior of btrfs inline d
At 04/10/2017 11:34 PM, David Sterba wrote:
On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote:
On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote:
Hi,
Recent btrfs/137 test case makes me wonder what's the designed behavior of
btrfs inline data extent.
The current behavior in fact is
At 04/10/2017 10:14 PM, David Sterba wrote:
On Mon, Apr 10, 2017 at 04:00:25PM +0200, David Sterba wrote:
On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote:
At 04/07/2017 08:00 PM, David Sterba wrote:
On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote:
@@ -3355,12 +3355,14
I was shocked to discover that 'btrfs receive --dump' doesn't print a
space after long filenames, so it runs together into the metadata; for
example:
truncate./20-00-03/this-name-is-32-characters-longsize=0
This is a trivial patch to add a single space unconditionally, so the
result is th
>> The command-line also rejects a number of perfectly legitimate
>> arguments that BTRFS does understand too though, so that's not much
>> of a test.
>
> Which are those? I didn't encounter any...
I think this bug still stands unresolved (for 3+ years, probably
because most people use init-rd/fs
On 04/10/2017 02:23 PM, Austin S. Hemmelgarn wrote:
> On 2017-04-08 16:19, Hans van Kranenburg wrote:
>> So... today a real life story / btrfs use case example from the trenches
>> at work...
>>
>> tl;dr 1) btrfs is awesome, but you have to carefully choose which parts
>> of it you want to use or a
On Mon, Apr 10, 2017 at 03:43:57PM -0400, Austin S. Hemmelgarn wrote:
> On 2017-04-10 14:18, Kai Krakow wrote:
> * strictatime, lazytime: Both atime and mtime updates happen, but they
> actual update may not hit the disk for up to 24 hours (this will let mutt
> work correctly as long as your syste
On 2017-04-10 14:18, Kai Krakow wrote:
Am Mon, 10 Apr 2017 13:13:39 -0400
schrieb "Austin S. Hemmelgarn" :
On 2017-04-10 12:54, Kai Krakow wrote:
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb "Austin S. Hemmelgarn" :
[...]
[...]
[...
KASAN reports that there is a use-after-free case of bio in btrfs_map_bio.
If we need to submit IOs to several disks at a time, the original bio
would get cloned and mapped to the destination disk, but we really should
use the original bio instead of a cloned bio to do the sanity check
because clo
On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote:
> Unbreaks ARM and possibly other 32-bit architectures.
>
Thanks a lot for the fix.
Reviewed-by: Liu Bo
Thanks,
-liubo
> Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len
> Reported-by: Icenowy Zheng
> Signed-off
On Sun, Apr 09, 2017 at 08:08:05PM +0300, Nikolay Borisov wrote:
>
>
> On 7.04.2017 23:11, Liu Bo wrote:
> > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> > introduced this bug during iterating bio pages in dio read's endio hook,
> > and it could end up with segmen
On Mon, Apr 10, 2017 at 07:13:46PM +0200, Diego wrote:
> In the latest git, with KASAN enabled:
>
> [ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at
> addr 8803801a76fc
> [ 180.560151] Read of size 4 by task localStorage DB/924
> [ 180.560160] CPU: 0 PID: 924 Comm:
Am Mon, 10 Apr 2017 13:13:39 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 12:54, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 18:44:44 +0200
> > schrieb Kai Krakow :
> >
> >> Am Mon, 10 Apr 2017 08:51:38 -0400
> >> schrieb "Austin S. Hemmelgarn" :
> >>
> [...]
> [...]
> >> [...]
On Tue, Apr 04, 2017 at 12:43:57AM +0200, Hans van Kranenburg wrote:
> On 04/03/2017 02:24 PM, David Sterba wrote:
> > On Fri, Mar 31, 2017 at 10:24:57PM +0200, Hans van Kranenburg wrote:
> Adding the 'nossd_spread' would be good to have, even if it might be
> just a marginal usecase.
> >
On Sun, Apr 09, 2017 at 12:37:47AM +0200, Hans van Kranenburg wrote:
> The text compress_lzo:: would show up directly after 'bigger than the
> page size' on the same line.
Applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord.
On 2017-04-10 12:54, Kai Krakow wrote:
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb "Austin S. Hemmelgarn" :
On 2017-04-10 08:45, Kai Krakow wrote:
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb "Austin S. Hemmelgarn" :
[...]
Does btrfs
In the latest git, with KASAN enabled:
[ 180.560145] BUG: KASAN: use-after-free in btrfs_map_bio+0x994/0x10b0 at addr
8803801a76fc
[ 180.560151] Read of size 4 by task localStorage DB/924
[ 180.560160] CPU: 0 PID: 924 Comm: localStorage DB Not tainted
4.11.0-rc6-g39da7c509acf #19
[ 180.5
Am Mon, 10 Apr 2017 18:44:44 +0200
schrieb Kai Krakow :
> Am Mon, 10 Apr 2017 08:51:38 -0400
> schrieb "Austin S. Hemmelgarn" :
>
> > On 2017-04-10 08:45, Kai Krakow wrote:
> > > Am Mon, 10 Apr 2017 08:39:23 -0400
> > > schrieb "Austin S. Hemmelgarn" :
> > >
> [...]
> > >
> > > Does btrf
Am Mon, 10 Apr 2017 08:51:38 -0400
schrieb "Austin S. Hemmelgarn" :
> On 2017-04-10 08:45, Kai Krakow wrote:
> > Am Mon, 10 Apr 2017 08:39:23 -0400
> > schrieb "Austin S. Hemmelgarn" :
> >
> >> They've been running BTRFS
> >> with LZO compression, the SSD allocator, atime disabled, and mtime
> >
On Sun, Apr 09, 2017 at 08:08:05PM +0300, Nikolay Borisov wrote:
>
>
> On 7.04.2017 23:11, Liu Bo wrote:
> > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> > introduced this bug during iterating bio pages in dio read's endio hook,
> > and it could end up with segmen
On Mon, Apr 10, 2017 at 10:17:52AM -0400, Josef Bacik wrote:
>
> > On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote:
> >
> > Hi,
> >
> > Recent btrfs/137 test case makes me wonder what's the designed behavior of
> > btrfs inline data extent.
> >
> > The current behavior in fact is quite a chaos.
On Mon 10-04-17 07:39:43, Christoph Hellwig wrote:
> On Mon, Apr 10, 2017 at 02:37:50PM +0200, Jan Kara wrote:
> > I don't understand here. Do you want that all filesystems support NOWAIT
> > direct IO?
>
> No. Per-file_system_type is way to coarse grained. All feature flag
> needs to be per-fil
On Mon, Apr 10, 2017 at 02:37:50PM +0200, Jan Kara wrote:
> I don't understand here. Do you want that all filesystems support NOWAIT
> direct IO?
No. Per-file_system_type is way to coarse grained. All feature flag
needs to be per-file_operation at least for cases like ext4 with our
without exten
> On Apr 9, 2017, at 11:27 PM, Qu Wenruo wrote:
>
> Hi,
>
> Recent btrfs/137 test case makes me wonder what's the designed behavior of
> btrfs inline data extent.
>
> The current behavior in fact is quite a chaos.
> We need a standard of how inline extent should behave.
>
> 1) max_inline lim
On Mon, Apr 10, 2017 at 04:00:25PM +0200, David Sterba wrote:
> On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote:
> >
> >
> > At 04/07/2017 08:00 PM, David Sterba wrote:
> > > On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote:
> > >> @@ -3355,12 +3355,14 @@ static int cache_save_
On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote:
>
>
> At 04/07/2017 08:00 PM, David Sterba wrote:
> > On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote:
> >> @@ -3355,12 +3355,14 @@ static int cache_save_setup(struct
> >> btrfs_block_group_cache *block_group,
> >>struct bt
On 2017-04-10 08:45, Kai Krakow wrote:
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb "Austin S. Hemmelgarn" :
They've been running BTRFS
with LZO compression, the SSD allocator, atime disabled, and mtime
updates deferred (lazytime mount option) the whole time, so it may be
a slightly different use
On 2017-04-08 17:07, Adam Borowski wrote:
Unbreaks ARM and possibly other 32-bit architectures.
Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len
Reported-by: Icenowy Zheng
Signed-off-by: Adam Borowski
---
You'd probably want to squash this with Liu's commit, to be nice to fut
Am Mon, 10 Apr 2017 08:39:23 -0400
schrieb "Austin S. Hemmelgarn" :
> They've been running BTRFS
> with LZO compression, the SSD allocator, atime disabled, and mtime
> updates deferred (lazytime mount option) the whole time, so it may be
> a slightly different use case than the OP from this thre
On 2017-04-10 04:53, Adam Borowski wrote:
Hi!
While messing with the division failure on current -next, I've noticed that
parity scrub splats immediately on all 32-bit archs I tried. But, it's not
a regression: it bisects to 5a6ac9eacb49143cbad3bbfda72263101cb1f3df (merged
in 3.19) which happens
On 2017-04-09 19:23, Hans van Kranenburg wrote:
On 04/08/2017 01:16 PM, Hans van Kranenburg wrote:
On 04/07/2017 11:25 PM, Hans van Kranenburg wrote:
Ok, I'm going to revive a year old mail thread here with interesting new
info:
[...]
Now, another surprise:
From the exact moment I did mount
On Mon 10-04-17 00:45:39, Christoph Hellwig wrote:
> On Tue, Apr 04, 2017 at 01:41:09PM -0500, Goldwyn Rodrigues wrote:
> > I am working on incorporating RWF_* flags. However, I am not sure how
> > RWF_* flags would get rid of FS_NOWAIT/FS_NOWAIT_IO. Since most of
> > "blocking" information is with
On 2017-04-08 16:19, Hans van Kranenburg wrote:
So... today a real life story / btrfs use case example from the trenches
at work...
tl;dr 1) btrfs is awesome, but you have to carefully choose which parts
of it you want to use or avoid 2) improvements can be made, but at least
the problems releva
On Fri, Apr 07, 2017 at 06:05:02PM +0200, David Sterba wrote:
> On Fri, Apr 07, 2017 at 08:10:48AM -0700, Randy Dunlap wrote:
> > On 04/07/17 08:08, Randy Dunlap wrote:
> > > On 04/07/17 01:27, Stephen Rothwell wrote:
> > >> Hi all,
> > >>
> > >> Changes since 20170406:
> > >>
> > >
> > > on i386:
On 2017-04-08 01:12, Duncan wrote:
Austin S. Hemmelgarn posted on Fri, 07 Apr 2017 07:41:22 -0400 as
excerpted:
2. Results from 'btrfs scrub'. This is somewhat tricky because scrub is
either asynchronous or blocks for a _long_ time. The simplest option
I've found is to fire off an asynchronou
On Sat, Apr 08, 2017 at 11:07:37PM +0200, Adam Borowski wrote:
> Unbreaks ARM and possibly other 32-bit architectures.
>
> Fixes: 7d0ef8b4d: Btrfs: update scrub_parity to use u64 stripe_len
> Reported-by: Icenowy Zheng
> Signed-off-by: Adam Borowski
> ---
> You'd probably want to squash this wit
On Mon, 2017-04-10 at 16:53 +0800, Qu Wenruo wrote:
>
> Then try chunk recovery
> --
> btrfs rescue chunk-recover /dev/dm-0
> --
>
> It can be very slow since it may scan the full device.
>
> Thanks,
> Qu
>
> > > Thanks,
> > > Qu
> >
> > Thank you
> >
Thank you for your help this fa
At 04/10/2017 04:37 PM, Malte Eggers wrote:
On Mon, 2017-04-10 at 16:18 +0800, Qu Wenruo wrote:
At 04/10/2017 01:17 AM, Malte Eggers wrote:
Hi,
After suspending and waking up my laptop with the external hard
drive
connected, I could no longer access the files on it. So I unmounted
and
remou
Hi!
While messing with the division failure on current -next, I've noticed that
parity scrub splats immediately on all 32-bit archs I tried. But, it's not
a regression: it bisects to 5a6ac9eacb49143cbad3bbfda72263101cb1f3df (merged
in 3.19) which happens to be when parity scrub was added. Ie, it
On Mon, 2017-04-10 at 16:18 +0800, Qu Wenruo wrote:
>
> At 04/10/2017 01:17 AM, Malte Eggers wrote:
> > Hi,
> >
> > After suspending and waking up my laptop with the external hard
> > drive
> > connected, I could no longer access the files on it. So I unmounted
> > and
> > remounted it, only to d
At 04/10/2017 01:17 AM, Malte Eggers wrote:
Hi,
After suspending and waking up my laptop with the external hard drive
connected, I could no longer access the files on it. So I unmounted and
remounted it, only to discover that I could no longer mount it.
This is the error (mounting with useba
On Sun, 2017-04-09 at 15:25 -0600, Chris Murphy wrote:
> On Sun, Apr 9, 2017 at 11:17 AM, Malte Eggers
> wrote:
> > Hi,
> >
> > After suspending and waking up my laptop with the external hard
> > drive
> > connected, I could no longer access the files on it. So I unmounted
> > and
> > remounted i
On Tue, Apr 04, 2017 at 01:41:09PM -0500, Goldwyn Rodrigues wrote:
> I am working on incorporating RWF_* flags. However, I am not sure how
> RWF_* flags would get rid of FS_NOWAIT/FS_NOWAIT_IO. Since most of
> "blocking" information is with the filesystem, it is a per-filesystem
> flag to block out
51 matches
Mail list logo