Risk of Writing to NTFS Volumes
Ouattara Oumar Aziz
wattazoum at gmail.com
Wed Sep 13 19:12:58 UTC 2006
Ouattara Oumar Aziz a écrit :
> Sameera Shaakunthala a écrit :
>> Hello,
>>
>> I heard that Dieter told that writing on NTFS volumes is still
>> experimental and there is a risk of doing this.
>>
>> What will actually happen in the background if I write to a NTFS volume?
>> What is the risk?
>>
>>
>> Sameera Shaakunthala
More Infos (I am so Kind :) )
KNOWN ISSUES, TROUBLESHOOTING
=============================
Recently added or updated items are always on the top.
Problem: File modification times aren't always updated.
Status: High priority work.
Problem: VMware segfaults during startup.
Answer: By default VMware tries to use shared writable mmap for paging
files but it can't detect that it's not yet supported.
Workaround: Set "mainMem.useNamedFile=FALSE" in your .vmx file. That will
disable these paging files and VMware will work fine.
Status: Priority, hard work.
Problem: Writing large files sometimes can be very slow.
Answer: The cluster allocator and the mapping pairs updater algorithms
aren't efficient for large files on very fragmented volumes.
Workaround: Try to defragment your NTFS, it may help.
Status: Priority work.
Problem: Why doesn't the driver work on 64-bit and big-endian systems?
Answer: The code is 64-bit ready and almost fully endian safe, however
unfortunately we are unable to validate the functionality and
keep ensuring correctness for the future due to lack of target
hardwares.
Problem: "Directory not empty" message when deleting "empty"
directories:
Answer: If locale isn't set correctly then glibc can't convert
some filenames, so they aren't visible and the directory
indeed isn't empty. Occurs very rarely.
Workaround: Set your locale properly according to the used characters
Status: High priority work.
Problem: "Operation not supported" message when creating a file:
Answer: This is a controlled refusal of file creation which can happen
when there are already about 100,000 files on the NTFS and the
MFT needs to be extended in a way which isn't implemented yet.
Workaround: Delete files then you can create new ones.
Status: High priority work.
Problem: "Operation not supported" message when deleting a file:
Answer: The support for certain very-very rare directory update
operations weren't fully tested yet, so they are not
included in the release. This is so rare that you probably
will never see it ;-)
Workaround: Delete or create other files in the same directory until you
can remove the file you originally wanted.
Status: High priority work.
Problem: Windows chkdsk complains about free space being marked in use.
Answer: chkdsk sometimes optimizes the NTFS layout and later finds
its own bugs (e.g. when index root attributes are moved from
extent mft records to the base one). This is not a problem
with ntfs-3g.
Workaround: No need, it's a chkdsk bug and it fixes itself.
Status: Low priority work: we will optimize our algorithms too.
Problem: Windows chkdsk reports the below messages (N is a number).
Cleaning up N unused index entries from index $SII of file 0x9.
Cleaning up N unused index entries from index $SDH of file 0x9.
Cleaning up N unused security descriptors.
Answer: These messages are part of an optimization process which is
completely independent of ntfs-3g. Nothing to worry about them.
Workaround: No need.
Status: Nothing to do.
Problem: Windows chkdsk may report minor inconsistency.
Answer: The allocation size of sparse files isn't set always correctly.
Workaround: No need.
Status: Normal priority work.
Problem: Why ntfs-3g CPU usage is always 100%?
Answer: You have some application running which inefficiently "polls"
for file modification events.
Workaround: Identify the software and try to upgrade it.
Status: Normal priority work: we also intend to improve significantly
our CPU usage for such cases.
More information about the ubuntu-users
mailing list