On Aug 12 2016, Brandon Orwell <[email protected]> wrote:
> (As a note - to the S3QL documentation editor - according to Amazon, the
> "Standard Region" now offers immediate consistency ("read after write") as
> of June 19, 2015. You may update your documentation to reflect this if you
> like as the current documentation reflects that it is "Unknown" and not
> immediate. For more, check out
> https://forums.aws.amazon.com/ann.jspa?annID=3112).
Thanks, could you file a bug for this?
> In definite terms, for ensuring the best consistency of my data integrity,
> how often should I run per-filesystem (I have 3 now) fsck.s3ql, and how
> often should I run s3ql_verify?
Obviously, for best consistency you want to identify problems as soon as
possible. So the theoretically best solution is to run both fsck.s3ql
and s3ql_verify continoussly in a loop.
Obviously, you don't want to do this in practice. There is no definite
answer to "best". It depends on the trade-offs you want to make -
i.e. how much money/time you are willing to invest for how much
reduction in risk.
> How long would s3ql_verify take,
> approximately, on a filesystem approximately 2TB in size?
Depends on your connection speed and computer speed.
> Are objects
> pulled - that is, can I expect to pay for data object retrieval for each
> invocation of s3ql_verify?
Only if you use the --data option.
> If an object is corrupt and s3ql_verify deletes
> it,
s3ql_verify doesn't delete objects. Did you read the documentation?
> and then fsck.s3ql detects the missing object, do I need a copy of the
> object on the local filesystem for it to duplicate from or does it have
> some kind of backup of that object somewhere on the S3QL fs?
I don't understand the question. If the backend looses an object, then
s3ql moves what's left of the affected files to lost+found.
> Please excuse me as I am not too familiar with filesystems under-the-hood,
> but I'd like to know the best practices for maintaining a S3QL filesystem
> for long periods of time as I am storing quite a lot of our data with
> it.
Reading the manual would be a good starting point then.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
