On Apr 09 2020, Rabid Mutant <[email protected]> wrote:
> On Friday, April 10, 2020 at 4:09:01 AM UTC+10, Nikolaus Rath wrote:
>>
>>
>> My guess is that it is simple corruption of the data. The original email
>> said that the server crashed. This means that the SQLite database can
>> get corrupted.
>>
>
> Looking through snapshots of the database, it was corrupted 2 hours before
> the server was shut down (didn't crash, but an s3ql session was in progress
> at shutdown). The corruption was, I think, due to the device being full
> during an unmount, and SQLite not being able to rollback properly. This
> seems to fit with the history pretty well (mount.log showing device full
> errors, database snapshots being good before those errors, corrupt after).
>
> Obviously I am rethinking the hourly mount/rsync/unmount cycle since it's
> harder to ensure unmount at system shutdown, and have not moved everything
> to a drive with more space.
What makes it hard? You probably just have to increase a timeout
somewhere...
> Unfortunately, I have a lot of s3ql snapshots, which means I have a huge DB
> which takes about 5 minutes to sync to amazon; that time would be added to
> any shutdown so permanently mounting it is not a clear win.
Shutdown only requires a metadata upload if the data has changed since
the last upload (which you can trigger with s3qlctrl without needing to
unmount), so it's not always slow.
> If I do a lazy dismount, then shutdown, am I correct an fsck will still be
> needed? I guess the solution there would to always do an fsck before mount
> after system boot.
I'd very much advise against crashing the filesystem by default. I'd
just ensure that shutdown is blocked until the file system is unmounted,
no matter if you mount temporarily or permanently.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/s3ql/871rovpeso.fsf%40vostro.rath.org.
