From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28391C282C0 for ; Wed, 23 Jan 2019 17:06:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CE3A521855 for ; Wed, 23 Jan 2019 17:06:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="G54Ed2/a" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726279AbfAWRGL (ORCPT ); Wed, 23 Jan 2019 12:06:11 -0500 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:36536 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfAWRGK (ORCPT ); Wed, 23 Jan 2019 12:06:10 -0500 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 8F0998EE27B; Wed, 23 Jan 2019 09:06:09 -0800 (PST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3H4iM5LmBZ-7; Wed, 23 Jan 2019 09:06:09 -0800 (PST) Received: from [153.66.254.194] (unknown [50.35.68.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id E703C8EE02B; Wed, 23 Jan 2019 09:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1548263169; bh=IQnhYHscQeLDdiG9MTTzOYWlFyns9kqljgzUWLrltHo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=G54Ed2/aqrGbVSOajSEmTCZGY1wWL0I7FGVzcN/gXmGuoSXNbp0hz1caxnq+pvyW0 yJ2lmWiGuONID19DRCA6kppGvDTwuN+JQuHXWnu0NQZ7VsofDIj3A1NoMuZJwhF9cZ 3IDCh3j2fjI76b73WTN0R8CoH/Wym7r59HmUmH+4= Message-ID: <1548263167.2949.27.camel@HansenPartnership.com> Subject: Re: [LSF/MM TOPIC] Sharing file backed pages From: James Bottomley To: Amir Goldstein , lsf-pc@lists.linux-foundation.org Cc: Al Viro , "Darrick J. Wong" , Dave Chinner , Jan Kara , Matthew Wilcox , Chris Mason , Miklos Szeredi , linux-fsdevel , Linux MM Date: Wed, 23 Jan 2019 09:06:07 -0800 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, 2019-01-23 at 10:48 +0200, Amir Goldstein wrote: > Hi, > > In his session about "reflink" in LSF/MM 2016 [1], Darrick Wong > brought up the subject of sharing pages between cloned files and the > general vibe in room was that it could be done. This subject has been around for a while. We talked about cache sharing for containers in LSF/MM 2013, although it was as a discussion within a session rather than a session about it. At that time, Parallels already had an out of tree implementation of a daemon that forced this sharing and docker was complaining about the dual caching problem of their graph drivers. So, what we need in addition to reflink for container images is something like ksm for containers which can force read only sharing of pages that have the same content even though they're apparently from different files. This is because most cloud container systems run multiple copies of the same container image even if the overlays don't necessarily reflect the origin. Essentially it's the same reason why reflink doesn't solve the sharing problem entirely for VMs. James