There is a bug that, when btrfs is beyond qgroup limit, touching a file
could crash btrfs.
Such beyond limit situation needs to be intentionally created, e.g.
writing 1GiB file, then limit the subvolume to 512 MiB.
As current qgroup works pretty well at preventing us from reaching the
limit.
This
On Fri, Dec 18, 2020 at 11:32:17AM +0100, Alejandro Colomar (man-pages) wrote:
> Hi Omar,
>
> Linux 5.10 has been recently released.
> Do you have any updates for this patch?
>
> Thanks,
>
> Alex
Hi, Alex,
Now that the holidays are over I'm revisiting this series and plan to
send a new version
On 2021/1/12 上午7:32, Ole Tange wrote:
I am trying to use Btrfs' compression on some highly compressible data.
I try to make zstd give better performance than 34:1.
This:
$ truncate -s 1T /tmp/btrfs
$ mkfs.btrfs /tmp/btrfs
$ mount -o compress=zstd:9 /tmp/btrfs /mnt/btrfs
$ h
On Thu, Nov 19, 2020 at 09:38:17AM +0200, Amir Goldstein wrote:
> On Wed, Nov 18, 2020 at 9:18 PM Omar Sandoval wrote:
> >
> > From: Omar Sandoval
> >
> > Btrfs supports transparent compression: data written by the user can be
> > compressed when written to disk and decompressed when read back.
>
I am trying to use Btrfs' compression on some highly compressible data.
I try to make zstd give better performance than 34:1.
This:
$ truncate -s 1T /tmp/btrfs
$ mkfs.btrfs /tmp/btrfs
$ mount -o compress=zstd:9 /tmp/btrfs /mnt/btrfs
$ head -c 10G /dev/zero > /mnt/btrfs/zero
$ du
The pull request you sent on Mon, 11 Jan 2021 22:09:55 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-5.11-rc3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6e68b9961ff690ace07fac22c3c7752882ecc40a
Thank you!
--
Deet-doot-dot, I am a
On Wed, Dec 16, 2020 at 11:22:15AM -0500, Josef Bacik wrote:
> --- a/fs/btrfs/relocation.c
> +++ b/fs/btrfs/relocation.c
> @@ -98,6 +98,7 @@ struct tree_block {
> u64 bytenr;
> }; /* Use rb_simple_node for search/insert */
> struct btrfs_key key;
> + u64 owner;
>
On Wed, Dec 16, 2020 at 11:22:12AM -0500, Josef Bacik wrote:
> I hit a pretty ugly corruption when doing some error injection, it turns
Maybe it's useful to have the stack trace even for injected errors, it
gives some perspective about the context and call chain.
Regarding the subject, you can write plain 'assert', no need to spell
it exactly as it's in the code.
On Wed, Dec 16, 2020 at 11:22:10AM -0500, Josef Bacik wrote:
> A weird KASAN problem that Zygo reported
Please add the relevant part of the report to the changelog and/or link
to the report itsel
Dear all,
this is an RFC. I made very few test, so use at your risk.
In the past there were several reports [1][2] about corruption when O_DIRECT is
used.
Every time the analysis was the same: it is too difficult to sync the checksum
with the data when O_DIRECT is used.
This aim of this patch
On Wed, Dec 16, 2020 at 11:22:09AM -0500, Josef Bacik wrote:
> Any number of things could have gone wrong, like ENOMEM or EIO, so don't
> WARN_ON() if we're unable to find the reloc root in the backref code.
Where does the ENOMEM or EIO happen? The return value from
find_reloc_root is just a point
On Wed, Dec 16, 2020 at 11:22:08AM -0500, Josef Bacik wrote:
> While doing error injection testing with my relocation patches I hit the
> following ASSERT()
>
> assertion failed: list_empty(&block_group->dirty_list), in
> fs/btrfs/block-group.c:3356
> [ cut here ]
> kernel
On Wed, Dec 16, 2020 at 11:22:05AM -0500, Josef Bacik wrote:
> This was partially fixed by f3e3d9cc35252, however it missed a spot when
Please use full commit reference like f3e3d9cc3525 ("btrfs: avoid
possible signal interruption of btrfs_drop_snapshot() on relocation
tree")
> we restart a trans
On Mon, Jan 11, 2021 at 10:33:42AM +0200, Nikolay Borisov wrote:
> On 8.01.21 г. 18:01 ч., David Sterba wrote:
> > On Fri, Dec 18, 2020 at 02:24:20PM -0500, Josef Bacik wrote:
> >> @@ -2043,23 +2043,22 @@ int btrfs_commit_transaction(struct
> >> btrfs_trans_handle *trans)
> >>btrfs_trans_relea
On Mon, Jan 11, 2021 at 12:58:11PM +0200, Nikolay Borisov wrote:
> It's currently u64 which gets instantly translated either to LONG_MAX
> (if U64_MAX is passed) or casted to an unsigned long (which is in fact,
> wrong because iwriteback_control::nr_to_write is a signed, long type).
>
> Just conve
On Mon, Jan 11, 2021 at 11:42:32AM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> After commit 040ee6120cb670 ("Btrfs: send, improve clone range") we do not
> use anymore the data_offset field of struct backref_ctx, as after that we
> do all the necessary checks for the data offset o
On Mon, 2021-01-11 at 22:15 +0100, David Sterba wrote:
> On Mon, Jan 11, 2021 at 08:02:43PM +0100, Roman Anasal wrote:
> > --- a/fs/btrfs/send.c
> > +++ b/fs/btrfs/send.c
> > @@ -6299,12 +6299,18 @@ static int changed_inode(struct send_ctx
> > *sctx,
> > right_gen = btrfs_inode_generati
On 12/21/20 10:49 PM, Naohiro Aota wrote:
This commit implements a zoned chunk/dev_extent allocator. The zoned
allocator aligns the device extents to zone boundaries, so that a zone
reset affects only the device extent and does not change the state of
blocks in the neighbor device extents.
Also,
Hi Roman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on kdave/for-next]
[also build test WARNING on btrfs/next v5.11-rc3 next-20210111]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On Mon, Jan 11, 2021 at 08:02:43PM +0100, Roman Anasal wrote:
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -6299,12 +6299,18 @@ static int changed_inode(struct send_ctx *sctx,
> right_gen = btrfs_inode_generation(sctx->right_path->nodes[0],
> righ
Hi,
more material for stable trees. Please pull, thanks.
- tree-checker: check item end overflow
- fix false warning during relocation regarding extent type
- fix inode flushing logic, caused notable performance regression (since
5.10)
- debugging fixups:
- print correct offset for reloc t
On Mon, Jan 11, 2021 at 03:35:24PM -0500, Josef Bacik wrote:
> On 1/11/21 3:21 PM, Omar Sandoval wrote:
> > On Thu, Dec 03, 2020 at 09:32:37AM -0500, Josef Bacik wrote:
> > > On 11/18/20 2:18 PM, Omar Sandoval wrote:
> > > > From: Omar Sandoval
> > > >
> > > > There are 4 main cases:
> > > >
> >
On 12/21/20 10:49 PM, Naohiro Aota wrote:
From: Johannes Thumshirn
Emulate zoned btrfs mode on non-zoned devices. This is done by "slicing
up" the block-device into static sized chunks and fake a conventional zone
on each of them. The emulated zone size is determined from the size of
device ext
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 as to be recreated when
> > the
> > genrations differ. But with inodes in
On 1/11/21 3:21 PM, Omar Sandoval wrote:
On Thu, Dec 03, 2020 at 09:32:37AM -0500, Josef Bacik wrote:
On 11/18/20 2:18 PM, Omar Sandoval wrote:
From: Omar Sandoval
There are 4 main cases:
1. Inline extents: we copy the data straight out of the extent buffer.
2. Hole/preallocated extents: we
On Thu, Dec 03, 2020 at 09:32:37AM -0500, Josef Bacik wrote:
> On 11/18/20 2:18 PM, Omar Sandoval wrote:
> > From: Omar Sandoval
> >
> > There are 4 main cases:
> >
> > 1. Inline extents: we copy the data straight out of the extent buffer.
> > 2. Hole/preallocated extents: we fill in zeroes.
> >
On 12/21/20 10:49 PM, Naohiro Aota wrote:
The implementation of fitrim is depending on space cache, which is not used
and disabled for zoned btrfs' extent allocator. So the current code does
not work with zoned btrfs. In the future, we can implement fitrim for zoned
btrfs by enabling space cache
On 12/21/20 10:48 PM, Naohiro Aota wrote:
From: Johannes Thumshirn
Since fs_info->zoned is unioned with fs_info->zone_size, loading
fs_info->zoned from the incompat flag screw up the zone_size. So, let's
avoid to load it from the flag. It will be eventually set by
btrfs_get_dev_zone_info_all_de
On 12/21/20 10:48 PM, Naohiro Aota wrote:
From: Johannes Thumshirn
Since we have no write pointer in conventional zones, we cannot determine
allocation offset from it. Instead, we set the allocation offset after the
highest addressed extent. This is done by reading the extent tree in
btrfs_load
On 12/21/20 10:48 PM, Naohiro Aota wrote:
We cannot use log-structured superblock writing in conventional zones since
there is no write pointer to determine the last written superblock
position. So, we write a superblock at a static location in a conventional
zone.
The written position is at the
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 as to be recreated when the
> genrations differ. But with inodes in the same generation the emitted
> commands will cause the receiver to fail
On 12/21/20 10:48 PM, Naohiro Aota wrote:
This is preparation patch to implement zone emulation on a regular device.
To emulate zoned mode on a regular (non-zoned) device, we need to decide an
emulating zone size. Instead of making it compile-time static value, we'll
make it configurable at mkfs
cur_inode_new_gen is used to detect whether an inode was/has to be
recreated which is - currently (!) - only based on whether a changed
inode as differing generations.
To allow additional checks for recreating an inode (see following patch)
and still have a sane naming this change was made.
Signed
Trying to incremental send and receive some subvolumes I repeatedly ran into
errors with btrfs-receive failing. Taking a deeper look into the issue showed
that btrfs-send was producing (semantically) invalid command streams. I could
pin down the conditions of this happening to having inodes with th
When doing a send, if a new inode has the same number as an inode in the
parent subvolume it will only be detected as to be recreated when the
genrations differ. But with inodes in the same generation the emitted
commands will cause the receiver to fail.
This case does not happen when doing increm
On 1/10/21 1:36 PM, David Woodhouse wrote:
On Sun, 2021-01-10 at 13:08 +0100, Forza wrote:
[...]
It showed up as errors. There appears to be a btrfs bug there but since
Yes, it is an old btrfs bug. And qemu is not the guilty.
https://lore.kernel.org/linux-btrfs/cf8a733f-2c9d-7ffe-e865-4c13d
Hi dear friend,
I'm Barr: Jerome Mbatah from Ghana west Africa. Please, I would wish
to have a communication with you if you don`t mind. I will be waiting
for your response. Thank you.
Jerome.
On 12/21/20 10:49 PM, Naohiro Aota wrote:
This commit extract page adding to bio part from submit_extent_page(). The
page is added only when bio_flags are the same, contiguous and the added
page fits in the same stripe as pages in the bio.
Condition checkings are reordered to allow early return
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 extents cloned into
> > itself, at
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 extents cloned into
itself, at different offsets, and a large part of that extent was
overwritten, so al
On 1/11/21 6:41 AM, fdman...@kernel.org wrote:
From: Filipe Manana
When an incremental send finds an extent that is shared, it checks which
file extent items in the range refer to that extent, and for those it
emits clone operations, while for others it emits regular write operations
to avoid c
On 8.01.21 г. 18:23 ч., David Sterba wrote:
> The inode number cache has been removed in this dev cycle, there's one
> more leftover. We don't need to run the delayed refs again after
> commit_fs_roots as stated in the comment, because btrfs_save_ino_cache
> is no more since 5297199a8bca ("btrfs
On 1/11/21 4:17 AM, Nikolay Borisov wrote:
This test verifies btrfs' free objectid management. I.e it ensures that
the first objectid is always 256 in an fs tree.
Signed-off-by: Nikolay Borisov
Reviewed-by: Josef Bacik
Will you add this to our staging branch so it gets picked up by the nigh
On 1/11/21 5:58 AM, Nikolay Borisov wrote:
It's currently u64 which gets instantly translated either to LONG_MAX
(if U64_MAX is passed) or casted to an unsigned long (which is in fact,
wrong because iwriteback_control::nr_to_write is a signed, long type).
Just convert the function's argument to
On 2021/1/11 下午8:15, Filipe Manana wrote:
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 >>
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 +, Filipe Manana wrote:
> >
> > > clone mb/Documents.AZ/0.SYNC/pdf -
> > > source=mb/Documents.AZ/0.SYNC/pdf
> > > > source offset=20705280
From: Filipe Manana
After commit 040ee6120cb670 ("Btrfs: send, improve clone range") we do not
use anymore the data_offset field of struct backref_ctx, as after that we
do all the necessary checks for the data offset of file extent items at
clone_range(). Since there are no more users of data_off
From: Filipe Manana
Test that an incremental send operation correctly issues clone operations
for a file that had different parts of one of its extents cloned into
itself, at different offsets, and a large part of that extent was
overwritten, so all the reflinks only point to subranges of the ext
From: Filipe Manana
When an incremental send finds an extent that is shared, it checks which
file extent items in the range refer to that extent, and for those it
emits clone operations, while for others it emits regular write operations
to avoid corruption at the destination (as described and fi
Following the rework in
"btrfs: shrink delalloc pages instead of full inodes" the nr variable
is no longer passed by reference to start_delalloc_inodes hence it
cannot change. Additionally we are always guaranteed for it to be
positive number hence it's redundant to have it as a condition in the
lo
It's currently u64 which gets instantly translated either to LONG_MAX
(if U64_MAX is passed) or casted to an unsigned long (which is in fact,
wrong because iwriteback_control::nr_to_write is a signed, long type).
Just convert the function's argument to be long time which obviates the
need to manua
On 22/12/2020 14:40, Christoph Hellwig wrote:
> I just did a very quick look, but didn't see anything (based on the
> subjects) that deals with ITER_BVEC direct I/O. Is the support for that
> hidden somewhere?
I couldn't reproduce the problem you reported and asked for a reproducer.
Probably
the
On 8/1/21 9:57 pm, David Sterba wrote:
On Wed, Jan 06, 2021 at 03:08:15PM +0800, Anand Jain wrote:
In the meantime, since I have sent the base patch as below [1], the
block layer commit 0d02129e76ed (block: merge struct block_device and
struct hd_struct) has changed the first argument in the
Add round-robin read policy to route the read IO to the next device in the
round-robin order. The chunk allocation and thus the stripe-index follows
the order of free space available on devices. So to make the round-robin
effective it shall follow the devid order instead of the stripe-index
order.
Read-policy type 'device' and device flag 'read-preferred':
The read-policy type device picks the device(s) flagged as
read-preferred for reading stripes of type raid1, raid10,
raid1c3 and raid1c4.
A system might contain SSD, nvme, iscsi, or san lun, and which are all
a non-rotational device, so
This is a preparatory patch and introduces a new device flag
'read_preferred', RW-able using sysfs interface.
Signed-off-by: Anand Jain
---
v2: C style fixes. Drop space in between '! test_bit' and extra lines
after it.
fs/btrfs/sysfs.c | 53 ++
v3:
The block layer commit 0d02129e76ed (block: merge struct block_device and
struct hd_struct) has changed the first argument in the function
part_stat_read_all() in 5.11-rc1. So trickle down its changes in the patch 1/4.
v2:
Fixes as per review comments, as in the individual patches.
v1:
Drop t
The read policy type latency routes the read IO based on the historical
average wait-time experienced by the read IOs through the individual
device. This patch obtains the historical read IO stats from the kernel
block layer and calculates its average.
Example usage:
echo "latency" > /sys/fs/btrf
> You can use `btrbk diff old-snap new-snap` to list changes between
> snapshots.
>
The problem with 'btrbk diff' approach (as stated here [1]) is that it
can not show changes for empty files, empty folders and deletions,
because it also uses 'btrfs find_new' under the hood (see [2]).
However, I
This test verifies btrfs' free objectid management. I.e it ensures that
the first objectid is always 256 in an fs tree.
Signed-off-by: Nikolay Borisov
---
* Changes since V1:
- Added _require_btrfs_command
- Save temporary output to a file and parse it from there
- Call $AWK_PROG instead of pl
On 2021-01-09 01:33:52 [+0100], Thomas Bogendoerfer wrote:
> On Sat, Jan 09, 2021 at 12:58:05AM +0100, Thomas Bogendoerfer wrote:
> > On Fri, Jan 08, 2021 at 08:20:43PM +, Paul Cercueil wrote:
> > > Hi Thomas,
> > >
> > > 5.11 does not boot anymore on Ingenic SoCs, I bisected it to this commit
On 8.01.21 г. 18:01 ч., David Sterba wrote:
> On Fri, Dec 18, 2020 at 02:24:20PM -0500, Josef Bacik wrote:
>> I've been running a stress test that runs 20 workers in their own
>> subvolume, which are running an fsstress instance with 4 threads per
>> worker, which is 80 total fsstress threads.
On 10.01.21 г. 13:52 ч., David Woodhouse wrote:
> I migrated a system to btrfs which was hosting virtual machins with
> qemu.
>
> Using it without disabling copy-on-write was a mistake, of course, and
> it became horribly fragmented and slow.
>
> So I tried copying it to a new file... but it h
64 matches
Mail list logo
