[9fans] Fossil disk usage over 100%?

[9fans] Fossil disk usage over 100%?

[Jeremy Jackins]

Hi 9fans,

I recently set up my fossil to be backed by venti, for the first time.
I think it's archiving correctly. As an experiment, I just did a mk
install in /sys/src/cmd, which I know to require more disk space that
my fossil alone can handle.

Can someone help me understand this?

main: df
main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808 (109.1% used)
main:

Thanks.

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

[Jeremy Jackins]

Sorry, I think I understand what this number represents now. I thought
it was a percentage of used disk space in my fossil partition and
completely separate from venti.

On Thu, May 30, 2013 at 1:45 PM, Jeremy Jackins <jeremyjackins@gmail.com> wrote:
> Hi 9fans,
>
> I recently set up my fossil to be backed by venti, for the first time.
> I think it's archiving correctly. As an experiment, I just did a mk
> install in /sys/src/cmd, which I know to require more disk space that
> my fossil alone can handle.
>
> Can someone help me understand this?
>
> main: df
> main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808 (109.1% used)
> main:
>
> Thanks.

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

[David du Colombier]

> Sorry, I think I understand what this number represents now. I thought
> it was a percentage of used disk space in my fossil partition and
> completely separate from venti.

No, you were right. The Fossil df command returns
the number of used blocks in the Fossil write buffer.

Df can report used > total if you removed files
without using rm(1) or fossilcons(4) remove.
For example, when you marked blocks available
for allocation with bfree.

See fl->nused in /sys/src/cmd/fossil/cache.c.

--
David du Colombier

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

[Jeremy Jackins]

Hmm, I don't think that was the case for me. I wasn't removing files
in any strange way, and later, after doing some more work, df was
reporting closer to 200%. After rebooting, df reports this:

main: df
main: 33,783,808 used + 477,184,000 free = 510,967,808 (6.6% used)

Which seems to make sense, but now I'm even more confused about the
output I was getting before:

main: df
main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808 (109.1% used)

I thought the large number was my disk space including venti. Looking
more closely, I certainly don't have 35 terabytes hiding anywhere.

On Thu, May 30, 2013 at 4:06 PM, David du Colombier <0intro@gmail.com> wrote:
>> Sorry, I think I understand what this number represents now. I thought
>> it was a percentage of used disk space in my fossil partition and
>> completely separate from venti.
>
> No, you were right. The Fossil df command returns
> the number of used blocks in the Fossil write buffer.
>
> Df can report used > total if you removed files
> without using rm(1) or fossilcons(4) remove.
> For example, when you marked blocks available
> for allocation with bfree.
>
> See fl->nused in /sys/src/cmd/fossil/cache.c.
>
> --
> David du Colombier
>

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

[lucio]

> main: df
> main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808 (109.1% used)

I recently had a "free" number in that same league together with a
very many damaged files.  It was trivial to receover from the venti
archive and the two issues may have been unrelated, but I would
strongly recommend against pushing fossil's capacity boundaries.
That's how I broke it.

++L

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

[David du Colombier]

> main: df
> main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808
> (109.1% used)
>
> I thought the large number was my disk space including venti. Looking
> more closely, I certainly don't have 35 terabytes hiding anywhere.

The "large number" simply come from total - used
when used > total.

What is important here is that fl->nused increased
more than it decreased and exceed the total number
of blocks.

--
David du Colombier

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

[James Chapman]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

i
On 31 May 2013 11:36, "David du Colombier" <0intro@gmail.com> wrote:

> > main: df
> > main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808
> > (109.1% used)
> >
> > I thought the large number was my disk space including venti. Looking
> > more closely, I certainly don't have 35 terabytes hiding anywhere.
>
> The "large number" simply come from total - used
> when used > total.
>
> What is important here is that fl->nused increased
> more than it decreased and exceed the total number
> of blocks.
>
> --
> David du Colombier
>
>

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

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

[James Chapman]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

Z
On 31 May 2013 11:36, "David du Colombier" <0intro@gmail.com> wrote:

> > main: df
> > main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808
> > (109.1% used)
> >
> > I thought the large number was my disk space including venti. Looking
> > more closely, I certainly don't have 35 terabytes hiding anywhere.
>
> The "large number" simply come from total - used
> when used > total.
>
> What is important here is that fl->nused increased
> more than it decreased and exceed the total number
> of blocks.
>
> --
> David du Colombier
>
>

