Re: [s3ql] Re: S3QL cache directory and SSD longevity

[Ivan Shapovalov]

On 2021-06-22 at 10:53 +0100, Nikolaus Rath wrote:
> On Jun 22 2021, Ivan Shapovalov  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 s3ql+unsubscr...@googlegroups.com.
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

[s3ql] Re: S3QL cache directory and SSD longevity

[Nikolaus Rath]

On Jun 22 2021, Ivan Shapovalov  wrote:
> I tried with 10 MiB block size and this made s3ql to re-upload 300 GiB
> when just 30 were changed this particular day.

Does "30" refer to "30 MB of changes"? If so, then this isn't saying
anything.

If you change one byte every 10 MB, then S3QL would have to upload every
block even though you only changed 30 MB of data. If, on the other hand,
you write 30 MB in sequence, then S3QL should only upload 3 blocks. If
anything else happens, there is a bug (and it would be great if you
could construct a small testcase that reproduces it).


Best,
-Nikolaus

-- 
GPG 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 s3ql+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/s3ql/87lf7243z6.fsf%40vostro.rath.org.

[s3ql] Re: S3QL cache directory and SSD longevity

[Nikolaus Rath]

On Jun 22 2021, Ivan Shapovalov  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.


Best,
-Nikolaus

-- 
GPG 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 s3ql+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/s3ql/87o8by444n.fsf%40vostro.rath.org.

S3QL cache directory and SSD longevity (Was: Re: [s3ql] Optimal/minimum block size?)

[Ivan Shapovalov]

On 2021-06-15 at 02:29 +0200, Daniel Jagszent wrote:
> Hello intelfx,
> 
> > does s3ql have any practical/recommended limits on amount of blocks
> > in
> > a single filesystem? In other words, if I have, say, 10 TiB of
> > data,
> > what would be the minimum recommended block size?
> > 
> > My use-case (for this specific filesystem) is storing consolidated
> > Macrium Reflect backups — a large disk image which is updated in
> > place
> > daily. If I'm using a large block size (say, 100 or 500 MiB), this
> > basically causes the entire disk image to be retransmitted almost
> > entirely every time it is changed.
> > 
> > Can this be made to work at all?
> There is a theoretical limit of 2^64 blocks because that is the limit
> that sqlite  imposes. Before you get
> there your database size gets probably "too big to handle".
> 10 TiB of data with big files in the file system isn't that much that
> you need to worry about the database size. I have file systems for
> Bareos backups ranging from 5 TiB to 20 TiB. They have a maximum
> block
> size of 300 MiB because I feared that the database size would become
> unhandleable big. That fear was unwarranted. The database size is <
> 10
> MiB (uncompressed). If I would redo these file systems I would
> probably
> choose a smaller maximum block size of 25 MiB to better utilize the
> CPU
> cores.
> 
> For your use case (only small blocks of a big file change) lowering
> the
> maximum block size to 1 MiB to 5 MiB would be better. I guess this
> would
> make a database size (uncompressed) of ~ 1 GiB. I probably would not
> go
> below 1 MiB.
> 

Thanks.

I tried with 10 MiB block size and this made s3ql to re-upload 300 GiB
when just 30 were changed this particular day. I'm now trying with 1
MiB; interestingly, it doesn't seem to affect multithreaded upload
speed too much.

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.

-- 
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 s3ql+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/s3ql/d3155f561ad2e05f7ed27712d990e978194f38dd.camel%40intelfx.name.


signature.asc
Description: This is a digitally signed message part