Re: strange zfs size allocation data

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Is bup zfs-specific?
> No, it is a general backup program.  I just happen to have sources
> for it on zfs.  Which people tell me is a great filesystem and is now
> not odd on NetBSD....

Well, great for some use cases.  I have, for example, seen it said that
it's ludicrously RAM-hungry (as in, you need multiple gigs of RAM or
you shouldn't even think about using it).  This is fine if you have a
machine so overspecced that you have that much RAM to burn; it's less
great if you're looking for something more general-purpose.  (To be
fair, it also has upsides; for example, I think I've seen it described
as having the ability to add and remove partitions live, and as keeping
integrity checksums.)

>> Because, if you're not doing something filesystem-specific, I
>> actually think you will have trouble even _defining_ what "100%
>> right" is for this test, since everything about sparseness, right
>> down to whether it's even a thing, is filesystem-dependent.

> True.  the point is to try to verify that the backup program, when
> restoring a sparse file, writes it in such a way that the normal
> implementation of sparse files works, meaning results in a file
> without blocks storing all the zeros.

Fair point.  You might want to have the test verify that the filesystem
in use does support sparseness in the form you're looking for before
doing the rest of the testing.

> What you are missing, and everybody else too, is that the fact that
> this is theoretically impossible is irrelevant to it being useful in
> the real world, to detect regressions, even if it also occasionally
> detects bizarre behavior.

I, at least, haven't been missing that.  When you talk about getting a
test "100% right", though, I read that as including "...even in
relatively unlikely circumstances".

Running on msdosfs strikes me as unlikely enough to not care about.
tmpfs, though, is relatively plausible as a filesystem for tests.

> A better test would be 'fuse-sparsetest' that makes metadata
> available for inspection later about the writes it sees.  But that's
> hard to write.

You could get much of that information by ktracing and looking for the
relevant calls - {,p}write{,v} and lseek seem to me to be the most
likely candidates.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B