[-- Attachment #2: Type: text/html, Size: 880 bytes --]

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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

Purely anecdotal, but I've found that after setting up venti for a
long-lived fossil (approximately 9 months), re-initializing based on the
latest vac cleared up various bits of weirdness. YMMV.


On Thu, May 30, 2013 at 12:45 PM, Jeremy Jackins <jeremyjackins@gmail.com>wrote:

> Hi 9fans,
>
> I recently set up my fossil to be backed by venti, for the first time.
> I think it's archiving correctly. As an experiment, I just did a mk
> install in /sys/src/cmd, which I know to require more disk space that
> my fossil alone can handle.
>
> Can someone help me understand this?
>
> main: df
> main: 557,539,328 used + 35,184,325,517,312 free = 510,967,808 (109.1%
> used)
> main:
>
> Thanks.
>
>

[-- Attachment #2: Type: text/html, Size: 1057 bytes --]

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

[Kurt H Maier]

On Fri, May 31, 2013 at 12:53:03PM -0700, Steven Stallion wrote:
> long-lived fossil (approximately 9 months)


:)

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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

Alright. That's fair. I probably even walked into that.

I suspect it's probably an artifact of any serious filesystem I use on a
daily basis (*cough*) measured in years are all based on 64-bit Ken's.
Fossil still feels foreign to me, though I'm attempting to change that.


On Fri, May 31, 2013 at 1:06 PM, Kurt H Maier <khm-9@intma.in> wrote:

> On Fri, May 31, 2013 at 12:53:03PM -0700, Steven Stallion wrote:
> > long-lived fossil (approximately 9 months)
>
>
> :)
>
>

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

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

[Matthew Veety]

> Fossil still feels foreign to me, though I'm attempting to change that.

You misspelled unstable. You have more sack than I could ever say I have for putting anything mildly important on fossil.

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

[Richard Miller]

> You misspelled unstable. You have more sack than I could ever say I have for putting anything mildly important on fossil.

Nonsense.

I've been using fossil on my main system since 2008, and on a thinkpad
which I used daily when working at clients' offices for some years
before that.  My professional livelihood depends on the integrity of
those file systems, and I've never lost a file in an active partition
-- apart from two or three "human error" instances like typing 'mv x y'
when I meant 'mv y x', or inadvertently starting two simultaneous
fossils on the same partition.  I have had some damage in historical
dumps, but that bug was fixed in March 2012.

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

[steve]

secconded!

my two fossils + venti file servers have been running since 2004.
there where problems to do with snapshots which i disabled.
That bug is now fixed and it have reenabled them.

my only losscame some years ago due to me being
paranoid and over-cooling drives, and that was a loss of
a one of a mirrored pair, not of real data.

-Steve


On 1 Jun 2013, at 07:09, Richard Miller <9fans@hamnavoe.com> wrote:

>> You misspelled unstable. You have more sack than I could ever say I have for putting anything mildly important on fossil.
> 
> Nonsense.
> 
> I've been using fossil on my main system since 2008, and on a thinkpad
> which I used daily when working at clients' offices for some years
> before that.  My professional livelihood depends on the integrity of
> those file systems, and I've never lost a file in an active partition
> -- apart from two or three "human error" instances like typing 'mv x y'
> when I meant 'mv y x', or inadvertently starting two simultaneous
> fossils on the same partition.  I have had some damage in historical
> dumps, but that bug was fixed in March 2012.
> 

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

[Kurt H Maier]

On Sat, Jun 01, 2013 at 07:09:41AM +0100, Richard Miller wrote:
> Nonsense.
>
> I've been using fossil on my main system since 2008, and on a thinkpad
> which I used daily when working at clients' offices for some years
> before that.  My professional livelihood depends on the integrity of
> those file systems, and I've never lost a file in an active partition
> -- apart from two or three "human error" instances like typing 'mv x y'
> when I meant 'mv y x', or inadvertently starting two simultaneous
> fossils on the same partition.  I have had some damage in historical
> dumps, but that bug was fixed in March 2012.
>
>


This paragraph has more qualifiers than your average winter olympics

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

