Do `parted resizepart` and `resize2fs` not modify or remove existing files on a partition?
Clash Royale CLAN TAG#URR8PPP
Does parted's resizepart command by default not modify or remove existing files on a partition? Furthermore, does it never modify or remove existing files on a partition (even by some option)?
Similar questions for resize2fs?
Thanks.
partition parted resize2fs
asked Feb 18 at 16:11
TimTim
27.7k78265483
add a comment |
Does parted's resizepart command by default not modify or remove existing files on a partition? Furthermore, does it never modify or remove existing files on a partition (even by some option)?
Similar questions for resize2fs?
Thanks.
partition parted resize2fs
asked Feb 18 at 16:11
TimTim
27.7k78265483
add a comment |
Does parted's resizepart command by default not modify or remove existing files on a partition? Furthermore, does it never modify or remove existing files on a partition (even by some option)?
Similar questions for resize2fs?
Thanks.
partition parted resize2fs
asked Feb 18 at 16:11
TimTim
27.7k78265483
Does parted's resizepart command by default not modify or remove existing files on a partition? Furthermore, does it never modify or remove existing files on a partition (even by some option)?
Similar questions for resize2fs?
Thanks.
partition parted resize2fs
partition parted resize2fs
asked Feb 18 at 16:11
TimTim
27.7k78265483
asked Feb 18 at 16:11
TimTim
27.7k78265483
asked Feb 18 at 16:11
TimTim
27.7k78265483
asked Feb 18 at 16:11
TimTim
27.7k78265483
asked Feb 18 at 16:11
TimTim
27.7k78265483
27.7k78265483
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.
resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.
But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.
The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.
At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.
But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".
After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f501392%2fdo-parted-resizepart-and-resize2fs-not-modify-or-remove-existing-files-on-a%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
When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.
resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.
But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.
The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.
At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.
But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".
After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
add a comment |
When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.
resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.
But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.
The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.
At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.
But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".
After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
add a comment |
When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.
resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.
But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.
The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.
At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.
But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".
After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
When shrinking a filesystem, resize2fs first checks if the part of the filesystem that is going to be cut away is free. If not, it can try to move those files out of the area that will be cut away, if there is space to do so. If this cannot be done, it stops and reports an error without shrinking the filesystem.
resizepart does not care about the filesystem at all. It just changes the partition table to specify a new location where the partition now ends. It does not overwrite anything at or near that location. After modifying the partition table, it will signal the kernel that the partition table has been changed. The kernel will read the new table and apply it if possible.
But for the filesystem driver, the end of the partition will be a hard wall. If the filesystem was not shrunk before the partition was, or the partition was accidentally shrunk more than the partition was, a part of the filesystem will now be cut off from the rest.
The filesystem will assume that the cut-off space is still available, until it actually attempts to use it. At that point the part of the kernel that is responsible for mapping any partition-relative block numbers to actual whole-disk block numbers will return an error to the filesystem driver, as the filesystem is trying to access beyond the end of its partition. The filesystem driver will usually drop to read-only mode as such an error tends to indicate that the filesystem may be corrupted. At that point, the system administrator usually gets involved.
At this point, if the sysadmin realizes that the partition resize operation has cut off part of the filesystem, and undoes the partition resize operation, the filesystem can be fully accessed through the partition device again, and everything may still be just fine: the filesystem may need a fsck to clear the error flag, but the files will still be there. After mounting the filesystem again, the files that were bisected by the partition resize operation will be fully accessible again.
But if the sysadmin simply runs a filesystem check on the partition in its shrunken state, the filesystem checker will see that there are files that appear to continue beyond the end of the partition, and say to itself: "Let's amputate". Since it takes the partition size as a solid fact, it has no choice but to truncate or delete the files that seem to go beyond the end of the partition. This is where the actual damage is done. The filesystem metadata will also need some adjustment to remove the space that is beyond the end of the partition from the "books".
After the filesystem checker is done, the cut-off parts of the files are still there on the physical disk, beyond the new end of the partition, unchanged... but the parts of the files still inside the filesystem are now truncated into stumps.
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
answered Feb 18 at 21:32
telcoMtelcoM
19k12348
19k12348
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
add a comment |
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
If you run a file system check on a truncated file system, the checker will first report that the file system size is inconsistent with the underlying device, before it starts truncating or discarding files altogether.
– Stephen Kitt
Feb 19 at 9:03
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Sure. My point was that one wrong choice at that time is what ultimately causes the destruction of data. The detailed behavior of the checker can vary between filesystem types. Many filesystem checkers may offer a chance to stop at that point, but I'm not confident enough to say that all will.
– telcoM
Feb 19 at 9:11
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
Right, I wasn’t disagreeing, I thought it was worth pointing out that there is (at least in many cases) a size-based consistency check before the checker starts losing data.
– Stephen Kitt
Feb 19 at 9:37
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f501392%2fdo-parted-resizepart-and-resize2fs-not-modify-or-remove-existing-files-on-a%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