From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <9front-bounces@9front.inri.net> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: from 9front.inri.net (9front.inri.net [168.235.81.73]) by inbox.vuxu.org (Postfix) with ESMTP id 07BB922060 for ; Mon, 6 May 2024 18:38:33 +0200 (CEST) Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Mon May 6 12:37:45 -0400 2024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1715013455; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=O87rtHVfqwpbpEdZHe1CFtvOgp/nr305JqAcHDDq1fw=; b=TP6HWF5tuPa/pmzVoD0CNUoQyFITBDL0V4WJd4XE+JnnhNoHH3+ZXLcAYfPePijoT1Lb6h Yb9gQQ9+rVeLuZhg+ovbsHgZu+coloq4xZ67NUbgYpU00VMhcYiVgUrwbEbA4C2dHLnNOE ACdwCd9B+plhNXQiA+QULes1VxgisBA= Received: from [192.168.168.200] ( [207.45.82.38]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id afa53ab5 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Mon, 6 May 2024 11:37:34 -0500 (CDT) Message-ID: Date: Mon, 6 May 2024 11:37:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: 9front@9front.org References: <944CC9D807FB7E302CDDB114CBE15BD0@wopr.sciops.net> <73EDEC59-DF58-4D74-A2C8-B2090C47F579@stanleylieber.com> <33bdda90-6291-4405-9e7e-818062c53110@sirjofri.de> <230238EB-7CE3-41CE-B50E-8140DA74D45B@stanleylieber.com> Content-Language: en-US From: Jacob Moody In-Reply-To: <230238EB-7CE3-41CE-B50E-8140DA74D45B@stanleylieber.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: open flexible hardware ORM standard configuration-oriented locator Subject: Re: [9front] Re: [9front] cwfs no-worm + venti Reply-To: 9front@9front.org Precedence: bulk On 5/6/24 11:21, Stanley Lieber wrote: > On May 6, 2024 12:08:03 PM EDT, sirjofri wrote: >> Hello, >> >> did anyone ever try to run a cwfs without worm and a venti? >> >> Here's my thought: >> >> - Public accessible VPS with just cwfs, no worm >> - local/on-site, non-public-accessible, not-always-available venti server for backups/dumps >> >> Those dumps could happen manually. The benefit would be that a small local server is cheap and doesn't have to run all the time, so that would be one of the cheapest worms possible. You'd get the benefit of that worm, plus the convenience of a non-worm partition on the server. >> >> It could also be extended by running the cwfs+worm combination on the local server, and the publicly accessible VPS would only need a cfs. >> >> That's only theory. I never actually used venti in any way, and my fossil days are a long time ago. Let me know what you think. >> >> sirjofri >> > > i'd be willing to try it out. > > one problem with the advice i promised to give my younger self: the default cwfs already creates an other partition for storing un-dumped files. but with constrained disk space (vm prices increase steeply for huge ssd storage), we never have enough room to make the worm large enough AND make other large enough to do our business. it's easy to fill a "small" worm even with just normal system churn. and other is useless if it's small. > > right now, 9front.org and cat-v.org live on separate servers, each one a 60gb cwfs with no dump. 9front.org has plenty of room, but all the cat-v.org stuff has a lot more files and hovers at over 50gb usage. if i'd set this up with a worm i'd already be fucked, but the way things are now i could conceivably just move some sites around and delete files off the existing installation. fortunately, the cat-v.org stuff is relatively static, so it's not a real emergency. > > sl Another dimension I want to add here is bls's devsnap. I talked about this on jitsi but never more public. Last year's IWP9 had bls present his devsnap kernel device. I have had thoughts of trying it out underneath a no-dump cwfs. That would have manual only snapshots at more of the block layer, which I think would make it a bit easier to migrate The issue is that cwfs is not aware of this, so to do this "properly" you would need to make some modifications to cwfs, and at which point are we just reinventing the worm. The benefit here would just be the manual snapshot timing combined with there only being "one pool" so to say. Gefs also addresses these issues depending on how brave someone is feeling. I've got the latest code from bls and it does compile in 9front without any modifications, but likely needs some effort put in to more properly integrating. Thanks, moody