Re: [9fans] fossil

Noam Preil: > I have a > branch at https://git.sr.ht/~pixelherodev/plan9 which has fossil > integrated. I took the liberty of having a look at the fossil source in that repo. It seems to be missing the fossil-time-backward patch. That's on the current 9legacy distribution ISO (built 14 April

Re: [9fans] fossil [was: List of companies that use Plan 9.]

Indeed, the coupling is moderately loose (I found one constant shared in the code I compiled for 9front - Fossil from somewhere, probably p9p, but maybe not - the 56000-byte Venti block size, I believe). But Fossil without Venti is a much less valuable component, as I understand it. And Fossil

Re: [9fans] fossil [was: List of companies that use Plan 9.]

Fossil will run without venti, but the moment you connect it to a venti, it cannot be standalone again, as it stands. On Sat, 18 May 2024 at 14:50, Lucio De Re wrote: > Please include me as well. I have an unambitious plan I would like to > experiment with. And the most advanced version of

Re: [9fans] fossil [was: List of companies that use Plan 9.]

Please include me as well. I have an unambitious plan I would like to experiment with. And the most advanced version of Fossil would fit nicely into that. Also, am I mistaken in believing that in all of 9legacy, 9front and p9p, Fossil and Venti need to be treated as a bundle, possibly starting

Re: [9fans] fossil [was: List of companies that use Plan 9.]

Just a simple note. When I compared the fossil version posted by Moody in the original discussion thread to the one I am using (and IIRC  it is the one in the 9legacy git repository), I found that they differed in 2 points. One was the increase of a msg buffer, which is probably no big issue,

Re: [9fans] fossil [was: List of companies that use Plan 9.]

> Responding off list shortly :) I'd like to be included into the discussion as well. Thanks. -- David du Colombier -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M789b993f6eb5e311f7e78821 Delivery options:

Re: [9fans] fossil [was: List of companies that use Plan 9.]

Responding off list shortly :) -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T6b867aa3be7bf660-M3fe517cc779e245e44a024b1 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] fossil [was: List of companies that use Plan 9.]

Noam Preil: > I demonstrated one > of the problems with fossil by (attempting to) install Go, which crashes > the file system _every single time_. This is a useful bit of evidence that needs following up. The go test suite (which begins by installing and completely rebuilding go) is running 24/7

Re: [9fans] fossil+venti vs. cwfs - dealing with backups

The easiest method with cwfs or Ken's is to keep track of the size of the WORM - since everything is appended, it's fairly simple to copy the set of blocks after each dump. It's been a few years since I've done this, but it is just as reliable as venti, albeit less convenient. On Mon, Apr 16,

[9fans] fossil+venti vs. cwfs - dealing with backups

What has kept me running fossil+venti is the ease of backing up the file server. Copying the venti arenas offsite is trivial. And Geoff put together glue to write sealed arenas to blu-ray as well. I don't see any simple way to do that with cwfs*. Or hjfs. I am very curious to know how the

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

Hi Jim, It's important to point out that the arena size does not have to match the size of an arenas file. In my case, I do something similar where I use 2GB for an arena but keep my arenas files at 2GB (I don't have much use for keeping multiple arena files). More indexes help to an extent. My

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

On Wed, Oct 19, 2016 at 9:47 AM Steven Stallion wrote: > In short, start small and grow as needed. For reference, when I ran > Coraid's fs based on 64-bit Ken's (WORM only, no dedupe) in RWC > (based on the main fs in Athens). Over the course of a few years > the entire WORM

[9fans] fossil vs. fossil+venti in 9atom installation?

I was looking over the 9atom install script and I saw it appeared to code in support for building filesystems based on kfs, fossil, or fossil+venti, but it only surfaced kfs and fossil+venti. I was wondering why that was. Does anyone know? Jim

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

i agree absolutely with steve here, expanding venture arena by arena is easy, the ventibackup scripts show you how. even easier is to add arenas on a different disk partition to the same venti. personally i wouldn't keep music or videos in venti. they don't compress well using the arithmetic

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

> On 20 Oct 2016, at 19:41, Steven Stallion wrote: > >> On Thu, Oct 20, 2016 at 1:15 PM, wrote: >> Steven Stallion writes: >> >>> Sizing venti is also simple. >> >> I disagree with this. The best way to

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

