subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: enhancement suggestion
Date Tue, 20 Feb 2018 15:29:47 GMT
On 20.02.2018 15:59, Johan Corveleyn wrote:
> On Tue, Feb 20, 2018 at 1:11 PM, Christian Klie <> wrote:
>> Hello,
>> currently I made a huge commit. In respect of the number of the files (see
>> attachment "working copy").
>> While the commit went down the transaction grew and grew and grew (see
>> attachment "transaction").
>> That all happend because of the files in the transaction's folder being very
>> small but huge in number so
>> those have a relativly huge overheat, because of the blocksize. So I am
>> suggesting to rethink the commit procedure but I am not
>> sure whether to report this or not.
> So the directory 5-6.txn below db/transactions showed:
> - Number of files: 244295 (0 folders)
> - Size: 88.6 MB
> - Size on disk: 29.8 GB
> (Wow, that's huge! For only 88.6 MB of data in 244295 files, that's a
> factor of more than 300 compared to the actual data size)

344 exactly. The filesystem cluster is 128 KiB and the average file size
is 380 bytes. The cluster (allocation unit) size is quite large, which
suggests it may not be NTFS, or it is a really humongously huge volume. See:

> And your working copy showed:
> - 118094 files, 5350 folders
> - Size: 903 MB
> - Size on disk: 1.01 GB
> What SVN version is the server? What SVN version is the client?
> What version of back-end filesystem on the server (BDB or FSFS, which version)?
> -> If you have a 1.9 server, please send the output of "svnadmin info
> REPOS_PATH". Otherwise, send the contents of REPOS_PATH/format and of
> REPOS_PATH/db/format.
> The server is on Windows apparently. Which version of Windows? NTFS I
> presume? Anything special about that disk? Any special settings?
> Oh and one more question: do those files in your working copy have
> many svn properties?

You're missing the point, Johan ... the "enhancement suggestion" was to
"rethink the commit procedure". Having rethunked it, I suggest the
obvious cheapest solution would be to fix the underlying filesystem. :)

-- Brane

View raw message