subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ashod Nakashian <ashodnakash...@yahoo.com>
Subject Re: Compressed Pristines (Summary)
Date Wed, 04 Apr 2012 17:18:47 GMT
>________________________________
> From: Daniel Shahaf <danielsh@elego.de>
>To: Ashod Nakashian <ashodnakashian@yahoo.com> 
>Cc: Markus Schaber <m.schaber@3s-software.com>; "julianfoad@btopenworld.com" <julianfoad@btopenworld.com>;
"mtherieau@gmail.com" <mtherieau@gmail.com>; Subversion Development <dev@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


>

Mime
View raw message