Here is v2 of factoring out common code when flushing ordered extent. The main
change in this version is the switch from inode to btrfs_inode for function
interfaces as per David's feedback.
Nikolay Borisov (3):
btrfs: Implement btrfs_lock_and_flush_ordered_range
btrfs: Use newly introduced
In case no cached_state argument is passed to
btrfs_lock_and_flush_ordered_range use one locally in the function. This
optimises the case when an ordered extent is found since the unlock
function will be able to unlock that state directly without searching
for it again.
Signed-off-by: Nikolay Bori
There is a certain idiom used in multiple places in btrfs' codebase,
dealing with flushing an ordered range. Factor this in a separate
function that can be reused. Future patches will replace the existing
code with that function.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ordered-data.c | 33 ++
There several functions which open code
btrfs_lock_and_flush_ordered_range, just replace them with a call
to the function. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/extent_io.c | 29 -
fs/btrfs/file.c | 14 ++
fs/btrfs/inode.c
The first thing code does in check_can_nocow is trying to block
concurrent snapshots. If this fails (due to snpashot already being in
progress) the function returns ENOSPC which makes no sense. Instead
return EAGAIN. Despite this return value not being propagated to callers
it's good practice to re
On 6.05.19 г. 5:04 ч., Qu Wenruo wrote:
> [snip]
>>>
>>> For data writeback, it should only cause sync related failure.
>>
>> Ok, so please remove the transaction abort comments for next iteration.
>> By sync related failure, you mean running dealloc fails with ENOSPC,
>> since when it tries to
On Mon, May 6, 2019 at 3:04 AM Qu Wenruo wrote:
>
> [snip]
> >>
> >> For data writeback, it should only cause sync related failure.
> >
> > Ok, so please remove the transaction abort comments for next iteration.
> > By sync related failure, you mean running dealloc fails with ENOSPC,
> > since whe
Hi Guys,
I am running btrfs on a 4.4.178 kernel, I want to support a longer file name,
now the NAME_MAX is 255, can I just increase the NAME_MAX macro and recompile
the kernel to support longer file name ? I guess I will break sth, but I am
not sure what part will be broken.
Thanks.
On Tue, May 07, 2019 at 05:48:47PM +0800, litaibaich...@gmail.com wrote:
> I am running btrfs on a 4.4.178 kernel, I want to support a longer
> file name, now the NAME_MAX is 255, can I just increase the NAME_MAX
> macro and recompile the kernel to support longer file name ? I guess
> I will bre
On 2019/5/7 下午4:56, Filipe Manana wrote:
> On Mon, May 6, 2019 at 3:04 AM Qu Wenruo wrote:
>>
>> [snip]
For data writeback, it should only cause sync related failure.
>>>
>>> Ok, so please remove the transaction abort comments for next iteration.
>>> By sync related failure, you mean r
On Tue, May 7, 2019 at 12:13 PM Qu Wenruo wrote:
>
>
>
> On 2019/5/7 下午4:56, Filipe Manana wrote:
> > On Mon, May 6, 2019 at 3:04 AM Qu Wenruo wrote:
> >>
> >> [snip]
>
> For data writeback, it should only cause sync related failure.
> >>>
> >>> Ok, so please remove the transaction abor
Signed-off-by: Nikolay Borisov
---
fs/btrfs/volumes.h | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index 3b97e8092ba7..514799362244 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -52,8 +52,8 @@ struct btrfs_io
Finally found some time to finish the compilation of the requested
kernel and accomplish the required test - s. below.
2019-04-12 12:50, Qu Wenruo:
On 2019/4/12 下午6:44, Nik. wrote:
2019-04-08 23:22, Nik.:
2019-04-08 15:09, Qu Wenruo:
Unfortunately, I didn't receive the last mail from Ni
We have been seeing issues in production where a cleaner script will end
up unlinking a bunch of files that have pending iputs. This means they
will get their final iput's run at btrfs-cleaner time and thus are not
throttled, which impacts the workload.
Since we are unlinking these files we can j
On Tue, May 7, 2019 at 11:17 AM Nik. wrote:
>
> It took about 18 hours to compare the mounted volume with the backup
> (used rsync, without the "--checksum" option, because it was too slow; I
If you're comparing without --checksum, it's just checking file size
and timestamp. It's not checking fil
On Tue, May 07, 2019 at 10:19:21AM +0300, Nikolay Borisov wrote:
> Here is v2 of factoring out common code when flushing ordered extent. The main
> change in this version is the switch from inode to btrfs_inode for function
> interfaces as per David's feedback.
>
> Nikolay Borisov (3):
> btrf
On Fri, May 03, 2019 at 09:08:52AM +0800, Qu Wenruo wrote:
> [BUG]
> The following command can lead to unexpected data COW:
>
> #!/bin/bash
>
> dev=/dev/test/test
> mnt=/mnt/btrfs
>
> mkfs.btrfs -f $dev -b 1G > /dev/null
> mount $dev $mnt -o nospace_cache
>
> xfs_io -f -c "falloc 8k
On Mon, May 06, 2019 at 04:44:12PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> Having file extent items with ranges that overlap each other is a serious
> issue that leads to all sorts of corruptions and crashes (like a BUG_ON()
> during the course of __btrfs_drop_extents() when i
On Mon, May 06, 2019 at 04:44:02PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we do a full fsync (the bit BTRFS_INODE_NEEDS_FULL_SYNC is set in the
> inode) that happens to be ranged, which happens during a msync() or writes
> for files opened with O_SYNC for example, we can
On Mon, May 06, 2019 at 04:43:51PM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When we are doing a full fsync (bit BTRFS_INODE_NEEDS_FULL_SYNC set) of a
> file that has holes and has file extent items spanning two or more leafs,
> we can end up falling to back to a full transactio
Any advice here please?
ma 6. toukok. 2019 klo 19.21 Otto Kekäläinen (o...@seravo.fi) kirjoitti:
>
> Hello!
>
> I attempted to run btrfs balance, but it crashed soon after start.
> Status is stuck on this:
>
> $ sudo btrfs balance status -v /data
> Balance on '/data' is running
> 0 out of about 10
On Tue, May 7, 2019 at 6:44 PM Josef Bacik wrote:
>
> On Mon, May 06, 2019 at 04:44:02PM +0100, fdman...@kernel.org wrote:
> > From: Filipe Manana
> >
> > When we do a full fsync (the bit BTRFS_INODE_NEEDS_FULL_SYNC is set in the
> > inode) that happens to be ranged, which happens during a msync(
On Tue, May 07, 2019 at 08:09:02PM +0100, Filipe Manana wrote:
> On Tue, May 7, 2019 at 6:44 PM Josef Bacik wrote:
> >
> > On Mon, May 06, 2019 at 04:44:02PM +0100, fdman...@kernel.org wrote:
> > > From: Filipe Manana
> > >
> > > When we do a full fsync (the bit BTRFS_INODE_NEEDS_FULL_SYNC is set
On Mon, May 6, 2019 at 10:22 AM Otto Kekäläinen wrote:
>
> Logs have the output below. How shall I read it and debug this situation?
> What are the next steps I could test/debug?
>
>
> kernel: BTRFS info (device dm-9): disk space caching is enabled
> kernel: BTRFS: has skinny extents
> kernel: BTR
24 matches
Mail list logo
