* XFS reflinks @ 2017-08-29 11:23 Chris Cottam 2017-08-29 13:00 ` Christoph Hellwig 0 siblings, 1 reply; 10+ messages in thread From: Chris Cottam @ 2017-08-29 11:23 UTC (permalink / raw) To: linux-xfs [-- Attachment #1.1: Type: text/plain, Size: 282 bytes --] I've got a project where being able to take COW copies of a VMs disc would be really useful (disc snapshots to be then archived off elsewhere) How stable is the the experimental reflinks feature and do you have any idea when it might be declared stable? Regards Chris [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 11:23 XFS reflinks Chris Cottam @ 2017-08-29 13:00 ` Christoph Hellwig 2017-08-29 13:39 ` Chris Cottam 2017-08-29 16:03 ` Darrick J. Wong 0 siblings, 2 replies; 10+ messages in thread From: Christoph Hellwig @ 2017-08-29 13:00 UTC (permalink / raw) To: Chris Cottam; +Cc: linux-xfs On Tue, Aug 29, 2017 at 12:23:13PM +0100, Chris Cottam wrote: > I've got a project where being able to take COW copies of a VMs disc > would be really useful (disc snapshots to be then archived off elsewhere) > > How stable is the the experimental reflinks feature and do you have any > idea when it might be declared stable? I've got a customer that heavily uses (and tests) reflinks. They initially found a few issues, but these days the QA teams finds bugs in decade old XFS code but not related to reflinks.. You're mileage my vary, but I think we should be able to drop the experimental tag now. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 13:00 ` Christoph Hellwig @ 2017-08-29 13:39 ` Chris Cottam 2017-08-29 16:40 ` Christoph Hellwig 2017-08-29 16:03 ` Darrick J. Wong 1 sibling, 1 reply; 10+ messages in thread From: Chris Cottam @ 2017-08-29 13:39 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-xfs [-- Attachment #1.1: Type: text/plain, Size: 1194 bytes --] Could I enquire about the severity of a few issues? Regard Chris On 29/08/17 14:00, Christoph Hellwig wrote: > On Tue, Aug 29, 2017 at 12:23:13PM +0100, Chris Cottam wrote: >> I've got a project where being able to take COW copies of a VMs disc >> would be really useful (disc snapshots to be then archived off elsewhere) >> >> How stable is the the experimental reflinks feature and do you have any >> idea when it might be declared stable? > > I've got a customer that heavily uses (and tests) reflinks. They > initially found a few issues, but these days the QA teams finds > bugs in decade old XFS code but not related to reflinks.. > > You're mileage my vary, but I think we should be able to drop the > experimental tag now. > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Chris Cottam Bytemark Hosting Support http://www.bytemark.co.uk/ tel: +44 (0) 1904 890 890 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 13:39 ` Chris Cottam @ 2017-08-29 16:40 ` Christoph Hellwig 0 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2017-08-29 16:40 UTC (permalink / raw) To: Chris Cottam; +Cc: Christoph Hellwig, linux-xfs On Tue, Aug 29, 2017 at 02:39:56PM +0100, Chris Cottam wrote: > Could I enquire about the severity of a few issues? The most recent ones were: xfs: try to avoid blowing out the transaction reservation when bunmaping a shared extent which is a case wher we blew a transaction under extreme unlink loads, leading to a fs shutdown in those cases. xfs: try any AG when allocating the first btree block when reflinking again could lead to a shutdown xfs: fix COW writeback race this could lead to a kernel crash xfs: only reclaim unwritten COW extents periodically could lead to a kernel crash ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 13:00 ` Christoph Hellwig 2017-08-29 13:39 ` Chris Cottam @ 2017-08-29 16:03 ` Darrick J. Wong 2017-08-29 16:23 ` Christoph Hellwig 1 sibling, 1 reply; 10+ messages in thread From: Darrick J. Wong @ 2017-08-29 16:03 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Chris Cottam, linux-xfs On Tue, Aug 29, 2017 at 06:00:46AM -0700, Christoph Hellwig wrote: > On Tue, Aug 29, 2017 at 12:23:13PM +0100, Chris Cottam wrote: > > I've got a project where being able to take COW copies of a VMs disc > > would be really useful (disc snapshots to be then archived off elsewhere) > > > > How stable is the the experimental reflinks feature and do you have any > > idea when it might be declared stable? > > I've got a customer that heavily uses (and tests) reflinks. They > initially found a few issues, but these days the QA teams finds > bugs in decade old XFS code but not related to reflinks.. > > You're mileage my vary, but I think we should be able to drop the > experimental tag now. I still have (at least) two unresolved questions before we drop the experimental tag on reflink -- First, should we land the incore extent map rework (not that I've seen a patchset yet) so that the increased extent map fragmentation resulting from cow/dedupe don't overwhelm the memory allocator with high order allocations? Incore extent map memory usage hasn't been an issue here... Second, regarding realtime + reflink: Right now we don't forbid mounting a filesystem with reflink enabled and a realtime device. You can't have an inode with both realtime and reflink flags set, so if future xfs supports it, old kernels won't totally stumble over those inodes. (Though, EFSCORRUPTED is a little rude.) Is that ok? or should we (a) make reflink work on realtime devices, (b) complain at mount time, or (c) leave everything the way it is? (The "root a metadata btree in an inode" series, which is the first half of realtime rmapbt, will enable us to create a refcount btree for the realtime device, though any reflink-capable realtime device also has a requirement that sb_rextsize <= page size unless we devise a mechanism to cow larger blocks, which is also problematic. I used to have a realtime reflink patch set but it died when we went to iomap and I haven't resurrected it.) --D > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 16:03 ` Darrick J. Wong @ 2017-08-29 16:23 ` Christoph Hellwig 2017-08-29 22:03 ` Dave Chinner 0 siblings, 1 reply; 10+ messages in thread From: Christoph Hellwig @ 2017-08-29 16:23 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Christoph Hellwig, Chris Cottam, linux-xfs On Tue, Aug 29, 2017 at 09:03:08AM -0700, Darrick J. Wong wrote: > First, should we land the incore extent map rework (not that I've seen a > patchset yet) so that the increased extent map fragmentation resulting > from cow/dedupe don't overwhelm the memory allocator with high order > allocations? Incore extent map memory usage hasn't been an issue here... Working on this now, but so far this hasn't been a major issue. The main workload where the extent list currently hurts and that prompted my work in this area doesn't even involve reflinks (sparse VM image). > Second, regarding realtime + reflink: Right now we don't forbid mounting > a filesystem with reflink enabled and a realtime device. You can't have > an inode with both realtime and reflink flags set, so if future xfs > supports it, old kernels won't totally stumble over those inodes. > (Though, EFSCORRUPTED is a little rude.) Is that ok? or should we (a) > make reflink work on realtime devices, (b) complain at mount time, or > (c) leave everything the way it is? I think the current situation is fine - if we add reflinks on the RT device we can just add a ROCOMPAT flag. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 16:23 ` Christoph Hellwig @ 2017-08-29 22:03 ` Dave Chinner 2017-08-30 7:03 ` Christoph Hellwig 2017-08-31 10:33 ` Chris Cottam 0 siblings, 2 replies; 10+ messages in thread From: Dave Chinner @ 2017-08-29 22:03 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Darrick J. Wong, Chris Cottam, linux-xfs On Tue, Aug 29, 2017 at 09:23:10AM -0700, Christoph Hellwig wrote: > On Tue, Aug 29, 2017 at 09:03:08AM -0700, Darrick J. Wong wrote: > > First, should we land the incore extent map rework (not that I've seen a > > patchset yet) so that the increased extent map fragmentation resulting > > from cow/dedupe don't overwhelm the memory allocator with high order > > allocations? Incore extent map memory usage hasn't been an issue here... > > Working on this now, but so far this hasn't been a major issue. > The main workload where the extent list currently hurts and that > prompted my work in this area doesn't even involve reflinks (sparse > VM image). Yup, that's a problem, and it's going to be even more of a problem once people start using reflink to snapshot sparse VM images. I think that the extent rework is probably the most important thing we need to solve for COW to be generally usable. Christoph, ignoring the CoW consideration, this is top of my list of "things we've been ignoring for too long that need to be fixed ASAP". I've got the time to work on this right now, so if you don't have time to get it done in the next merge cycle I can probably make that happen.... Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 22:03 ` Dave Chinner @ 2017-08-30 7:03 ` Christoph Hellwig 2017-08-31 10:33 ` Chris Cottam 1 sibling, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2017-08-30 7:03 UTC (permalink / raw) To: Dave Chinner; +Cc: Christoph Hellwig, Darrick J. Wong, Chris Cottam, linux-xfs On Wed, Aug 30, 2017 at 08:03:16AM +1000, Dave Chinner wrote: > Christoph, ignoring the CoW consideration, this is top of my list of > "things we've been ignoring for too long that need to be fixed > ASAP". I've got the time to work on this right now, so if you don't > have time to get it done in the next merge cycle I can probably make > that happen.... I've been working on it for a while, and it's not just spare time but customer work. I've finally found a data structure that fits, and I've already posted various cleanups to isolate the extent list. I'll have something ready to post in the next few weeks. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-29 22:03 ` Dave Chinner 2017-08-30 7:03 ` Christoph Hellwig @ 2017-08-31 10:33 ` Chris Cottam 2017-08-31 13:09 ` Christoph Hellwig 1 sibling, 1 reply; 10+ messages in thread From: Chris Cottam @ 2017-08-31 10:33 UTC (permalink / raw) To: Dave Chinner, Christoph Hellwig; +Cc: Darrick J. Wong, linux-xfs On 29/08/17 23:03, Dave Chinner wrote: > On Tue, Aug 29, 2017 at 09:23:10AM -0700, Christoph Hellwig wrote: >> On Tue, Aug 29, 2017 at 09:03:08AM -0700, Darrick J. Wong wrote: >>> First, should we land the incore extent map rework (not that I've seen a >>> patchset yet) so that the increased extent map fragmentation resulting >>> from cow/dedupe don't overwhelm the memory allocator with high order >>> allocations? Incore extent map memory usage hasn't been an issue here... >> >> Working on this now, but so far this hasn't been a major issue. >> The main workload where the extent list currently hurts and that >> prompted my work in this area doesn't even involve reflinks (sparse >> VM image). > > Yup, that's a problem, and it's going to be even more of a problem > once people start using reflink to snapshot sparse VM images. I > think that the extent rework is probably the most important thing we > need to solve for COW to be generally usable. Assuming I was feeling brave, what should I be doing to limit the chances of hitting this issue? Would smaller filesystems or lots of memory on the host help etc? Also what should I be monitoring to warn me before anything actually breaks? Thanks for the help so far. Chris ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: XFS reflinks 2017-08-31 10:33 ` Chris Cottam @ 2017-08-31 13:09 ` Christoph Hellwig 0 siblings, 0 replies; 10+ messages in thread From: Christoph Hellwig @ 2017-08-31 13:09 UTC (permalink / raw) To: Chris Cottam; +Cc: Dave Chinner, Christoph Hellwig, Darrick J. Wong, linux-xfs On Thu, Aug 31, 2017 at 11:33:44AM +0100, Chris Cottam wrote: > > Yup, that's a problem, and it's going to be even more of a problem > > once people start using reflink to snapshot sparse VM images. I > > think that the extent rework is probably the most important thing we > > need to solve for COW to be generally usable. > > Assuming I was feeling brave, what should I be doing to limit the > chances of hitting this issue? Would smaller filesystems or lots of > memory on the host help etc? > Also what should I be monitoring to warn me before anything actually breaks? Make sure you have memory compaction enabled is the best bet, don't run under crazy memory pressure. I've not actually seen an actual deadlock due to it, just the possible memory allocation deadlock warnings from kmem_alloc (and lots of those). ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2017-08-31 13:09 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-29 11:23 XFS reflinks Chris Cottam 2017-08-29 13:00 ` Christoph Hellwig 2017-08-29 13:39 ` Chris Cottam 2017-08-29 16:40 ` Christoph Hellwig 2017-08-29 16:03 ` Darrick J. Wong 2017-08-29 16:23 ` Christoph Hellwig 2017-08-29 22:03 ` Dave Chinner 2017-08-30 7:03 ` Christoph Hellwig 2017-08-31 10:33 ` Chris Cottam 2017-08-31 13:09 ` Christoph Hellwig
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.