FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Sun Jun 13, 2021 04:48



Post new topic Reply to topic  [ 9 posts ] 
Write speed falls to half if NTFS partition becomes 91% full 
Author Message

Joined: Wed May 12, 2010 10:59
Posts: 3
Post Write speed falls to half if NTFS partition becomes 91% full
Hi,

The usual write speed I get from ntfs-3g is ~30MB/sec on my Linux desktop but it drops to around ~12MB/sec when the partition becomes 91% full. Why does this happen and how can I fix it? I am prepared to modify/rewirte the source code if someone can just point me in the right direction.

I checked to confirm that its not due to fragmentation by creating 3 partitions of various sizes and creating fragmentation of 40%, 60% and 80% on them respectively and then timing the write operation with data in increments of 100MB. In all partitions, the write speed becomes slower after crossing the 91% disk utilization mark. After repeated experiments, I think that the problem is not with fragmentation but with extent of space utilization. Help :?:


Wed May 12, 2010 11:17
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Quote:
The usual write speed I get from ntfs-3g is ~30MB/sec on my Linux desktop but it drops to around ~12MB/sec when the partition becomes 91% full. Why does this happen

Which ntfs-3g version are you using ? In most cases this performance drop should not be seen with recent versions. At least it should only happen if you have a lot of file creations and deletions.
This is because the space is divided into three zones, with the first one favored for user files and the last one favored for internal files, in order to avoid fragmentation on these internal files with bad impact on performances. When the disk becomes full, there is generally no more space in first and second zone, but when a file is deleted in the first zone, allocations can be made again in the first zone, forcing searches for the last available byte, hence the drop in performance.
Quote:
and how can I fix it?

If you have a big disk, you should increase the cluster size. Doubling the cluster size halves the time to search for an available cluster in a bitmap, and halves again the count of needed searches, at least on big files. What are your disk capacity and cluster size ? Type :
Code:
ntfsinfo -m <device>

Quote:
I am prepared to modify/rewirte the source code if someone can just point me in the right direction

Good idea, that is the ultimate answer to your question... All of it is in lcnalloc.c and there are a lot of constraints to account for (avoiding fragmentation, avoiding files being created simultaneously to be intertwined, processing huge bitmaps on big disks, etc.)

Regards

Jean-Pierre


Wed May 12, 2010 19:51
Profile

Joined: Wed May 12, 2010 10:59
Posts: 3
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Thanks for the detailed answer, it was really helpful :)

Quote:
Which ntfs-3g version are you using ? In most cases this performance drop should not be seen with recent versions. At least it should only happen if you have a lot of file creations and deletions.


I compiled the latest stable version from source (ntfs-3g-2010.3.6) on Ubuntu (Lucid). The performance drop happens even if I copy a single 100MB file on an ntfs-3g partition but only after "df -h" shows that its 91% full, not before that.

Quote:
If you have a big disk, you should increase the cluster size. Doubling the cluster size halves the time to search for an available cluster in a bitmap, and halves again the count of needed searches, at least on big files.


This was right on the money. I formatted a partitions with the max cluster size (64K, I think), and all performance issues went away. But I'm afraid its not a practical solution (cannot go around re-formatting people's windows drives to increase ntfs-3g performance :p)

Quote:
What are your disk capacity and cluster size?


I created 3 ntfs-3g partitions of sizes 2, 3 and 4 GB to test this problem. Cluster size on all is the default 4KB. Total disk capacity is 160GB.

Quote:
... there are a lot of constraints to account for (avoiding fragmentation, avoiding files being created simultaneously to be intertwined, processing huge bitmaps on big disks, etc.)


The idea suddenly seems very daunting :p ..... can you also point me to some good resource (book/tutorial etc.) where I can learn to identify and manage these constraints?

Thanks again for the help :)


Thu May 13, 2010 07:22
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Quote:
The performance drop happens even if I copy a single 100MB file on an ntfs-3g partition but only after "df -h" shows that its 91% full, not before that.

There is a hard point when an allocation zone is nearly full, as we have to hunt for available clusters, leading to fragmented files, but things should improve after the zone is declared full... until you delete a file, making the zone not full anymore (the percentage depends on formatting parameters, you can get them by "ntfsinfo -m").
Quote:
I formatted a partitions with the max cluster size (64K, I think), and all performance issues went away

So it is indeed a cluster allocation issue.
Quote:
But I'm afraid its not a practical solution (cannot go around re-formatting people's windows drives to increase ntfs-3g performance :p)

But much easier than designing a cluster allocation scheme with no side effects.
Quote:
I created 3 ntfs-3g partitions of sizes 2, 3 and 4 GB to test this problem.

These are small partitions. Can you check the fragmentation of $MFT by doing
Code:
# as root on unmounted device
ntfsinfo -vi 0 <device>


Quote:
can you also point me to some good resource (book/tutorial etc.) where I can learn to identify and manage these constraints?

