Re: [9fans] fossil+plan9: disk full revisited - Plan9

This is a discussion on Re: [9fans] fossil+plan9: disk full revisited - Plan9 ; I did it again! on a second machine I tried dd -if=/dev/null -of=fillit.all bs=1024k count=2048 with a 1.8G fossil partition to be sure to fill it up completely. I learned four things from it: - fossil does not compress duplicated ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: [9fans] fossil+plan9: disk full revisited

  1. Re: [9fans] fossil+plan9: disk full revisited

    I did it again!

    on a second machine I tried

    dd -if=/dev/null -of=fillit.all bs=1024k count=2048

    with a 1.8G fossil partition to be sure to fill it up completely.

    I learned four things from it:

    - fossil does not compress duplicated data blocks
    - fossil cannot store total data bigger then its partition size
    - read the documentation
    - Read the Documentation!

    The excelent paper:

    http://www.cs.bell-labs.com/sys/doc/fossil.pdf

    tells it all, it's a pity it is not referenced in the papers section
    on Bell labs Plan9 page. You must instead go to the wiki and there to
    the papers section.

    I think the Plan9 papers section tend to confuse, since the "old" file
    server is still referenced there although it seems more of historical
    interest then as introductory material.

    On the other hand my perception was biased by the installers
    suggestion of the distribution of space between fossil and venti.

    I have a 12GByte Harddisk, which was divided into:

    fossil 1.84G
    arenas 9.24G

    considering that the filesystem gets compressed in venti, after some
    thought I'd use as much fossil as possible and the smallest venti
    possible for a reasonable archival time span (1 year?). If venti runs
    out of space one would archive some arenas to CD, DVD etc.

    With a dumb estimate of 30% compression ratio one would give about 60%
    of a disk to fossil, and 40% to venti. What are venti compression
    ratios experienced in real live?!


    However I am not sure, if my conclusions are right. At

    http://www.magma.com.ni/moin/Plan9Tutorial/FossilVenti

    my current understandings about fossil+venti are put together. I would
    be very pleased to get feedback and corrections about it.

    Regards


    Jorge-León

  2. Re: [9fans] fossil+plan9: disk full revisited

    Fossil does not eliminate duplicate blocks nor compress blocks, but
    venti does both, and it is intended that serious use of fossil should
    be backed with venti (which arenas should be stored on a RAID or
    equivalent). Using fossil without a backing venti gives the
    equivalent of an `other' partition on Ken's file server: scratch
    space.

    The fossil write buffer needs to be only as large as the largest set
    of blocks dirtied between dumps to venti, loosely speaking, so it can
    typically be much smaller than the venti arenas backing it. Edith,
    our current primary file server, has 400GB of venti arenas, with
    another 100GB available but not yet configured, and 34GB of fossil
    write buffer, of which df reports 3% used. 87% of the arenas are
    used. (Yes, we have a new, larger file server ready to replace
    edith.)


+ Reply to Thread