Re: Compressed Pristines (Summary)

>________________________________
> From: Daniel Shahaf <danielsh_at_elego.de>
>To: Ashod Nakashian <ashodnakashian_at_yahoo.com>
>Cc: Markus Schaber <m.schaber_at_3s-software.com>; "julianfoad_at_btopenworld.com" <julianfoad_at_btopenworld.com>; "mtherieau_at_gmail.com" <mtherieau_at_gmail.com>; Subversion Development <dev_at_subversion.apache.org>
>Sent: Wednesday, April 4, 2012 9:46 AM
>Subject: Re: Compressed Pristines (Summary)
>
>> >1.  Filesystem compression.
>> >
>> >Would you like to assess the feasibility of compressing the pristine
>> >store by re-mounting the "pristines" subdirectory as a compressed
>> >subtree in the operating system's file system?
>>
>> No :-)
>>
>> There are two ways to answer this interesting proposition of
>> compressed file-systems. The obvious one is that it isn't something
>> SVN can or should control. The file-system and certainly system
>> drivers are up to the user and any requirement or suggestion of
>> tempering with them is decidedly unwarranted and unexpected from
>> a VCS.
>
>The suggestion wasn't that you teach svn how to change the OS's fs
>settinsg, it was that you investigate how solutions at the OS level
>compare to the other approaches already suggested (custom format -based
>and sqlite-based pristine store).

That's an easy question. The answer is that at *best* they'll do as good as in-place compression. However, in practice they'll do much worse. The reason is that the OS level compression works on not only the single file level, but actually at the block level. This is to make modifications reasonably fast (read compressed data, uncompress, modify, write recompressed data). If the complete file is compressed then even changing a single byte (neglecting that no storage works on the byte-level anyway) will yield performance that will at least linearly degrade by the filesize.

>
>In short: if 'mount -o compress=yes' provides 90% space savings then we
>would have little reason to implement space-saving solutions in svn itself.
>But it's the user's, not svn's, responsibility to run that.

I should kindly disagree here. The user can do that any time, anyway. SVN is trying to improve its pristine store design, not advise users on how best to organize their storage (in general or when using SVN). In addition, I find discriminating against users who don't have that luxury or knowledge to be a bit unfair. At least if are claiming to support the wide range of systems that we do.

-Ash

>
Received on 2012-04-04 19:19:22 CEST