Re: [9front] Re: [9front] cwfs no-worm + venti

[Jacob Moody <moody@posixcafe.org>]

On 5/6/24 11:21, Stanley Lieber wrote:
> On May 6, 2024 12:08:03 PM EDT, sirjofri <sirjofri+ml-9front@sirjofri.de> 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