Re: Data authentication for geli(8) committed to HEAD.

Pawel Jakub Dawidek wrote:
> One of the main design goals was to make it reliable and resistant to
> power failures or system crashes. This was very important to commit both
> data update and HMAC update as an atomic operation to the disk, so users
> don't have to fight with false positives.

Great stuff. I take this opportunity to hijack this thread and ask I
question that has been bothering me a long time now.

I have an external HDD that I initially attached via Firewire, but I've
since switched to USB, as our firewire subsystem is less than rock
solid. When configuring geli encryption on the drive, I made the folly
of using 4kB sectors, as this should improve performance. But, it has a
disastrous impact on data integrity if your system crashes.

Now, I don't know if I'm right with the following thoughts, so please
correct me if I'm wrong.

Consider an mtime or atime update. You need to update 4 bytes on the
disk, which will be accomplished by writes of 512 bytes. If the system
crashes in between (I'm not talking about power failures), the disk has
either updated the 512 bytes, or not. No harm done.

With 4096 byte sectors and unencrypted data, the hard disk will have
written/updated 512 or 1024, ... or the whole 4096 bytes. Since only 4
bytes needed to be changed, you either got these changes or not. No harm
done.

Now consider encryption with 4096 byte sectors. Whenever you twiddle one
bit, the whole 4096 byte sector changes completely. To leave the disk in
a consistent state, you always have to make sure, that the whole 8
512-byte blocks are written to disk. If only a single 512-byte block is
not updated (due to kernel crashing because of that !_at_#^#$_at_ firewire),
the whole 4096 are useless. SoL.

The question really is, are 512 byte disk writes considered to be some
kind of "atomic" as it is the smallest disk block size? What does the
ATA subsystem do with writes of 4096? Are they completed atomically too,
or not?

Due to various kernel panics (no power failures involved!) I lost
several blocks of inodes on a 4096 byte sector geli mount. It's really
no fun, if fsck tells you that inodes 102340 - 109329 are lost.

Please note that I'm not asking any action from you, I'd simply
appreciated it, if someone could confirm or dispute my claims. Thanks.

Ulrich Spoerlein
-- 
 PGP Key ID: 20FEE9DD				Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70  6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.