>> > Thanks for quick reply. Unfortunately in this case logrotate is not an
>> > option.
>> > Is it possible to update the snapshot not each night but when cache is
>> > full?
>>
>> The problem is, if you have a 1GB file on the hard disk (which would be a ro
>> branch for unionfs), whenever you append to it, Unionfs will copy the entire
>> file into the rw branch, and append the data there. So, with a 4GB flash
>> disk, all you have to do is append to 8, 512MB files stored on the disk, and
>> your flash is full.
>
>I was doing work for a while on a "sparse" version of unionfs where
>instead of copying up the files, it did a versionfs type block based
>system, where it would create a sparse file on "copyup" and use a bitmap
>file to determine which blocks were in which files.
>
>unfortunately, it was never that stable and it performance sucked
>(basically only useful for append only things like log files).
There is a problem (or advantage) with sparse copyup. Consider the
following action table (dirs=/B=rw:/A=ro):
Current unionfs CVS
Action | BRANCH A | BRANCH B | UNION VIEW
------------------------------------+----------+----------+------------
mount union | 0000 | - | 0000
make changes to some range | 0000 | 0001 | 0001
umount union | 0000 | 0001 | 0001
make changes to the underlying file | 1000 | 0001 | 0001
0 = some bytes filled with 0
1 = some bytes filled with 1
- = sparse bytes
With sparse copyup:
Action | BRANCH A | BRANCH B | UNION VIEW
------------------------------------+----------+----------+------------
mount union | 0000 | - | 0000
make changes to some range | 0000 | ---1 | 0001
umount union | 0000 | ---1 | 0001
make changes to the underlying file | 1000 | ---1 | 1001
0001 vs 1001 - whoops! Though modifying underlying files is unsupported while
mounted, you see that this issue persists _across_ a not-mounted union.
-`J'
--
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