[Richard Miller]

> 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%?

[Kurt H Maier]

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%?

[lucio]

> I disagree.

Yes.

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

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 in 2006 until about 2010.  all have been
through power outages and in one case a disk failure. dedicate a machine to
the file server.



On Sun, Jun 2, 2013 at 9:09 AM, <lucio@proxima.alt.za> wrote:

> > I disagree.
>
> Yes.
>
>
>

[-- Attachment #2: Type: text/html, Size: 900 bytes --]

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

[Matthew Veety]

On Jun 2, 2013, at 12:41, Skip Tavakkolian <skip.tavakkolian@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%?

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 351 bytes --]

my guess is that it's a mutated gene.


On Sun, Jun 2, 2013 at 9:45 AM, Matthew Veety <mveety@gmail.com> wrote:

> On Jun 2, 2013, at 12:41, Skip Tavakkolian <skip.tavakkolian@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
>

[-- Attachment #2: Type: text/html, Size: 795 bytes --]

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

[Kurt H Maier]

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%?

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

but was probably abused as a child.


On Sun, Jun 2, 2013 at 9:53 AM, Kurt H Maier <khm-9@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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 598 bytes --]

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

[Kurt H Maier]

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 make snarky
comments."  You clearly need practice; this one was clumsy.

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

the feeding hours are over for the day; back to your cave.


On Sun, Jun 2, 2013 at 10:13 AM, Kurt H Maier <khm-9@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 make snarky
> comments."  You clearly need practice; this one was clumsy.
>
>

