From owner-freebsd-fs@freebsd.org Thu Apr 20 16:12:54 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77DC0D4825E for ; Thu, 20 Apr 2017 16:12:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAA2164B for ; Thu, 20 Apr 2017 16:12:54 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi0-x232.google.com with SMTP id x184so57452764oia.1 for ; Thu, 20 Apr 2017 09:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3ZelR0FV5ngrRPAzmpbiiLxHYnAYWXPkic6IaRfxnJ0=; b=UTFzmwlN8SwV7yNdTYBhG0UYWQP9xp8w9nZGVXJg4Et8tc6/wDpXnZuwET9vcy1kpc GjQuOM+bvvmYv9CZGvS9derQMvrTsdgRcDcSE1PHnVHHLg/vaFQRBuHfDtZlUyU6sXHU +p8azgR1ca709v3UoWXcYcb6KLG1iqg11SWGDhFgeTR08/aLQOJ7SsbX4zrZlPUIRT6s i0lP3NLGKM+YRebCv5IUjwRCSiI1dWArSYmHPaVYGjmmGKVNibELotvWc5nGraEMKzrm MTnKv7sw1fxeP2FWGG1zGCMbPM9mPLiq7m3JhsD18V8Ljd5A2yA26AQTxyhwPS8uq1u8 bh1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3ZelR0FV5ngrRPAzmpbiiLxHYnAYWXPkic6IaRfxnJ0=; b=ItmOQlLKSmfkyBgndWzNw8FT/LEUtPJNX46cDmdzPXuPy5tHd5CetoTxIeNrp85opV dpPb29cUYr7//qXlKLqp0ZHzdSNHM2juNRw2jxINhYuea7iQT+ueyJrgLTjtyxACOWOA w+X35kwEN/fH8ZeBb5GqtRnz4MOuTkBYktB3yh93cit3JeF7loD5BnU+A9cVG8Hb3dqq vTX4ryj3X8PRz5zFwvSDlGnUhT8Grd00QVdUzC2SYutQs5KoDM0FY3M5UtrgPAFB/uME 5o4kNlBnrRVcDcPFBqFTbdW/RvkDOoJq0YrSCKwBPHfqDf0/ro30QRo5OMQwianJHTg0 hQIA== X-Gm-Message-State: AN3rC/6FH1fj3h+dDjd/feyL6co5xDrxDXKYoRvts7xqvF8zkMH8mSFo xrF+LEgdxYiPRvZmVHfBVnnlDZnfirR4 X-Received: by 10.36.85.148 with SMTP id e142mr4850445itb.106.1492704773414; Thu, 20 Apr 2017 09:12:53 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.102.193 with HTTP; Thu, 20 Apr 2017 09:12:52 -0700 (PDT) In-Reply-To: <201704201431.v3KEVN59061503@chez.mckusick.com> References: <201704201431.v3KEVN59061503@chez.mckusick.com> From: Maxim Sobolev Date: Thu, 20 Apr 2017 09:12:52 -0700 X-Google-Sender-Auth: HNE8SnvbiIgLFzj_5aN-UnmJXns Message-ID: Subject: Re: UFS snapshot "file" is slightly bigger than underlying disk partition To: Kirk McKusick Cc: FreeBSD Filesystems Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 16:12:54 -0000 Is it possible to hide it somehow from the external view then by any chance? If nothing else, there are some reserved areas for boot code for example and such in the on-disk format as far as I know. What I am interested here is just making compressed image of the FS with the mkuzip, but since the snapshot has some extra bytes at the end, what I am getting is not 1:1 replica, but it now has an extra unwanted block(s) at the end. I can obviously tweak mkuzip to have ability to ignore trailing XXX bytes, but IMHO that would better to be handled in the UFS code. -Max On Thu, Apr 20, 2017 at 7:31 AM, Kirk McKusick wrote: > > From: Maxim Sobolev > > Date: Thu, 20 Apr 2017 02:39:12 -0700 > > Subject: UFS snapshot "file" is slightly bigger than underlying disk > partition > > To: FreeBSD Filesystems , > > Kirk McKusick > > > > Hi Kirk, > > > > I've noticed that the snapshot file is slightly bigger than underlying > disk > > partition. First I thought it's some kind of header attached to the end, > > but the size of difference is actually dependent on the disk size. Is it > by > > design, or some sort of "off by x" error? What's annoying about that is > > that the size is not multiple of SECTOR_SIZE. Also looks like if I just > cut > > that junk out resulting FS image is just as usable. > > > > Attached script illustrates that. The first column is size of the > > partition, the second column is the size of the difference, both in > bytes. > > > > 1048576 48 > > 2097152 56 > > 4194304 72 > > 8388608 72 > > 16777216 72 > > 33554432 72 > > 67108864 72 > > 134217728 72 > > 268435456 72 > > 536870912 72 > > 1073741824 72 > > 2147483648 72 > > 4294967296 96 > > 8589934592 152 > > 17179869184 256 > > 34359738368 464 > > 68719476736 880 > > 137438953472 1720 > > 274877906944 3392 > > 549755813888 6744 > > > > Please advise, thanks. > > > > -Max > > (P.S. This is 11.0-RELEASE-p9) > > The extra space is for auxilary information that is used to track > changes made in the snapshot. Removing it will cause your snapshot > maintainance to slow down by 10-100x and in the worst case can > cause it to become corrupt. In short, don't mess with it. > > Kirk McKusick > >