> On 28 Apr 2017, at 02:45, Qu Wenruo wrote:
>
>
>
> At 04/26/2017 01:50 AM, Christophe de Dinechin wrote:
>> Hi,
>> I”ve been trying to run btrfs as my primary work filesystem for about 3-4
>> months now on Fedora 25 systems. I ran a few times into filesystem
>> corruptions. At least one I
We allow recursive mounts with subvol options such as [1]
[1]
mount -o rw,compress=lzo /dev/sdc /btrfs1
mount -o ro,subvol=sv2 /dev/sdc /btrfs2
And except for the btrfs-specific subvol and subvolid options
all-other options are just ignored in the subsequent mounts.
In the below example [2] th
See https://bugzilla.redhat.com/show_bug.cgi?id=1435567 for an example
where the message occurs,
Signed-off-by: Christophe de Dinechin
---
cmds-check.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/cmds-check.c b/cmds-check.c
index 17b7efb..2d3ebc1 100644
--- a/c
When this happens, we will trip a BUG_ON(end < start) in insert_state
because in check_extent_refs, we use this max_size expecting it's not zero:
set_extent_dirty(root->fs_info->excluded_extents,
rec->start,
rec->start + rec->max_size - 1);
See https://bugz
Since we memset tmpl, max_size==0. This does not seem consistent with nr = 1.
In check_extent_refs, we will call:
set_extent_dirty(root->fs_info->excluded_extents,
rec->start,
rec->start + rec->max_size - 1);
This ends up with BUG_ON(end < start) in insert_
On Fri, 28 Apr 2017 11:13:36 +0200
Christophe de Dinechin wrote:
> Since we memset tmpl, max_size==0. This does not seem consistent with nr = 1.
> In check_extent_refs, we will call:
>
> set_extent_dirty(root->fs_info->excluded_extents,
>rec->start,
>rec
On Wed, Apr 26, 2017 at 7:09 PM, 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 invalid deref
When this happens, we will trip a BUG_ON(end < start) in insert_state
because in check_extent_refs, we use this max_size expecting it's not zero:
set_extent_dirty(root->fs_info->excluded_extents,
rec->start,
rec->start + rec->max_size - 1);
See https://bugz
On Wed, Apr 26, 2017 at 7:09 PM, Liu Bo wrote:
> This case tests whether buffered read can repair the bad copy if we
> have a good copy.
>
> Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed
> and drop checks") introduced the regression.
>
> The upstream fix is
> Btrfs
Since we memset tmpl, max_size==0. This does not seem consistent with nr = 1.
In check_extent_refs, we will call:
set_extent_dirty(root->fs_info->excluded_extents,
rec->start,
rec->start + rec->max_size - 1);
This ends up with BUG_ON(end < start) in insert_
Hi,
On Fri, Apr 28, 2017 at 02:55:31PM +0530, Lakshmipathi.G wrote:
> Seems like user reported an issue with this patch. please check
> https://bugzilla.kernel.org/show_bug.cgi?id=195597
I can take a look. What I'm wondering about is why it fails only in the HDD
to SSD case. If -ENODATA is return
On Wed, Apr 26, 2017 at 9:54 PM, Liu Bo wrote:
> Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
> introduced this regression. It'd cause 'Segmentation fault' error.
>
> The upstream fix is
> Btrfs: fix segment fault when doing dio read
Same issue as the other
Hi.
Adding the bug reporter, Nazar for the discussion (as I'm not familiar
with send/receive feature/code).
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org
On Fri, Apr 28, 2017 at 3:25 PM, Christian Brauner
wrote:
>
> Hi,
>
> On Fri, Apr 28, 2017 at 02:55:31PM +0530, L
On Wed, Apr 26, 2017 at 9:54 PM, 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 sure that
Hi,
Sorry for confusion, I've checked once again and the same issue happens in all
cases.
I didn't notice this because my regular backups are done automatically in cron
task + snapshots look fine despite the error, so I incorrectly assumed an error
didn't happen there, but it actually did.
I'
Dmarc is off, here's the output of the allocations: it's working
correctly right now, I'll update when it does it again.
/sys/fs/btrfs/7af2e65c-3935-4e0d-aa63-9ef6be991cb9/allocation/system/flags:2
/sys/fs/btrfs/7af2e65c-3935-4e0d-aa63-9ef6be991cb9/allocation/system/raid1/used_bytes:3948544
/sys/f
Old news is that systemd-journald journals end up pretty heavily
fragmented on Btrfs due to COW. While journald uses chattr +C on
journal files now, COW still happens if the subvolume the journal is
in gets snapshot. e.g. a week old system.journal has 19000+ extents.
The news is I started a system
On 2017-04-28 18:16, Chris Murphy wrote:
> Old news is that systemd-journald journals end up pretty heavily
> fragmented on Btrfs due to COW. While journald uses chattr +C on
> journal files now, COW still happens if the subvolume the journal is
> in gets snapshot. e.g. a week old system.journal ha
On Fri, Apr 28, 2017 at 11:05 AM, Goffredo Baroncelli
wrote:
> In the past I faced the same problems; I collected some data here
> http://kreijack.blogspot.it/2014/06/btrfs-and-systemd-journal.html.
> Unfortunately the journald files are very bad, because first the data is
> written (appended),
> Old news is that systemd-journald journals end up pretty
> heavily fragmented on Btrfs due to COW.
This has been discussed before in detail indeeed here, but also
here: http://www.sabi.co.uk/blog/15-one.html?150203#150203
> While journald uses chattr +C on journal files now, COW still
> happens
> [ ... ] And that makes me wonder whether metadata
> fragmentation is happening as a result. But in any case,
> there's a lot of metadata being written for each journal
> update compared to what's being added to the journal file. [
> ... ]
That's the "wandering trees" problem in COW filesystems,
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 invalid dereference in btrfs_retry_endio
Signed-off-by: Liu Bo
---
v2: -
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 sure that both
of the copy has the same content.
Commit 20a7db8ab
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized blocks")
introduced this regression. It'd cause 'Segmentation fault' error.
The upstream fix is
Btrfs: fix segment fault when doing dio read
Signed-off-by: Liu Bo
---
v2: - Add 'mkfs -b 1G' to limit filesystem size to 2G
This case tests whether buffered read can repair the bad copy if we
have a good copy.
Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed
and drop checks") introduced the regression.
The upstream fix is
Btrfs: bring back repair during read
Signed-off-by: Liu Bo
---
v2
On Fri, Apr 28, 2017 at 10:52:12AM +0100, Filipe Manana wrote:
> On Wed, Apr 26, 2017 at 7:09 PM, Liu Bo wrote:
> > This case tests whether buffered read can repair the bad copy if we
> > have a good copy.
> >
> > Commit 20a7db8ab3f2 ("btrfs: add dummy callback for readpage_io_failed
> > and drop
On 2017-04-28 19:41, Chris Murphy wrote:
> On Fri, Apr 28, 2017 at 11:05 AM, Goffredo Baroncelli
> wrote:
>
>> In the past I faced the same problems; I collected some data here
>> http://kreijack.blogspot.it/2014/06/btrfs-and-systemd-journal.html.
>> Unfortunately the journald files are very bad
>> The gotcha though is there's a pile of data in the journal
>> that would never make it to rsyslogd. If you use journalctl
>> -o verbose you can see some of this.
> You can send *all the info* to rsyslogd via imjournal
> http://www.rsyslog.com/doc/v8-stable/configuration/modules/imjournal.html
>
On Fri, Apr 28, 2017 at 11:46 AM, Peter Grandi
wrote:
> So there are three layers of silliness here:
>
> * Writing large files slowly to a COW filesystem and
> snapshotting it frequently.
> * A filesystem that does delayed allocation instead of
> allocate-ahead, and does not have psychic cod
On Fri, Apr 28, 2017 at 11:53 AM, Peter Grandi
wrote:
> Well, depends, but probably the single file: it is more likely
> that the 20,000 fragments will actually be contiguous, and that
> there will be less metadata IO than for 40,000 separate journal
> files.
You can see from the examples I pos
On Fri, Apr 28, 2017 at 1:39 PM, Peter Grandi
wrote:
> In a particularly demented setup I had to decastrophize with
> great pain a Zimbra QCOW2 disk image (XFS on NFS on XFS on
> RAID6) containining an ever growing number Maildir email archive
> ended up with over a million widely scattered mic
On Fri, Apr 28, 2017 at 3:10 AM, Christophe de Dinechin
wrote:
>
> QEMU qcow2. Host is BTRFS. Guests are BTRFS, LVM, Ext4, NTFS (winXP and
> win10) and HFS+ (macOS Sierra). I think I had 7 VMs installed, planned to
> restore another 8 from backups before my previous disk crash. I usually have
> a
On Fri, Apr 28, 2017 at 11:41:00AM -0600, Chris Murphy wrote:
> The same behavior happens with NTFS in qcow2 files. They quickly end
> up with 100,000+ extents unless set nocow. It's like the worst case
> scenario.
You should never use qcow2 on btrfs, especially if snapshots are involved.
They bot
> [ ... ] these extents are all over the place, they're not
> contiguous at all. 4K here, 4K there, 4K over there, back to
> 4K here next to this one, 4K over there...12K over there, 500K
> unwritten, 4K over there. This seems not so consequential on
> SSD, [ ... ]
Indeed there were recent report
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org [mailto:linux-btrfs-
> ow...@vger.kernel.org] On Behalf Of Goffredo Baroncelli
> Sent: Saturday, 29 April 2017 3:05 AM
> To: Chris Murphy
> Cc: Btrfs BTRFS
> Subject: Re: btrfs, journald logs, fragmentation, and fallocate
>
>
Goffredo Baroncelli posted on Fri, 28 Apr 2017 19:05:21 +0200 as
excerpted:
> After some thinking I adopted a different strategies: I used journald as
> collector, then I forward all the log to rsyslogd, which used a "log
> append" format. Journald never write on the root filesystem, only in
> tmp
28.04.2017 12:14, Anand Jain пишет:
> We allow recursive mounts with subvol options such as [1]
>
> [1]
> mount -o rw,compress=lzo /dev/sdc /btrfs1
> mount -o ro,subvol=sv2 /dev/sdc /btrfs2
>
> And except for the btrfs-specific subvol and subvolid options
> all-other options are just ignored in
37 matches
Mail list logo
