On Tue, 28 Nov 2006, Szakacsits Szabolcs wrote:
> On Tue, 28 Nov 2006, Anton Altaparmakov wrote:
> > On Tue, 2006-11-28 at 14:20 +0100, Szakacsits Szabolcs wrote:
> > relocate_inodes() -> relocate_inode() -> at the end of the function
> > calls write_mft_record() which uses the ntfs_volume and the libntfs
> > function ntfs_mft_record_write() to do the writing.
>
> Think about relocating $MFT.
I don't understand what you mean. If you relocate the mft itself and you
do not update the ntfs_volume structure and the mft bitmap attribute inode
which is kept open for the duration of the mount then with each call of
ntfs_mft_record_write() in your relocate_inodes() it would write to the
old locations instead of the new relocated locations...
> > After that we have truncate_badclust_file() and truncate_bitmap_file()
> > both of which use write_mft_record() also...
>
> The beginning of the $MFT is never relocated, so the MFT records belonging
> to these files can be safely modified in place, otherwise resizing is
> restricted to a safe size.
>
> > Remember that what you were doing was not working for Vista and it works
> > now...
>
> I didn't have time to check the patches yet but wasn't the Vista problem due
> to a bug in libntfs and not because of ntfsresize?
The problem is that with my first patch which does not turn on unmounting
you end up with an ntfsresize that is horrible:
Every time you run ntfsresize and either you answer "no" to the "really
proceed" question or ntfsresize aborts without doing anything because it
hits a "this is not supported" case or you try to resize to a too small
size or anything like that the volume is left dirty thus running
ntfsresize again then fails. This is because ntfsresize does not unmount
the volume. My complete patches up to CVS head cause the unmounting to
happen but only until all the checks have passed and ntfsresize is about
to start migrating clusters around. At that point, before the first
modification happens, I turn off the unmounting and from then on
ntfsresize will run and independent of when it is going to stop (abort or
complete), it will no longer unmount like you want it to be. Then the
volume is left dirty which is what you want to happen anyway.
I think it is now correct. Please take the time to review the patches...
> You seem to mix here two different problems: the missing log file reset in
> libntfs and the unsafe umount you introduced by another patch to ntfsresize
> because you thought that it was missing by accident.
Not really, as you see above if you do not unmount at all you now end up
marking the volume dirty unconditionally even if ntfsresize does not
actually do anything at all.
> > Anyway, given ntfsresize is your code, if you want to insist on not
> > allowing unmounting, then can you please tell me the exact point in the
> > code at which unmounting becomes dangerous/wrong
>
> I must think about it. The design rule was being always consistent or
> trivially recoverable whenever we exit immediately without any cleanup.
The current code does that I believe.
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
