NTFS formatting a new volume (4TB) over iSCSI is impossibly slow
dbutti
33 Posts
March 27, 2025, 3:55 pmQuote from dbutti on March 27, 2025, 3:55 pmHello, we are running a 4-node Petasan cluster with 20 OSDs and ~120TB total raw capacity. The cluster is performing rather smoothly, HDDs are used for storage and SSDs for journals and cache.
Lastly I have stumbled upon the following issue: I have connected a brand new 4TB LUN to a Windows Server 2016 machine, using 2 dedicated 10Gbps links with 9000 bytes MTU and the built-in Windows iSCSI initiator. The LUN is immediately visible, but formatting the volume as NTFS is taking forever, now running since 3+ hours, and no end in sight. Network activity on the 2 links is almost non-existent, about 40kbps each. This test is being made with 4x multipathing enabled, but previously I got similarly bad performance while using a single path.
Meanwhile, activity on the cluster is quite low, and OSD commit latency is indicated as approximately 1ms everywhere (with some spare spikes due to other activities).
Do you have any clues, what could possibly be wrong here?
Thank-you in advance,
Hello, we are running a 4-node Petasan cluster with 20 OSDs and ~120TB total raw capacity. The cluster is performing rather smoothly, HDDs are used for storage and SSDs for journals and cache.
Lastly I have stumbled upon the following issue: I have connected a brand new 4TB LUN to a Windows Server 2016 machine, using 2 dedicated 10Gbps links with 9000 bytes MTU and the built-in Windows iSCSI initiator. The LUN is immediately visible, but formatting the volume as NTFS is taking forever, now running since 3+ hours, and no end in sight. Network activity on the 2 links is almost non-existent, about 40kbps each. This test is being made with 4x multipathing enabled, but previously I got similarly bad performance while using a single path.
Meanwhile, activity on the cluster is quite low, and OSD commit latency is indicated as approximately 1ms everywhere (with some spare spikes due to other activities).
Do you have any clues, what could possibly be wrong here?
Thank-you in advance,
dbutti
33 Posts
March 27, 2025, 5:47 pmQuote from dbutti on March 27, 2025, 5:47 pmJust a quick update on this: I have interrupted the format operation after several hours, connected to the LUN from a Linux machine, and there I could instantly create a 4TB volume with the mfntfs command. Right after, I reconnected the LUN to the same Windows server, and it can mount and use the new volume without issues. So there must be definitely something wrong with the formatting operation under Windows...
Just a quick update on this: I have interrupted the format operation after several hours, connected to the LUN from a Linux machine, and there I could instantly create a 4TB volume with the mfntfs command. Right after, I reconnected the LUN to the same Windows server, and it can mount and use the new volume without issues. So there must be definitely something wrong with the formatting operation under Windows...
admin
2,957 Posts
March 28, 2025, 5:04 pmQuote from admin on March 28, 2025, 5:04 pmif you enable trim/discard, formatting under Windows could be slow, you can format it then enable trim if needed.
if you enable trim/discard, formatting under Windows could be slow, you can format it then enable trim if needed.
NTFS formatting a new volume (4TB) over iSCSI is impossibly slow
dbutti
33 Posts
Quote from dbutti on March 27, 2025, 3:55 pmHello, we are running a 4-node Petasan cluster with 20 OSDs and ~120TB total raw capacity. The cluster is performing rather smoothly, HDDs are used for storage and SSDs for journals and cache.
Lastly I have stumbled upon the following issue: I have connected a brand new 4TB LUN to a Windows Server 2016 machine, using 2 dedicated 10Gbps links with 9000 bytes MTU and the built-in Windows iSCSI initiator. The LUN is immediately visible, but formatting the volume as NTFS is taking forever, now running since 3+ hours, and no end in sight. Network activity on the 2 links is almost non-existent, about 40kbps each. This test is being made with 4x multipathing enabled, but previously I got similarly bad performance while using a single path.
Meanwhile, activity on the cluster is quite low, and OSD commit latency is indicated as approximately 1ms everywhere (with some spare spikes due to other activities).
Do you have any clues, what could possibly be wrong here?
Thank-you in advance,
Hello, we are running a 4-node Petasan cluster with 20 OSDs and ~120TB total raw capacity. The cluster is performing rather smoothly, HDDs are used for storage and SSDs for journals and cache.
Lastly I have stumbled upon the following issue: I have connected a brand new 4TB LUN to a Windows Server 2016 machine, using 2 dedicated 10Gbps links with 9000 bytes MTU and the built-in Windows iSCSI initiator. The LUN is immediately visible, but formatting the volume as NTFS is taking forever, now running since 3+ hours, and no end in sight. Network activity on the 2 links is almost non-existent, about 40kbps each. This test is being made with 4x multipathing enabled, but previously I got similarly bad performance while using a single path.
Meanwhile, activity on the cluster is quite low, and OSD commit latency is indicated as approximately 1ms everywhere (with some spare spikes due to other activities).
Do you have any clues, what could possibly be wrong here?
Thank-you in advance,
dbutti
33 Posts
Quote from dbutti on March 27, 2025, 5:47 pmJust a quick update on this: I have interrupted the format operation after several hours, connected to the LUN from a Linux machine, and there I could instantly create a 4TB volume with the mfntfs command. Right after, I reconnected the LUN to the same Windows server, and it can mount and use the new volume without issues. So there must be definitely something wrong with the formatting operation under Windows...
Just a quick update on this: I have interrupted the format operation after several hours, connected to the LUN from a Linux machine, and there I could instantly create a 4TB volume with the mfntfs command. Right after, I reconnected the LUN to the same Windows server, and it can mount and use the new volume without issues. So there must be definitely something wrong with the formatting operation under Windows...
admin
2,957 Posts
Quote from admin on March 28, 2025, 5:04 pmif you enable trim/discard, formatting under Windows could be slow, you can format it then enable trim if needed.
if you enable trim/discard, formatting under Windows could be slow, you can format it then enable trim if needed.