forked from luck/tmp_suning_uos_patched
457b1e353c
When ext4 encryption support was first added, ZERO_RANGE was disallowed,
supposedly because test failures (e.g. ext4/001) were seen when enabling
it, and at the time there wasn't enough time/interest to debug it.
However, there's actually no reason why ZERO_RANGE can't work on
encrypted files. And it fact it *does* work now. Whole blocks in the
zeroed range are converted to unwritten extents, as usual; encryption
makes no difference for that part. Partial blocks are zeroed in the
pagecache and then ->writepages() encrypts those blocks as usual.
ext4_block_zero_page_range() handles reading and decrypting the block if
needed before actually doing the pagecache write.
Also, f2fs has always supported ZERO_RANGE on encrypted files.
As far as I can tell, the reason that ext4/001 was failing in v4.1 was
actually because of one of the bugs fixed by commit
|
||
|---|---|---|
| .. | ||
| acl.c | ||
| acl.h | ||
| balloc.c | ||
| bitmap.c | ||
| block_validity.c | ||
| dir.c | ||
| ext4_extents.h | ||
| ext4_jbd2.c | ||
| ext4_jbd2.h | ||
| ext4.h | ||
| extents_status.c | ||
| extents_status.h | ||
| extents.c | ||
| file.c | ||
| fsmap.c | ||
| fsmap.h | ||
| fsync.c | ||
| hash.c | ||
| ialloc.c | ||
| indirect.c | ||
| inline.c | ||
| inode-test.c | ||
| inode.c | ||
| ioctl.c | ||
| Kconfig | ||
| Makefile | ||
| mballoc.c | ||
| mballoc.h | ||
| migrate.c | ||
| mmp.c | ||
| move_extent.c | ||
| namei.c | ||
| page-io.c | ||
| readpage.c | ||
| resize.c | ||
| super.c | ||
| symlink.c | ||
| sysfs.c | ||
| truncate.h | ||
| verity.c | ||
| xattr_security.c | ||
| xattr_trusted.c | ||
| xattr_user.c | ||
| xattr.c | ||
| xattr.h | ||