I have been thinking about making such research myself, alas, I did not find time for it so far.

Regards

Jean-Pierre


Thu May 13, 2010 12:49
Profile

Joined: Wed May 12, 2010 10:59
Posts: 3
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Thanks again for the quick reply. I think I understand now why the problem exists. I am giving the output of ntfsinfo -vi 0 <device> at the end, however I couldn't understand from it how much fragmentation is there on the disk. Therefore, I did a small experiment myself. I fragmented the 3 drives I mentioned earlier from within Windows using the fragger tool as 40%, 60% and 90% fragmented respectively and re-ran my read/write test on them from within Linux. Interestingly, the results were same (~30 MB/sec) on all drives until I reached ~90% full mark, after which the performance decreases exponentially. So does it mean that degree of fragmentation is not a major issue?

After that, I also tried to do the same kind of test from within Windows. The performance in Windows also decreased on all drives when they became more than ~90% full but interestingly, if I delete some data to make the drive less than 90% full and then again copy something new (fearing the previously copied stuff would still be in the buffer and hence give false results), I get full performance (~50 MB/sec). Whereas in ntfs-3g on Linux, if I empty the drives to less than 90% full and then again copy something new, I get the old slow results (~10-15 MB/sec) !!!

Does this mean that in Windows, when the MFT-zone is somehow compressed to make room for data (I am assuming that I have correctly paraphrased from your last post?), the MFT-zone is kept compressed even when the data is deleted, whereas in ntfs-3g, once the data is deleted, the MFT-zone is uncompressed. So we will see bad performance repeatedly as we continue to cross and recross this threshold?

Code:
Dumping Inode 0 (0x0)
Upd. Seq. Array Off.:    48 (0x30)
Upd. Seq. Array Count:    3 (0x3)
Upd. Seq. Number:    20 (0x14)
LogFile Seq. Number:    0x103583b
MFT Record Seq. Numb.:    1 (0x1)
Number of Hard Links:    1 (0x1)
Attribute Offset:    56 (0x38)
MFT Record Flags:    IN_USE
Bytes Used:       416 (0x1a0) bytes
Bytes Allocated:    1024 (0x400) bytes
Next Attribute Instance: 6 (0x6)
MFT Padding:   00 00
Dumping attribute $STANDARD_INFORMATION (0x10) from mft record 0 (0x0)
   Attribute length:    96 (0x60)
   Resident:        Yes
   Name length:       0 (0x0)
   Name offset:       24 (0x18)
   Attribute flags:    0x0000
   Attribute instance:    0 (0x0)
   Data size:       72 (0x48)
   Data offset:       24 (0x18)
   Resident flags:       0x00
   ReservedR:       0 (0x0)
   File Creation Time:    Wed May 12 17:19:49 2010
   File Altered Time:    Wed May 12 17:19:49 2010
   MFT Changed Time:    Wed May 12 17:19:49 2010
   Last Accessed Time:    Wed May 12 17:19:49 2010
   File attributes:    HIDDEN SYSTEM (0x00000000)
   Maximum versions:    0
   Version number:       0
   Class ID:       0
   User ID:       0 (0x0)
   Security ID:       256 (0x100)
   Quota charged:       0 (0x0)
   Update Sequence Number:    0 (0x0)
Dumping attribute $FILE_NAME (0x30) from mft record 0 (0x0)
   Attribute length:    104 (0x68)
   Resident:        Yes
   Name length:       0 (0x0)
   Name offset:       24 (0x18)
   Attribute flags:    0x0000
   Attribute instance:    3 (0x3)
   Data size:       74 (0x4a)
   Data offset:       24 (0x18)
   Resident flags:       0x01
   ReservedR:       0 (0x0)
   Parent directory:    5 (0x5)
   File Creation Time:    Wed May 12 17:19:49 2010
   File Altered Time:    Wed May 12 17:19:49 2010
   MFT Changed Time:    Wed May 12 17:19:49 2010
   Last Accessed Time:    Wed May 12 17:19:49 2010
   Allocated Size:       16384 (0x4000)
   Data Size:       16384 (0x4000)
   Filename Length:    4 (0x4)
   File attributes:    HIDDEN SYSTEM (0x00000000)
   Namespace:       Win32 & DOS
   Filename:       '$MFT'
Dumping attribute $DATA (0x80) from mft record 0 (0x0)
   Attribute length:    72 (0x48)
   Resident:        No
   Name length:       0 (0x0)
   Name offset:       64 (0x40)
   Attribute flags:    0x0000
   Attribute instance:    1 (0x1)
   Lowest VCN       0 (0x0)
   Highest VCN:       32255 (0x7dff)
   Mapping pairs offset:    64 (0x40)
   Compression unit:    0 (0x0)
   Data size:       16515072 (0xfc0000)
   Allocated size:       16515072 (0xfc0000)
   Initialized size:    16515072 (0xfc0000)
   Runlist:   VCN      LCN      Length
         0x0      0x200000      0x7e00
