Hi All I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why. Cheers Nic
none of my suggestions, though humorous, are helpful... disk partition level thinking doesn't consider file system level thinking is probably the correct answer, which incidentally also explains why some hypervisor snapshots suck chunks... On Thu, 31 Jan 2019 at 12:16, Nic Baxter via luv-main <luv-main@luv.asn.au> wrote:
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why.
Cheers
Nic
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
Paul van den Bergen via luv-main wrote:
none of my suggestions, though humorous, are helpful...
disk partition level thinking doesn't consider file system level thinking is probably the correct answer, which incidentally also explains why some hypervisor snapshots suck chunks...
On Thu, 31 Jan 2019 at 12:16, Nic Baxter via luv-main <luv-main@luv.asn.au <mailto:luv-main@luv.asn.au>> wrote:
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why.
In trying to unwrap Paul's explanation above ; a naive suggestion is as follows (complaints welcomed): 1/ part of the function of "file systems" is to hide the connection of data eg files, to the underlying hardware ie platter; track, sector.. number, etc; from the OS and the user; but in part that connection is still visible; in the possibility that NTFS like FAT32, is still capable of becoming fragmented, yes? -therefore files fragments can become scattered all over the partition space; -therefore just extending the partition "200MB to the right" (sector numbers are increasing ?); then removing 200 MB of file fragments from the "left" and moving it to this new vacant partition space ; is going to do severe damage to the file system ! 2/More generally "partition management software" ; for partition: creation, extension, cloning and recently the ability to create virtual partitions as files in such underlying partitions; is intimately involved with hiding this connection of files and file fragments to the hardware ie platter number, sector number, etc; which is why such software is not simple; even though its operation at the OS level is conceptually (logically ?) simple. 3/Digressing;a further take-away point is that occasionally it is worth looking back at the mountain of abstraction we have built; and often hide from ourselves in this notion of data: bits, bytes,hexadecimal number, decimal floating point number, measure of physical quantity in relevant units,....etc regards Rohan McLeod
Hi Nic. A bit of googling found me at the following link: http://www.file-recovery.com/recovery-understanding-file-system-ntfs.htm Long and short of it is that the NTFS partition layout wants certain components to be at defined offsets from the beginning of the partition. So in moving the partition by 200MB, it need to keep the partition contents in exactly the order in which it found them. Otherwise Windows is likely to chuck a major hissy fit and tell you that the partition is corrupted or missing. A bit like a library shelf. If you want to add books at the left end, you need to start by moving all the other books to the right, starting at the right hand end. You just can't move "A to C" to the end of "Z" end without getting the entire alphabet out of sequence. (Your librarian would quickly relieve you of a few choice bits of your anatomy.) Well it seems like a reasonable analogy. :-) Regards, Morrrie. -----Original Message----- From: luv-main [mailto:luv-main-bounces@luv.asn.au] On Behalf Of Nic Baxter via luv-main Sent: Thursday, 31 January 2019 12:16 PM To: luv-main@luv.asn.au Subject: moving partition Hi All I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why. Cheers Nic _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
yep, pretty much what I was trying to say - on a mobile - while distracted... The FS has an index of some sort that keeps track of where the bits are, etc. If you move the goal posts you have to change the index to suit, otherwise 1) the OS doesn't know where to find the index and 2) the index doesn't know where to find the files. so in theory you could change the partition start and end point, as long as they still encompass any "data", more the metadata where it needs to be (most FS's expect the index and other metadata to be at a specific place... well - ok. I'm going to hazzard all) and adjust said metadata to know where the data actually is - and presuming it's OK with now having it's written data somewhere in the middle of it's "file system", it'll be fine... does anyone do this? Bueller? In the case of VM's, the underlying file system could have excellent snapshot (copy on write) at the file system level but the hypervisor doesn't have this exposed to it so it makes a new file instead and writes all changes into that... which has consequences... there are good reasons to not ask the file system to look too deeply into the pdisk management, nor the VM to look at the file system that it's busy abstracting away - but I still think it's a bloody waste of an opportunity... YMMV... On Thu, 31 Jan 2019 at 19:32, Morrie Wyatt via luv-main <luv-main@luv.asn.au> wrote:
Hi Nic.
A bit of googling found me at the following link:
http://www.file-recovery.com/recovery-understanding-file-system-ntfs.htm
Long and short of it is that the NTFS partition layout wants certain components to be at defined offsets from the beginning of the partition.
So in moving the partition by 200MB, it need to keep the partition contents in exactly the order in which it found them. Otherwise Windows is likely to chuck a major hissy fit and tell you that the partition is corrupted or missing.
A bit like a library shelf. If you want to add books at the left end, you need to start by moving all the other books to the right, starting at the right hand end. You just can't move "A to C" to the end of "Z" end without getting the entire alphabet out of sequence.
(Your librarian would quickly relieve you of a few choice bits of your anatomy.)
Well it seems like a reasonable analogy. :-)
Regards, Morrrie.
-----Original Message----- From: luv-main [mailto:luv-main-bounces@luv.asn.au] On Behalf Of Nic Baxter via luv-main Sent: Thursday, 31 January 2019 12:16 PM To: luv-main@luv.asn.au Subject: moving partition
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why.
Cheers
Nic
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
Thanks for the info guys. My initial thought was why doesn't the partition tell the file system to move the data. But thinking about it more, the partition doesn't understand files and the file-system doesn't understand raw data. I imagine you could add the functions but it would be a duplication and a potential security hazard. Simpler and safer to move everything to another disk and repartition. Cheers Nic On 31/1/19 8:52 pm, Paul van den Bergen via luv-main wrote:
yep, pretty much what I was trying to say - on a mobile - while distracted...
The FS has an index of some sort that keeps track of where the bits are, etc. If you move the goal posts you have to change the index to suit, otherwise 1) the OS doesn't know where to find the index and 2) the index doesn't know where to find the files.
so in theory you could change the partition start and end point, as long as they still encompass any "data", more the metadata where it needs to be (most FS's expect the index and other metadata to be at a specific place... well - ok. I'm going to hazzard all) and adjust said metadata to know where the data actually is - and presuming it's OK with now having it's written data somewhere in the middle of it's "file system", it'll be fine...
does anyone do this? Bueller?
In the case of VM's, the underlying file system could have excellent snapshot (copy on write) at the file system level but the hypervisor doesn't have this exposed to it so it makes a new file instead and writes all changes into that... which has consequences...
there are good reasons to not ask the file system to look too deeply into the pdisk management, nor the VM to look at the file system that it's busy abstracting away - but I still think it's a bloody waste of an opportunity...
YMMV...
On Thu, 31 Jan 2019 at 19:32, Morrie Wyatt via luv-main <luv-main@luv.asn.au <mailto:luv-main@luv.asn.au>> wrote:
Hi Nic.
A bit of googling found me at the following link:
http://www.file-recovery.com/recovery-understanding-file-system-ntfs.htm
Long and short of it is that the NTFS partition layout wants certain components to be at defined offsets from the beginning of the partition.
So in moving the partition by 200MB, it need to keep the partition contents in exactly the order in which it found them. Otherwise Windows is likely to chuck a major hissy fit and tell you that the partition is corrupted or missing.
A bit like a library shelf. If you want to add books at the left end, you need to start by moving all the other books to the right, starting at the right hand end. You just can't move "A to C" to the end of "Z" end without getting the entire alphabet out of sequence.
(Your librarian would quickly relieve you of a few choice bits of your anatomy.)
A good analogy.
Well it seems like a reasonable analogy. :-)
Regards, Morrrie.
-----Original Message----- From: luv-main [mailto:luv-main-bounces@luv.asn.au <mailto:luv-main-bounces@luv.asn.au>] On Behalf Of Nic Baxter via luv-main Sent: Thursday, 31 January 2019 12:16 PM To: luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> Subject: moving partition
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why.
Cheers
Nic
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
While installing Linux recently, I found that Windows 10 would only shrink the NTFS partition to approximately half of its previous size. I read claims via a web search for information on this subject that there are metadata in the middle of an NTFS partition, and Microsoft's tools won't reduce the size of the file system beyond this point. I'm not sure how accurate this is, although it's consistent with the observed results. On 1/31/19 6:46 PM, Nic Baxter via luv-main wrote:
Thanks for the info guys.
My initial thought was why doesn't the partition tell the file system to move the data. But thinking about it more, the partition doesn't understand files and the file-system doesn't understand raw data.
I imagine you could add the functions but it would be a duplication and a potential security hazard. Simpler and safer to move everything to another disk and repartition.
Cheers
Nic
On 31/1/19 8:52 pm, Paul van den Bergen via luv-main wrote:
yep, pretty much what I was trying to say - on a mobile - while distracted...
The FS has an index of some sort that keeps track of where the bits are, etc. If you move the goal posts you have to change the index to suit, otherwise 1) the OS doesn't know where to find the index and 2) the index doesn't know where to find the files.
so in theory you could change the partition start and end point, as long as they still encompass any "data", more the metadata where it needs to be (most FS's expect the index and other metadata to be at a specific place... well - ok. I'm going to hazzard all) and adjust said metadata to know where the data actually is - and presuming it's OK with now having it's written data somewhere in the middle of it's "file system", it'll be fine...
does anyone do this? Bueller?
In the case of VM's, the underlying file system could have excellent snapshot (copy on write) at the file system level but the hypervisor doesn't have this exposed to it so it makes a new file instead and writes all changes into that... which has consequences...
there are good reasons to not ask the file system to look too deeply into the pdisk management, nor the VM to look at the file system that it's busy abstracting away - but I still think it's a bloody waste of an opportunity...
YMMV...
On Thu, 31 Jan 2019 at 19:32, Morrie Wyatt via luv-main <luv-main@luv.asn.au <mailto:luv-main@luv.asn.au>> wrote:
Hi Nic.
A bit of googling found me at the following link:
http://www.file-recovery.com/recovery-understanding-file-system-ntfs.htm
Long and short of it is that the NTFS partition layout wants certain components to be at defined offsets from the beginning of the partition.
So in moving the partition by 200MB, it need to keep the partition contents in exactly the order in which it found them. Otherwise Windows is likely to chuck a major hissy fit and tell you that the partition is corrupted or missing.
A bit like a library shelf. If you want to add books at the left end, you need to start by moving all the other books to the right, starting at the right hand end. You just can't move "A to C" to the end of "Z" end without getting the entire alphabet out of sequence.
(Your librarian would quickly relieve you of a few choice bits of your anatomy.)
A good analogy.
Well it seems like a reasonable analogy. :-)
Regards, Morrrie.
-----Original Message----- From: luv-main [mailto:luv-main-bounces@luv.asn.au <mailto:luv-main-bounces@luv.asn.au>] On Behalf Of Nic Baxter via luv-main Sent: Thursday, 31 January 2019 12:16 PM To: luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> Subject: moving partition
Hi All
I am moving a 1TB NTFS partition 200MB to the right using gparted and of course it is very slow. I don't understand why gparted is moving all of the data. Why not just move 200MB and add it to the end of the partition? My googling only tells me how to do it but not why.
Cheers
Nic
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au <mailto:luv-main@luv.asn.au> https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
-- Dr Paul van den Bergen
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
participants (5)
-
Jason White -
Morrie Wyatt -
Nic Baxter -
Paul van den Bergen -
Rohan McLeod