节点在Subversion中使用多少存储并不像看起来那么简单.我将讨论FSFS(仅提供FSFS的答案),因为这几乎可以肯定是您正在使用的文件系统实现.如果你正在使用BDB,那么事情会有所不同.
一个节点可以使用4种方式存储.节点,属性的实际文本或主体,以及现有的性质,它们在目录节点中使用存储来指出它们的存在(目录节点具有由其子节点和子节点的表示组成的主体),以及最后是文件系统的开销(当你提交一个文件时,它会冒泡到根目录的新表示形式,所以我认为存储的使用应该属于导致需要存储它的文件) .
文件文本和属性占用的空间相对容易,目录存储和开销更加困难.然而,即使对于文件文本相对容易的问题,由于表示共享,它仍然稍微复杂一些.表示共享发生在两个文件相同时(文件可能具有相同的名称,或者不重要,唯一重要的是它们的文本是相同的),我们避免再次存储它.
以下单行应回答单个文件的文件文本问题.
REPO=~/my-repo; FILE=/somebigfile; grep --recursive --no-filename --text --before-context 3 "cpath: $FILE" "$REPO/db/revs/"* | grep 'text:' | cut -d' ' -f 1-7 | sort -u | awk '{ DISK+=$4; if ($5 == 0) { FULL += $4 } else { FULL += $5 } } END { print DISK, FULL, FULL-DISK}'
您需要将REPO更改为设置为存储库的路径,并将FILE更改为存储库中所需文件的绝对路径.这可能不完美,因为我可能忘记了一些细节或其他细节.但让我来看看它的工作原理.
它会查找您要查找的文件的每个修订文件,询问前面的3行以及匹配行.然后它删除除了带有text:的行以外的所有内容(详细说明文本表示的行).然后我们排除最后一个字段(唯一符;用于区分共享表示).这允许我们将其限制为我们实际存储的唯一表示.然后我们将第5和第4个字段(分别是全文大小和表示大小)相加.全文大小可以为零,这意味着它与表示大小相同(我们存储的全文不是delta).最后,我们打印出以下字段:实际存储的大小,全文文件的所有版本的大小,最后差异(负数意味着我们的效率低于存储明文,积极意味着我们节省了大量空间).
文本数据的字段如下:
revision offset_in_rev_file size_of_rep size_of_full_text md5 sha1 uniquifier
较旧的存储库可能没有所有这些字段,这很好.
因为我依赖于文本字段在rev文件中的cpath字段的3行内(嘿这是一个快速的黑客)它可能无法完美地工作.您可能希望运行前两个grep命令而不需要其余所有命令,然后查看提供的修订版本(它们将是左侧的第一组数字).将其与svn log文件的outout进行比较.如果所有的转速都在那里,那么它应该是准确的.
如果我找到时间,我会尝试编写一个以正确的方式(使用SVN库)执行此操作的实用程序,这更有用.可能包括属性使用的存储,也可能包括我上面提到的一些其他存储.
TL; DR这不是一个容易回答的问题.使用上面的shell脚本来回答文件文本的存储.它将为您提供输出,即我们在磁盘上使用的空间,所有修订的全文空间,然后我们节省了多少(负面意味着我们由于增量开销而丢失了空间).
| 归档时间： |
|
| 查看次数： |
1171 次 |
| 最近记录： |