[9fans] Migration of vac score to fossil

[9fans] Migration of vac score to fossil

[Ole-Hjalmar Kristensen]

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

I have a file server running Linux at home, with a normal ext3 file system
and a plan9port venti. I use this venti for vac backup of both the ext3
file system and other Linux boxes. However, the 2 TB ext3 is running out of
space, while the venti is roughly 50% full. I could just buy a bigger disk,
of course, but the exit3 itself is mainly an archive (pictures, video, and
many years of accumulated documents and software), so I consider switching
to a fossil+venti file server instead. The fossil manual says "The score
should have been generated by fossil rather than by vac, so that the
appropriate snapshot metadata is present". Is there any way of coercing
fossil to initialize itself properly from a score produced by vac? I could
copy the files from ext3, but would likely run out of space in fossil,
which I gather is a bad idea. I run a 9front cwfs auth/cpu/file server, but
have no experience with fossil, so any help is welcome.

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

Re: [9fans] Migration of vac score to fossil

[Steve Simon]

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

I have long wanted to do this but on the one occasion I tried I got lost inside fossil.

the problem is fossil expects venti to have a hierarchy of the form /active/ and /archive/ where as your venti does not, I guess it has just your home dir.

it is easy to create the required placeholder in a new fossil attached to your fossil. what is missing is a fossil admin command to create a new directory but attach it to a given, existing venti score. if you could do this you could creat an empty fossil attached to your existing fossil and then populate your /archive/yyyy/mmdd/usr/yourname with each venti score you have from your old vac(1)s.

have a look at the fossil create command.

-Steve




> On 17 Dec 2015, at 17:05, Ole-Hjalmar Kristensen <ole.hjalmar.kristensen@gmail.com> wrote:
> 
> I have a file server running Linux at home, with a normal ext3 file system and a plan9port venti. I use this venti for vac backup of both the ext3 file system and other Linux boxes. However, the 2 TB ext3 is running out of space, while the venti is roughly 50% full. I could just buy a bigger disk, of course, but the exit3 itself is mainly an archive (pictures, video, and many years of accumulated documents and software), so I consider switching to a fossil+venti file server instead. The fossil manual says "The score should have been generated by fossil rather than by vac, so that the appropriate snapshot metadata is present". Is there any way of coercing fossil to initialize itself properly from a score produced by vac? I could copy the files from ext3, but would likely run out of space in fossil, which I gather is a bad idea. I run a 9front cwfs auth/cpu/file server, but have no experience with fossil, so any help is welcome.
> 
> 
> 
> 
> 

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

Re: [9fans] Migration of vac score to fossil

[Ole-Hjalmar Kristensen]

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

Yes, I was think about something like that. As an initial experiment, I
tried to used flfmt with the -v option on a vac archive just to see the
result. It seems that the vac archive does not contain the max qid that
flfmt needs. This seems strange to me, as vac -a should need this info just
as much as fossil needs it. Maybe it's tucked away somewhere else. Guess I
need to look some more at the code.



ole@ole-TECRA-R940 ~/Desktop/plan9 $ bin/fossil/flfmt -h 192.168.0.101 -v
f648dbae0075eb73bc394ad6cd4c059e655e127c fossil.dat
fs header block already exists; are you sure? [y/n]: y
fs file is mounted via devmnt (is not a kernel device); are you sure?
[y/n]: y
0xfb1e734c
0x1d1feaf1
c85978546e4048fce83120d3992cfc2f57ff2f8c
bin/fossil/flfmt: bad root: no qidSpace

    /*
     * Maximum qid is recorded in root's msource, entry #2 (conveniently in
e).
     */
    ventiRead(e.score, VtDataType);
    if(!mbUnpack(&mb, buf, bsize))
        sysfatal("bad root: mbUnpack");
    meUnpack(&me, &mb, 0);
    if(!deUnpack(&de, &me))
        sysfatal("bad root: dirUnpack");
    if(!de.qidSpace)
        sysfatal("bad root: no qidSpace");
    qid = de.qidMax;



On Thu, Dec 17, 2015 at 11:13 PM, Steve Simon <steve@quintile.net> wrote:

> I have long wanted to do this but on the one occasion I tried I got lost
> inside fossil.
>
> the problem is fossil expects venti to have a hierarchy of the form
> /active/ and /archive/ where as your venti does not, I guess it has just
> your home dir.
>
> it is easy to create the required placeholder in a new fossil attached to
> your fossil. what is missing is a fossil admin command to create a new
> directory but attach it to a given, existing venti score. if you could do
> this you could creat an empty fossil attached to your existing fossil and
> then populate your /archive/yyyy/mmdd/usr/yourname with each venti score
> you have from your old vac(1)s.
>
> have a look at the fossil create command.
>
> -Steve
>
>
>
>
> On 17 Dec 2015, at 17:05, Ole-Hjalmar Kristensen <
> ole.hjalmar.kristensen@gmail.com> wrote:
>
> I have a file server running Linux at home, with a normal ext3 file system
> and a plan9port venti. I use this venti for vac backup of both the ext3
> file system and other Linux boxes. However, the 2 TB ext3 is running out of
> space, while the venti is roughly 50% full. I could just buy a bigger disk,
> of course, but the exit3 itself is mainly an archive (pictures, video, and
> many years of accumulated documents and software), so I consider switching
> to a fossil+venti file server instead. The fossil manual says "The score
> should have been generated by fossil rather than by vac, so that the
> appropriate snapshot metadata is present". Is there any way of coercing
> fossil to initialize itself properly from a score produced by vac? I could
> copy the files from ext3, but would likely run out of space in fossil,
> which I gather is a bad idea. I run a 9front cwfs auth/cpu/file server, but
> have no experience with fossil, so any help is welcome.
>
>
>
>
>
>

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