Hi Andy, When replying to emails on this list, please do not put your reply above the quoted text, and do not quote the entire message you're answering to. This makes it unnecessarily hard for other readers to understand the context of your email. Instead, please cut quoted parts that are not relevant to your reply, and insert your responses right after the points you're replying to (as I have done below). Thanks!
On Jul 07 2015, Andy Cress <[email protected]> wrote: > On Mon, Jun 29, 2015 at 10:07 PM, Nikolaus Rath <[email protected]> wrote: >> On Jun 29 2015, Andy Cress <[email protected]> wrote: >>> Before starting a data copy to an s3ql filesystem, we would like to be >>> able to check whether or not the backend is there (can be contacted) >>> or not. >>> >>> The test case came up where the s3ql filesystem is mounted on a >>> system, and someone else deletes the bucket that it is mounted to. We >>> don't seem to be able to detect this, unless we do umount / mount. >>> s3qlstat shows the cached size information, but that doesn't help this case. >>> >>> Any thoughts on how this could be checked? >> >> Depends, you need to be more precise. What exactly do you want to check >> for? First you are talking about contacting the backend (e.g. if there's >> a connection to AWS), but then you are talking about detecting if a >> bucket has been removed (which has nothing to do with S3QL being able to >> talk to S3). >> >> However, in either case this will probably require additional >> programming in S3QL. > > I would like to have both levels of checking, if possible: > level 1 - can we still contact the backend > level 2 - can we still see the bucket > but adding either one would be helpful. Well, in case 1 S3QL will retry until the backend becomes available again. You could detect this by looking in ~/.s3ql/mount.log for messages of the form Encountered %s exception (%s), retrying call to %s.%s... For the second case I'm actually not sure. S3QL may bail out, or it may retry here as well. In either case, looking at mount.log is currently the only way to determine that this has happened (apart from the sudden disappearance of the mountpoint). I'd suggest to do an experiment to find out what happens. If you need something more sophisticated, you'll need to convince someone to add that functionality to S3QL. I personally have little interesting in this so I'm unlikely to use my spare time to work on this, but I'm willing to review patches and merge them if they fit reasonably well into S3QL's general architecture. Best, -Nikolaus PS: Please remember the first paragraph when replying. -- 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.
