Can ZFS sync=disabled cause corruption of previously written data?
If sync=disabled is set, I understand that the ZIL isn't written to disk and, instead, changes are written directly to disk. Aside from possibly inconsistent data from an application-standpoint due, especially in networked situations where data that is supposedly committed is not and thus not written after storage comes back on-line, are there any other data corruption risks? More specifically, if I have a snapshot I have previously taken of the data, is that data at risk of being corrupted?
For example, suppose I have some kiosk machines running off an iSCSI volume that I restore to a snapshot daily. Suppose, further, that I've disabled sync and the server crashes mid-write (perhaps updating some file system structures). Is it guaranteed that if I run a zfs rollback operation that the snapshot I roll back to is still consistent and that any other volumes in the same pool (say, with sync=always) are not trashed?
If it matters, I'm running Solaris 11.3 or 11.4.
zfs
asked Dec 30 '18 at 17:13
lungjlungj
316112
add a comment |
If sync=disabled is set, I understand that the ZIL isn't written to disk and, instead, changes are written directly to disk. Aside from possibly inconsistent data from an application-standpoint due, especially in networked situations where data that is supposedly committed is not and thus not written after storage comes back on-line, are there any other data corruption risks? More specifically, if I have a snapshot I have previously taken of the data, is that data at risk of being corrupted?
For example, suppose I have some kiosk machines running off an iSCSI volume that I restore to a snapshot daily. Suppose, further, that I've disabled sync and the server crashes mid-write (perhaps updating some file system structures). Is it guaranteed that if I run a zfs rollback operation that the snapshot I roll back to is still consistent and that any other volumes in the same pool (say, with sync=always) are not trashed?
If it matters, I'm running Solaris 11.3 or 11.4.
zfs
asked Dec 30 '18 at 17:13
lungjlungj
316112
add a comment |
If sync=disabled is set, I understand that the ZIL isn't written to disk and, instead, changes are written directly to disk. Aside from possibly inconsistent data from an application-standpoint due, especially in networked situations where data that is supposedly committed is not and thus not written after storage comes back on-line, are there any other data corruption risks? More specifically, if I have a snapshot I have previously taken of the data, is that data at risk of being corrupted?
For example, suppose I have some kiosk machines running off an iSCSI volume that I restore to a snapshot daily. Suppose, further, that I've disabled sync and the server crashes mid-write (perhaps updating some file system structures). Is it guaranteed that if I run a zfs rollback operation that the snapshot I roll back to is still consistent and that any other volumes in the same pool (say, with sync=always) are not trashed?
If it matters, I'm running Solaris 11.3 or 11.4.
zfs
asked Dec 30 '18 at 17:13
lungjlungj
316112
If sync=disabled is set, I understand that the ZIL isn't written to disk and, instead, changes are written directly to disk. Aside from possibly inconsistent data from an application-standpoint due, especially in networked situations where data that is supposedly committed is not and thus not written after storage comes back on-line, are there any other data corruption risks? More specifically, if I have a snapshot I have previously taken of the data, is that data at risk of being corrupted?
For example, suppose I have some kiosk machines running off an iSCSI volume that I restore to a snapshot daily. Suppose, further, that I've disabled sync and the server crashes mid-write (perhaps updating some file system structures). Is it guaranteed that if I run a zfs rollback operation that the snapshot I roll back to is still consistent and that any other volumes in the same pool (say, with sync=always) are not trashed?
If it matters, I'm running Solaris 11.3 or 11.4.
zfs
zfs
asked Dec 30 '18 at 17:13
lungjlungj
316112
asked Dec 30 '18 at 17:13
lungjlungj
316112
asked Dec 30 '18 at 17:13
lungjlungj
316112
asked Dec 30 '18 at 17:13
lungjlungj
316112
asked Dec 30 '18 at 17:13
lungjlungj
316112
316112
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The short answer is that snapshots cannot be corrupted by future writes, even when you’ve disabled the ZIL. Also, nothing you do to one dataset should affect any other dataset (besides properties being inherited from parent dataset to child dataset, but that doesn’t affect the data itself). Old data could be corrupted if there’s a cosmic ray, or a major bug causing data to be overwritten (which I have never heard of), but either of those would be detected through checksum failures.
Of course, if sync is disabled when you take the snapshot, you might end up with application-level corruptions (same guarantees as if you crash and reboot). That has nothing to do with writes after the snapshot though.
answered Dec 31 '18 at 7:41
DanDan
698314
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1389021%2fcan-zfs-sync-disabled-cause-corruption-of-previously-written-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The short answer is that snapshots cannot be corrupted by future writes, even when you’ve disabled the ZIL. Also, nothing you do to one dataset should affect any other dataset (besides properties being inherited from parent dataset to child dataset, but that doesn’t affect the data itself). Old data could be corrupted if there’s a cosmic ray, or a major bug causing data to be overwritten (which I have never heard of), but either of those would be detected through checksum failures.
Of course, if sync is disabled when you take the snapshot, you might end up with application-level corruptions (same guarantees as if you crash and reboot). That has nothing to do with writes after the snapshot though.
answered Dec 31 '18 at 7:41
DanDan
698314
add a comment |
The short answer is that snapshots cannot be corrupted by future writes, even when you’ve disabled the ZIL. Also, nothing you do to one dataset should affect any other dataset (besides properties being inherited from parent dataset to child dataset, but that doesn’t affect the data itself). Old data could be corrupted if there’s a cosmic ray, or a major bug causing data to be overwritten (which I have never heard of), but either of those would be detected through checksum failures.
Of course, if sync is disabled when you take the snapshot, you might end up with application-level corruptions (same guarantees as if you crash and reboot). That has nothing to do with writes after the snapshot though.
answered Dec 31 '18 at 7:41
DanDan
698314
add a comment |
The short answer is that snapshots cannot be corrupted by future writes, even when you’ve disabled the ZIL. Also, nothing you do to one dataset should affect any other dataset (besides properties being inherited from parent dataset to child dataset, but that doesn’t affect the data itself). Old data could be corrupted if there’s a cosmic ray, or a major bug causing data to be overwritten (which I have never heard of), but either of those would be detected through checksum failures.
Of course, if sync is disabled when you take the snapshot, you might end up with application-level corruptions (same guarantees as if you crash and reboot). That has nothing to do with writes after the snapshot though.
answered Dec 31 '18 at 7:41
DanDan
698314
The short answer is that snapshots cannot be corrupted by future writes, even when you’ve disabled the ZIL. Also, nothing you do to one dataset should affect any other dataset (besides properties being inherited from parent dataset to child dataset, but that doesn’t affect the data itself). Old data could be corrupted if there’s a cosmic ray, or a major bug causing data to be overwritten (which I have never heard of), but either of those would be detected through checksum failures.
Of course, if sync is disabled when you take the snapshot, you might end up with application-level corruptions (same guarantees as if you crash and reboot). That has nothing to do with writes after the snapshot though.
answered Dec 31 '18 at 7:41
DanDan
698314
answered Dec 31 '18 at 7:41
DanDan
698314
answered Dec 31 '18 at 7:41
DanDan
698314
answered Dec 31 '18 at 7:41
DanDan
698314
698314
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1389021%2fcan-zfs-sync-disabled-cause-corruption-of-previously-written-data%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
