On Thu, Nov 16, 2017 at 11:47:45AM -0500, Austin S. Hemmelgarn wrote:
> >
> >At least btrfs can take the advantage of the simplicity of separate layers.
> >
> >And other filesystem can get a little higher chance to recover its
> >metadata if built on dm-raid.
> Again, just put dm-integrity below
Hi,
On Wed, Sep 13, 2017 at 02:38:49PM +0800, peterh wrote:
> From: Kuanling Huang
>
> By analyzing the perf on btrfs send, we found it take large
> amount of cpu time on page_cache_sync_readahead. This effort
> can be reduced after switching to asynchronous one. Overall
>
On Thu, May 18, 2017 at 06:12:22AM +, Duncan wrote:
> Roman Mamedov posted on Thu, 18 May 2017 10:17:19 +0500 as excerpted:
>
> > On Thu, 18 May 2017 04:09:38 +0200 ??ukasz Wróblewski wrote:
> >
> >> I will try when stable 4.12 comes out.
> >> Unfortunately I do not have a
On Mon, Sep 12, 2016 at 09:57:17PM +0200, Martin Steigerwald wrote:
> Am Montag, 12. September 2016, 18:27:47 CEST schrieb David Sterba:
> > On Mon, Sep 12, 2016 at 04:27:14PM +0200, David Sterba wrote:
> > > > I therefore would like to propose that some sort of feature / stability
> > > > matrix
On Thu, Oct 15, 2015 at 07:39:20AM +0200, audio muze wrote:
> Thanks Chris
>
> I should've browsed recent threads, my apologies. Terribly
> frustrating though that the issues you refer to aren't documented in
> the btrfs wiki. Reading the wiki one is lead to believe that the only
> real issue
Hi,
On Wed, Sep 23, 2015 at 09:41:21AM +0100, Filipe David Manana wrote:
> On Tue, Sep 22, 2015 at 9:04 PM, Hugo Mills wrote:
> > On Tue, Sep 22, 2015 at 09:52:19PM +0200, carlo von lynX wrote:
> >> Hello, it's me again. This time I searched the web to make sure
> >> I'm not
On Thu, Dec 04, 2014 at 07:24:29PM +0100, Goffredo Baroncelli wrote:
Add reference to BTRFS_SKIP_LVM_SNAPSHOT environment viarble in
^^^
a small typo.. should be variable.
-- Pasi
the btrfs(8) documentation.
Signed-off-by:
On Fri, Nov 22, 2013 at 07:12:39PM +1100, Russell Coker wrote:
On Thu, 21 Nov 2013 18:30:49 Stan Hoeppner wrote:
I suggest that anyone in the future needing fast random write IOPS is
going to move those workloads to SSD, which is steadily increasing in
capacity. And I suggest anyone