On Tue, Oct 10, 2023 at 9:26 PM Josef Bacik wrote:
>
> From: Sweet Tea Dorminy
>
> Make sure that snapshots of encrypted data are readable and writeable.
>
> Test deliberately high-numbered to not conflict.
>
> Signed-off-by: Sweet Tea Dorminy
> ---
> tests/btrfs/614 | 76 +
On Fri, Apr 16, 2021 at 10:14 AM Johannes Thumshirn
wrote:
>
> On 16/04/2021 11:12, Filipe Manana wrote:
> > On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
> > wrote:
> >>
> >> When relocating a block group the freed up space is not discarded in on
t; void btrfs_mark_bg_unused(struct btrfs_block_group *bg);
> +void btrfs_reclaim_bgs_work(struct work_struct *work);
> +void btrfs_reclaim_bgs(struct btrfs_fs_info *fs_info);
> +void btrfs_mark_bg_to_reclaim(struct btrfs_block_group *bg);
> int btrfs_read_block_groups(str
On Thu, Apr 15, 2021 at 3:00 PM Johannes Thumshirn
wrote:
>
> As a preparation for another user, rename the unused_bgs_mutex into
> reclaim_bgs_lock.
>
> Signed-off-by: Johannes Thumshirn
Reviewed-by: Filipe Manana
Looks good, thanks.
> ---
> fs/btrfs/block-group.c |
return ret;
> }
>
> - /*
> -* step two, delete the device extents and the
> -* chunk tree entries
> -*/
This hunk seems unrelated and unintentional.
Not that the comment adds any value, but if the removal was
intentional, I wou
On Wed, Apr 14, 2021 at 2:00 PM Johannes Thumshirn
wrote:
>
> On 14/04/2021 13:23, Johannes Thumshirn wrote:
> > From how I understand the code, yes. It's a quick test, so let's just do it
> > and see what breaks.
> >
> > I'd prefer to just drop the ->ro check, it's less special casing for zoned
>
On Wed, Apr 14, 2021 at 1:35 PM Johannes Thumshirn
wrote:
>
> On 14/04/2021 14:09, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When doing a device replace on a zoned filesystem, if we find a block
> > group with ->to_copy == 0, we jump to the label
On Wed, Apr 14, 2021 at 12:22 PM Johannes Thumshirn
wrote:
>
> On 14/04/2021 13:17, Filipe Manana wrote:
> > Yep, that's what puzzled me, why the need to do it for non-zoned file
> > systems when using -o discard=sync.
> > I assumed you ran into a case where dis
On Tue, Apr 13, 2021 at 6:48 PM Johannes Thumshirn
wrote:
>
> On 13/04/2021 14:57, Filipe Manana wrote:
> > And what about the other mechanism that triggers discards on pinned
> > extents, after the transaction commits the super blocks?
> > Why isn't that happeni
On Tue, Apr 13, 2021 at 1:44 PM Johannes Thumshirn
wrote:
>
> On 12/04/2021 16:21, Johannes Thumshirn wrote:
> >> If it affects only the zoned case, I also don't see why doing it when
> >> not in zoned mode (and -o discard=sync is set).
> >> Unless of course the default discard mechanism is broken
On Mon, Apr 12, 2021 at 2:49 PM Johannes Thumshirn
wrote:
>
> On 09/04/2021 13:37, Filipe Manana wrote:
> > On Fri, Apr 9, 2021 at 11:54 AM Johannes Thumshirn
> > wrote:
> >>
> >> When relocating a block group the freed up space is not discarded. On
> >
On Fri, Apr 9, 2021 at 2:39 PM Dennis Zhou wrote:
>
> On Fri, Apr 09, 2021 at 12:39:38PM +0100, Filipe Manana wrote:
> > On Thu, Apr 8, 2021 at 4:02 PM Dennis Zhou wrote:
> > >
> > > On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> > > >
On Thu, Apr 8, 2021 at 4:02 PM Dennis Zhou wrote:
>
> On Thu, Apr 08, 2021 at 03:28:20PM +0100, Filipe Manana wrote:
> > On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
> > >
> > > On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> > > > Hi,
On Fri, Apr 9, 2021 at 11:54 AM Johannes Thumshirn
wrote:
>
> When relocating a block group the freed up space is not discarded. On
> devices like SSDs this hint is useful to tell the device the space is
> freed now. On zoned block devices btrfs' discard code will reset the zone
> the block group
On Thu, Apr 8, 2021 at 2:50 PM Dennis Zhou wrote:
>
> On Thu, Apr 08, 2021 at 05:20:00PM +0800, Wang Yugui wrote:
> > Hi,
> >
> > > On Thu, Apr 08, 2021 at 07:28:01AM +0800, Wang Yugui wrote:
> > > > Hi,
> > > >
> > > > > > > > upper caller:
> > > > > > > > nofs_flag = memalloc_nofs_save();
>
On Sun, Apr 4, 2021 at 5:16 AM Zygo Blaxell
wrote:
>
> Base kernel is 9228ad80f849 "btrfs: zoned: move log tree node allocation
> out of log_root_tree->log_mutex" from misc-next on 2021-03-29.
>
> The BUG() moved, but we are still hitting it:
>
> [145427.426011][ T5492] BTRFS info (device
On Mon, Mar 29, 2021 at 7:49 PM David Sterba wrote:
>
> On Tue, Mar 23, 2021 at 06:39:49PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > If we reflink to or from a file opened with O_SYNC/O_DSYNC or to/from a
> > file that has the S_SYNC attribu
On Thu, Mar 25, 2021 at 12:07 PM James Freiwirth
wrote:
>
> I'm trying to perform an incremental backup as I usually do but I'm
> getting an error:
>
> sudo btrfs send -p /vault_pool/.snapshots/2020-12-31
> /vault_pool/.snapshots/2021-03-20 | sudo btrfs receive
> /mnt/WDElements/vault
> At subvol
...
> // update cur_offset & len
> // advance cur_offset & len in hole-punching case if needed
> }
>
> Reported-by: Robbie Ko
> Fixes: d77815461f04 ("btrfs: Avoid trucating page or punching hole in a
> already existed hole.")
> Reviewed-by: R
nfo->tree_root->log_mutex, we can (and should) move the code out of the
> lock scope of log_root_tree->log_mutex and silence the warning.
>
> Cc: Filipe Manana
> Cc: Johannes Thumshirn
> Signed-off-by: Naohiro Aota
Reviewed-by: Filipe Manana
Looks good, thanks.
> -
On Wed, Mar 24, 2021 at 11:15 AM bingjingc wrote:
>
> From: BingJing Chang
>
> In commit d77815461f04 ("btrfs: Avoid trucating page or punching hole in
> a already existed hole."), existed holes can be skipped by calling
> find_first_non_hole() to adjust *start and *len. However, if the given
> l
On Fri, Mar 19, 2021 at 10:52 AM Johannes Thumshirn
wrote:
>
> When a file gets deleted on a zoned file system, the space freed is not
> returned back into the block group's free space, but is migrated to
> zone_unusable.
>
> As this zone_unusable space is behind the current write pointer it is no
On Thu, Mar 18, 2021 at 11:25 AM wrote:
>
> From: Filipe Manana
>
> While removing a qgroup's sysfs entry we end up taking the kernfs_mutex,
> through kobject_del(), while holding the fs_info->qgroup_lock spinlock,
> producing the following trace:
>
> [ 821.84363
On Thu, Mar 18, 2021 at 10:53 AM Stuart Shelton wrote:
>
> Hi all,
>
> I recently migrated an existing ext4 fs using btrfs-convert (setting nodesize
> to 32k and enabling optional features `extref`, `skinny-metadata` and
> `no-holes` - the first two of which I believe are now the default in any
On Wed, Mar 17, 2021 at 10:40 AM Johannes Thumshirn
wrote:
>
> When a file gets deleted on a zoned file system, the space freed is no
> returned back into the block group's free space, but is migrated to
> zone_unusable.
>
> As this zone_unusable space is behind the current write pointer it is not
On Wed, Mar 17, 2021 at 3:31 PM Johannes Thumshirn
wrote:
>
> On 17/03/2021 16:26, Filipe Manana wrote:
> >> +void btrfs_reclaim_bgs(struct btrfs_fs_info *fs_info)
> >> +{
> >> + struct btrfs_block_group *bg;
> >> + struct btrfs_space_
On Tue, Mar 16, 2021 at 11:43 AM Filipe Manana wrote:
>
> On Tue, Mar 16, 2021 at 6:49 AM robbieko wrote:
> >
> > Hi All,
> >
> > The patch delayed find orphan roots.
> > Move to after orphan cleanup with tree_root.
> > I think this will cause all
On Mon, Mar 15, 2021 at 7:31 PM David Sterba wrote:
>
> On Thu, Mar 11, 2021 at 02:31:06PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When freeing a tree block we may end up adding its extent back to the
> > free space cache/tree, as long a
On Tue, Mar 16, 2021 at 6:49 AM robbieko wrote:
>
> Hi All,
>
> The patch delayed find orphan roots.
> Move to after orphan cleanup with tree_root.
> I think this will cause all orphan items to be deleted
> when orphan cleanup with tree_root.
> Afterwards, find orphan roots cannot find
> the subvo
or slightly different cases. So I prefer
to keep them separate for ease of review.
>
> Best Regards
> Wang Yugui (wangyu...@e16-tech.com)
> 2021/03/13
>
> > From: Filipe Manana
> >
> > The tree modification log functions are called very frequently, basically
>
On Thu, Mar 11, 2021 at 6:05 PM Martin Raiber wrote:
>
> On 11.03.2021 15:43 Filipe Manana wrote:
> > On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
> >> Hi,
> >>
> >> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in
> &
On Thu, Mar 11, 2021 at 5:27 PM kernel test robot wrote:
>
> Hi,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on v5.12-rc2]
> [also build test WARNING on next-20210311]
> [cannot apply to kdave/for-next]
> [If your patch is applied to the wrong git tree,
On Wed, Mar 10, 2021 at 5:18 PM Martin Raiber wrote:
>
> Hi,
>
> I have this in a btrfs directory. Linux kernel 5.10.16, no errors in dmesg,
> no scrub errors:
>
> ls -lh
> total 19G
> -rwxr-x--- 1 root root 783 Mar 10 14:56 disk_config.dat
> -rwxr-x--- 1 root root 783 Mar 10 14
On Wed, Mar 10, 2021 at 5:52 PM Zygo Blaxell
wrote:
>
> On Fri, Mar 05, 2021 at 12:45:08PM +, Filipe Manana wrote:
> > On Fri, Mar 5, 2021 at 1:08 AM Zygo Blaxell
> > wrote:
> > >
> > > On Tue, Mar 02, 2021 at 04:24:19PM +, Filipe Manana wrote:
>
On Sun, Mar 7, 2021 at 3:24 PM Eryu Guan wrote:
>
> On Sun, Mar 07, 2021 at 03:07:43PM +, Filipe Manana wrote:
> > On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
> > >
> > > On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrot
On Sun, Mar 7, 2021 at 2:41 PM Eryu Guan wrote:
>
> On Thu, Feb 11, 2021 at 05:01:18PM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Test cases where a direct IO write, with O_DSYNC, can not be done and has
> > to fallback to a buffered write.
On Fri, Mar 5, 2021 at 1:08 AM Zygo Blaxell
wrote:
>
> 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
> > >
On Fri, Mar 5, 2021 at 9:46 AM Jia-Ju Bai wrote:
>
> When the list of reloc_roots is empty, no error return code of
> btrfs_recover_relocation() is assigned.
> To fix this bug, err is assigned with -ENOENT as error return code.
No, there isn't any such bug.
If there are no reloc roots, it means
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 extents in
> btrfs_zero_range in case of quota reservation errors
>
> Looks like
On Thu, Feb 25, 2021 at 7:52 PM Casey Schaufler wrote:
>
> I recently upgraded a Smack based system to Fedora33. I now get
> this stack trace on a regular basis. The system appears to be
> functioning correctly, but I find the warning worrisome.
You have SELinux enabled I suppose.
Try the follow
On Thu, Feb 25, 2021 at 1:23 PM Neal Gompa wrote:
>
> On Wed, Feb 24, 2021 at 11:10 PM Amy Parker wrote:
> >
> > The compression options in Btrfs are great, and help save a ton of
> > space on disk. Zstandard works extremely well for this, and is fairly
> > fast. However, it can heavily reduce th
On Wed, Feb 17, 2021 at 12:29 PM Qu Wenruo wrote:
>
>
>
> On 2021/2/17 下午8:12, Filipe Manana wrote:
> > On Wed, Feb 17, 2021 at 11:28 AM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2021/2/17 下午6:59, Filipe Manana wrote:
&
On Wed, Feb 17, 2021 at 11:28 AM Qu Wenruo wrote:
>
>
>
> On 2021/2/17 下午6:59, Filipe Manana wrote:
> > On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
> >>
> >>
> >>
> >> On 2021/2/16 下午10:45, Filipe Manana wrote:
> >>> On
On Tue, Feb 16, 2021 at 11:42 PM Qu Wenruo wrote:
>
>
>
> On 2021/2/16 下午10:45, Filipe Manana wrote:
> > On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
> >>
> >> [BUG]
> >> The following script could lead to corrupted btrfs fs after
> >>
On Tue, Feb 16, 2021 at 4:28 PM Sidong Yang wrote:
>
> Remove a code that inserting new line in fmt_end() for text mode.
> Old code made a failure in fstest btrfs/006.
>
> Signed-off-by: Sidong Yang
> ---
> Hi, I've just read mail that Filipe written that some failure about fstest.
> I'm worried
t; btrfs filesystem sync
>
> And the sync will error out because we'll abort the transaction. The
> magic values above are used because they generate hash collisions with
> the first file in the main subvol.
>
> The fix for this is to remove the hash value check from tree ch
97886c0 R14: 0001 R15: 557ef976e2a0
>
> This happens, because we are taking the ->log_mutex albeit it has already
> been locked.
>
> Also while at it, fix the bogus unlock of the tree_log_mutex in the error
> handling.
>
> Fixes: 3ddebf27fcd3 ("btrfs: zoned
On Tue, Feb 16, 2021 at 8:45 PM Josef Bacik wrote:
>
> This is a regression test for a problem where we would flip read only if
> we reflink'ed enough extents to generate key'ed references, and then got
> a hash collision with those references. This is a test for the fix
>
> btrfs: do not
On 16/02/21 14:50, Greg KH wrote:
> On Tue, Feb 16, 2021 at 02:40:31PM +, fdman...@kernel.org wrote:
>> From: Filipe Manana
>>
>> Whenever we attempt to do a non-aligned direct IO write with O_DSYNC, we
>> end up triggering an assertion and crashing. Exampl
On Wed, Jun 24, 2020 at 10:00 PM Qu Wenruo wrote:
>
> [BUG]
> The following script could lead to corrupted btrfs fs after
> btrfs-convert:
>
> fallocate -l 1G test.img
> mkfs.ext4 test.img
> mount test.img $mnt
> fallocate -l 200m $mnt/file1
> fallocate -l 200m $mnt/file2
> fallocate -
On Tue, Feb 16, 2021 at 2:25 PM David Sterba wrote:
>
> On Mon, Feb 15, 2021 at 11:05:33AM +, Filipe Manana wrote:
> > On Sat, Feb 13, 2021 at 1:07 AM Wang Yugui wrote:
> > > > This bug only affects 5.10 kernels, and the regression was introduced in
> > > &g
On Tue, Jan 19, 2021 at 5:26 AM David Sterba wrote:
>
> Hi,
>
> btrfs-progs version 5.10 have been released.
>
> Only minor changes snice -rc1: CI on gitlab disabled, some docs added.
>
> Changelog:
>
> * scrub status:
> * print percentage of progress
> * add size unit options
> * fi u
On Fri, Feb 5, 2021 at 11:33 AM David Sterba wrote:
>
> Hi,
>
> btrfs-progs version 5.10.1 have been released.
>
> The static build got broken due to libmount added in 5.10, this works now. The
> minimum libmount version is 2.24 that is not available on some LTS distros
> like
> CentOS 7. The pla
On Wed, Nov 11, 2020 at 4:42 PM Sidong Yang wrote:
>
> Add supports for json formatting, this patch changes hard coded printing
> code to formatted print with output formatter. Json output would be
> useful for other programs that parse output of the command. but it
> changes the text format.
>
>
On Sat, Feb 13, 2021 at 3:09 PM Cerem Cem ASLAN wrote:
>
> Basically I'm using btrbk to create snapshots on main disk (MMM) and
> send them 2 distinct disks (AAA and BBB). I have many nested
> subvolumes (X, X/foo/Y, etc), so every distinct subvolume is
> enumerated separately, like X.111, X.112,
something wrong is
significant. That's why I opted to send this patch, which is much more
simple.
David has more experience on that and it's up to him to decide.
>
> Best Regards
> Wang Yugui (wangyu...@e16-tech.com)
> 2021/02/13
>
>
> > Fixes: 0eb79294dbe328
On Tue, Feb 9, 2021 at 9:32 PM Michal Rostecki wrote:
>
> From: Michal Rostecki
>
> Add the btrfs_check_mixed() function which checks if the filesystem has
> the mixed type of devices (non-rotational and rotational). This
> information is going to be used in roundrobin raid1 read policy.
>
> Sign
On Fri, Feb 5, 2021 at 12:55 PM Naohiro Aota wrote:
>
> On Fri, Feb 05, 2021 at 11:49:05AM +, Filipe Manana wrote:
> > On Fri, Feb 5, 2021 at 9:26 AM Naohiro Aota wrote:
> > >
> > > Since the zoned filesystem requires sequential write out of metadata, we
>
On Fri, Feb 5, 2021 at 7:44 AM Anand Jain wrote:
>
> On 2/4/2021 6:11 PM, Filipe Manana wrote:
> > On Thu, Feb 4, 2021 at 8:48 AM Anand Jain wrote:
> >>
> >> On 2/3/2021 7:17 PM, fdman...@kernel.org wrote:
> >>> From: Filipe Manana
> >>>
&g
On Fri, Feb 5, 2021 at 11:49 AM Filipe Manana wrote:
>
> On Fri, Feb 5, 2021 at 9:26 AM Naohiro Aota wrote:
> >
> > Since the zoned filesystem requires sequential write out of metadata, we
> > cannot proceed with a hole in tree-log pages. When such a hole exists,
>
If we want to wait for them and got the error, we cannot wait for them
> because it will cause a deadlock. So, let's bail out to a full commit in
> this case.
>
> Signed-off-by: Naohiro Aota
Reviewed-by: Filipe Manana
It looks good now, thanks!
> ---
> fs/btrfs/tr
; to be written, because it will cause a deadlock. So, let's bail out to a
> full commit in this case.
>
> Cc: Filipe Manana
> Signed-off-by: Naohiro Aota
> ---
> fs/btrfs/tree-log.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> This
ng.
> +*/
> + if (zoned && !created) {
> + ret = -EAGAIN;
> goto out;
> + }
>
> ret = btrfs_add_log_tree(trans, root);
> if (ret)
>
Ok, with th
them. So, the
> writing causes unaligned write errors.
>
> Reorder the allocation of them by delaying allocation of the root node of
> "fs_info->log_root_tree," so that the node buffers can go out sequentially
> to devices.
>
> Cc: Filipe Manana
> Reviewed-by: J
log
> transaction when other subvolumes already allocated the global log root
> tree.
>
> Cc: Filipe Manana
> Reviewed-by: Josef Bacik
> Signed-off-by: Naohiro Aota
> ---
> fs/btrfs/tree-log.c | 29 +
> 1 file changed, 29 insertions(+)
>
On Wed, Feb 3, 2021 at 10:15 PM Martin Raiber wrote:
>
> Hi,
>
> I've been looking a bit into the btrfs space cache and came to following
> conclusions. Please correct me if I'm wrong:
>
> 1. The space cache mount option only modifies how the space cache is
> persisted and not the in-memory stru
On Thu, Feb 4, 2021 at 8:48 AM Anand Jain wrote:
>
> On 2/3/2021 7:17 PM, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we active a swap file, at btrfs_swap_activate(), we acquire the
> > exclusive operation lock to prevent the physical location o
On Tue, Feb 2, 2021 at 2:15 PM Wang Yugui wrote:
>
> Hi, Filipe Manana
>
> There are some dbench(sync mode) result on the same hardware,
> but with different linux kernel
>
> 4.14.200
> Operation CountAvgLatMaxLat
> -
On Sun, Jan 31, 2021 at 3:52 PM Roman Anasal | BDSU
wrote:
>
> On Mon, Jan 25, 2021 at 20:51 + Filipe Manana wrote:
> > On Mon, Jan 25, 2021 at 7:51 PM Roman Anasal
> > wrote:
> > > Second example:
> > > # case 2: same ino at different path
&g
On Tue, Feb 2, 2021 at 5:42 AM Wang Yugui wrote:
>
> Hi, Filipe Manana
>
> The dbench result with these patches is very good. thanks a lot.
>
> This is the dbench(synchronous mode) result , and then a question.
>
> command: dbench -s -t 60 -D /btrfs/ 32
> mount option:
On Wed, Jan 27, 2021 at 6:48 PM Naohiro Aota wrote:
>
> This is the 3/3 patch to enable tree-log on ZONED mode.
>
> The allocation order of nodes of "fs_info->log_root_tree" and nodes of
> "root->log_root" is not the same as the writing order of them. So, the
> writing causes unaligned write error
On Tue, Jan 26, 2021 at 5:53 AM Naohiro Aota wrote:
>
> This is the 2/3 patch to enable tree-log on ZONED mode.
>
> Since we can start more than one log transactions per subvolume
> simultaneously, nodes from multiple transactions can be allocated
> interleaved. Such mixed allocation results in no
On Fri, Jan 29, 2021 at 5:54 PM David Sterba wrote:
>
> On Fri, Jan 29, 2021 at 05:15:21PM +, Michal Rostecki wrote:
> > On Fri, Jan 29, 2021 at 11:22:48AM -0500, Josef Bacik wrote:
> > > On 1/27/21 8:57 AM, Michal Rostecki wrote:
> > > > From: Michal Rostecki
> > > >
> > > > Before this chan
cation.
> Either way the eb will or has been cached, thus readahead has no need to
> wait for it.
>
> This patch will add extra comment on this counter-intuitive behavior.
>
> Reported-by: Dan Carpenter
> Signed-off-by: Qu Wenruo
Reviewed-by: Filipe Manana
Looks good, thanks
_ERR(em)) as the status
> - Set em to NULL
>
> Signed-off-by: Michal Rostecki
Reviewed-by: Filipe Manana
I think this is a fine optimization.
For very large filesystems, i.e. several thousands of allocated
chunks, not only this avoids searching two times the rbtree,
saving time, it ma
On Wed, Jan 27, 2021 at 3:23 PM Josef Bacik wrote:
>
> On 1/27/21 5:34 AM, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Whenever we fsync an inode, if it is a directory, a regular file that was
> > created in the current transaction or ha
On Wed, Jan 27, 2021 at 9:59 AM Michal Rostecki wrote:
>
> From: Michal Rostecki
>
> Before this change, the btrfs_get_io_geometry() function was calling
> btrfs_get_chunk_map() to get the extent mapping, necessary for
> calculating the I/O geometry. It was using that extent mapping only
> intern
On Tue, Jan 26, 2021 at 7:19 PM Roman Anasal | BDSU
wrote:
>
> Am Montag, den 25.01.2021, 20:51 + schrieb Filipe Manana:
> > On Mon, Jan 25, 2021 at 7:51 PM Roman Anasal
> > wrote:
> > > This is analogous to the preceding patch ("btrfs: send: fix invali
re will be more comprehensive rework to convert the open coded loop to
> a proper while loop.
>
> Fixes: dbfdb6d1b369 ("Btrfs: Search for all ordered extents that could span
> across a page")
> Signed-off-by: Qu Wenruo
Anyway, it looks good to me, thanks.
Reviewed-by: F
On Thu, Jan 21, 2021 at 4:52 PM David Sterba wrote:
>
> On Thu, Jan 21, 2021 at 02:13:54PM +0800, Qu Wenruo wrote:
> > [BUG]
> > There is a long existing bug in the last parameter of
> > btrfs_add_ordered_extent(), in commit 771ed689d2cd ("Btrfs: Optimize
> > compressed writeback and reads") back
On Mon, Jan 25, 2021 at 7:51 PM Roman Anasal wrote:
>
> This is analogous to the preceding patch ("btrfs: send: fix invalid
> commands for inodes with changed type but same gen") but for changed
> rdev:
>
> When doing an incremental send, if a new inode has the same number as an
> inode in the par
On Sat, Jan 23, 2021 at 8:46 AM Qu Wenruo wrote:
>
>
>
> On 2021/1/22 上午6:20, Dave Chinner wrote:
> > Hi btrfs-gurus,
> >
> > I'm running a simple reflink/snapshot/COW scalability test at the
> > moment. It is just a loop that does "fio overwrite of 10,000 4kB
> > random direct IOs in a 4GB file;
On Fri, Jan 22, 2021 at 6:39 PM Josef Bacik wrote:
>
> On 1/22/21 12:56 PM, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > After a sudden power failure we may end up with a space cache on disk that
> > is not valid and needs to be rebuilt from scratch.
&
On Fri, Jan 22, 2021 at 4:43 PM Josef Bacik wrote:
>
> On 1/22/21 10:28 AM, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > After a sudden power failure we may end up with a space cache on disk that
> > is not valid and needs to be rebuilt from scratch.
&
On Thu, Jan 21, 2021 at 6:27 AM Qu Wenruo wrote:
>
> [BUG]
> There is a long existing bug in the last parameter of
> btrfs_add_ordered_extent(), in commit 771ed689d2cd ("Btrfs: Optimize
> compressed writeback and reads") back to 2008.
>
> In that ancient commit btrfs_add_ordered_extent() expects t
On Tue, Jan 12, 2021 at 2:37 PM Roman Anasal | BDSU
wrote:
>
> On Tue, 2021-01-12 at 13:54 +, Filipe Manana wrote:
> > On Tue, Jan 12, 2021 at 1:10 PM Roman Anasal | BDSU
> > wrote:
> > > On Tue, 2021-01-12 at 11:27 +, Filipe Manana wrote:
> > > > Y
On Tue, Jan 12, 2021 at 1:10 PM Roman Anasal | BDSU
wrote:
>
> On Tue, 2021-01-12 at 11:27 +, Filipe Manana wrote:
> > You get all these issues because you are using an incremental send in
> > a way it's not supposed to.
> > You are using two subvolumes that are c
On Tue, Jan 12, 2021 at 1:01 PM Anand Jain wrote:
>
> In the current kernel both scrub and balance fails due to ENOSPC,
> however there is no reason that it should be transitioned to the
> RDONLY and making free spaces difficult.
No way.
There are plenty of places where ignoring an ENOSPC would
On Tue, Jan 12, 2021 at 12:08 PM Graham Cobb wrote:
>
> On 12/01/2021 11:27, Filipe Manana wrote:
> > ...
> > In other words, what I think we should have is a check that forbids
> > using two roots for an incremental send that are not snapshots of the
> > same su
e, so its commit hash should be referenced.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f23277a49e68f8a9355385c846939ad0b1261e7
Thanks for refreshing it.
>
> Link: https://bugzilla.suse.com/show_bug.cgi?id=1178634
> Reviewed-by: Filipe Manana
> Signed
On Tue, Jan 12, 2021 at 9:42 AM Roman Anasal | BDSU
wrote:
>
> On Mon, 2021-01-11 at 22:30 +0300, Andrei Borzenkov wrote:
> > 11.01.2021 22:02, Roman Anasal пишет:
> > > When doing a send, if a new inode has the same number as an inode
> > > in the
> > > parent subvolume it will only be detected a
On Mon, Jan 11, 2021 at 4:08 PM Josef Bacik wrote:
>
> On 1/11/21 6:41 AM, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > Test that an incremental send operation correctly issues clone operations
> > for a file that had different parts of one of its exte
On Sat, Nov 14, 2020 at 12:09 AM Qu Wenruo wrote:
>
>
>
> On 2020/11/13 下午11:19, David Sterba wrote:
> > On Thu, Nov 12, 2020 at 07:50:22AM +0800, Qu Wenruo wrote:
> +$BTRFS_UTIL_PROG quota enable $SCRATCH_MNT
> +$BTRFS_UTIL_PROG quota rescan -w $SCRATCH_MNT >> $seqres.full
> +
> >>
On Fri, Dec 18, 2020 at 11:44 AM Filipe Manana wrote:
>
> On Fri, Dec 18, 2020 at 7:25 AM Massimo B. wrote:
> >
> > On Mon, 2020-12-14 at 09:46 +0000, Filipe Manana wrote:
> >
> > > clone mb/Documents.AZ/0.SYNC/pdf -
> > > source=mb/Documents.AZ/0.S
On Thu, Jan 7, 2021 at 1:13 PM syzbot
wrote:
>
> syzbot suspects this issue was fixed by commit:
>
> commit f30bed83426c5cb9fce6cabb3f7cc5a9d5428fcc
> Author: Filipe Manana
> Date: Fri Nov 13 11:24:17 2020 +
>
> btrfs: remove unnecessary attempt to drop extent
On Mon, Jan 4, 2021 at 5:06 PM Josef Bacik wrote:
>
> This is a revert for 38d715f494f2 ("btrfs: use
> btrfs_start_delalloc_roots in shrink_delalloc"). A user reported a
> problem where performance was significantly worse with this patch
> applied. The problem needs to be fixed with proper pre-f
On Fri, Dec 18, 2020 at 7:25 AM Massimo B. wrote:
>
> On Mon, 2020-12-14 at 09:46 +, Filipe Manana wrote:
>
> > clone mb/Documents.AZ/0.SYNC/pdf - source=mb/Documents.AZ/0.SYNC/pdf
> > > source offset=20705280 offset=20709376 length=4096
> > > clo
On Thu, Dec 17, 2020 at 5:45 PM David Sterba wrote:
>
> On Mon, Dec 14, 2020 at 10:10:45AM +, fdman...@kernel.org wrote:
> > +static bool rescan_should_stop(struct btrfs_fs_info *fs_info)
> > +{
> > + return btrfs_fs_closing(fs_info) ||
> > + test_bit(BTRFS_FS_STATE_REMOUNTING,
On Thu, Dec 17, 2020 at 3:03 PM David Sterba wrote:
>
> On Mon, Dec 14, 2020 at 09:56:40AM +, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > For a very long time there's been a race between clone/dedupe and memory
> > mapped writes as well as
4840-8e26-35db08fa17d7
> +# chunk uuid 9ba39317-3159-46c9-a75a-965ab1e94267
> +#item 0 key (256 DIR_ITEM 3737737011) itemoff 25 itemsize 65410
> +#...
> +#
> +
> +$PYTHON2_PROG $here/src/btrfs_crc32c_forged_name.py -d $SCRATCH_MNT -c 310
> +
> +ISRW=$(_fs_options $SC
1 - 100 of 1047 matches
Mail list logo
