|
From: Szakacsits S. <sz...@si...> - 2002-07-06 17:11:17
|
On Sat, 6 Jul 2002, Andrew Clausen wrote: > > About cluster relocation/defrag in the future: I think partly "defrag" > > at the end of the volume is more then enough for two reasons: > > - less chance to screw things up (by a power failure of course ;) > > - could be significantly faster: people, who resize at e.g. install > > or whatever time, are really not interested in full defrag however > > fast operation. > > Actually, it's significantly slower, if you want to "move the start". Agreed but two comments, keeping fs integrity is higher priority then performance. Second, "move the start" is not the typical customer scenario however quote from http://www.microsoft.com/hwdev/tech/storage/ntfs-preinstallP.asp "NTFS is the recommended file system for computers running the Microsoft Windows XP and Windows .NET Server operating systems. Microsoft strongly encourages system manufacturers to manufacture single NTFS volumes on all systems where a 32-bit version of Windows ^^^^^^^^^^^^^^^^^^^ XP is preinstalled. ... Feedback from customers and system manufacturers indicates that users want single volumes because they do not want to manage multiple volumes and do not understand multiple-volume usage scenarios." If one (in some years probably most Win user) has such a box you think he is care about "move the start" to be able to try out Linux? > Have you looked at how my FAT resizer works? You can read the source, > or read the last section of doc/FAT. > > It copies all clusters that won't be addressable in the new FS's > partition location to free space that will be addressable. > It also copies all metadata clusters. Then, in the copies of all > metadata clusters, it changes all references to other blocks to make > them their copies. > > I'm not convinced this approach is better, just putting it on the > table ;) Well, NTFS isn't FAT (has its own oddities). Anyway thank you for the idea. > Another thing that's worth looking at is: > > http://tzukanov.narod.ru/convertfs/ > > Is it possible to support NTFS via this route? It would be very > cool if it were... Clever indeed. I see many minor and two big problems: - no NTFS write support in the kernel - lots of NTFS specific attribute/data (e.g. streams) would get lost during mv. I guess this is also true in the case of converting between different unix filesystems or even during resizing (see e.g. 'man 1 chattr' what I mean). Thanks again for your comments. Szaka |
