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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5141C433EF for ; Mon, 27 Sep 2021 13:06:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CEFF960EC0 for ; Mon, 27 Sep 2021 13:06:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234445AbhI0NI0 (ORCPT ); Mon, 27 Sep 2021 09:08:26 -0400 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:55091 "EHLO wout4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230089AbhI0NI0 (ORCPT ); Mon, 27 Sep 2021 09:08:26 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CCD4E3200BF9; Mon, 27 Sep 2021 09:06:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 27 Sep 2021 09:06:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=/ GKVm9aT1QMpB/PByfoVomF5FC+99BMfJqPbdonFHp4=; b=YS1kiQTMUOFzQSTzT Kfv2rv7W/w1qHoGhCyLgmR7ixr5gyB3NmITvwsC9YmAhiS3omMnq75e5+Z1Yw7rY BkJ+aHrBO0RTxtFNaVHs4FN7vBKy18hd4BrIjnHz0Fl3lm7JQ0YRVrm4rvI44IaY BK/HkB5FJgwkv9uNRchLwjpsyh0uWLbhbUCftEAK81sdtthaxmOyumNGwp1u4fek l4yppv7tjT+Ep4PI8kShCuTD0A6IeM83o+x6+vFSF0Y0FNNRY5ygNH6mGAJUp6um 9p5TqXIxtBNCislqinmGEqqj0VoSaPXLHBpgChg4SE4TqyX4W7DYm2XMr7u0fvHL 2OpNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/GKVm9aT1QMpB/PByfoVomF5FC+99BMfJqPbdonFH p4=; b=K25pBMePdTG4j5ulgG0Vgs0SXd5RIo28O7/AK+XLgMlHWqVJSJrBK0J3a Y+9sedgG2LQE+gTFTaNcapB31/3S2BOkXpw8UPeaLI+8BJpsrZXSsxg4FSrgrAsp +nc4Pu1aDMaZjkMRb0zQ+q0GlxEDo6PhQbeZIGaELsTxhaAQ+vp+fCkaeYzb30lI D2sNpCm4aVPH0dPjmKOQ08cVI9Ev7Df7p/udHMo+quw/AN1EhoHu6ozhokW++w39 em4dCu4wQECwdl6vPJEIqR0rtNct1k75LzdWU0ln5eR9VDJlxFkw7sGgzFC73FRk C6pLrJ0/WT/nbhFLP77R2YyeWlZZQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejkedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepuegvrhhn ugcuufgthhhusggvrhhtuceosggvrhhnugdrshgthhhusggvrhhtsehfrghsthhmrghilh drfhhmqeenucggtffrrghtthgvrhhnpeduhfdvuefgieejueekjefhieeuffeigfdtvedu ledutdejtdehueegfedugeduueenucffohhmrghinhepsggtrggthhgvfhhsrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsggvrhhn ugdrshgthhhusggvrhhtsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Sep 2021 09:06:46 -0400 (EDT) Subject: Re: bcachefs - snapshots To: Kent Overstreet , linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org, linux-fsdevel@vger.kernel.org References: From: Bernd Schubert Message-ID: Date: Mon, 27 Sep 2021 15:06:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-bcachefs@vger.kernel.org On 9/27/21 3:49 AM, Kent Overstreet wrote: > Snapshots have been merged! 9 months of work and 3k lines of new code, finally > released. Some highlights: > > - btrfs style subvolumes & snapshots interface > - snapshots are writeable > - highly scalable: number of snapshots is limited only by your disk space > - highly space efficient: no internal fragmentation issues > > Design doc here: https://bcachefs.org/Snapshots/ > > The core functionality is complete - snapshot creation and deletion works, fsck > changes are done (most of the complexity was in making fsck work without > O(number of snapshots) performance - tricky). Everything else is a todo item: > > - still need to export different st_dev for files in different subvolumes > (we'll never allocate a new inode with an inode number that collides with an > inode inother subvolume - but snapshots will naturally result in colliding > inode numbers) With my limited high level view on it - shouldn't you discuss with Neil about a solution and to avoid going the btrfs route for colliding inode numbers?