Specifying sectorsize for encrypted swap partition can make kernel crash during swapping

Example,
Code:
/dev/ada2p2.eli    none         swap                          sw,ealgo=aes,keylen=128,sectorsize=16384 0 0
Error,
kernel: [370] swap_pager: I/O error - pageout failed; blkno 1950541,size 126976, error 22
 
Smells like a bug. The errno is EINVAL, and the size is 7-3/4 sectors of 16K each. Looks some internal code was trying to swap 4K blocks. Maybe this really isn't supported? The handbook isn't specific as to sector sizes, and I can't find it mentioned in man pages: the fstab(5) man page doesn't describe sectorsize limits (although it mentions the sectorsize parameter), the swapon(8) man page doesn't describe geli parameters at all, and the geli(8) man page doesn't mention the use of sectorsize for swap.
 
For me the handbook "suggest" larger sectorsizes.
Out of the handbook :
sectorsize
The size of the blocks data is broken into before it is encrypted. Larger sector sizes increase performance at the cost of higher storage overhead. The recommended size is 4096 bytes.
 
I saw that recommendation. But it never says where the upper limit is. You picked 16K. Why not 1M? Wouldn't that give even better performance?

The underlying problem is that the VM system manages memory in units of pages. And the includes making decisions on whether to swap, which is probably made on a page-by-page basis. On most architectures, the basic page size is 4K, and some also support superpages of 2M and larger. But if you say that the sectorsize of your swap device is 16K, it can't do IOs smaller than 16K Observe that the failed IO is a multiple of 4K. I suspect that sector sizes larger than 4K won't work, because the VM system makes swapping decisions page-by-page.
 
pageout failed; blkno 1950541,size 126976, error 22

look at the code and post what error 22 is

is pageout a block on it's way to being encrypted? or is it an encrypted block being written to disk? i read only the linux swap kernel design only (which has mem caching for app page overflows and virtualization of pages, overflow of main memory itself, and swapping to actual disk, all separate from actual hardware built-in caching of the CPU and HD).

I like the idea that the VM could have "re-negged" on a previous agreement/assumption. I'm not sure I'd be optimistic that changing the block size would fix.

Are you saying you change block size and the problem stopped already tested? And you tried this without encryption?

It's definitely a "HOT AREA", where while your paging a page might dis-appear be marked for dismissal: so everything "just has to be right" and the kernel the decider of what is asynchronous. Usually "distributed filesystems" have tons of bugs continually (along years of development) because somehow they thing there is a magic way around asychronous when: there ain't.
 
Back
Top