All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liu Bo <bo.li.liu@oracle.com>
To: Xin Zhou <xin.zhou@gmx.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/6] btrfs dax IO
Date: Thu, 8 Dec 2016 08:53:47 -0800	[thread overview]
Message-ID: <20161208165347.GC20111@localhost.localdomain> (raw)
In-Reply-To: <trinity-1b4598b4-93e0-4762-90a6-d2f7aadc7dd2-1481179698241@3capp-mailcom-bs01>

On Thu, Dec 08, 2016 at 07:48:18AM +0100, Xin Zhou wrote:
> Hi Liu,
>  
> From the patch, is the snapshot disabled by disabling the COW in the mounting path?
> It seems the create_snapshot() in ioctl.c does not get changed.

Well, I think I made a mistake in this cover letter, snapshot still
works while mounting with dax, but if a snapshot is taken, then we'll
get -EIO while writing to dax inodes that belong to either snapshot tree
or its source tree.  So in fact, only a readonly snapshot makes sense in
practice, I'll update the patch so that we only allow a readonly
snapshot to be taken.

COW is disabled by letting the dax mount option imply the "nodatacow"
option.

Thanks for spotting this!

Thanks,

-liubo

> 
> I experienced some similar system but am a bit new to the brtfs code.
>   
> Thanks, 
> Xin
>  
>  
> 
> Subject: [PATCH 0/6] btrfs dax IOFrom: Liu Bo <bo.li.liu@xxxxxxxxxx>Date: Wed, 7 Dec 2016 13:45:04 -0800Cc: Chris Mason <clm@xxxxxx>, Jan Kara <jack@xxxxxxx>, David Sterba <dsterba@xxxxxxx>
> This is a prelimanary patch set to add dax support for btrfs, with
> this we can do normal read/write to dax files and can mmap dax files
> to userspace so that applications have the ability to access
> persistent memory directly.
> 
> Please note that currently this is limited to nocow, i.e. all dax
> inodes do not have COW behaviour.
> 
> COW:   	    	     	no
> mutliple device:	no
> clone/reflink:		no
> snapshot:		no
> compression:		no
> checksum:		no
> 
> Right now snapshot is disabled while mounting with -odax, but snapshot
> can be created without -odax, and writing to a dax file in snapshot
> will get -EIO.
> 
> Clone/reflink is dealt with as same as snapshot, -EIO will be returned
> when writing to shared extents.
> 
> This has adopted the latest iomap framework for dax read/write
> and dax mmap.
> 
>  
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-12-08 16:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <trinity-f6bd31da-24aa-4876-bde0-fe5b26b1af92-1481179495753@3capp-mailcom-bs01>
2016-12-08  6:48 ` [PATCH 0/6] btrfs dax IO Xin Zhou
2016-12-08 16:53   ` Liu Bo [this message]
2016-12-07 21:45 Liu Bo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161208165347.GC20111@localhost.localdomain \
    --to=bo.li.liu@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=xin.zhou@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.