Re: [fossil-users] Bitrot defense?

[Warren Young]

On Jul 5, 2016, at 4:55 PM, Paul Hammant  wrote:
> 
> somehow Btrfs or ZFS know Fossil well enough to repair a small section of a 
> moving target? 

Those filesystems don’t need to know Fossil’s internals at all.

Self-repair only requires checksums and redundancy.  If one checksum doesn’t 
match the contents of the data being checksummed, another copy of the data is 
checked, and if its contents match the checksum, it is presumed to be the 
correct one, so the bad copy is overwritten with it.

ZFS and btrfs will do this opportunistically on a data read,[*] or on-demand 
with the scrub command:

  https://docs.oracle.com/cd/E23823_01/html/819-5461/gbbwa.html
  https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub 

Fossil could do the same by comparing the local copy data against its local 
checksum, and if that doesn’t match, ask the server it most recently sync’d 
against for its copy.

Incidentally, this is also why People On The Internet Are Being Wrong when they 
claim it is a problem that Apple’s new APFS filesystem lacks data checksumming. 
 APFS also doesn’t support pools of redundant storage, a la ZFS, which I 
believe is because Apple doesn’t sell a single device with redundant storage 
today.

Without redundant storage, there’s no especially good reason for APFS to 
include data checksums since a bad data block can only be rejected, not fixed.  
The solution is backups, not data checksums.

The vast bulk of Apple’s devices sold don’t even have the option of external 
storage (iPhones, iWatches, etc.), and I’d bet the minority of Apple devices 
hooked up to external storage are non-redundant, and that the minority of that 
minority that do have external redundant storage are using some kind of 
proprietary RAID system, and so couldn’t use APFS even if they wanted to.

Those weirdos among us who want to pool JBODs with redundancy and data 
checksumming on a Mac will continue to use ZFS.  It’s no surprise that Apple 
has chosen not to support this minority of a minority of a minority.


[*] Scrub is still better than opportunistic checks because it forces the 
filesystem to read all copies of all blocks, not just one.  That is, if you 
have a 2-way mirror, I believe both ZFS and btrfs will interleave reads so that 
half the blocks come from each disk, which speeds the operation up.  If there’s 
a corrupt block on disk 0 but the filesystem chose to read that block from disk 
1, the filesystem won’t know the block is corrupt until you try again and 
somehow cause it to read from disk 0 this time.  Scrub forces that to happen 
for every block.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bitrot defense?

[Paul Hammant]

>
>
> Fossil *could* be modified to self-repair.  It has the info it needs to do
> so.
>
> But then, why bother in a world where you have things like ZFS, which can
> protect not only your Fossil repos, but also everything else you hold dear?
>

So say the's an old version of a PNG that's corrupt in replica-a.  It is
four versions back from tip/head by that's academic, In replica-b it is OK.
There's three commits/pushes a minute to both replica-a (and b by
implication) which are now at 6GB in size, because this is a busy
hypothetical team. So somehow Btrfs or ZFS know Fossil well enough to
repair a small section of a moving target?

- Paul
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Release 1.35 checksums?

[jungle Boogie]

On 1 July 2016 at 09:39, Warren Young  wrote:
> If you’re expecting the checksum to protect you against someone hacking the 
> web site and uploading malware, they can modify the checksums on the web site 
> at the same time.

Absolutely.

As a small request, maybe when Dr. Hipp makes a release, he can also
include the hash in the email. As Andy indicated, this can be archived
by search engines and even available on the archive of the mailing
list.


-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Need help /tips SQLITE_CONSTRAINT: abort at 42

[Richard Hipp]

Can I get access to your repository for debugging purposes?

