Chris Murphy posted on Fri, 22 May 2015 13:15:09 -0600 as excerpted:
> On Thu, May 21, 2015 at 10:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> For in-production use, therefore, btrfs raid56 mode, while now at least
>> in theory complete, is really too immature at this point to recommend.
>
> At
Hi Linus,
My for-linus-4.1 branch has three more fixes:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
for-linus-4.1
I fixed up a regression from 4.0 where conversion between different raid
levels would sometimes bail out without converting.
Filipe tracked down a race wher
Hello,
Yes the conversion from raid0 to single went fine.
> For the metadata, one approach is to convert to single, delete the
> device, then convert to DUP. That at least will work, if be a little
> risky.
This worked great, thank you !
On Sat, May 23, 2015 at 12:22 AM, Hugo Mills wrote:
>
On Sat, May 23, 2015 at 12:15:13AM +0200, Arnaud Kapp wrote:
> Hello,
>
> I've setup a filesystem with 2 devices. The metadata are in raid1.
> Data is in raid0.
>
> I wish to remove one of this device from the filesystem (to use for an
> unrelated purpose) but I am not able to do so.
> It *seems*
Hello,
I've setup a filesystem with 2 devices. The metadata are in raid1.
Data is in raid0.
I wish to remove one of this device from the filesystem (to use for an
unrelated purpose) but I am not able to do so.
It *seems* that attempting to balance metadata to dup is not allowed
(btrfs -mconvert=d
On Thu, May 21, 2015 at 10:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> For in-production use, therefore, btrfs raid56 mode, while now at least
> in theory complete, is really too immature at this point to recommend.
At some point perhaps a developer will have time to state the expected
stability
On Fri, May 22, 2015 at 11:17:59AM -0700, Darrick J. Wong wrote:
> Back when I was writing the stable pages patches, I observed that some of the
> filesystems didn't hold the pages containing their own metadata stable during
> writeback on a stable-writes device. The journalling filesystems were f
From: Kent Overstreet
Btrfs has been doing bio splitting from btrfs_map_bio(), by checking
device limits as well as calling ->merge_bvec_fn() etc. That is not
necessary any more, because generic_make_request() is now able to
handle arbitrarily sized bios. So clean up unnecessary code paths.
Cc:
On Thu, May 21, 2015 at 09:21:12PM +0200, Jan Kara wrote:
> On Thu 21-05-15 11:09:55, Kent Overstreet wrote:
> > On Thu, May 21, 2015 at 06:54:53PM +0200, Jan Kara wrote:
> > > On Wed 20-05-15 18:04:40, Kent Overstreet wrote:
> > > > > Yeah. I never figured out a sane way to migrate pages and keep
Duncan <1i5t5.duncan cox.net> writes:
> FWIW, btrfs raid5 (and raid6, together called raid56 mode) is still
> extremely new, only normal runtime implemented as originally introduced,
> with complete repair from a device failure only completely implemented in
> kernel 3.19, and while in theory
When the btrfs on a device is overwritten with a new btrfs (mkfs),
the old btrfs instance in the kernel becomes stale. So with this
patch if kernel finds device is overwritten, then delete the stale
fsid/uuid.
Signed-off-by: Anand Jain
---
V5->V5.1: since this deals with only devices in unmounted
On 05/22/2015 12:30 AM, David Sterba wrote:
On Fri, May 15, 2015 at 11:42:57PM +0800, Anand Jain wrote:
On 05/13/2015 09:43 PM, David Sterba wrote:
On Tue, May 12, 2015 at 12:00:28PM +0800, Anand Jain wrote:
I strongly recommend this feature to be part of btrfstune as
of now, as or
I just did that. When I disable the 0 byte file writes, it still
causes the abort. So, it's not the 0 byte files that cause it
currently.
2015-05-22 2:17 GMT+02:00 Gareth Pye :
> Maybe try switching the script to not use the 0 byte file to indicate
> the directory is finished. That might let you d
13 matches
Mail list logo
