On Thu, May 16, 2019 at 04:54:42PM +0200, Axel Burri wrote: > Trying to get the size of a subvolume created using "btrfs receive", > I've come with a cute little script: > > SUBVOL=/path/to/subvolume > CGEN=$(btrfs subvolume show "$SUBVOL" \ > | sed -n 's/\s*Gen at creation:\s*//p') > btrfs subvolume find-new "$SUBVOL" $((CGEN+1)) \ > | cut -d' ' -f7 \ > | tr '\n' '+' \ > | sed 's/\+\+$/\n/' \ > | bc > > This simply sums up the "len" field from all modified files since the > creation of the subvolume. Works fine, as btrfs-receive first makes a > snapshot of the parent subvolume, then adds the files according to the > send-stream. > > Now this rises some questions: > > 1. How accurate is this? AFAIK "btrfs find-new" prints real length, not > compressed length. > > 2. If there are clone-sources in the send-stream, the cloned files > probably also appear in the list. > > 3. Is there a better way? It would be nice to have a btrfs command for > this. It would be straight-forward to have a "--summary" option in > "btrfs find-new", another approach would be to calculate and dump the > size in either "btrfs send" or "btrfs receive". btrfs find-new also doesn't tell you about deleted files (fairly obviously), so if anything's been removed, you'll be overestimating the overall change in size. > Any thoughts? I'm willing to implement such a feature in btrfs-progs if > this sounds reasonable to you. If you're looking for the incremental usage of the subvolume, why not just use the "exclusive" value from btrfs fi du? That's exactly that information. (And note that it changes over time, as other subvols it shares with are deleted). Hugo. -- Hugo Mills | Your problem is that you've got too much taste to be hugo@... carfax.org.uk | a web developer. http://carfax.org.uk/ | PGP: E2AB1DE4 | Steve Harris
Attachment:
signature.asc
Description: Digital signature
