From nobody Wed Oct 18 16:05:57 2023 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4S9bLT3lmdz4xD3T for ; Wed, 18 Oct 2023 16:06:09 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from mail.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 4S9bLS2CQhz4HYw for ; Wed, 18 Oct 2023 16:06:08 +0000 (UTC) (envelope-from martin@lispworks.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=lispworks.com header.s=default header.b=aTBa8Ht9; spf=pass (mx1.freebsd.org: domain of martin@lispworks.com designates 46.17.166.21 as permitted sender) smtp.mailfrom=martin@lispworks.com; dmarc=pass (policy=none) header.from=lispworks.com Received: from lwfs1-cam.cam.lispworks.com (localhost [[UNIX: localhost]]) by lwfs1-cam.cam.lispworks.com (8.16.1/8.16.1) with ESMTP id 39IG604m028166 for ; Wed, 18 Oct 2023 17:06:00 +0100 (BST) (envelope-from martin@lispworks.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lispworks.com; s=default; t=1697645160; bh=ccpir/71GoYAcdQOmVpFH0uEUn+duees12ErYif+ru4=; h=Date:From:To:CC:In-reply-to:Subject:References; b=aTBa8Ht9Z+yXMVvsChdg905spMm5suojCdMRGncrODN7HuBEdftCV8jbh4m1q/jj4 /RrEcLt8mYUafWhzGPG7e67mOTtaI4362tp8QHmFULjJOtSAebxDpKbrvkj5IGRtLI cbiV0UrEXk2ZyNwo2fmeUqhmYsk/M1rsAPT6rPMh1TeXZ98skCauMYmoMIlBRmR/tA RDhd2tddG1FhqR2+NzT/XqB4kMWgbzhk/3GhuRFEmNwXAH6RQ6k13D9/iIVD4iCjOP t+Qj+958yYT00dQLuw/yynhz+RncfAH1BgkonWacSAyq9HALour4Qt38k5/dt7Choa 393y7Bqi0qCSA== Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.16.1/8.16.1) with ESMTP id 39IG5vgc028146; Wed, 18 Oct 2023 17:05:57 +0100 (BST) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id 39IG5vmN007080; Wed, 18 Oct 2023 17:05:57 +0100 Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id 39IG5vYv007076; Wed, 18 Oct 2023 17:05:57 +0100 Date: Wed, 18 Oct 2023 17:05:57 +0100 Message-Id: <202310181605.39IG5vYv007076@higson.cam.lispworks.com> From: Martin Simmons To: void CC: freebsd-fs@freebsd.org In-reply-to: (message from void on Wed, 18 Oct 2023 13:58:12 +0100) Subject: Re: free space considerations writing bhyve image to a zvol References: X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.992]; DMARC_POLICY_ALLOW(-0.50)[lispworks.com,none]; R_DKIM_ALLOW(-0.20)[lispworks.com:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-fs@freebsd.org]; ARC_NA(0.00)[]; FREEMAIL_TO(0.00)[f-m.fm]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[lispworks.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[martin]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; ASN(0.00)[asn:51055, ipnet:46.17.160.0/21, country:GB] X-Rspamd-Queue-Id: 4S9bLS2CQhz4HYw List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org >>>>> On Wed, 18 Oct 2023 13:58:12 +0100, void said: > > A linux file-backed vm was created initially like this: > > truncate -s 2T linuxvm.img > > Within the vm, df -h reports 1.1Tb used in total. > Externally, on the freebsd host, the linuxvm.img is 2Tb. How did you measure this external size? The truncate command will create a file taking 0 bytes of space initially. You need to use du linuxvm.img on the host to see how much is being used at the moment. > If i write the vm to a 1.6Tb zvol with compression set (lz4), > would it be feasible to expect the vm to work? > > I expect it might break the vm's filesystem internally, > now, thinking about it. If the writing succeeds then I don't see how it would affect the vm's filesystem, because that just sees the same data regardless of how it is actually stored by the host. More interesting is what will happen if the vm's filesystem becomes fuller and the compressed size exceeds 1.6Tb. The host will report an error, but I don't know if the vm will handle it gracefully (it might see it as the equivalent of a disk write error). __Martin