Re: [LSF/MM TOPIC] Software RAID Support for NV-DIMM

2019-02-16 Thread Bob Liu
On 2/16/19 1:39 PM, Dave Chinner wrote: > On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote: >> On Fri, Feb 15, 2019 at 10:57:12AM +0100, Johannes Thumshirn wrote: >>> (This is a joint proposal with Hannes Reinecke) >>> >>> Servers with NV-DIMM are slowly emerging in data centers but one

Re: [LSF/MM TOPIC] Software RAID Support for NV-DIMM

2019-02-16 Thread Dan Williams
On Fri, Feb 15, 2019 at 9:40 PM Dave Chinner wrote: > > On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote: > > On Fri, Feb 15, 2019 at 10:57:12AM +0100, Johannes Thumshirn wrote: > > > (This is a joint proposal with Hannes Reinecke) > > > > > > Servers with NV-DIMM are slowly emerging i

Re: Btrfs send with parent different size depending on source of files.

2019-02-16 Thread Andrei Borzenkov
14.02.2019 14:37, André Malm пишет: > Hello, > > I'm not sure this is the right forum to ask on but I'll try and if its > not I do apologize. I have also created a stack overflow question > without success ( > https://stackoverflow.com/questions/54634703/btrfs-send-with-parent-different-size-depen

Re: Btrfs send with parent different size depending on source of files.

2019-02-16 Thread Andrei Borzenkov
15.02.2019 21:56, Remi Gauvin пишет: > On 2019-02-15 1:38 p.m., Chris Murphy wrote: >> >> Well I'd say maybe use -vvv and --no-data instead of -f and see what >> it's doing. It sounds like the former has no payload, just difference >> information, and the latter has a payload. I don't know why. >>

Re: Btrfs send with parent different size depending on source of files.

2019-02-16 Thread Andrei Borzenkov
15.02.2019 22:11, Chris Murphy пишет: ... >>> >>> It doesn't work this way. >> >> It works exactly this way. > > Unproven. And in fact we have an example where it does not work, hence > the point of the thread! > > The proven way it works, is as I've described, and many emails over a > decade on

Re: Btrfs send with parent different size depending on source of files.

2019-02-16 Thread Andrei Borzenkov
16.02.2019 23:26, Andrei Borzenkov пишет: ... >> Difference suggests the order does not matter. Increment suggests it >> does matter. >> >> btrfs sub create A >> cp somestuff A >> btrfs sub snap -r A a.1 >> cp morestuff A >> btrfs sub snap -r A a.2 >> >> The normal case of send is: >> >> btrfs send

Re: Btrfs corruption: Cannot mount partition

2019-02-16 Thread Martin Pöhlmann
Thanks a lot for your help. @Qu Wenruo: WIll zero log after completing the backup @Chris Murphy: First of all, mount -ro,nologreplay works. dump-tree displays two items: # btrfs insp dump-tree -b 88560877568 --follow /dev/mapper/cryptroot btrfs-progs v4.19.1 leaf 88560877568 items 2 free space 1

Re: [LSF/MM TOPIC] Software RAID Support for NV-DIMM

2019-02-16 Thread Dave Chinner
On Sat, Feb 16, 2019 at 09:05:31AM -0800, Dan Williams wrote: > On Fri, Feb 15, 2019 at 9:40 PM Dave Chinner wrote: > > > > On Sat, Feb 16, 2019 at 04:31:33PM +1100, Dave Chinner wrote: > > > On Fri, Feb 15, 2019 at 10:57:12AM +0100, Johannes Thumshirn wrote: > > > > (This is a joint proposal with

Re: [PATCH v2] vfs: don't decrement i_nlink in d_tmpfile

2019-02-16 Thread Al Viro
On Fri, Feb 15, 2019 at 02:39:25PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong > > d_tmpfile was introduced to instantiate an inode in the dentry cache as > a temporary file. This helper decrements the inode's nlink count and > dirties the inode, presumably so that filesystems could ca

Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

2019-02-16 Thread Andreas Dilger
On Feb 14, 2019, at 11:59 PM, Omar Sandoval wrote: > > On Fri, Feb 15, 2019 at 11:16:57AM +1100, Dave Chinner wrote: >> On Thu, Feb 14, 2019 at 03:14:29PM -0800, Omar Sandoval wrote: >>> I see a few options, none of which are particularly nice: >>> >>> 1. Filesystems like XFS could choose not to

Re: Btrfs send with parent different size depending on source of files.

2019-02-16 Thread Remi Gauvin
On 2019-02-16 3:08 p.m., Andrei Borzenkov wrote: > > File size of "real" server.jar is not exact multiple of btrfs block size > (4096) which causes the last extent to be "incomplete". btrfs won't > clone extent in this case. You can trivially reproduce it by using the > same size in the first cas