Y prosiect OpenZFS 2.2.1, sy'n datblygu gweithrediad system ffeiliau ZFS ar gyfer Linux a FreeBSD. Mae'r datganiad yn nodedig am ychwanegu cefnogaeth i'r cnewyllyn. Linux 6.6 ac ymgais i ddileu'r broblem sy'n arwain at lygredd data (sero rhai blociau) mewn ffeiliau ar ôl iddynt gael eu copïo.
I ddechrau, tybiwyd bod y broblem yn ymddangos yn y gangen 2.2.x yn unig ac yn cael ei achosi gan gamgymeriad yn y mecanwaith clonio bloc a gynhwysir yn OpenZFS 2.2.0, sy'n eich galluogi i greu copi o ffeil neu ran ohoni heb ddyblygu data, gan ddefnyddio yn yr ail gopi cyfeiriadau at flociau data sydd eisoes yn bodoli o'r ffeil ffynhonnell heb eu copïo gwirioneddol. Yn OpenZFS 2.2.1, i rwystro'r broblem, analluogwyd y mecanwaith clonio bloc yn ddiofyn, ac ychwanegwyd y gosodiad zfs_bclone_enabled i ddychwelyd cefnogaeth ar gyfer y modd hwn.
Yn ddiweddarach, adroddodd y datblygwyr eu bod wedi atgynhyrchu'r broblem mewn ffurfweddiadau gyda'r gangen OpenZFS 2.1.x. Ni chadarnhawyd y dybiaeth bod y broblem yn amlygu ei hun ar systemau gyda fersiynau hŷn o'r pecyn coreutils chwaith—atgynhyrchwyd y gwall yn llwyddiannus yn FreeBSD a Linux-dosbarthiadau gyda'r datganiad diweddaraf o coreutils 9.4.
Mae llygredd ffeil yn digwydd o dan amgylchiadau eithaf prin, er enghraifft, mae rhedeg y gorchymyn "emerge -1 dev-lang/go" yn Gentoo yn arwain at osod y pecyn cymorth Go gyda ffeiliau llygredig yn y /usr/lib/go/pkg/tool/ linux_amd64/ cyfeiriadur. llunio. Tybir bod y gwall wedi dechrau ymddangos ar ôl gosod y paramedr rhagosodedig “zfs_dmu_offset_next_sync=1” yn fersiwn openzfs 2.1.4. Nid yw ffynhonnell y gwall wedi'i nodi eto. Fel ateb a argymhellir ar gyfer atal y gwall, cynigir gosod y paramedr “/ sys/module/zfs/parameters/zfs_dmu_offset_next_sync” i 0.
Ffynhonnell: opennet.ru
