On 2021-06-22 at 10:53 +0100, Nikolaus Rath wrote: > On Jun 22 2021, Ivan Shapovalov <[email protected]> wrote: > > I'm also worried about the s3ql block cache. If I'm going to use > > s3ql > > in this setup at all, no matter the block size, it means I'll be > > writing 1 TB of data daily(!) to the SSD that holds the block > > cache. > > > > Is this solvable in s3ql somehow? I'd just put it in RAM (reducing > > the > > cache size to something like 1 GiB which I can spare), but the > > cache > > directory also holds the metadata, which needs to be non-volatile. > > The cache is in a -cache subdirectory. You might be able to symlink > that > / mount over it. Note that the name depends on the storage URL > though.
Fair enough. It's kinda fragile (I'd really prefer if block cache and metadata cache were configurable separately, might write a patch if I get around to it), but indeed it will work. A more serious question, though: what if the machine crashes or loses power and I lose the cache contents? Is this handled gracefully in fsck.s3ql (any way other than crashing / abandoning the filesystem)? > > > Best, > -Nikolaus > > -- > GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F > > »Time flies like an arrow, fruit flies like a Banana.« > -- Ivan Shapovalov / intelfx / -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/s3ql/3ffa2aac1cdc59512762aefc54e54eabf7730264.camel%40intelfx.name.
signature.asc
Description: This is a digitally signed message part
