On Sat, Jul 06, 2002 at 06:07:56PM +0200, Szakacsits Szabolcs wrote:
> 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.
I don't see how there is a difference wrt "fs integrity". Actually,
my method (which I call "reconstructive" as opposed to "incremental")
is basically atomic, and doesn't require journaling, or sophisticated
tricks to prevent problems occuring on interruption.
Compare the parted's ext2 and fat resizers. If you interrupt the
ext2 resizer (the traditional type of resizer you are proposing,
like defrag + superblock update), then e2fsck can recover. If you
interrupt the FAT resizer, you get the old file system (except
in the very last phase which is very short). No fsck required.
Also, I don't believe defragging requires any less knowledge of
the FS than reconstruction. Aren't all references in NTFS done
via attributes?
> 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."
What about CHS/LBA addressing issues? It's often convenient to have
a small boot partition at the start, etc.
> 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?
I think it's still a useful case to support.
> Well, NTFS isn't FAT (has its own oddities).
What are the oddities that make a difference?
(I have spent a lot of time reading NTFS docs, so you can throw
details at me, if you want)
> > 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
Obviously a big problem, right ;)
> - 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).
Yeah, I'm wondering if this will be fixed. Like some version of
cp that copies attributes as well. Anyway, it seems like a solvable
problem. (Although possibly painful, since many attributes in
various fs's are "built in" and interpreted by the FS, etc. - but
this shouldn't be an issue for resizing, only converting)
Cheers,
Andrew
|