On Thu, Oct 20, 2016 at 1:15 PM, wrote: > Steven Stallion writes: > >> Sizing venti is also simple. > > I disagree with this. The best way to configure venti depends largely > on how you plan to use it. I have multiple venti servers

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

"James A. Robinson" writes: > Anyone able to tell me whether or not there are > disk size limits I should beware of given a limited > amount of system memory in a file server? Although there have been some replies on this thread, none of them have really yet directly

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

Steven Stallion writes: > Sizing venti is also simple. I disagree with this. The best way to configure venti depends largely on how you plan to use it. I have multiple venti servers configured for different uses. For example, I keep my DVD images on a different venti

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

On Wed, Oct 19, 2016 at 10:13 AM Aram Hăvărneanu wrote: > There are cheaper ways of disposing of 10TB of data. > If I decide the configuration is problematic I'm sure I can repurpose the device. Besides, the costs of spinning disk these days is amazingly low. As, I think, the

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

Hi Jim, It probably helps to break apart fossil and venti for the sake of the conversation. While you can use fossil as a standalone filesystem, it is effectively your write cache in this scenario since it will be backed by venti. Conventional wisdom is to size your main fossil fs based on how

Re: [9fans] Fossil+Venti system memory requirements to be aware of?

There are cheaper ways of disposing of 10TB of data. -- Aram Hăvărneanu

[9fans] Fossil+Venti system memory requirements to be aware of?

Anyone able to tell me whether or not there are disk size limits I should beware of given a limited amount of system memory in a file server? What I'm wanting to try and do is get a hardware RAID1+0 enclosure and put in 20TB of disk (so 10TB of usable space). The board I am looking at will take

Re: [9fans] fossil+venti performance question

* the SYN-ACK needs to send the local mss, not echo the remote mss. asymmetry is fine in the other side, even if ip/tcp.c isn't smart enough to keep tx and rx mss seperate. (scare quotes = untested, there may be some performance niggles if the sender is sending legal packets larger than

Re: [9fans] fossil+venti performance question

2.a) tcpiput() gets a ACK packet for Listening connection, calls tcpincoming(). 2.b) tcpincoming() looks in limbo, finds lp. and makes new connection. 3.c) initialize our connections tcb-mss. * the setting of tcb-mss in tcpincoming is not correct, tcp-mss is set by SYN, not by ACK, and

Re: [9fans] fossil+venti performance question

