On Mon, Mar 31, 2014 at 5:35 PM, Marc MERLIN <m...@merlins.org> wrote: > On Sat, Mar 29, 2014 at 05:21:23PM -0700, Marc MERLIN wrote: >> I had a look at >> http://bj0z.wordpress.com/2011/04/27/determining-snapshot-size-in-btrfs/#comment-35 >> but it's quite old and does not work anymore since userland became >> incompatible with it. >> >> Has anyone seen something newer or have a newer fixed version of this? > > While watching a btrfs send|receive going for hours, keeping the > backup disk array spinning in my living room, and my wondering "how far > is it from being done", I was thinking: > > Would it be reasonably simple for btrfs send -p to have a few more > features? > 1) don't read all the data from disk, just read the metadata and tell me > how many megabytes it will take to send. > I can do this with > btrfs send | wc -c > I believe, but it would be better if it could do this without reading all > the data blocks to send when I'm only caring about the byte output > > In turn this could be used to easily compute snapshot size diffs at > least from one another.
Totally agree. A progress indicator makes the feature much more user friendly. In fact this is something I had been thinking for a while, but didn't start implementation until a couple days ago after your mail. Here's a couple RFC patches (kernel and btrfs-progs) with a prototype: https://patchwork.kernel.org/patch/3938801/ https://patchwork.kernel.org/patch/3938811/ > > > 2) output a list of files added/changed/removed, maybe with how much > data is related to each. > Arguably this would supersede 1) above even if it would be a little bit > more work to do That would be cool I think. Most of what is needed is already implemented in the send code. You can get it somehow, in a not very user friendly way by passing the flag BTRFS_SEND_FLAG_NO_FILE_DATA to the send ioctl, which doesn't send any data back, only information about new/modified extent's offset and length and passing -vvv to btrfs receive. > > > 3) when a real btrfs send is running, just like dd, I could send it a > USR1 signal and it would output some kind of progress report. > The Ted T'so motto (used for e2fsck) is "everything with a progress bar > is faster" :) > Note, the progress wouldn't have to be perfect, it could be by number of > blocks, number of files, anything reasonably easy to implement it on. > > Does that sound reasonable? It does. > > Thanks, > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet > cooking > Home page: http://marc.merlins.org/ | PGP > 1024R/763BE901 -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
