State updated:
The deadlock seems to be caused by 2 bugs:
1) Bad error handling in run_delalloc_nocow()
The direct cause is, btrfs_reloc_clone_csums() fails and return -EIO.
Then error handler will call extent_clear_unlock_delalloc() to
clear dirty flag and end writeback of the resting
On 02/11/17 07:03, Omar Sandoval wrote:
From: Omar Sandoval
If btrfs_decompress_buf2page() is handed a bio with its page in the
middle of the working buffer, then we adjust the offset into the working
buffer. After we copy into the bio, we advance the iterator by the
number of bytes we copie
Just as Filipe pointed out, the most time consuming parts of qgroup are
btrfs_qgroup_account_extents() and
btrfs_qgroup_prepare_account_extents().
Which both call btrfs_find_all_roots() to get old_roots and new_roots
ulist.
What makes things worse is, we're calling that expensive
btrfs_find_all_ro
When balance(relocation) fails, btrfs-progs will report like:
ERROR: error during balancing '/mnt/scratch': Input/output error
There may be more info in syslog - try dmesg | tail
However kernel can't provide may useful info in many cases to locate the
problem.
This patch will add error messages
At 02/15/2017 04:34 AM, Filipe Manana wrote:
On Tue, Feb 14, 2017 at 12:57 AM, Qu Wenruo wrote:
When balance(relocation) fails, btrfs-progs will report like:
ERROR: error during balancing '/mnt/scratch': Input/output error
There may be more info in syslog - try dmesg | tail
However kernel c
On Tue, Feb 14, 2017 at 08:35:26PM +, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> If we have a file with an implicit hole (NO_HOLES feature enabled) that
> has an extent following the hole, delayed writes against regions of the
> file behind the hole happened before but were not yet
Signed-off-by: Lakshmipathi.G
---
.../019-fix-corrupted-superblock/test.sh | 37 ++
1 file changed, 37 insertions(+)
create mode 100755 tests/misc-tests/019-fix-corrupted-superblock/test.sh
diff --git a/tests/misc-tests/019-fix-corrupted-superblock/test.sh
b/tests
From: Filipe Manana
Test that both a full and incremental btrfs send operation preserves file
holes.
This used to fail when the filesystem had the NO_HOLES feature enabled,
that is, when the test is run with MKFS_OPTIONS="-O no-holes".
This is fixed by the following patch for the linux kernel:
From: Filipe Manana
Test that if we have a file with a hole, do a mix of direct IO and
buffered writes to it and truncate the file to a size that lies in the
middle of the hole, after unmounting and mounting again the filesystem,
the file has a correct size and no data loss happened.
This test i
From: Filipe Manana
When using the NO_HOLES feature, during an incremental send we often issue
write operations for holes when we should not, because that range is already
a hole in the destination snapshot. While that does not change the contents
of the file at the receiver, it avoids preservati
From: Filipe Manana
If we have a file with an implicit hole (NO_HOLES feature enabled) that
has an extent following the hole, delayed writes against regions of the
file behind the hole happened before but were not yet flushed and then
we truncate the file to a smaller size that lies inside the ho
On Tue, Feb 14, 2017 at 12:57 AM, Qu Wenruo wrote:
> When balance(relocation) fails, btrfs-progs will report like:
>
> ERROR: error during balancing '/mnt/scratch': Input/output error
> There may be more info in syslog - try dmesg | tail
>
> However kernel can't provide may useful info in many cas
On Mon, Feb 13, 2017 at 10:53:12AM +0100, David Sterba wrote:
> We do a readahead of the free space cache inode to speed things up but
> the failure is not fatal, like in other readahead cases. Proper reads
> would need to happen anyway and any errors would be caught there.
>
Reviewed-by: Liu Bo
On Tue, Feb 14, 2017 at 08:57:50AM +0800, Qu Wenruo wrote:
> When balance(relocation) fails, btrfs-progs will report like:
>
> ERROR: error during balancing '/mnt/scratch': Input/output error
> There may be more info in syslog - try dmesg | tail
>
> However kernel can't provide may useful info in
On Mon, Feb 13, 2017 at 10:34:47AM +0100, David Sterba wrote:
> Both unused after the call to update_cache_item has been moved to
> __btrfs_wait_cache_io.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Signed-off-by: David Sterba
> ---
> fs/btrfs/free-space-cache.c | 11 +++
> 1 file changed
On Mon, Feb 06, 2017 at 09:40:47PM +0100, Goffredo Baroncelli wrote:
>
> IIRC, the parity is spread across the disk stripes of the chunk.
>
> So first you have to find the logical-offset [LO] where the the file begins.
> Then you have to map this offset to the chunk which holds the data. The chu
On Mon, Feb 06, 2017 at 09:36:58AM +0800, Qu Wenruo wrote:
>
> Please note the following things when calculating RAID5/6 data and P/Q
> location:
>
> 1) Basic layout
> The chunk stripe only shows the *first* full stripe layout.
> And it always follows the sequence of "Data0, Data1, ... Data N, Pa
On Mon, Feb 13, 2017 at 10:34:35AM +0100, David Sterba wrote:
> After the page locking has been reworked, we get all pages prepared via
> cmp_pages.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Signed-off-by: David Sterba
> ---
> fs/btrfs/ioctl.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 dele
[root@server ~]# btrfs-show-super -af /dev/sdc
superblock: bytenr=65536, device=/dev/sdc
-
csum_type 0 (crc32c)
csum_size 4
csum0x17d56ce0 [match]
bytenr 65536
flags
On Mon, Feb 13, 2017 at 10:34:26AM +0100, David Sterba wrote:
> The name parameters have never been used, as the name is passed via the
> dentry.
>
Reviewed-by: Liu Bo
Thanks,
-liubo
> Signed-off-by: David Sterba
> ---
> fs/btrfs/ioctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletion
On Mon, Feb 13, 2017 at 10:34:13AM +0100, David Sterba wrote:
> The 'tree' was used to call locking hook that does not exist anymore.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/btrfs/extent_io.c
On Mon, Feb 13, 2017 at 10:34:04AM +0100, David Sterba wrote:
> This used to hold number of maximum pages to allocate, but this is now
> limited by BIO_MAX_PAGES.
>
> Signed-off-by: David Sterba
> ---
> fs/btrfs/extent_io.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff
On Tue, Feb 14, 2017 at 04:56:06PM +0100, David Sterba wrote:
> On Mon, Feb 13, 2017 at 03:42:21PM -0800, Liu Bo wrote:
> > This uses a helper instead of open code around used byte of space_info
> > everywhere.
> >
> > Signed-off-by: Liu Bo
>
> Reviewed-by: David Sterba
>
> > ---
> > fs/btrfs
On Tue, Feb 14, 2017 at 12:42:07PM +0100, David Sterba wrote:
> On Mon, Feb 13, 2017 at 06:11:56PM -0800, Liu Bo wrote:
> > On Mon, Feb 13, 2017 at 10:33:55AM +0100, David Sterba wrote:
> > > None of the checks need to know the RO/RW status.
> > >
> >
> > OK...there was a readonly check, which let
On 2017-02-14 11:46, Austin S. Hemmelgarn wrote:
On 2017-02-14 11:07, Chris Murphy wrote:
On Tue, Feb 14, 2017 at 8:30 AM, Austin S. Hemmelgarn
wrote:
I was just experimenting with snapshots on 4.9.0, and came across some
unexpected behavior.
The simple explanation is that if you snapshot a s
On 2017-02-14 11:07, Chris Murphy wrote:
On Tue, Feb 14, 2017 at 8:30 AM, Austin S. Hemmelgarn
wrote:
I was just experimenting with snapshots on 4.9.0, and came across some
unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in the
subvolume that have the
On Mon, Feb 13, 2017 at 03:35:09PM -0800, Liu Bo wrote:
> As 0 refers to an existing type BTRFS_ORDERED_IO_DONE, this specifies a
> new type 'REGULAR' for regular IO.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
On Tue, Feb 14, 2017 at 8:30 AM, Austin S. Hemmelgarn
wrote:
> I was just experimenting with snapshots on 4.9.0, and came across some
> unexpected behavior.
>
> The simple explanation is that if you snapshot a subvolume, any files in the
> subvolume that have the NOCOW attribute will not have that
On Mon, Feb 13, 2017 at 03:42:21PM -0800, Liu Bo wrote:
> This uses a helper instead of open code around used byte of space_info
> everywhere.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
> ---
> fs/btrfs/extent-tree.c | 42 --
> 1 file changed,
On Tue, 14 Feb 2017 10:30:43 -0500
"Austin S. Hemmelgarn" wrote:
> I was just experimenting with snapshots on 4.9.0, and came across some
> unexpected behavior.
>
> The simple explanation is that if you snapshot a subvolume, any files in
> the subvolume that have the NOCOW attribute will not h
On Mon, Feb 13, 2017 at 03:42:30PM -0800, Liu Bo wrote:
> We don't need to take the lock if the block group has not been cached.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vg
dear all,
two days ago I got an old 1TB external USB HDD drive. I scanned it
using smartctl, long scan, no errors. I created one partition
/dev/sde1, formatted it using BTRFS, and created two subvolumes. One
subvolume was intended for backups. This morning I started copying some
200GB data on t
I was just experimenting with snapshots on 4.9.0, and came across some
unexpected behavior.
The simple explanation is that if you snapshot a subvolume, any files in
the subvolume that have the NOCOW attribute will not have that attribute
in the snapshot. Some further testing indicates that th
Hi again,
so, it seems that I've solved the problem: After having to umount/mount the
FS several times to get btrfs-cleaner to finish, I thought of the "failed to
load free space [...], rebuilding it now" type errors and decided to try the
clear_cache mount option. Since then, my home server
Hi all
I recently submitted a bug report to launchpad (
https://bugs.launchpad.net/ubuntu/+source/btrfs-tools/+bug/1664013 ) but
I now found out about this mailing list, which may be a better place to
post.
Basically, whenever many files are created at high throughput in my
empty btrfs file
On Tue, Feb 14, 2017 at 05:29:14PM +0800, Qu Wenruo wrote:
>
>
> At 02/13/2017 10:30 PM, David Sterba wrote:
> > Make ulist_fini externally visible so the ulist API is complete.
>
> Looks good to me.
>
> While I'm not pretty sure if the name "ulist_fini" is good enough.
>
> Maybe "ulist_finis
On Mon, Feb 13, 2017 at 06:11:56PM -0800, Liu Bo wrote:
> On Mon, Feb 13, 2017 at 10:33:55AM +0100, David Sterba wrote:
> > None of the checks need to know the RO/RW status.
> >
>
> OK...there was a readonly check, which lets us skip all checks,
> it was removed by the below commit, should we add
It looks you're right!
On a different machine:
# btrfs sub list / | grep -v lxc
ID 327 gen 1959587 top level 5 path mnt/reaver
ID 498 gen 593655 top level 5 path var/lib/machines
# btrfs sub list / -d | wc -l
0
Ok, apparently it's a regression in one of the latest versions then.
But, it seem
At 02/13/2017 10:30 PM, David Sterba wrote:
Make ulist_fini externally visible so the ulist API is complete.
Looks good to me.
While I'm not pretty sure if the name "ulist_fini" is good enough.
Maybe "ulist_finish" or "ulist_release" (just like release_path and
free_path)?
Thanks,
Qu
S
At 02/13/2017 10:30 PM, David Sterba wrote:
We can embed range_changed to the extent changeset to address following
problems:
- no need to allocate ulist dynamically, we also get rid of the GFP_NOFS
for free
- fix lack of allocation failure checking in btrfs_qgroup_reserve_data
Nice catch.
On 14.02.2017 04:46, Goldwyn Rodrigues wrote:
> From: Goldwyn Rodrigues
>
> Return EAGAIN if any of the following checks fail
> + i_rwsem is lockable
> + NODATACOW or PREALLOC is set
perhaps you wanted to say "NODATACOW or PREALLOC is _not_ set"? See below
> + Can nocow at the desired lo
41 matches
Mail list logo
