Re: 5 _thousand_ snapshots? even 160? (was: device balance times)

[Robert White <rwhite@pobox.com>]

On 10/22/2014 01:08 PM, Zygo Blaxell wrote:
> I have datasets where I record 14000+ snapshots of filesystem directory
> trees scraped from test machines and aggregated onto a single server
> for deduplication...but I store each snapshot as a git commit, not as
> a btrfs snapshot or even subvolume.
>
> We do sometimes run queries like "in the last two years, how many times
> did $CONDITION occur?" which will scan a handful files in all of the
> snapshots.  The use case itself isn't unreasonable, although using the
> filesystem instead of a more domain-specific tool to achieve it may be.
>

Okay, sure. And as stated by others, there _are_ use cases that are 
exceptional.

But such an archival system most likely does not _need_ to be balanced 
etc with any frequency, or likely ever because it isn't experiencing 
churn from dynamic use.

In the world of trade-offs, trade-offs happen.

The guy who cited the 5000 snapshots said they were hourly and taken 
because he might remove an important file or something. This is _way_ 
more action than the feared condition.

ASIDE: While fixing someone's document archive RAID device (a Sun 
hardware device the size of a fridge) back in 1997 or so I discovered 
that they'd disabled _all_ the hardware cache features. When asked I was 
told that "the procedure for replacing a failed drive required the cache 
device to be cleared by pressing the red button" and they were afraid 
that, should that day come, someone would forget to press that button... 
so they'd turned off the feature entirely. This is a form of 
unreasonable paranoia. They were afraid that someone in the future would 
not follow the directions would be printed on both the machine and the 
new drive (these were _not_ commodity parts).

When an over-abundance of caution passes beyond reasonable expectations, 
performance will suffer. The system is immaterial, the rule holds.

What's worse is it becomes very like "security theater" only its "a 
backup show" where no actual backing up is really happening in any 
useful sense. And god save you picking which version of a file was the 
last "good one".

So in your use case, your git repository of snapshots isn't actually 
"live" on the production server you are archiving, right?

So too, it would be reasonable to btrfs send periodic snapshots to an 
archive system, retain lots and lots of them, and expect reasonable 
performance of your queries.

And you cold expect reasonable performance in your maintenance.

But "reasonable performance" in the maintenance case is massively 
different than reasonable performance in use cases. Indeed if you try to 
balance multiple terabytes of data spread across thousands of snapshots 
you'll be taking a lot of time. A _perfectly_ _reasonable_ lot of time 
for the operation at hand.

But if you expect to be able to do maintenance (like btrfsck your 
production box with its 5k snapshots) in just a few minutes when you've 
got logarithmic-rate meta data to shuffle through... well good luck with 
that.