On 09.04.2019 13:23, Julian Foad wrote: > I am working on an API to report the size on disk of a given revision, in > FSFS. A client wants this for (human) informational purposes -- so users or > administrators can understand how much space their commits are using. > > Before FSFS f7, this information was easy to obtain from the on-disk size of > a revision file, or for a packed shard by taking (offset[REV] - > offset[REV-1]) from the manifest file. Since f7 it's harder, when revisions > are packed. > > This seems a reasonable feature to me. > > The attached patch starts to implement it, providing an API in this form > which is like a cut-down version of svn_fs_fs__get_stats(): > > /* Set *REV_SIZE to the total size of objects belonging to revision REVISION > * in FS. */ > svn_error_t * > svn_fs_fs__get_rev_size(apr_off_t *rev_size, > svn_fs_t *fs, > svn_revnum_t revision, > apr_pool_t *scratch_pool); > > and a CLI in this form: > > $ svnfsfs rev-size /path/to/repo -r1 > 1238 bytes in revision 1 > > The definition of "size" I have chosen excludes the index entries, because > determining the on-disk size of them is tricky (they are stored in a > variable-length encoding) and their size is not particularly important for > the purposes. > > TODO before commit: > * support FSFS pre-f7 and physical addressing mode > * simplify implementation by using the existing svn_fs_fs__dump_index() API > with a simple callback > > Any comments?
Is there a reason why this would be hidden away in 'svnfsfs' instead of 'svnadmin'? Other than that the latter would have to return 'something' for BDB repositories. -- Brane
