On Mon, Jul 13, 2015 at 07:33:13PM +0200, Marc Joliet wrote:
> Am Mon, 13 Jul 2015 19:21:54 +0200
> schrieb Marc Joliet :
>
> > OK, I'll make the changes then (sans kernel log).
>
> Just a heads up: I accepted the terms of service, but the link goes to a
> non-existent wiki page.
I have reported
Hi.
I have an Old Server with a bunch of btrfs Snapshots.
I'm setting up a new server and I would like to transfer those Snapshots
as efficiently as possible, while still maintaining their parent<->child
relationships for space efficient storage.
Apart from manually using "btrfs send" and "btrfs
On Tue, Jul 14, 2015 at 10:13:01AM +0800, Qu Wenruo wrote:
> This reverts commit 5f8232e5c8f0b0de0ef426274911385b0e877392.
Thanks. The revert is justified for the severity of the problem, I'll
release 4.1.2 asap.
> This commit causes a regression:
> ---
BTW, do not use --- in the changelog as '
So, after experiencing this same issue multiple times (on almost a dozen
different kernel versions since 4.0) and ruling out the possibility of it being
caused by my hardware (or at least, the RAM, SATA controller and disk drives
themselves), I've decided to report it here.
The general symptom
Hello,
at the weekend we had a disk-fail in a 5-disk BtrFS-RAID1
setup. Ideally one failing disk in a RAID1 setup should (at least
temporarily) degrade the filesystem and inform root about the
situation, but should let the rest of the system unaffected. That’s
not what happend. Processes accessing
On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Regardless of whether 1 or huge -t means maximum defrag, however, the
> nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
> should be considered ideally defragged at 31 extents. This is a
> departure from ext4,
Hi,
due to a buggy bugfix to mkfs, filesystems created with version 4.1.1 are not
entirely correct.
To check if the filesystem is affected run 'btrfs check' and look for
Chunk[256, 228, 0]: length(4194304), offset(0), type(2) mismatch with block
group[0, 192, 4194304]: offset(4194304), objectid
On 2015-07-14 07:49, Austin S Hemmelgarn wrote:
So, after experiencing this same issue multiple times (on almost a dozen
different kernel versions since 4.0) and ruling out the possibility of it being
caused by my hardware (or at least, the RAM, SATA controller and disk drives
themselves), I'v
From: Filipe Manana
Using the clone ioctl (or extent_same ioctl, which calls the same extent
cloning function as well) we end up allowing copy an inline extent from
the source file into a non-zero offset of the destination file. This is
something not expected and that the btrfs code is not prepar
On Tue, Jul 07, 2015 at 10:12:16AM +0800, Wang Yanfeng wrote:
> Man manual need to be updated since RAID5/6 has been supported
> by btrfs-replace.
>
> Signed-off-by: Wang Yanfeng
Applied, thanks. Please do not forget to add 'btrfs-progs' into the subject
otherwise, I might miss progs patches whi
From: Filipe Manana
This tests that we can not clone an inline extent into a non-zero file
offset. Inline extents at non-zero offsets is something btrfs is not
prepared for and results in all sorts of corruption and crashes on
future IO operations, such as the following BUG_ON() triggered by the
Patrik Lundquist posted on Tue, 14 Jul 2015 13:57:07 +0200 as excerpted:
> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>>
>> Regardless of whether 1 or huge -t means maximum defrag, however, the
>> nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
>> should b
On Tue, Jul 07, 2015 at 04:15:28PM +0800, Qu Wenruo wrote:
[...]
>
> Signed-off-by: Qu Wenruo
Applied, thanks a lot. I've tested several data/metadata combinations
and the resulting 'fi df' looks ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a messa
On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
> >
> > Regardless of whether 1 or huge -t means maximum defrag, however, the
> > nominal data chunk size of 1 GiB means that 30 GiB file you mentioned
> > should be co
On 14 July 2015 at 20:41, Hugo Mills wrote:
> On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
>> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
>> >
>> > Regardless of whether 1 or huge -t means maximum defrag, however, the
>> > nominal data chunk size of 1 GiB me
On Tue, Jul 14, 2015 at 09:09:00PM +0200, Patrik Lundquist wrote:
> On 14 July 2015 at 20:41, Hugo Mills wrote:
> > On Tue, Jul 14, 2015 at 01:57:07PM +0200, Patrik Lundquist wrote:
> >> On 24 June 2015 at 12:46, Duncan <1i5t5.dun...@cox.net> wrote:
> >> >
> >> > Regardless of whether 1 or huge -t
$ btrfs subvolume list /
ERROR: can't perform the search - Operation not permitted
ERROR: can't get rootid for ‘/'
I don't know what a 'rootid' is as a user, and i don't really want to ponder
whether I need to find out.
What about a simple
ERROR: Permission denied.
instead?
Cheers,
Johannes.
On Tue, Jul 14, 2015 at 7:25 AM, Austin S Hemmelgarn
wrote:
> On 2015-07-14 07:49, Austin S Hemmelgarn wrote:
>>
>> So, after experiencing this same issue multiple times (on almost a dozen
>> different kernel versions since 4.0) and ruling out the possibility of it
>> being caused by my hardware (
On Thu, Jul 9, 2015 at 10:45 PM, Qu Wenruo wrote:
>
>
> Chris Murphy wrote on 2015/07/09 18:45 -0600:
>>
>> On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo wrote:
>>>
>>> One of my patch addressed a problem that a converted btrfs can't pass
>>> btrfsck.
>>>
>>> Not sure if that is the cause, but if you
The way it works in snazzer (and btrbk and I think also btrfs-sxbackup
as well), local snapshots continue to happen as normal (Eg. daily or
hourly) and so when your backup media or backup server is finally
available again, the size of each individual incremental is still the
same as usual, it just
"btrfs subvolume list -uq /some/subvol" can help figure out the
existing parent relationships, but in practice if your snapshots are
simply a linear series over time then I doubt you'll gain much by
parsing all those UUIDs over simply doing an initial btrfs
send/receive without any parent followed
David Sterba wrote on 2015/07/14 13:45 +0200:
On Tue, Jul 14, 2015 at 10:13:01AM +0800, Qu Wenruo wrote:
This reverts commit 5f8232e5c8f0b0de0ef426274911385b0e877392.
Thanks. The revert is justified for the severity of the problem, I'll
release 4.1.2 asap.
This commit causes a regression:
On Wed, Jul 15, 2015 at 10:03:16AM +1000, Paul Harvey wrote:
> The way it works in snazzer (and btrbk and I think also btrfs-sxbackup
> as well), local snapshots continue to happen as normal (Eg. daily or
> hourly) and so when your backup media or backup server is finally
> available again, the siz
From: Zhao Lei
Liu Bo reported a lockdep warning of
delayed_iput_sem in xfstests generic/241:
[ 2061.345955] =
[ 2061.346027] [ INFO: possible recursive locking detected ]
[ 2061.346027] 4.1.0+ #268 Tainted: GW
[ 2061.346027] --
On 14/07/15 11:25 PM, Austin S Hemmelgarn wrote:
On 2015-07-14 07:49, Austin S Hemmelgarn wrote:
So, after experiencing this same issue multiple times (on almost a
dozen different kernel versions since 4.0) and ruling out the
possibility of it being caused by my hardware (or at least, the RAM,
25 matches
Mail list logo