how is this the opposite? your patch shows the tcb-mss init being removed completely from tcpincoming(). - /* our sending max segment size cannot be bigger than what he asked for */ - if(lp-mss != 0 lp-mss tcb-mss) { - tcb-mss = lp-mss; -

Re: [9fans] fossil+venti performance question

On Sun May 10 14:36:15 PDT 2015, cinap_len...@felloff.net wrote: how is this the opposite? your patch shows the tcb-mss init being removed completely from tcpincoming(). - /* our sending max segment size cannot be bigger than what he asked for */ - if(lp-mss != 0 lp-mss

Re: [9fans] fossil+venti performance question

On Sun May 10 10:58:55 PDT 2015, 0in...@gmail.com wrote: however, after fixing things so the initial cwind isn't hosed, i get a little better story: so, actually, i think this is the root cause. the intial cwind is misset for loopback. i but that the symptom folks will see is that

Re: [9fans] fossil+venti performance question

however, after fixing things so the initial cwind isn't hosed, i get a little better story: so, actually, i think this is the root cause. the intial cwind is misset for loopback. i but that the symptom folks will see is that /net/tcp/stats shows fragmentation when performance sucks.

Re: [9fans] fossil+venti performance question

however, after fixing things so the initial cwind isn't hosed, i get a little better story: so, actually, i think this is the root cause. the intial cwind is misset for loopback. i but that the symptom folks will see is that /net/tcp/stats shows fragmentation when performance sucks.

Re: [9fans] fossil+venti performance question

2015-05-09 10:35 GMT-07:00 Lyndon Nerenberg lyn...@orthanc.ca: On May 9, 2015, at 10:30 AM, Devon H. O'Dell devon.od...@gmail.com wrote: Or when your client is on a cell phone. Cell networks are the worst. Really? Quite often I slave my laptop to my phone's LTE connection, and I never

Re: [9fans] fossil+venti performance question

for what it's worth, the original newreno work tcp does not have the mtu bug. on a 8 processor system i have around here i get bwc; while() nettest -a 127.1 tcp!127.0.0.1!40357 count 10; 81920 bytes in 1.505948 s @ 519 MB/s (0ms) tcp!127.0.0.1!47983 count 10; 81920 bytes in

Re: [9fans] fossil+venti performance question

yes, but i was not refering to the adjusting which isnt changed here. only the tcpmtu() call that got added. yes, it *should* not make any difference but maybe we'r missing something. at worst it makes the code more confusing and cause bugs in the future because one of the initializations of mss

Re: [9fans] fossil+venti performance question

On Fri May 8 20:12:57 PDT 2015, cinap_len...@felloff.net wrote: do we really need to initialize tcb-mss to tcpmtu() in procsyn()? as i see it, procsyn() is called only when tcb-state is Syn_sent, which only should happen for client connections doing a connect, in which case tcpsndsyn() would

Re: [9fans] fossil+venti performance question

On Fri May 8 20:12:57 PDT 2015, cinap_len...@felloff.net wrote: do we really need to initialize tcb-mss to tcpmtu() in procsyn()? as i see it, procsyn() is called only when tcb-state is Syn_sent, which only should happen for client connections doing a connect, in which case tcpsndsyn() would

Re: [9fans] fossil+venti performance question

Looking at the first few bytes in each dir of the initial TCP handshake (with tcpdump) I see: 0x: 4500 0030 24da = from plan9 to freebsd 0x: 4500 0030 d249 4000 = from freebsd to plan9 Looks like FreeBSD always sets the DF (don't fragment) bit (0x40 in

Re: [9fans] fossil+venti performance question

2015-05-09 10:25 GMT-07:00 Lyndon Nerenberg lyn...@orthanc.ca: On May 9, 2015, at 7:43 AM, erik quanstrom quans...@quanstro.net wrote: easy enough until one encounters devices that don't send icmp responses because it's not implemented, or somehow considered secure that way. Oddly

Re: [9fans] fossil+venti performance question

On May 9, 2015, at 7:43 AM, erik quanstrom quans...@quanstro.net wrote: easy enough until one encounters devices that don't send icmp responses because it's not implemented, or somehow considered secure that way. Oddly enough, I don't see this 'problem' in the real world. And FreeBSD is far

Re: [9fans] fossil+venti performance question

On May 9, 2015, at 10:30 AM, Devon H. O'Dell devon.od...@gmail.com wrote: Or when your client is on a cell phone. Cell networks are the worst. Really? Quite often I slave my laptop to my phone's LTE connection, and I never have problems with PMTU. Both here (across western Canada) and in

Re: [9fans] fossil+venti performance question

On May 9, 2015, at 10:25 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On May 9, 2015, at 7:43 AM, erik quanstrom quans...@quanstro.net wrote: easy enough until one encounters devices that don't send icmp responses because it's not implemented, or somehow considered secure that way.

Re: [9fans] fossil+venti performance question

do we really need to initialize tcb-mss to tcpmtu() in procsyn()? as i see it, procsyn() is called only when tcb-state is Syn_sent, which only should happen for client connections doing a connect, in which case tcpsndsyn() would have initialized tcb-mss already no? tcb-mss may still need to

Re: [9fans] fossil+venti performance question

I've enabled tcp, tcpwin and tcprxmt logs, but there isn't anything very interesting. tcpincoming s 127.0.0.1!53150/127.0.0.1!53150 d 127.0.0.1!17034/127.0.0.1!17034 v 4/4 Also, the issue is definitely related to the loopback. There is no problem when using an address on /dev/ether0. cpu% cat

Re: [9fans] fossil+venti performance question

On 8 May 2015 at 17:13, David du Colombier 0in...@gmail.com wrote: Also, the issue is definitely related to the loopback. There is no problem when using an address on /dev/ether0. oh. possibly the queue isn't big enough, given the window size. it's using qpass on a Queue with Qmsg and if the

Re: [9fans] fossil+venti performance question

I've finally figured out the issue. The slowness issue only appears on the loopback, because it provides a 16384 MTU. There is an old bug in the Plan 9 TCP stack, were the TCP MSS doesn't take account the MTU for incoming connections. I originally fixed this issue in January 2015 for the Plan 9

Re: [9fans] fossil+venti performance question

On Fri, 08 May 2015 21:24:13 +0200 David du Colombier 0in...@gmail.com wrote: On the loopback medium, I suppose this is the opposite issue. Since the TCP stack didn't fix the MSS in the incoming connection, the programs sent multiple small 1500 bytes IP packets instead of large 16384 IP

Re: [9fans] fossil+venti performance question

I confirm - my old performance is back. Thanks very much David. -Steve

Re: [9fans] fossil+venti performance question

do we really need to initialize tcb-mss to tcpmtu() in procsyn()? as i see it, procsyn() is called only when tcb-state is Syn_sent, which only should happen for client connections doing a connect, in which case tcpsndsyn() would have initialized tcb-mss already no? -- cinap

Re: [9fans] fossil+venti performance question

NOW is defined as MACHP(0)-ticks, so this is a pretty course timer that can't go backwards on intel processors. this limits the timer's resolution to HZ, which on 9atom is 1000, and 100 on pretty much anything else. further limiting the resolution is the tcp retransmit timers which

Re: [9fans] fossil+venti performance question

cpu% cat /net/tcp/3/local 127.0.0.1!57796 cpu% cat /net/tcp/3/remote 127.0.0.1!17034 cpu% cat /net/tcp/3/status Established qin 0 qout 0 rq 0.0 srtt 80 mdev 40 sst 1048560 cwin 258192 swin 10485604 rwin 10485604 qscale 4 timer.start 10 timer.count 10 rerecv 0 katimer.start 2400

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 22:28, David du Colombier 0in...@gmail.com wrote: Since the problem only happen when Fossil or vacfs are running on the same machine as Venti, I suppose this is somewhat related to how TCP behaves with the loopback. Interesting. That would explain the clock-like delays.

Re: [9fans] fossil+venti performance question

Definitely interesting, and explains why I've never seen the regression (I switched to a dedicated venti server a couple of years ago). Were these the changes that erik submitted? ISTR him working on reno bits somewhere around there... On Wed, May 6, 2015 at 4:28 PM, David du Colombier

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 23:35, Steven Stallion sstall...@gmail.com wrote: Were these the changes that erik submitted? I don't think so. Someone else submitted a different set of tcp changes independently much earlier.

Re: [9fans] fossil+venti performance question

Just to be sure, I tried again, and the issue is not related to the lock change on 2013-09-19. However, now I'm sure the issue was caused by a kernel change in 2013. There is no problem when running a kernel from early 2013. -- David du Colombier

Re: [9fans] fossil+venti performance question

Since the problem only happen when Fossil or vacfs are running on the same machine as Venti, I suppose this is somewhat related to how TCP behaves with the loopback. -- David du Colombier

Re: [9fans] fossil+venti performance question

On 6 May 2015 at 21:55, David du Colombier 0in...@gmail.com wrote: However, now I'm sure the issue was caused by a kernel change in 2013. There is no problem when running a kernel from early 2013. Welly, welly, welly, well. That is interesting.

Re: [9fans] fossil+venti performance question

I got it! The regression was caused by the NewReno TCP change on 2013-01-24. https://github.com/0intro/plan9/commit/e8406a2f44 -- David du Colombier

Re: [9fans] fossil+venti performance question

On Wed May 6 15:30:24 PDT 2015, charles.fors...@gmail.com wrote: On 6 May 2015 at 22:28, David du Colombier 0in...@gmail.com wrote: Since the problem only happen when Fossil or vacfs are running on the same machine as Venti, I suppose this is somewhat related to how TCP behaves with the

Re: [9fans] fossil+venti performance question

On Tue May 5 15:54:45 PDT 2015, ara...@mgk.ro wrote: It's pretty interesting that at least three people all got exactly 150kB/s on vastly different machines, both real and virtual. Maybe the number comes from some tick frequency? i might suggest altering HZ and seeing if there is a throughput

Re: [9fans] fossil+venti performance question

On Wed May 6 14:28:03 PDT 2015, 0in...@gmail.com wrote: I got it! The regression was caused by the NewReno TCP change on 2013-01-24. https://github.com/0intro/plan9/commit/e8406a2f44 if you have proof, i'd be interested in reproduction of the issue from the original source, or perhaps

Re: [9fans] fossil+venti performance question

It's pretty interesting that at least three people all got exactly 150kB/s on vastly different machines, both real and virtual. Maybe the number comes from some tick frequency? -- Aram Hăvărneanu

Re: [9fans] fossil+venti performance question

Thanks Anthony. I bet if you re-run the same test twice in a row, you’re going to see dramatically improved performance. I try to re-run ‘iostats md5sum /386/9pcf’. Read result is very fast. first read result is 152KB/s. second read result is 232MB/s. Your write performance in that test

Re: [9fans] fossil+venti performance question

Thanks Aram. I have spent some time debugging this, but unfortunately, I couldn't find the root cause, and I just stopped using fossil. I tried to measure performance effect by replacement of component. 1) mbr or GRUB 2) pbs or pbslba 3) sdata or sdvirtio (sdvirtio is imported from 9legacy)

Re: [9fans] fossil+venti performance question

I too see this, and feel, no proof, that things used to be better. I.e. the first time I read a file from venti it it very, very slow. subsequent reads from the ram cache are quick. I think venti used to be faster a few years ago. maybe another effect of this is the boot time seems slower than

Re: [9fans] fossil+venti performance question

Hello! imho placing fossil, venti, isect, bloom and swap on single drive is bad idea. As written in in http://plan9.bell-labs.com/sys/doc/venti/venti.html - The prototype Venti server is implemented for the Plan 9 operating system in about 10,000 lines of C. The server runs on a dedicated dual

Re: [9fans] fossil+venti performance question

On 4 May 2015 at 19:51, David du Colombier 0in...@gmail.com wrote: I've just made some measurements when reading a file: Vacfs running on the same machine as Venti: 151 KB/s Vacfs running on another machine: 5131 KB/s How many times do you time it on each machine?

Re: [9fans] fossil+venti performance question

I've just made some measurements when reading a file: Vacfs running on the same machine as Venti: 151 KB/s Vacfs running on another machine: 5131 KB/s How many times do you time it on each machine? Maybe ten times. The results are always the same ~5%. Also, I restarted vacfs between each

Re: [9fans] fossil+venti performance question

Yes, I'm pretty sure it's not related to Fossil, since it happens with vacfs as well. Also, Venti was pretty much unchanged during the last few years. I suspected it was related to the lock change on 2013-09-19. https://github.com/0intro/plan9/commit/c4d045a91e But I remember I tried to revert

Re: [9fans] fossil+venti performance question

On 5 May 2015 at 16:38, David du Colombier 0in...@gmail.com wrote: How many times do you time it on each machine? Maybe ten times. The results are always the same ~5%. Also, I restarted vacfs between each try. It was the effect of the ram caches that prompted the question. My experience

Re: [9fans] fossil+venti performance question

I too see this, and feel, no proof, that things used to be better. I.e. the first time I read a file from venti it it very, very slow. subsequent reads from the ram cache are quick. I think venti used to be faster a few years ago. maybe another effect of this is the boot time seems slower

[9fans] fossil+venti performance question

Hello, fans. I’m running Plan 9(labs) on public QEMU/KVM service. My Plan 9 system has a slow read performance problem. I ran 'iostats md5sum /386/9pcf’, DMA is on, read result is 150KB/s. but write performance is fast. My Plan 9 system has a 200GB HDD, formatted with fossil+venti. disk layout

Re: [9fans] fossil+venti performance question

The reason, in general: In a fossil+venti setup, fossil runs (basically) as a cache for venti. If your access just hits fossil, it’ll be quick; if not, you hit the (significantly slower) venti. I bet if you re-run the same test twice in a row, you’re going to see dramatically improved performance.

Re: [9fans] fossil+venti performance question

I'm experiencing the same issue as well. When I launch vacfs on the same machine as Venti, reading is very slow. When I launch vacfs on another Plan 9 or Unix machine, reading is fast. I've just made some measurements when reading a file: Vacfs running on the same machine as Venti: 151 KB/s

[9fans] fossil memory corruption

small but potentially deadly diff -c /n/dump/2014/0402/sys/src/cmd/fossil/9fsys.c 9fsys.c /n/dump/2014/0402/sys/src/cmd/fossil/9fsys.c:34,40 - 9fsys.c:34,40 char* curfsys; } sbox; - static char *_argv0; + char *_argv0; #define argv0 _argv0 static char FsysAll[] = all;

Re: [9fans] fossil memory corruption

i should explain further, since this is sneaky. since we're calling ARGBEGIN lots of times, we hit a special case. the defn is #define ARGBEGINfor((argv0||(argv0=*argv)),argv++,argc--;\ a subsequent call to ARGBEGIN will not reset argv0, and worse, argv0 can be pointing to bogus

Re: [9fans] Fossil disk usage over 100%?

In article 20130603202129.ga84...@intma.in, kh...@intma.in says... On Mon, Jun 03, 2013 at 03:41:39PM -0400, erik quanstrom wrote: which is to say that the thesis that fossil sucks is refuted. - erik *now* I know what you guys meant by 'snarky comments.' Just the place for some

Re: [9fans] Fossil disk usage over 100%?

Richard mentioned fixing the snapshots bug in fossil. This is about as close as we've come to examining the technical issues. No: this *is* examining the technical issues. Richard has done actual engineering here; it's moderately depressing that many members of this list, and particularly

Re: [9fans] Fossil disk usage over 100%?

Richard mentioned fixing the snapshots bug in fossil. This is about as close as we've come to examining the technical issues. No: this *is* examining the technical issues. Richard has done actual engineering here; it's moderately depressing that many members of this list, and particularly

Re: [9fans] Fossil disk usage over 100%?

Long-haul airlines can appear to have better safety statistics than local services, because they spend proportionately more flying hours in a straight-and-level steady state than in takeoff and landing where most accidents occur. Similarly someone who has used fossil as a production system over

Re: [9fans] Fossil disk usage over 100%?

if one dedicates a machine (or vm) to the file server, than one can be sure that punting the cpu server will leave one's files available and bugs in the cpu server won't leak over. There's also a security advantage to reducing the amount of extra stuff running on the same machine as the file

Re: [9fans] Fossil disk usage over 100%?

I see that in this thread we've made progress: someone has admitted that fossil _used_to_be_ unreliable. (I expect even this assault on the sanctity of fossil will now be repelled.) I think not. The archive bug was well known, and you'll find several conversations about it over the years

Re: [9fans] Fossil disk usage over 100%?

On 3 June 2013 12:49, Kurt H Maier kh...@intma.in wrote: I *know* fossil has had problems, because I've lost data to it. Once a bug kills my data, that software doesn't land on my computer again, full stop. Sure. But I've lost nothing with fossil and I did indeed lose things with the old

Re: [9fans] Fossil disk usage over 100%?

The point I was making that it's amusing how much effort goes into the annual fossil does NOT suck! parade on this mailing list. I'd be i believe you may have misread the emails. iirc, the way this started was a random jibe at fossil to the tune of fossil is teh suck. data = lossage. it's

Re: [9fans] Fossil disk usage over 100%?

what would be helpful, and move the discussion forward, is if someone could try to replicate this with unclean shutdowns after various file operations. i suspect that it won't repeat. but either way, it will move the discussion forward. For what it's worth, unclean shutdowns resulted in

Re: [9fans] Fossil disk usage over 100%?

On 3 June 2013 16:45, s...@9front.org wrote: Saying there is no problem changes nothing. You can debate with the Grand Canyon for hours, but when you walk off the cliff you're still going to plummet to the ground. No doubt, but you then do then *exactly* the same thing with cwfs. To my

Re: [9fans] Fossil disk usage over 100%?

No doubt, but you then do then *exactly* the same thing with cwfs. Certainly. And we're back at square one. Everyone has their own story about how they lost data. -sl

Re: [9fans] Fossil disk usage over 100%?

No doubt, but you then do then *exactly* the same thing with cwfs. To my certain knowledge, it is possible for the old file server to lose data and files, sometimes catastrophically so, forcing a recover main, and sometimes, a recover further back. That's unsurprising if you look at the

Re: [9fans] Fossil disk usage over 100%?

On Jun 3, 2013, at 4:50 PM, s...@9front.org wrote: Certainly. And we're back at square one. Everyone has their own story about how they lost data. which is to say that the thesis that fossil sucks is refuted. I think it rather says that everyone has a story. Someone was complaining

Re: [9fans] Fossil disk usage over 100%?

On Mon, Jun 03, 2013 at 03:41:39PM -0400, erik quanstrom wrote: which is to say that the thesis that fossil sucks is refuted. - erik *now* I know what you guys meant by 'snarky comments.' Just the place for some Snark! the 9fan cried, As he landed his Apples with care; Supporting each mac on

Re: [9fans] Fossil disk usage over 100%?

What I don't userstand is how do we do better than anecdotal evidence; unless we write everything in Z (haeven forbid). I suppose we have some measures like XYZfs is simpler so its less likely to have bugs' or age 'ABCfs is so old the bugs are more likely to have been be found', but these are

Re: [9fans] Fossil disk usage over 100%?

On Mon, Jun 3, 2013 at 1:14 PM, Federico G. Benavento benave...@gmail.comwrote: Don't worry, I'm not going to bore you with my stories about how fossil/venti saved my life so many times and never lost a file, I'll just keep using it. Now *that* sounds like a story worth listening too!

Re: [9fans] Fossil disk usage over 100%?

On Mon, Jun 3, 2013 at 3:17 PM, Steve Simon st...@quintile.net wrote: In the end we have to fall back on 'it works for me' done we? I think there is a certain amount of wisdom in choosing and (more importantly) accepting a tool. Provided you aren't attempting to hammer a screw, there is a lot

Re: [9fans] Fossil disk usage over 100%?

On Jun 3, 2013, at 15:50 , s...@9front.org wrote: Richard mentioned fixing the snapshots bug in fossil. This is about as close as we've come to examining the technical issues. No: this *is* examining the technical issues. Richard has done actual engineering here; it's moderately depressing

Re: [9fans] Fossil disk usage over 100%?

This paragraph has more qualifiers than your average winter olympics If you prefer snarky insinuations rather than an attempt to convey accurate information, I think you're reading the wrong mailing list.

Re: [9fans] Fossil disk usage over 100%?

On Sun, Jun 02, 2013 at 04:55:59PM +0100, Richard Miller wrote: This paragraph has more qualifiers than your average winter olympics If you prefer snarky insinuations rather than an attempt to convey accurate information, I think you're reading the wrong mailing list. I disagree.

Re: [9fans] Fossil disk usage over 100%?

I disagree. Yes.

Re: [9fans] Fossil disk usage over 100%?

it takes no skill to make snarky comments. i have two file servers that have been continuously and reliably operating since 2003 and 2010 -- a ken fs since 2003, and a venti-backed fossil fs since 2010. I have a third which is currently pickled -- an fs64 that ran from the time geoff created it

Re: [9fans] Fossil disk usage over 100%?

On Jun 2, 2013, at 12:41, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: it takes no skill to make snarky comments. Khm brought trolling back to the intelligent man. His work is truly an art. Veety

Re: [9fans] Fossil disk usage over 100%?

my guess is that it's a mutated gene. On Sun, Jun 2, 2013 at 9:45 AM, Matthew Veety mve...@gmail.com wrote: On Jun 2, 2013, at 12:41, Skip Tavakkolian skip.tavakkol...@gmail.com wrote: it takes no skill to make snarky comments. Khm brought trolling back to the intelligent man. His work

Re: [9fans] Fossil disk usage over 100%?

On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote: my guess is that it's a mutated gene. Ah, a Chomskyite.

Re: [9fans] Fossil disk usage over 100%?

but was probably abused as a child. On Sun, Jun 2, 2013 at 9:53 AM, Kurt H Maier kh...@intma.in wrote: On Sun, Jun 02, 2013 at 09:49:26AM -0700, Skip Tavakkolian wrote: my guess is that it's a mutated gene. Ah, a Chomskyite.

Re: [9fans] Fossil disk usage over 100%?

the feeding hours are over for the day; back to your cave. On Sun, Jun 2, 2013 at 10:13 AM, Kurt H Maier kh...@intma.in wrote: On Sun, Jun 02, 2013 at 10:01:12AM -0700, Skip Tavakkolian wrote: but was probably abused as a child. This is a perfect counterexample to it takes no skill to

  1   2   3   4   >