mirror of
https://git.proxmox.com/git/mirror_zfs.git
synced 2024-11-17 10:01:01 +03:00
047187c1bd
When we try assign a new transaction to a TXG we must know beforehand if there is sufficient free space on disk. This is to decide, in dmu_tx_assign(), if we should reject the TX with ENOSPC. We rely on spa_get_worst_case_asize() to inflate the size of our logical writes by a factor of spa_asize_inflation which is calculated as: (VDEV_RAIDZ_MAXPARITY + 1) * SPA_DVAS_PER_BP * 2 == 24 The problem with the current implementation is that we don't take into account what happens with very small writes on VDEVs with large physical block sizes. Consider the case of writes to a dataset with recordsize=512, copies=3 on a VDEV with ashift=13 (usually SSD with 8K block size): every logical IO will end up allocating 3 * 8K = 24K on disk, so 512 bytes multiplied by 48, which is double the size we account for. If we allow this kind of writes to be assigned a TX it is possible, when the pool is almost full, to trigger an allocation failure (ENOSPC) in the ZIO pipeline, which will in turn result in the whole pool being suspended. The bug is fixed by using, in spa_get_worst_case_asize(), the MAX() value chosen between the logical io size from zfs_write() and the maximum physical block size used among our VDEVs. Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes #5941 |
||
---|---|---|
.github | ||
cmd | ||
config | ||
contrib | ||
etc | ||
include | ||
lib | ||
man | ||
module | ||
rpm | ||
scripts | ||
tests | ||
udev | ||
.gitignore | ||
.gitmodules | ||
AUTHORS | ||
autogen.sh | ||
configure.ac | ||
copy-builtin | ||
COPYRIGHT | ||
DISCLAIMER | ||
Makefile.am | ||
META | ||
OPENSOLARIS.LICENSE | ||
README.markdown | ||
TEST | ||
zfs-script-config.sh.in | ||
zfs.release.in |
ZFS is an advanced file system and volume manager which was originally
developed for Solaris and is now maintained by the Illumos community.
ZFS on Linux, which is also known as ZoL, is currently feature complete. It includes fully functional and stable SPA, DMU, ZVOL, and ZPL layers. And it's native!
Official Resources
Installation
Full documentation for installing ZoL on your favorite Linux distribution can be found at our site.
Contribute & Develop
We have a separate document with contribution guidelines.