LWN: Comments on "Btrfs: The Swiss army knife of storage (;login:)"

Btrfs: The Swiss army knife of storage (;login:)

geek — Fri, 24 Feb 2012 00:23:28 +0000

https://c59951.ssl.cf2.rackcdn.com/4376-bacik_0.pdf

this one worked for me

Btrfs: The Swiss army knife of storage (;login:)

Yenya — Fri, 17 Feb 2012 19:58:25 +0000

Thanks for the link - I was able to download the PDF from it, even though the page says "$5.00".

Btrfs: The Swiss army knife of storage (;login:)

dlang — Fri, 17 Feb 2012 19:31:46 +0000

it looks like the content is not free as of this time

https://www.usenix.org/publications/login/february-2012/b...

you may want to e-mail the author, in the past I've had cases where I wanted to discuss an article more publicly and the Author asked usenix to make the article available for free.

Btrfs: The Swiss army knife of storage (;login:)

Yenya — Fri, 17 Feb 2012 19:14:54 +0000

Both links to db.usenix.org return 502 bad gateway for me. Does it work for anybody, or is the content mirrored somewhere? Thanks!

Btrfs: The Swiss army knife of storage (;login:)

pbaum — Sat, 11 Feb 2012 19:29:13 +0000

This is what I call a killer feature.

Many thanks.

Peter

Btrfs: The Swiss army knife of storage (;login:)

bluss — Sat, 11 Feb 2012 17:04:49 +0000

yes, btrfs subvolume find-new <subvolume> <last_gen>

Btrfs: The Swiss army knife of storage (;login:)

nybble41 — Fri, 10 Feb 2012 17:03:37 +0000

> You can easily find parts (subdirs, etc.) of a snapshot which you can see are still identical because they are using the same storage. That saves you from having to do a brute-force comparison of the whole of the file system's contents with a backup.

Not only that, but it should be possible to use the back-references to determine specifically _which_ files from the older snapshot share storage with the file you're examining, meaning that you could (in theory) efficiently track renames and copies across the entire filesystem without comparing every file against every other file.

Btrfs: The Swiss army knife of storage (;login:)

dwmw2 — Fri, 10 Feb 2012 14:22:44 +0000

No, it wouldn't require extra information. When you make a snapshot, nothing is actually copied. You just end up with two pointers to the same tree. As either or both of them change, that's when the COW kicks in and new data are written out elsewhere as the trees diverge.

You can easily find parts (subdirs, etc.) of a snapshot which you can see are still identical because they are using the same storage. That saves you from having to do a brute-force comparison of the whole of the file system's contents with a backup.

But no, I don't believe this is implemented yet even though it's theoretically possible.

Btrfs: The Swiss army knife of storage (;login:)

khim — Fri, 10 Feb 2012 13:48:36 +0000

I doubt it. It'll require huge amount of useless (for other purposes) information to be kept around. Snapshot is basically just a directory COWed to other place. It can share it's content with any number of other directories and btrfs neither knows nor cares about that.

Btrfs: The Swiss army knife of storage (;login:)

pbaum — Fri, 10 Feb 2012 12:38:05 +0000

Is it possible with Btrfs to find the difference between two snapshots, so that one can do incremental backups without looking at all files?

Peter

Btrfs: The Swiss army knife of storage (;login:)

dlang — Thu, 09 Feb 2012 19:34:52 +0000

that's the normal method that LWN uses to indicate the source of the article

Btrfs: The Swiss army knife of storage (;login:)

PO8 — Thu, 09 Feb 2012 18:57:34 +0000

Yeah, probably needed to italicize or quote that one.

Btrfs: The Swiss army knife of storage (;login:)

patrick_g — Thu, 09 Feb 2012 18:21:53 +0000

It's the title of this magazine.

Btrfs: The Swiss army knife of storage (;login:)

Lumag — Thu, 09 Feb 2012 17:48:44 +0000

Hmm. What does that (;login:) mean?