Re: [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl

On Wed, May 10, 2017 at 01:14:37PM -0700, Darrick J. Wong wrote: > [cc btrfs, since afaict that's where most of the dedupe tool authors hang out] > > On Wed, May 10, 2017 at 02:27:33PM -0500, Eric W. Biederman wrote: > > Theodore Ts'o writes: > > > > > On Tue, May 09, 2017 at

Re: Question on compression unit

At 05/11/2017 04:11 AM, Xiaochu Liu wrote: Hi there, I'm trying to tune compression options for btrfs. Specifically, I want to know the performance impact on the system under different compression unit (block) sizes. Compression unit size is fixed in btrfs. It's sectorsize, determined at

Re: qgroup: direct writes returns -EDQUOT too soon

At 05/11/2017 08:19 AM, Goldwyn Rodrigues wrote: Here is a sample script to recreate the issue: mkfs.btrfs -f /dev/vdb mount /dev/vdb /mnt btrfs quota enable /mnt btrfs sub create /mnt/tmp btrfs qgroup limit 200M /mnt/tmp btrfs quota rescan -w /mnt cd /mnt/tmp for i in {1..5}; do sync

qgroup: direct writes returns -EDQUOT too soon

Here is a sample script to recreate the issue: mkfs.btrfs -f /dev/vdb mount /dev/vdb /mnt btrfs quota enable /mnt btrfs sub create /mnt/tmp btrfs qgroup limit 200M /mnt/tmp btrfs quota rescan -w /mnt cd /mnt/tmp for i in {1..5}; do sync dd if=/dev/zero of=/mnt/tmp/file-$i

errno=-28 No space left, with kernel backtrace (blocking bug)

Hi, this bug is very blocking for me: https://bugzilla.kernel.org/show_bug.cgi?id=195257 The server is backup server, I btrfs receive (with and without -p), and of course btrfs subvolume delete The volume is 70TB, then I use space_cache=v2 Cheers, -- alpha_one_x86/BRULE Herman

Re: [PATCH] ioctl_getfsmap.2: document the GETFSMAP ioctl

[cc btrfs, since afaict that's where most of the dedupe tool authors hang out] On Wed, May 10, 2017 at 02:27:33PM -0500, Eric W. Biederman wrote: > Theodore Ts'o writes: > > > On Tue, May 09, 2017 at 02:17:46PM -0700, Eric Biggers wrote: > >> 1.) Privacy implications. Say the

Question on compression unit

Hi there, I'm trying to tune compression options for btrfs. Specifically, I want to know the performance impact on the system under different compression unit (block) sizes. I'm aware of '--nodesize' parameter which sets the block size of metadata tree. Does that also set the block size in an

Re: [RFC PATCH v3 5/6] btrfs: qgroup: Introduce extent changeset for qgroup reserve functions

On 05/09/2017 09:36 PM, Qu Wenruo wrote: > Introduce a new parameter, struct extent_changeset for > btrfs_qgroup_reserved_data() and its callers. > > Such extent_changeset was used in btrfs_qgroup_reserve_data() to record > which range it reserved in current reserve, so it can free it at error

Re: [PATCH 0/6 RFC] utilize bio_clone_fast to clean up

On Tue, May 09, 2017 at 03:49:13PM -0700, Liu Bo wrote: > > This patch is too big, can you split it to smaller chunks? I was not > > able to review it, it seems to touch several things at once, it's hard > > to keep the context. > > Oh I see, the diff does look scary but the changes are in fact

Re: [PATCH v4 23/27] gfs2: clean up some filemap_* calls

- Original Message - | In some places, it's trying to reset the mapping error after calling | filemap_fdatawait. That's no longer required. Also, turn several | filemap_fdatawrite+filemap_fdatawait calls into filemap_write_and_wait. | That will at least return writeback errors that occur

Re: [PATCH] btrfs: fix incorrect error return ret being passed to mapping_set_error

On Tue, May 09, 2017 at 11:58:55AM -0700, Liu Bo wrote: > On Tue, May 09, 2017 at 06:14:01PM +0100, Colin King wrote: > > From: Colin Ian King > > > > The setting of return code ret should be based on the error code > > passed into function end_extent_writepage and not

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

On Wed, 2017-05-10 at 07:18 -0700, Matthew Wilcox wrote: > On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote: > > +++ b/lib/errseq.c > > @@ -0,0 +1,199 @@ > > +#include > > +#include > > +#include > > +#include > > + > > +/* > > + * An errseq_t is a way of recording errors in one

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

On Tue, May 09, 2017 at 11:49:16AM -0400, Jeff Layton wrote: > +++ b/lib/errseq.c > @@ -0,0 +1,199 @@ > +#include > +#include > +#include > +#include > + > +/* > + * An errseq_t is a way of recording errors in one place, and allowing any > + * number of "subscribers" to tell whether it has

Re: [PATCH v4 14/27] fs: new infrastructure for writeback error handling and reporting

On Wed 10-05-17 08:19:50, Jeff Layton wrote: > On Wed, 2017-05-10 at 13:48 +0200, Jan Kara wrote: > > On Tue 09-05-17 11:49:17, Jeff Layton wrote: > > > diff --git a/fs/file_table.c b/fs/file_table.c > > > index 954d510b765a..d6138b6411ff 100644 > > > --- a/fs/file_table.c > > > +++

Re: [PATCH v4 06/27] fs: check for writeback errors after syncing out buffers in generic_file_fsync

On Tue, May 09, 2017 at 11:49:09AM -0400, Jeff Layton wrote: > ext2 currently does a test+clear of the AS_EIO flag, which is > is problematic for some coming changes. > > What we really need to do instead is call filemap_check_errors > in __generic_file_fsync after syncing out the buffers. That >

Re: [PATCH v4 14/27] fs: new infrastructure for writeback error handling and reporting

On Wed, 2017-05-10 at 13:48 +0200, Jan Kara wrote: > On Tue 09-05-17 11:49:17, Jeff Layton wrote: > > Most filesystems currently use mapping_set_error and > > filemap_check_errors for setting and reporting/clearing writeback errors > > at the mapping level. filemap_check_errors is indirectly

Re: [PATCH v4 14/27] fs: new infrastructure for writeback error handling and reporting

On Tue 09-05-17 11:49:17, Jeff Layton wrote: > Most filesystems currently use mapping_set_error and > filemap_check_errors for setting and reporting/clearing writeback errors > at the mapping level. filemap_check_errors is indirectly called from > most of the filemap_fdatawait_* functions and from

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

On Tue 09-05-17 11:49:16, Jeff Layton wrote: > An errseq_t is a way of recording errors in one place, and allowing any > number of "subscribers" to tell whether an error has been set again > since a previous time. > > It's implemented as an unsigned 32-bit value that is managed with atomic >

Re: [PATCH v4 13/27] lib: add errseq_t type and infrastructure for handling it

On Wed, 2017-05-10 at 08:03 +1000, NeilBrown wrote: > On Tue, May 09 2017, Jeff Layton wrote: > > > An errseq_t is a way of recording errors in one place, and allowing any > > number of "subscribers" to tell whether an error has been set again > > since a previous time. > > > > It's implemented

Re: runtime btrfsck

Hello, thanks. But is there any way to recover from this error? Like removing the item or so? Data loss isn't a problem. Just reconstructing the whole FS will take quite a long time. Stefan Am 10.05.2017 um 11:54 schrieb Hugo Mills: > On Wed, May 10, 2017 at 11:20:58AM +0200, Stefan Priebe -

Re: [PATCH v4 12/27] cifs: set mapping error when page writeback fails in writepage or launder_pages

On Tue 09-05-17 11:49:15, Jeff Layton wrote: > Signed-off-by: Jeff Layton > Reviewed-by: Christoph Hellwig Looks good to me. You can add: Reviewed-by: Jan Kara Honza > --- >

Re: [PATCH v4 11/27] fuse: set mapping error in writepage_locked when it fails

On Tue 09-05-17 11:49:14, Jeff Layton wrote: > This ensures that we see errors on fsync when writeback fails. > > Signed-off-by: Jeff Layton > Reviewed-by: Christoph Hellwig Looks good to me. You can add: Reviewed-by: Jan Kara

Re: [PATCH v4 05/27] btrfs: btrfs_wait_tree_block_writeback can be void return

On Tue 09-05-17 11:49:08, Jeff Layton wrote: > Nothing checks its return value. > > Signed-off-by: Jeff Layton Looks good to me. You can add: Reviewed-by: Jan Kara Honza > --- >

Re: [PATCH v4 01/27] fs: remove unneeded forward definition of mm_struct from fs.h

On Tue 09-05-17 11:49:04, Jeff Layton wrote: > Signed-off-by: Jeff Layton Looks good. You can add: Reviewed-by: Jan Kara Honza > --- > include/linux/fs.h | 2 -- > 1 file changed, 2

Re: [PATCH 6/6] fstests: regression test for nocsum buffered read's repair

On Tue, May 09, 2017 at 11:56:11AM -0600, Liu Bo wrote: > This is to test whether buffered read retry-repair code is able to work in > raid1 case as expected. > > Please note that without checksum, btrfs doesn't know if the data used to > repair is correct, so repair is more of resync which makes

Re: [PATCH 3/6] fstests: regression test for btrfs dio read repair

On Tue, May 09, 2017 at 11:56:08AM -0600, Liu Bo wrote: > This case tests whether dio read can repair the bad copy if we have > a good copy. > > Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks") > introduced the regression. > > The upstream fix is > Btrfs: fix

Re: [PATCH 2/6] fstests: add _get_current_dmesg

On Tue, May 09, 2017 at 11:56:07AM -0600, Liu Bo wrote: > _get_current_dmesg can be used to grep customized pattern. > > Signed-off-by: Liu Bo I can't apply this patch on top of current master, perhaps it needs a rebase :) > --- > common/rc | 9 +++-- > 1 file

Re: runtime btrfsck

On Wed, May 10, 2017 at 11:20:58AM +0200, Stefan Priebe - Profihost AG wrote: > Hello, > > here's the output: > # for block in 163316514816 163322413056 163325722624; do echo $block; > btrfs-debug-tree -b $block /dev/mapper/crypt_md0|sed -re 's/(\t| )name: > .*/\1name: HIDDEN/'; done > >

Re: runtime btrfsck

Hello, here's the output: # for block in 163316514816 163322413056 163325722624; do echo $block; btrfs-debug-tree -b $block /dev/mapper/crypt_md0|sed -re 's/(\t| )name: .*/\1name: HIDDEN/'; done 163316514816 btrfs-progs v4.8.5 leaf 163316514816 items 188 free space 1387 generation 86739 owner

Re: runtime btrfsck

On Wed, May 10, 2017 at 10:40:31AM +0200, Stefan Priebe - Profihost AG wrote: > Am 10.05.2017 um 09:40 schrieb Hugo Mills: > > On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG > > wrote: > >> Hello Roman, > >> > >> the FS is mountable. It just goes readonly when trying to

Re: runtime btrfsck

On Wed, 10 May 2017 09:48:07 +0200 Martin Steigerwald wrote: > Yet, when it comes to btrfs check? Its still quite rudimentary if you ask me. > Indeed it is. It may or may not be possible to build a perfect Fsck, but IMO for the time being, what's most sorely missing, is

Re: runtime btrfsck

Hi, Am 10.05.2017 um 09:48 schrieb Martin Steigerwald: > Stefan Priebe - Profihost AG - 10.05.17, 09:02: >> I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me >> something about the expected runtime or how to fix bad key ordering? > > I had a similar issue which remained

Re: runtime btrfsck

Am 10.05.2017 um 09:40 schrieb Hugo Mills: > On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG wrote: >> Hello Roman, >> >> the FS is mountable. It just goes readonly when trying to write some data. >> >> The kernel msgs are: >> BTRFS critical (device dm-2): corrupt leaf, bad

Re: runtime btrfsck

Stefan Priebe - Profihost AG - 10.05.17, 09:02: > I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me > something about the expected runtime or how to fix bad key ordering? I had a similar issue which remained unresolved. But I clearly saw that btrfs check was running in a

Re: runtime btrfsck

On Wed, May 10, 2017 at 09:36:30AM +0200, Stefan Priebe - Profihost AG wrote: > Hello Roman, > > the FS is mountable. It just goes readonly when trying to write some data. > > The kernel msgs are: > BTRFS critical (device dm-2): corrupt leaf, bad key order: > block=163316514816,root=1, slot=39 >

Re: runtime btrfsck

Hello Roman, the FS is mountable. It just goes readonly when trying to write some data. The kernel msgs are: BTRFS critical (device dm-2): corrupt leaf, bad key order: block=163316514816,root=1, slot=39 BTRFS critical (device dm-2): corrupt leaf, bad key order: block=163322413056,root=1, slot=74

Re: runtime btrfsck

Hello, (Warning: I'm a user, not a developer here.) In my experience (on kernel 4.4) it processed larger and slower devices within a day, BUT according to some recent topics the runaway fragmentation (meaning in this case large number of small extents regardless of their relative location)

Re: runtime btrfsck

On Wed, 10 May 2017 09:02:46 +0200 Stefan Priebe - Profihost AG wrote: > how to fix bad key ordering? You should clarify does the FS in question mount (read-write? read-only?) and what are the kernel messages if it does not. -- With respect, Roman -- To unsubscribe from

Re: runtime btrfsck

I'm now trying btrfs progs 4.10.2. Is anybody out there who can tell me something about the expected runtime or how to fix bad key ordering? Greets, Stefan Am 06.05.2017 um 07:56 schrieb Stefan Priebe - Profihost AG: > It's still running. Is this the normal behaviour? Is there any other way > to

[PATCH] btrfs-progs: record_orphan_data_extent: Fix memory leak

The nodes of the list at btrfs_root->orphan_data_extents are never freed causing memory to be leaked. This commit fixes the bug by freeing the nodes on all the btrfs_root->orphan_data_extents list. Signed-off-by: Praveen K Pandey --- cmds-check.c | 23