Dumping attribute $BITMAP (0xb0) from mft record 0 (0x0)
   Attribute length:    80 (0x50)
   Resident:        No
   Name length:       0 (0x0)
   Name offset:       64 (0x40)
   Attribute flags:    0x0000
   Attribute instance:    5 (0x5)
   Lowest VCN       0 (0x0)
   Highest VCN:       15 (0xf)
   Mapping pairs offset:    64 (0x40)
   Compression unit:    0 (0x0)
   Data size:       4104 (0x1008)
   Allocated size:       8192 (0x2000)
   Initialized size:    4104 (0x1008)
   Runlist:   VCN      LCN      Length
         0x0      0x1fffff      0x1
         0x1      0x1ffff0      0xf
End of inode reached


Thu May 13, 2010 15:23
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Quote:
I think I understand now why the problem exists. I am giving the output of ntfsinfo -vi 0 <device> at the end, however I couldn't understand from it how much fragmentation is there on the disk

Well, your data show the MFT is not fragmented at all, so the MFT fragmentation is not at stake (assuming this was the data for a near-full disk). The relevant information is the number of runlist items in the $DATA attribute.
Quote:
After that, I also tried to do the same kind of test from within Windows. The performance in Windows also decreased on all drives when they became more than ~90% full

Useful to know.
Quote:
Whereas in ntfs-3g on Linux, if I empty the drives to less than 90% full and then again copy something new, I get the old slow results (~10-15 MB/sec)

That is what I expected. Deleting files leaves (scattered) space which has to be hunted for, this is the drawback of a bitmap-oriented allocation.
Quote:
Does this mean that in Windows, when the MFT-zone is somehow compressed to make room for data (I am assuming that I have correctly paraphrased from your last post?), the MFT-zone is kept compressed even when the data is deleted, whereas in ntfs-3g, once the data is deleted, the MFT-zone is uncompressed.

No. There is no compression or relocation of data, but the $MFT and user files have to compete for the same space, and when the $MFT grows, a user file may force the creation of a non-contiguous extent.
Quote:
So we will see bad performance repeatedly as we continue to cross and recross this threshold?

Currently I can explain the poor performance just below the threshold. When the threshold has been crossed, you should get the usual speed again. Note that the threshold changes in time : if you have filled 95% and deleted 10% in the first zone, your new threshold is at 95%, ie when the 10% in the first zone have been almost filled again. Your observation relative to the Windows behavior could mean that Windows still allocates user files in the last zone, even though some files have been deleted in the first zone (until the last zone is full, of course). Experiments needed to check this.
Can you do a "ntfsinfo -m <device>" to identify the layouts in your experiments ? The relevant items are :
Code:
        Volume Size in Clusters: 69700858
        MFT Zone Start: 0
        MFT Zone End: 8712611

The first user zone is above the MFT (so 8712612-69700857 or 87% of the capacity), the second user zone is below the MFT (none in this case). Of course when the first zone is full, the disk usage also accounts for the MFT and is reported over 87%.

Regards

Jean-Pierre


Thu May 13, 2010 18:05
Profile

Joined: Thu Sep 16, 2010 06:44
Posts: 3
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

I just come up with the same issue as write speed is decreased almost to half when the ntfs partition becomes 60-70 % full.So,I decided to find the cause for it and identified Cluster Allocation as one of the key factors contributing to Performance - Write Operation.
So, I decided to modify the source code and tried to optimize the cluster allocation technique and came up with some improved results.
I just to know some other areas where some optimization can be done.I am ready to modify/rewrite source code to any extent if it's possible..


Plz reply asap.


Thu Sep 16, 2010 07:08
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hi,

Quote:
I just come up with the same issue as write speed is decreased almost to half when the ntfs partition becomes 60-70 % full.

This has been improved in ntfs-3g-2010.8.8AR.5 see http://www.tuxera.com/community/ntfs-3g-advanced/
Quote:
So, I decided to modify the source code and tried to optimize the cluster allocation technique and came up with some improved results.

Good, this is tricky. Are the modifications public ? Do you have any figures ?
Quote:
I just to know some other areas where some optimization can be done.I am ready to modify/rewrite source code to any extent if it's possible..

Please do. Use a profiler to locate what need to be optimized.

Regards

Jean-Pierre


Thu Sep 16, 2010 08:32
Profile

Joined: Thu Sep 16, 2010 06:44
Posts: 3
Post Re: Write speed falls to half if NTFS partition becomes 91% full
Hey,

Thanks for your reply..
The modiification being done are not made public as of now which i'll do it once i confirmed the stability and consistency of my changes...
I'll let u know about the performance figures..


Thu Sep 16, 2010 09:00
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.