On 7/5/16, Tillmann Basien  wrote:
> my fossil repository has a branch which cannot be merged into another one.
>
> Fossil: This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC
> I already did fossil rebuild.
>
> This is the last line after:  fossil merge -n 
>
>
> *SQLITE_CONSTRAINT: abort at 42 in [INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT
> 42158,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=673981]:
> UNIQUE constraint failed: vfile.pathname, vfil**
> **/usr/local/bin/fossil: UNIQUE constraint failed: vfile.pathname,
> vfile.vid: {INSERT INTO
> vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT
> 42158,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=673981}**
> *
> Google point me to some renaming issues, which I did. But no idea how to
> fix this.
>
>
> Any Idea to fix this.
> Thank you very much.
>
> --
> 
>
> Get a first impression of our solution 
> http://engineering.amitego.com/youtube/gaincontrol.htm
>
> 
>
> *amitego engineering GmbH*
>
> CEO/CTO Tillmann A. Basien
>
> Balinger Straße 37A
>
> D-70567 Stuttgart
>
> Fon: +49 (0) 711 78 78 166-0
>
> Hy : +49 (0) 173 87 38 987
>
> *** Oracle Gold Partner ***
>
> mailto:t...@amitego.com / http://engineering.amitego.com HRB: 23711
>
> This message and any files or documents attached are strictly
> confidential or otherwise legally protected. It is intended only for the
> individual or entity named. If you are not the named addressee or have
> received this email in error, please inform the sender immediately,
> delete it from your system and do not copy or disclose it or use it for
> any purpose. Please also note that transmission cannot be guaranteed to
> be secure or error-free.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Need help /tips SQLITE_CONSTRAINT: abort at 42

[Tillmann Basien]

my fossil repository has a branch which cannot be merged into another one.

Fossil: This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC
I already did fossil rebuild.

This is the last line after:  fossil merge -n 


*SQLITE_CONSTRAINT: abort at 42 in [INSERT INTO 
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT 
42158,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=673981]: 
UNIQUE constraint failed: vfile.pathname, vfil**
**/usr/local/bin/fossil: UNIQUE constraint failed: vfile.pathname, 
vfile.vid: {INSERT INTO 
vfile(vid,chnged,deleted,rid,mrid,isexe,islink,pathname)  SELECT 
42158,3,0,rid,mrid,isexe,islink,pathname FROM vfile WHERE id=673981}**

*
Google point me to some renaming issues, which I did. But no idea how to 
fix this.



Any Idea to fix this.
Thank you very much.

--


Get a first impression of our solution  
http://engineering.amitego.com/youtube/gaincontrol.htm




*amitego engineering GmbH*

CEO/CTO Tillmann A. Basien

Balinger Straße 37A

D-70567 Stuttgart

Fon: +49 (0) 711 78 78 166-0

Hy : +49 (0) 173 87 38 987

*** Oracle Gold Partner ***

mailto:t...@amitego.com / http://engineering.amitego.com HRB: 23711

This message and any files or documents attached are strictly 
confidential or otherwise legally protected. It is intended only for the 
individual or entity named. If you are not the named addressee or have 
received this email in error, please inform the sender immediately, 
delete it from your system and do not copy or disclose it or use it for 
any purpose. Please also note that transmission cannot be guaranteed to 
be secure or error-free.



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [TCLCORE] FYI - tcl core - unintended fork

[Jan Nijtmans]

2016-07-05 16:18 GMT+02:00 Jan Nijtmans:
> But  there is currently a bug in fossil which shows
> a closed fork with an additional arrow going up. Now I don't
> have an example any more showing this ;-(

Never mind ... found it:


Regards,
  Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [TCLCORE] FYI - tcl core - unintended fork

[Jan Nijtmans]

2016-07-05 15:43 GMT+02:00 Donal K. Fellows:
> It's corrected now.

Yes, thanks!But  there is currently a bug in fossil which shows
a closed fork with an additional arrow going up. Now I don't
have an example any more showing this ;-(

It appears that the fossil bug was introduced with this commit:

investigating ..

This appears to fix the bug, probably not the right fix . but it works.


Regards,
Jan Nijtmans
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users