Enhancement: don't start if not enough room for block cache file

[Kirin-kun]

Got caught by this: I had a parameter for the blockCacheSize.

But then I decided to move it on another partition, but it was smaller than the previous blockCacheSize and I forgot to change the size before starting.

s3backer started normally and began to fill up the cache... until it couldn't anymore because the filesystem was full.

And then everything went awry...

A simple check if (blockSize * blockCacheSize) is available (or maybe attempt to preallocate it?) should be enough.

[archiecobbs]

There are two levels of functionality desired here...

First, at a minimum s3backer should behave reasonably when the disk fills up. E.g., it should not crash or corrupt the disk cache, and it should return some reasonable error back to the OS when it can't fulfill a write request.

Are you seeing anything other than "reasonable" behavior?

Secondly, a "nice to have" would be to do what you're suggesting which is check available disk space. This idea is (a) somewhat out of scope, and (b) not really solvable because available disk space can change at any time. So it's a little questionable. However it may be easy to do a one-time check on startup and issue a warning. I'll look into that.

[Kirin-kun]

Well, s3backer didn't crash.

I started to have errors on my zfs filesystem, which decided to suspend the I/O. Reasonable.

I looked at the log and there was a bunch of :

Dec 3 09:20:00 i-xxx s3backer: error reading cached block! Invalid argument Dec 3 09:20:05 i-xxx s3backer: error reading cache file `/mnt/cache/s3cache' at offset 19281936384: file is truncated

At this point, I had to reboot the instance because I was caught in a deadlock, where I couldn't export my pool so couldn't unmount the fuse filesystem.

And my idea of a "nice to have" was only like your last suggestion: issue a warning/error if the projected size of the cache file isn't available on the disk on startup.

Just a one time thing. It should be enough for the user to react.

[Kirin-kun]

And I don't know if s3backer can be called reasonable or not.

It produced I/O errors that were reported to the filsystem driver and it all went downhill. I don't know what happened to the cache file anyway, ie, if it was corrupted or not.

But a reasonable behavior would probably be to work with what space is available at the moment, up to the blockCachesize, which is a maximum since the cache isn't pre-allocated.

[Kirin-kun]

Right, there was additional errors in the log before those above that I forgot to copy/paste:

Dec  3 09:09:54 i-xxx s3backer: error writing cache file `/mnt/cache/s3cache' at offset 19976093696: Unknown error -1
Dec  3 09:09:54 i-xxx s3backer: error updating dirty block! Unknown error -1
Dec  3 09:09:54 i-xxx s3backer: error writing cache file `/mnt/cache/s3cache' at offset 19977142272: Unknown error -1
Dec  3 09:09:54 i-xxx s3backer: error updating dirty block! Unknown error -1

And after a while it turned in "error reading cached block! Invalid argument"

[archiecobbs]

Looks like the error codes got mixed up... easy to fix.

Warning added in fdc09da.

[Kirin-kun]

Just a question: does your warning take into account a previous cache file in its calculation?

Ie, for example, you have a partition of 1.5Gb and you want a cache file of 1Gb.

You already have a cache file with the same name in there, from a previous run (with dirty blocks or not) of 1GB.

So, there's 500Mb left.

Does it still issue a warning? Even if, technically, the space left is lower than 1Gb, it will still have enough room, since the existing file will be reused. So a warning would be weird.

[archiecobbs]

Good question.

It should account for that. The check compares available space in the partition to the maximum file size minus the space already used by the file. In other words, "Given how much MORE space this file might need, is there that much space available?"