Moving a file between two drives on one SSD - will it be copied?
When moving a file within one drive, the file is not copied-and-deleted. The table that refers to the files is just updated. And as far as I know, that is not the case on 2 drives on an HDD. But SSDs are different, there is no physical space dedicated to each drive. (source)
So my question is what happens when a file is moved from one drive to another on the same SSD, are the bytes copied and the original deleted, or is some table updated, thereby thrashing the SSD less?
There's already a duplicate question here. But both answers claim:
each partition will have it's own physical area of the drive to itself
and
Partitioning a hard drive actually designates physical regions for
each partition. [and in a comment:] SSD is still a hard drive, it just
doesn't have a disk.
As far as I know that's wrong. See here.
So will someone who knows more about SSDs please tell me if they are correct in their assessment despite their mistake?
windows windows-10 partitioning ssd
add a comment |
When moving a file within one drive, the file is not copied-and-deleted. The table that refers to the files is just updated. And as far as I know, that is not the case on 2 drives on an HDD. But SSDs are different, there is no physical space dedicated to each drive. (source)
So my question is what happens when a file is moved from one drive to another on the same SSD, are the bytes copied and the original deleted, or is some table updated, thereby thrashing the SSD less?
There's already a duplicate question here. But both answers claim:
each partition will have it's own physical area of the drive to itself
and
Partitioning a hard drive actually designates physical regions for
each partition. [and in a comment:] SSD is still a hard drive, it just
doesn't have a disk.
As far as I know that's wrong. See here.
So will someone who knows more about SSDs please tell me if they are correct in their assessment despite their mistake?
windows windows-10 partitioning ssd
4
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linuxmv
would have to cooperate, mixing abstraction layers greatly.
– Kamil Maciorowski
6 hours ago
1
@Kamil: If the OS implemented it,mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)
– grawity
6 hours ago
1
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
Take for example the Disk Management dialog. It saysChange Drive Letter and Paths
when referring to a partition/volume.
– ispiro
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago
add a comment |
When moving a file within one drive, the file is not copied-and-deleted. The table that refers to the files is just updated. And as far as I know, that is not the case on 2 drives on an HDD. But SSDs are different, there is no physical space dedicated to each drive. (source)
So my question is what happens when a file is moved from one drive to another on the same SSD, are the bytes copied and the original deleted, or is some table updated, thereby thrashing the SSD less?
There's already a duplicate question here. But both answers claim:
each partition will have it's own physical area of the drive to itself
and
Partitioning a hard drive actually designates physical regions for
each partition. [and in a comment:] SSD is still a hard drive, it just
doesn't have a disk.
As far as I know that's wrong. See here.
So will someone who knows more about SSDs please tell me if they are correct in their assessment despite their mistake?
windows windows-10 partitioning ssd
When moving a file within one drive, the file is not copied-and-deleted. The table that refers to the files is just updated. And as far as I know, that is not the case on 2 drives on an HDD. But SSDs are different, there is no physical space dedicated to each drive. (source)
So my question is what happens when a file is moved from one drive to another on the same SSD, are the bytes copied and the original deleted, or is some table updated, thereby thrashing the SSD less?
There's already a duplicate question here. But both answers claim:
each partition will have it's own physical area of the drive to itself
and
Partitioning a hard drive actually designates physical regions for
each partition. [and in a comment:] SSD is still a hard drive, it just
doesn't have a disk.
As far as I know that's wrong. See here.
So will someone who knows more about SSDs please tell me if they are correct in their assessment despite their mistake?
windows windows-10 partitioning ssd
windows windows-10 partitioning ssd
edited 4 hours ago
asked 7 hours ago
ispiro
5802730
5802730
4
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linuxmv
would have to cooperate, mixing abstraction layers greatly.
– Kamil Maciorowski
6 hours ago
1
@Kamil: If the OS implemented it,mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)
– grawity
6 hours ago
1
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
Take for example the Disk Management dialog. It saysChange Drive Letter and Paths
when referring to a partition/volume.
– ispiro
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago
add a comment |
4
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linuxmv
would have to cooperate, mixing abstraction layers greatly.
– Kamil Maciorowski
6 hours ago
1
@Kamil: If the OS implemented it,mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)
– grawity
6 hours ago
1
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
Take for example the Disk Management dialog. It saysChange Drive Letter and Paths
when referring to a partition/volume.
– ispiro
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago
4
4
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linux
mv
would have to cooperate, mixing abstraction layers greatly.– Kamil Maciorowski
6 hours ago
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linux
mv
would have to cooperate, mixing abstraction layers greatly.– Kamil Maciorowski
6 hours ago
1
1
@Kamil: If the OS implemented it,
mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)– grawity
6 hours ago
@Kamil: If the OS implemented it,
mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)– grawity
6 hours ago
1
1
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
Take for example the Disk Management dialog. It says
Change Drive Letter and Paths
when referring to a partition/volume.– ispiro
5 hours ago
Take for example the Disk Management dialog. It says
Change Drive Letter and Paths
when referring to a partition/volume.– ispiro
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago
add a comment |
1 Answer
1
active
oldest
votes
As far as I know that's wrong
The quoted description is half-correct, half-wrong. But it's also half-wrong for HDDs too.
Partitioning a drive designates logical regions for each partition. The OS doesn't care about physical locations at all – it just asks the drive to "read logical block #31415926" and the drive itself decides where the data is located. This works the same way for magnetic and flash memory.
It's actually the same as with HDDs from the last 20–25 years: although early operating systems used physical cylinder/head/sector locations, that's long gone now. You don't know precisely where on which platter LBA #1234 is kept. HDDs even remap bad physical sectors automatically, so the same LBA can suddenly be read from a completely different physical area – just like with SSDs.
So with both HDDs and SSDs, the OS just has a range of LBAs (e.g. 0–999999) to read and write data from. The purpose of partitioning is to allocate sub-ranges in it – e.g. partition A gets 10–499999, partition B gets 500000–999999. Each partition has an independent filesystem, and filesystems inside each partition cannot reference data outside it – they cannot cross the partition boundaries. (For example, partition A cannot have a file whose data is kept in sector #600000.)
As a result, all files moving from one to the other have to be copied in full.
(That said, in theory the OS may be able to ask the disk itself to duplicate data from one area to another (e.g. "copy LBA #1234 to #567890"), without having to copy it to the main memory and then back, and of course this would completely bypass partition boundaries. This could make use of the SSD's "flash translation layer", for example. But in practice, as far as I know, this isn't done.)
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
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%2f1387909%2fmoving-a-file-between-two-drives-on-one-ssd-will-it-be-copied%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
As far as I know that's wrong
The quoted description is half-correct, half-wrong. But it's also half-wrong for HDDs too.
Partitioning a drive designates logical regions for each partition. The OS doesn't care about physical locations at all – it just asks the drive to "read logical block #31415926" and the drive itself decides where the data is located. This works the same way for magnetic and flash memory.
It's actually the same as with HDDs from the last 20–25 years: although early operating systems used physical cylinder/head/sector locations, that's long gone now. You don't know precisely where on which platter LBA #1234 is kept. HDDs even remap bad physical sectors automatically, so the same LBA can suddenly be read from a completely different physical area – just like with SSDs.
So with both HDDs and SSDs, the OS just has a range of LBAs (e.g. 0–999999) to read and write data from. The purpose of partitioning is to allocate sub-ranges in it – e.g. partition A gets 10–499999, partition B gets 500000–999999. Each partition has an independent filesystem, and filesystems inside each partition cannot reference data outside it – they cannot cross the partition boundaries. (For example, partition A cannot have a file whose data is kept in sector #600000.)
As a result, all files moving from one to the other have to be copied in full.
(That said, in theory the OS may be able to ask the disk itself to duplicate data from one area to another (e.g. "copy LBA #1234 to #567890"), without having to copy it to the main memory and then back, and of course this would completely bypass partition boundaries. This could make use of the SSD's "flash translation layer", for example. But in practice, as far as I know, this isn't done.)
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
add a comment |
As far as I know that's wrong
The quoted description is half-correct, half-wrong. But it's also half-wrong for HDDs too.
Partitioning a drive designates logical regions for each partition. The OS doesn't care about physical locations at all – it just asks the drive to "read logical block #31415926" and the drive itself decides where the data is located. This works the same way for magnetic and flash memory.
It's actually the same as with HDDs from the last 20–25 years: although early operating systems used physical cylinder/head/sector locations, that's long gone now. You don't know precisely where on which platter LBA #1234 is kept. HDDs even remap bad physical sectors automatically, so the same LBA can suddenly be read from a completely different physical area – just like with SSDs.
So with both HDDs and SSDs, the OS just has a range of LBAs (e.g. 0–999999) to read and write data from. The purpose of partitioning is to allocate sub-ranges in it – e.g. partition A gets 10–499999, partition B gets 500000–999999. Each partition has an independent filesystem, and filesystems inside each partition cannot reference data outside it – they cannot cross the partition boundaries. (For example, partition A cannot have a file whose data is kept in sector #600000.)
As a result, all files moving from one to the other have to be copied in full.
(That said, in theory the OS may be able to ask the disk itself to duplicate data from one area to another (e.g. "copy LBA #1234 to #567890"), without having to copy it to the main memory and then back, and of course this would completely bypass partition boundaries. This could make use of the SSD's "flash translation layer", for example. But in practice, as far as I know, this isn't done.)
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
add a comment |
As far as I know that's wrong
The quoted description is half-correct, half-wrong. But it's also half-wrong for HDDs too.
Partitioning a drive designates logical regions for each partition. The OS doesn't care about physical locations at all – it just asks the drive to "read logical block #31415926" and the drive itself decides where the data is located. This works the same way for magnetic and flash memory.
It's actually the same as with HDDs from the last 20–25 years: although early operating systems used physical cylinder/head/sector locations, that's long gone now. You don't know precisely where on which platter LBA #1234 is kept. HDDs even remap bad physical sectors automatically, so the same LBA can suddenly be read from a completely different physical area – just like with SSDs.
So with both HDDs and SSDs, the OS just has a range of LBAs (e.g. 0–999999) to read and write data from. The purpose of partitioning is to allocate sub-ranges in it – e.g. partition A gets 10–499999, partition B gets 500000–999999. Each partition has an independent filesystem, and filesystems inside each partition cannot reference data outside it – they cannot cross the partition boundaries. (For example, partition A cannot have a file whose data is kept in sector #600000.)
As a result, all files moving from one to the other have to be copied in full.
(That said, in theory the OS may be able to ask the disk itself to duplicate data from one area to another (e.g. "copy LBA #1234 to #567890"), without having to copy it to the main memory and then back, and of course this would completely bypass partition boundaries. This could make use of the SSD's "flash translation layer", for example. But in practice, as far as I know, this isn't done.)
As far as I know that's wrong
The quoted description is half-correct, half-wrong. But it's also half-wrong for HDDs too.
Partitioning a drive designates logical regions for each partition. The OS doesn't care about physical locations at all – it just asks the drive to "read logical block #31415926" and the drive itself decides where the data is located. This works the same way for magnetic and flash memory.
It's actually the same as with HDDs from the last 20–25 years: although early operating systems used physical cylinder/head/sector locations, that's long gone now. You don't know precisely where on which platter LBA #1234 is kept. HDDs even remap bad physical sectors automatically, so the same LBA can suddenly be read from a completely different physical area – just like with SSDs.
So with both HDDs and SSDs, the OS just has a range of LBAs (e.g. 0–999999) to read and write data from. The purpose of partitioning is to allocate sub-ranges in it – e.g. partition A gets 10–499999, partition B gets 500000–999999. Each partition has an independent filesystem, and filesystems inside each partition cannot reference data outside it – they cannot cross the partition boundaries. (For example, partition A cannot have a file whose data is kept in sector #600000.)
As a result, all files moving from one to the other have to be copied in full.
(That said, in theory the OS may be able to ask the disk itself to duplicate data from one area to another (e.g. "copy LBA #1234 to #567890"), without having to copy it to the main memory and then back, and of course this would completely bypass partition boundaries. This could make use of the SSD's "flash translation layer", for example. But in practice, as far as I know, this isn't done.)
edited 6 hours ago
answered 6 hours ago
grawity
231k35488544
231k35488544
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
add a comment |
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
I assume you're right. However, notice that there is another option. The drive could decide that sector #001 on drive#1 would now switch with sector #123 in drive#2 (i.e. sector#001 on drive#1 will now refer to the physical data that used to be referred to as sector #123 in drive#2) thereby moving the file without having to copy the bytes. So moving a TB of data can in principle be near-instantaneous.
– ispiro
6 hours ago
3
3
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
The drive doesn't know about files or filesystems, and therefore cannot make such decisions by itself. It needs to receive a request from the OS for this to happen. As I already mentioned in the last paragraph, it's certainly technically possible but operating systems usually don't bother with this for cross-filesystem copies, and I doubt they do for same-filesystem copies either (more commonly it's done at FS level).
– grawity
6 hours ago
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.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- 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%2f1387909%2fmoving-a-file-between-two-drives-on-one-ssd-will-it-be-copied%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
4
The accepted answer there is right: each partition has it's own, independent filesystem. Each filesystem decides for itself how it utilizes blocks assigned to it. To do what you propose the firmware of SSD, filesystem(s) and userland tools like Linux
mv
would have to cooperate, mixing abstraction layers greatly.– Kamil Maciorowski
6 hours ago
1
@Kamil: If the OS implemented it,
mv
would actually need to do less than it currently does, I suspect. (That is, the OS would just need to make sure that a cross-filesystem rename() succeeds instead of failing as currently happens.)– grawity
6 hours ago
1
"2 drives on [an SSD/HDD]" -- I think you mean to say 2 filesystems or 2 partitions on one SSD/HDD. Remember that the last "D" in both acronyms is "Drive", so you're saying 2 drives in 1 drive, which doesn't make sense.
– JoL
5 hours ago
Take for example the Disk Management dialog. It says
Change Drive Letter and Paths
when referring to a partition/volume.– ispiro
5 hours ago
@ispiro Is that on Windows? Seems like an awful way to confuse users. I can only guess that they came up with the term "Drive Letter" before drive partitions where implemented, and then they ended up representing drive partitions as standalone "drives". So now you can have multiple Windows "drives" representing partitions of one hardware drive...
– JoL
5 hours ago