On Wed, Mar 03, 2021 at 06:54:40AM -0600, Goldwyn Rodrigues wrote:
> need_force_cow will evaluate to false if both BTRFS_INODE_NODATACOW and
> BTRFS_INODE_PREALLOC are not set. Change the function to should_cow()
> instead and correct the conditions so should_nocow() returns true if
> either BTRFS_
On Wed, Mar 03, 2021 at 05:45:28PM +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./fs/btrfs/volumes.c:1462:10-11: WARNING: return of 0/1 in function
> 'dev_extent_hole_check_zoned' with return type bool.
>
> Reported-by: Abaci Robot
> Signed-off-by: Jiapeng Chong
Add
On Tue, Mar 02, 2021 at 10:27:28AM +, Johannes Thumshirn wrote:
> I've just tripped over this lockdep splat on v5.12-rc1 (Linus' tree not
> misc-next),
> while investigating a different bug report.
>
>
> [ 1250.721882] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
That's not a new warning, it show
On 04/03/2021 02:50, Naohiro Aota wrote:
> These are fixes for zoned btrfs.
>
> Patch 01 fixes the type of a zone sector variable.
>
> Patch 02 moves the superblock location to address based.
>
> Patch 03 fixes zone_unusable acconting when a block group is read-only.
>
> v1 -> v2:
> - Move t
On Tue, Mar 02, 2021 at 12:44:40PM +0200, Nikolay Borisov wrote:
> Signed-off-by: Nikolay Borisov
Added to misc-next, thanks.
On Wed, Mar 03, 2021 at 05:55:46PM +0900, Naohiro Aota wrote:
> We need to use sector_t for zone_sectors, or it set the zone size = 0 when
> the size >= 4GB (= 2^24 sectors) by shifting the zone_sectors value by
> SECTOR_SHIFT.
This does not fix the same bug in btrfs_sb_log_location_bdev.
> Fixe
force_nocow can be calculated by btrfs_inode and does not need to be
passed as an argument.
This simplifies run_delalloc_nocow() call from btrfs_run_delalloc_range()
A new function, should_nocow() checks if the range should be nocow'd or
not. The function returns true iff either BTRFS_INODE_NODATA
On Wed, Mar 03, 2021 at 05:55:47PM +0900, Naohiro Aota wrote:
> This commit moves the location of superblock logging zones basing on the
> fixed address instead of the fixed zone number.
>
> By locating the superblock zones using fixed addresses, we can scan a
> dumped file system image without th
> I don't know. The exact nature of the damage of a failing controller
> is adding a significant unknown component to it. If it was just a
> matter of not writing anything at all, then there'd be no problem. But
> it sounds like it wrote spurious or corrupt data, possibly into
> locations that were
On Mon, Mar 01, 2021 at 09:26:41AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> This patchset adds btree read ahead for full and incremental send operations,
> which results in some nice speedups. Test and results are mentioned in the
> change log of each patch.
Thanks, added to m
On Thu, Mar 04, 2021 at 09:06:25AM -0600, Goldwyn Rodrigues wrote:
> force_nocow can be calculated by btrfs_inode and does not need to be
> passed as an argument.
>
> This simplifies run_delalloc_nocow() call from btrfs_run_delalloc_range()
> A new function, should_nocow() checks if the range shou
On Wed, Mar 03, 2021 at 06:55:37AM -0600, Goldwyn Rodrigues wrote:
> Unused variable: mirror.
>
> Signed-off-by: Goldwyn Rodrigues
Added to misc-next, thanks.
On Tue, Feb 23, 2021 at 12:08:46PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> The first patch fixes a race between fsync and memory mapped writes, which
> can result in corruptions. The second one fixes a different race that in
> practice should be "impossible" to happen, but in
On Wed, Feb 10, 2021 at 05:14:32PM -0500, Josef Bacik wrote:
> v1->v2:
> - Rebase against misc-next.
> - Add Filipe's reviewed-bys.
>
> --- Original email ---
>
> Hello,
>
> Both Filipe and I have found different issues that result in the same thing,
> we
> need to be able to exclude mmap from
On 3/3/21 2:38 PM, Neal Gompa wrote:
On Wed, Mar 3, 2021 at 1:42 PM Josef Bacik wrote:
On 2/24/21 10:47 PM, Neal Gompa wrote:
On Wed, Feb 24, 2021 at 10:44 AM Josef Bacik wrote:
On 2/24/21 9:23 AM, Neal Gompa wrote:
On Tue, Feb 23, 2021 at 10:05 AM Josef Bacik wrote:
On 2/22/21 11:03 P
On Wed, Feb 24, 2021 at 07:08:20PM +0100, David Sterba wrote:
On Wed, Feb 24, 2021 at 07:50:13AM -0500, Sasha Levin wrote:
From: Josef Bacik
[ Upstream commit e19eb11f4f3d3b0463cd897016064a79cb6d8c6d ]
I've been running a stress test that runs 20 workers in their own
subvolume, which are runn
On Wed, Feb 24, 2021 at 07:09:42PM +0100, David Sterba wrote:
On Wed, Feb 24, 2021 at 07:50:12AM -0500, Sasha Levin wrote:
From: Nikolay Borisov
[ Upstream commit 9db4dc241e87fccd8301357d5ef908f40b50f2e3 ]
It's currently u64 which gets instantly translated either to LONG_MAX
(if U64_MAX is pa
On 2021/03/05 0:20, David Sterba wrote:
> On Wed, Mar 03, 2021 at 05:55:47PM +0900, Naohiro Aota wrote:
>> This commit moves the location of superblock logging zones basing on the
>> fixed address instead of the fixed zone number.
>>
>> By locating the superblock zones using fixed addresses, we can
On Tue, Mar 02, 2021 at 09:49:30AM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 11:57 PM Dave Chinner wrote:
> >
> > On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> > > On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > > > I really don't see you seem to be telli
On Thu, Mar 4, 2021 at 3:25 PM Josef Bacik wrote:
>
> On 3/3/21 2:38 PM, Neal Gompa wrote:
> > On Wed, Mar 3, 2021 at 1:42 PM Josef Bacik wrote:
> >>
> >> On 2/24/21 10:47 PM, Neal Gompa wrote:
> >>> On Wed, Feb 24, 2021 at 10:44 AM Josef Bacik wrote:
>
> On 2/24/21 9:23 AM, Neal Gompa
On Tue, Mar 02, 2021 at 04:24:19PM +, Filipe Manana wrote:
> On Sat, Feb 27, 2021 at 3:53 PM Zygo Blaxell
> wrote:
> >
> > Hit this twice so far, while running the usual
> > balance/dedupe/rsync/snapshots/all at once on:
> >
> > a646ddc2bba2 (kdave-gitlab/misc-next) btrfs: unlock exten
On Thu, Mar 4, 2021 at 8:35 AM Sebastian Roller
wrote:
>
> > I don't know. The exact nature of the damage of a failing controller
> > is adding a significant unknown component to it. If it was just a
> > matter of not writing anything at all, then there'd be no problem. But
> > it sounds like it w
Hello,
My raid1 btrfs fs went read only recently. It was comprised of 2 drives:
/dev/sda ST4000VN008 (firmware SC60) - 6 month old drive
/dev/sdb ST4000VN000 (firmware SC44) - 5 year old drive (but it was
mostly idly spinning, very little accesses were done in that time)
The drives are pretty simi
23 matches
Mail list logo
