2012-02-14 20:28:16 +00:00
|
|
|
Currently, `git annex status` only shows the size of 1 copy of each file.
|
|
|
|
If numcopies is being used for redundancy, much more disk can actually be
|
|
|
|
in use than status shows.
|
|
|
|
|
|
|
|
One idea:
|
|
|
|
|
|
|
|
known annex size: 2 terabytes (plus 4 terabytes of redundant copies)
|
|
|
|
|
|
|
|
But, to get that number, it would have to walk every location log,
|
|
|
|
counting how many copies currently exist of each file. That would make
|
|
|
|
status a lot slower than it is.
|
|
|
|
|
|
|
|
One option is to just put it at the end of the status:
|
|
|
|
|
|
|
|
redundancy: 300% (4 terabytes of copies)
|
|
|
|
|
|
|
|
And ctrl-c if it's taking too long.
|
|
|
|
|
|
|
|
Hmm, fsck looks at that same info. Maybe it could cache the redundancy
|
|
|
|
level it discovers? Since fsck can be run incrementally, it would be tricky
|
|
|
|
to get an overall number. And the number would tend to be stale, but
|
|
|
|
then again it might also be nice if status shows how long ago the last fsck
|
|
|
|
was.
|
2018-10-03 17:42:56 +00:00
|
|
|
|
|
|
|
> `git annex info .` now includes this, which is basically the same
|
|
|
|
> idea:
|
|
|
|
|
|
|
|
combined size of repositories containing these files: 711.4 gigabytes
|
|
|
|
|
|
|
|
> I think that's close enough, it doesn't calculate a percentage, but
|
|
|
|
> it tells the total size of the directory earlier so the same information
|
|
|
|
> is there. [[done]] --[[Joey]]
|