[-- Attachment #2: Type: text/html, Size: 737 bytes --]

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

[hiro]

> dedicate a machine to the file server.

This must be the best way to keep the plebeian hands off the artwork:
museums that are only open to curators.
This certainly also provided for my technical contribution to this mailing list.

>> > my guess is that it's a mutated gene.
> but was probably abused as a child.

This is unhelpful. I wouldn't even go as far as calling Kurt a troll.
You are just hurling off boring insults whereas he was pointing out
the sad truth in a joking thus diplomatic manner - subsequently
getting supported by your replies - that this mailing list is snarky,
unfriendly and often unhelpful. Although I hope this is just you being
drunk and attempting to troll yourself.

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

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Sun, Jun 2, 2013 at 2:58 PM, hiro <23hiro@gmail.com> wrote:

> > dedicate a machine to the file server.
>
> This must be the best way to keep the plebeian hands off the artwork:
> museums that are only open to curators.
> This certainly also provided for my technical contribution to this mailing
> list.
>

you misunderstand the strength of Plan 9 and use a false premise in regards
to the cost.  the point of Plan 9 is to have a heterogeneous collection of
machines, each dedicated to a finite set of services (resources) that one
can import, export and access in a uniform way.  you seem to imply that
requiring more than one machine is elitist.  one can build a RPi Plan 9 cpu
for less than $50; hardware that can run an fs (any fs) is cheap-to-free.



>
> >> > my guess is that it's a mutated gene.
> > but was probably abused as a child.
>
> This is unhelpful. I wouldn't even go as far as calling Kurt a troll.
> You are just hurling off boring insults whereas he was pointing out
> the sad truth in a joking thus diplomatic manner - subsequently
> getting supported by your replies - that this mailing list is snarky,
> unfriendly and often unhelpful. Although I hope this is just you being
> drunk and attempting to troll yourself.
>
>
please tell us about your Plan 9 setup.

[-- Attachment #2: Type: text/html, Size: 2016 bytes --]

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

[erik quanstrom]

On Sun Jun  2 17:59:16 EDT 2013, 23hiro@gmail.com wrote:
> > dedicate a machine to the file server.
>
> This must be the best way to keep the plebeian hands off the artwork:
> museums that are only open to curators.
> This certainly also provided for my technical contribution to this mailing list.

it's odd to interpert this as a restriction when i believe this is a common
technique, even among people with single-user systems.

the reason for this technique is that 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.

at home, this is very helpful as sometimes the man cpu/auth server gets
confused.  dns is a common reason.  it's good to be able to reboot the
cpu server without interrupting my terminal.  running out of memory
or procs also has no effect on the fs.  it is tautology to say that
i have access to the file server.

a side benefit is this technique scales to very large systems.  at work we
run a file server(per location) that supports 40+ cpu/terminal machines and many
users.  in this case direct access to the file server is restricted to those
reponsible for keeping it running.  the seperate file server allows a
policy that many folks can fix the dns server without becoming responsible
for any file server issues.

> >> > my guess is that it's a mutated gene.
> > but was probably abused as a child.
>
> This is unhelpful. I wouldn't even go as far as calling Kurt a troll.
> You are just hurling off boring insults whereas he was pointing out
> the sad truth in a joking thus diplomatic manner - subsequently

sorry, what point was he making?  i saw a clearly false claim unsupported
by evidence or anecdote that fossil is not stable.  but that's not making
a point.

- erik

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

[Richard Miller]

> 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 service.  One of the things that
really impressed me on my first encounter with Plan 9 was the clean
separation of file service from everything else, in the original stand-alone
fs.  Little danger of a buffer overflow being exploited to exec a shell,
when the fs kernel doesn't have an exec.

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

[Kurt H Maier]

On Sun, Jun 02, 2013 at 10:45:53PM -0400, erik quanstrom wrote:
> 
> sorry, what point was he making?  i saw a clearly false claim unsupported
> by evidence or anecdote that fossil is not stable.  but that's not making
> a point.
> 

It's been shown that this mailing list is unwilling to admit that fossil
is unreliable (to the point that it's become a running joke).  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.)

Anyway, the point is that it does not matter and has never mattered what 
'evidence or anecdote' is presented -- not that there's any
non-anecdotal evidence available -- because it's not about the fossil.
It's about sending the message. Fossil is part of the plan 9
inheritance; one of the last gifts of the departing Maiar before they
went West to Tol Eressëa; blessed be its name.

What people seem to forget is that in many folks' eyes, a buggy
data store is a one-way street.  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.  There is no
'participation award' for software on my computers.  I fix what I can,
but I don't get enough utility from fossil to make it worth
understanding its code.

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
interested to know if anyone who has been burned by fossil has been
convinced to give it another try.

khm

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

[lucio]

> 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
> interested to know if anyone who has been burned by fossil has been
> convinced to give it another try.

I'd swap fossil for any number of Unix-ey file systems, despite
recently having pushed fossil over the edge and driven it where only
flfmt with the right venti score would recover it.  But a single command
sufficed to get me back where I wanted to be.

Every time I lost a NetBSD, Windows, Linux or Netware filesystem it's
always been easier to throw the damaged filesystem away than to figure
out how to recover.  That's happened more times than I've lost fossil.

I accept that fossil is WIP with no one actually working on it, but
the incomplete product is already better than any finished equivalent
I am familiar with, specially those where somebody comes along twice a
year to point out how it can all be improved by starting from scratch.

++L

PS: It's as much effort to point out one's success stories as it takes
to mention one known failure.  The question one gets tempted to ask is
why one failure should dominate the discussion.

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

[Richard Miller]

> 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 in the mailing list history, up
to the point where I finally nailed it last year.  I think it wasn't
a priority for many people to look at because it only damaged copies
of files on their way onto /n/dump; as rsc once remarked, once a file
is safely on venti you can rely on it staying there.

> but I don't get enough utility from fossil to make it worth
> understanding its code.

Fine, if it's not useful to you don't use it.  Speaking only for myself,
I'd be very unhappy to have to switch to any other file system lacking
fossil's frequent and effortless ephemeral snapshots.  Apart from using
them as a simple source-mananagement mechanism for keeping track of
progress on current projects, I find them an invaluable insurance against
fumble-fingered incidents of the 'mv y x' variety.

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 325 bytes --]

On 3 June 2013 12:49, Kurt H Maier <khm-9@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 file server.

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

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

[erik quanstrom]

> 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 not surprising to get responses that read to me like "from
personal experience fossil is stable and i trust it.  further you can recover
from issues with venti" from the many folks successfully using fossil.

this isn't new information, nor have any specific issues with fossil
been raised.  "fossil is teh suck.  data = lossage." is not a specific
issue given other folks successfully use fossil.  and it's awful black
and white.

i did see something specific with fossil on the raspberry pi recently.
i moved a few files and then accidentally did an unclean shutdown.
one of those file was corrupt.  when i rebooted it's parent directory
was gone.  when i rebooted again its parent was gone.  it was like a
prion.

now, i'd forgotten about this since it looked like hardware, i
i can't prove that i shut down the pi properly the second two times,
but i think i did.  there is a possiblity that this could be a fossil
issue.  unfortunately i've been to busy to try to replicate this.

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.

- erik

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

[sl]

> 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 lost data for me
under both fossil and hjfs. In my experience unclean shutdowns never
seemed to cause problems for cwfs64x.

In the case of both fossil and hjfs it is sometimes possible to repair
the damage. Other times it is not. Fossil has vocal supporters, while
hjfs is still marked experimental (bugs are actually getting fixed). The
problem for users is that when you boot the system and you can't access
your files, it gets in the way of the reason you booted the system in the
first place. Persistence of this condition is unacceptable.

I ran fossil on both hardware and under different virtual machines and
eventually experienced file corruption on every single install. Once I
found out about cwfs I switched to that and had zero problems, ever.
Okay, I said to myself, this is where I'll stay. Anecdotal? You betcha.
But cwfs never lost data.

We can argue about who misread what messages forever. The fact is
that some of us had problems with fossil and then found ways around
the problems. For some of us that meant patching fossil or changing
the way we used fossil. For others, it meant finding some other
filesystem. 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.

http://img.stanleylieber.com/src/15358/img/1370274020.jpg

-sl

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On 3 June 2013 16:45, <sl@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 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 code. It's easy to fix by making it really, really slow at writing.
And even then, your drives will have buffered the data and not written it.
There's a good reason my file servers were on UPS.
Even that isn't guaranteed, because notoriously, you'll find the UPS
battery has gone
just when you need it.

[-- Attachment #2: Type: text/html, Size: 1525 bytes --]

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

[sl]

> 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%?

[erik quanstrom]

> 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 code.  It's easy to fix by making it really, really slow
> at writing.  And even then, your drives will have buffered the data
> and not written it.  There's a good reason my file servers were on
> UPS.  Even that isn't guaranteed, because notoriously, you'll find the
> UPS battery has gone just when you need it.

i don't have experience with cwfs, but at my old house i had ken's
file server running for years with no ups.  and power was very unstable.
my average uptime was 3 days.  i may have been lucky, but i didn't
lose data, nor was i forced to recover main.

ken's file server *will* have trouble if you interrupt it while it's writing
superblocks.  this has happened to me twice due to network outages
making the remote copy of the worm inaccessable.  the file server could
have recovered, but was rebooted because it was thought to be hung.
obviously, rebooting didn't help, and only forced a recover main.

recover main is exactly the same sort of operation as recovering fossil
from a venti score.  all "recent" (for some value of recent) changes
are lost, but "older" data (for some value of older) are preserved.

On Mon Jun  3 15:34:26 EDT 2013, sl@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.

- erik

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

[sl]

>> 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 about anecdotes, but that's what we've got.

Richard mentioned fixing the snapshots bug in fossil. This
is about as close as we've come to examining the technical
issues.

It's mostly been story/counter-story about how we all have
lost files on each of these filesystems. The important takeaway
here is that we have reports of people losing data on every single
one of them.

I had problems with fossil. Like you, I never had problems with
(cw)fs. Charles had problems with fs. I don't think we've refuted
any claims about relative stability or even established a scale
to measure with.

-sl

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

[Federico G. Benavento]

On Jun 3, 2013, at 4:50 PM, sl@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 about anecdotes, but that's what we've got.
>
> Richard mentioned fixing the snapshots bug in fossil. This
> is about as close as we've come to examining the technical
> issues.
>
> It's mostly been story/counter-story about how we all have
> lost files on each of these filesystems. The important takeaway
> here is that we have reports of people losing data on every single
> one of them.
>
> I had problems with fossil. Like you, I never had problems with
> (cw)fs. Charles had problems with fs. I don't think we've refuted
> any claims about relative stability or even established a scale
> to measure with.
>
> -sl
>


Awesome, I'm happy to know that there's no clear data about anything
and that everything can be proven wrong.
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.
Thanks for sharing your wisdom with the list.

---
Federico G. Benavento
benavento@gmail.com

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

[sl]

> 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.
> Thanks for sharing your wisdom with the list.

I wasn't the one who complained about anecdotes. We just seem
to get lost in these words and chase the same rhetorical shadows
endlessly:

- Someone complains about fossil screwing up
- Someone says, "no it doesn't"
- Out come more anecdotes
- Attempts at making clever comments are made
- Discussion peters out (again)

We're all really clever but people keep experiencing data loss.

-sl

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

[Steve Simon]

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 still only subjective measures. In the end we have to fall
back on 'it works for me' done we?

-Steve

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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

On Mon, Jun 3, 2013 at 3:17 PM, Steve Simon <steve@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 of variety out there.

Steve

[-- Attachment #2: Type: text/html, Size: 705 bytes --]

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

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]

On Mon, Jun 3, 2013 at 1:14 PM, Federico G. Benavento
<benavento@gmail.com>wrote:

> 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!

[-- Attachment #2: Type: text/html, Size: 629 bytes --]

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

[Anthony Sorace]

On Jun 3, 2013, at 15:50 , sl@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 that many
members of this list, and particularly some of the more vocal,
don't seem able to recognize the difference.

Fossil likely has bugs, because all large software likely does.
Nobody's pretended otherwise. To the contrary, some of these
bugs have been openly discussed on this list. Some have
been identified and fixed in the past. The fossil of today is much
more stable than the initial release, and seems to be at least in
the same neighborhood as other comparable alternatives (cwfs,
ken's fs, various unix file systems). Assertions to the contrary
should be accompanied by data.

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

[sl]

>> 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 some of the more vocal,
> don't seem able to recognize the difference.

About as close as we've come to examining the technical issues
in this thread. The context of my observation was the continuing
cascade of vague recriminations. I don't think I was that unclear.
I am however losing track of who is defending what.

I'll stop attempting to moderate.

-sl

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

[Richard Miller]

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 the years to support their real work will have
a different subjective view of its reliability than someone with only
the frustrating experience of repeated experimental installs, maybe on
pushing-the-boundaries hardware or VMs that nobody else has tried,
maybe not getting the initial config quite right (it's tricky) or
trying to load it up with more files than it can hold before taking
the first venti snapshot.

That's my last word on the subject, except to say: any time someone
reports a data-corrupting fossil bug to the list, with enough factual
detail that it can be replicated, I'll do my best to fix it.  I enjoy
a bit of a challenge :)

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

[Kurt H Maier]

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 the top of the tide
By a lanyard tied off to his Air.

"Just the place for some Snark! I have said it twice:
That alone should encourage the macs.
Just the place for some Snark!  I have said it thrice:
What I tell you three times is true."

The mac was complete: it included a bootes--
An owner of hardware and hosts--
A mail program, brought to arrange their disputes--
And a Hivemind, to value their words.

A kernel-patch-maker, whose skill was immense,
Might perhaps have won more than his share--
But a Repo, engaged at enormous expense,
Had the whole of their code in his care.

There was also Safari, that paged out the stack,
Or would sit making .gifs in the bow,
And had often (the Bellman said) saved them from wreck,
Though none of the Apples knew how.

There was one who was famed for the number of things
He forgot when he entered the disk:
His email, his logs, all his photos and songs,
And the superblocks saved against risk.

He had forty-two journals, all carefully packed,
With his name painted clearly on each:
But, since he omitted to mention the fact,
The were all left behind on the beach.

The loss of his blocks hardly mattered, because
He had seven RAID drives when he came,
With three Dell PERC cards -- but the worst of it was,
He had wholly forgotten his name.

He would answer to "Hi!" or to any loud cry,
Such as "Fry me!" or "Fritter my wig!"
To "What-you-may-call-um!" or "What-was-his-name!"
But especially "Thing-um-a-jig!"

While, for those who preferred a more forcible word,
He had different names to tout:
His intimate friends called him "hjfs: ends"
And his enemies just patched him out.

"His form is ungainly -- his intellect small"
(So the 9fan would often remark)
"But his snapshot is perfect! And that, after all,
Is the thing that one needs with a Snark."

He would joke with fshalts, returning their strike
With an impudent park of the head:
And he once went a-walk, volt-in-volt, with a spike
"Just to keep up its spirits" he said.

He came as a filestore: but owned, when too late --
And it drove the poor 9fan half-mad --
He could only store cat pics (for which, I may state,
No tojpeg code was to be had.)

The last of the macs needs especial remark,
Though he looked an incredible dunce:
He had just one idea -- but that one being "Snark"
The good 9fan engaged him at once.

He came as a venti: but gravely declared
When the system was online a week,
He could only store data.  The 9fan looked scared,
And was almost too frightened to seek(2).

But at length he explained in a tremulous tone,
There were precious few data on board;
And that was some tame stuff he had on his own
Whose deletion was to be deplored.

The data, who happened to hear the remark,
Protested with tears in its eyes,
That not even the rapture of hunting the Snark
Could atone for that dismal suprise!

It strongly advised that the venti should be
Conveyed in a separate disk:
But the 9fan declared that would never agree
With the plans he had made without fsck.

File storage was always a difficult art,
Though with only one disk and one Nix:
And he feared he must really decline, for his part,
Operating another betwixt.

The data's best course was no doubt to procure
A second-hand shutdown-proof coat --
So the filestore advised it -- and next to insure
Its use within Office or Notes:

This the Repo suggested, and offered for use
On moderate terms or for sale,
Two excellent killfiles: one anti-abuse
And one for protection from mail.

Yet still ever after that sorrowful day,
Whenever the venti was by,
The data kept looking the opposite way,
And appeventiSend vtWrite block 0xa failed: not connected to venti server

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

[Bakul Shah]

On Jun 3, 2013, at 8:45 AM, sl@9front.org wrote:

> I ran fossil on both hardware and under different virtual machines and
> eventually experienced file corruption on every single install.

This may have something to do with VM settings -- I vaguely recall some
buffering issues. Haven't had any fossil problems once I switched to
VirtualBox. I save plan9 state, quit from Vbox and may later restart this
VM days/months later and things seem to keep working.

I tried putting venti on the RPi and ran into some issues but at that
time there were a lot of moving parts so can't be sure what happened.
Right now I don't use venti with RPi because I want it to work in
places with zero net connectivity and once you use venti with fossil,
fossil gets very unhappy without it! If everything accessible from
the last snapshot was locally available, fossil wouldn't fallover.

A `best practices' guide for fossil+venti would be very helpful.

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

[Aaron Sawyer]

In article <20130603202129.GA84380@intma.in>, khm-9@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 Snark!" the 9fan cried,
> As he landed his Apples with care;
> Supporting each mac on the top of the tide
> By a lanyard tied off to his Air.
>
> "Just the place for some Snark! I have said it twice:
> That alone should encourage the macs.
> Just the place for some Snark!  I have said it thrice:
> What I tell you three times is true."
>
(much awesomeness snipped)

"The Hunting of the Fossil"   FTW !!

Well done!
=Aaron

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

[hiro]

> If you prefer snarky insinuations rather than an attempt to convey
> accurate information, I think you're reading the wrong mailing list.

hahahahaha

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

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On 1 June 2013 04:56, Matthew Veety <mveety@gmail.com> wrote:

> You have more sack than I could ever say I have for putting anything
> mildly important on fossil.


!ls /n/dump
/n/dump/2004
/n/dump/2005
/n/dump/2006
/n/dump/2007
/n/dump/2008
/n/dump/2009
 ...

This is fossil on venti, on file server hardware that has changed
periodically (more than the software).
I had more trouble with SSDs than ever with fossil (given venti).
I can't remember the last time I had to reset the fossil from venti.

[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

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

[erik quanstrom]

> I suspect it's probably an artifact of any serious filesystem I use on a
> daily basis (*cough*) measured in years are all based on 64-bit Ken's.
> Fossil still feels foreign to me, though I'm attempting to change that.

ken's file server sure has that industrial-strength feel, doesn't it?

http://en.wikipedia.org/wiki/File:Wyman_Gordon_50000_ton_press.jpg

- erik

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

[sl]

>> 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 some of the more vocal,
> don't seem able to recognize the difference.

About as close as we've come to examining the technical issues
in this thread. The context of my observation was the continuing
cascade of vague recriminations. I don't think I was that unclear.
I am however losing track of who is defending what.

I'll stop attempting to moderate.

-sl