NTFS support

[Ivan@snb]

Hi.
I've used firmware 380.57 for the last year and yesterday upgraded it to the latest release 380.67.
Now I cannot use my 8TB HDD connected to USB3 port via SMB. Router hangs when I try to access SMB share. One for the CPUs is constantly 100% busty and system log is full with the errors like this (full log attached to this message):
Jul 31 16:12:29 kernel: __find_get_block_slow() failed. block=11953253248, b_blocknr=3363318656
Jul 31 16:12:29 kernel: b_state=0x00000020, b_size=512
Jul 31 16:12:29 kernel: device blocksize: 512

HDD is looking healthy and works fine in Windows. Chkdsk reports no issues with it.
Is there anything I can do to fix this issue?

TIA, Ivan.

 

[ColinTaylor]

It's not a SMB issue as such. Your router cannot read from the drive properly. Try switching over to the USB2 connection to see if that fixes it. Also try replacing the USB cable and using another power supply on the USB HDD.

 

[Ivan@snb]

It's not a SMB issue as such. Your router cannot read from the drive properly. Try switching over to the USB2 connection to see if that fixes it. Also try replacing the USB cable and using another power supply on the USB HDD.

That does not make sense as HDD worked fine just before the firmware upgrade on the same router and it functions properly with the other devices.

 

[ColinTaylor]

I didn't say the HDD wasn't working, I said that the router was having trouble accessing it.

 

[Ivan@snb]

I didn't say the HDD wasn't working, I said that the router was having trouble accessing it.

So it could be NTFS or USB driver issue.

P.S.: Switching to USB2 port does not make any difference.

 

[Ivan@snb]

It's not a SMB issue as such. Your router cannot read from the drive properly. Try switching over to the USB2 connection to see if that fixes it. Also try replacing the USB cable and using another power supply on the USB HDD.

Other users have similar problems:
https://www.snbforums.com/threads/r...65-is-now-available.37295/page-21#post-311852
https://www.snbforums.com/threads/100-cpu-after-update-firmware.40404/
https://www.snbforums.com/threads/usb-hard-drive-and-87u.29696/

And Jarp has resolved the issue by replacing NTFS dirver https://www.snbforums.com/threads/usb-hard-drive-and-87u.29696/#post-321148

 

[Ivan@snb]

Not sure it's related to this issue but it could be overflow bug: https://lists.ubuntu.com/archives/kernel-team/2014-October/048512.html

Can anybody close to *nix development check this out?

 

[RMerlin]

Asus does not officially support 8 TB HDDs with Asuswrt.

 

[Ivan@snb]

Asus does not officially support 8 TB HDDs with Asuswrt.

Looks like there's partition size limit (http://event.asus.com/2009/networks/disksupport/) But it worked with an older firmware somehow

What should be done to include support for large disks? Do I need to post a feature request at ASUS forum?

 

[RMerlin]

What should be done to include support for large disks? Do I need to post a feature request at ASUS forum?

You need to get a real NAS. Those routers lack the CPU power and the RAM to be able to handle such large disks. Even a 4 TB partition is already too large to be able to perform a file system check without errorring out due to running out of memory.

 

[Ivan@snb]

You need to get a real NAS. Those routers lack the CPU power and the RAM to be able to handle such large disks. Even a 4 TB partition is already too large to be able to perform a file system check without errorring out due to running out of memory.

That's not quite true. Resources required to manage file system (file table + optionally journals) depend not only on the partition size but on number of files and cluster size also.
E.g.: my Windows 750 GB drive has 792MB used for MFT because of thousands of small files but my 8TB drive uses only 6MB for MFT (see below). It's much easier to check/manage big drive with a relativelly small amount of huge files rather than a small drive with a huge amount of small files.


C:\Temp\sysinternals>ntfsinfo64 c:

NtfsInfo v1.2 - NTFS Information Dump
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Volume Size
-----------
Volume size : 701115 MB
Total sectors : 1435885567
Total clusters : 179485695
Free clusters : 1416921
Free space : 5534 MB (0% of drive)

Allocation Size
----------------
Bytes per sector : 512
Bytes per cluster : 4096
Bytes per MFT record : 0
Clusters per MFT record: 0

MFT Information
---------------
MFT size : 792 MB (0% of drive)
MFT start cluster : 786432
MFT zone clusters : 87939488 - 87990720
MFT zone size : 200 MB (0% of drive)
MFT mirror start : 2

Meta-Data files
---------------

C:\Temp\sysinternals>ntfsinfo64 h:

NtfsInfo v1.2 - NTFS Information Dump
Copyright (C) 2005-2016 Mark Russinovich
Sysinternals - www.sysinternals.com


Volume Size
-----------
Volume size : 7630755 MB
Total sectors : 15627788287
Total clusters : 122092095
Free clusters : 10305380
Free space : 644086 MB (8% of drive)

Allocation Size
----------------
Bytes per sector : 512
Bytes per cluster : 65536
Bytes per MFT record : 0
Clusters per MFT record: 0

MFT Information
---------------
MFT size : 6 MB (0% of drive)
MFT start cluster : 49152
MFT zone clusters : 49248 - 52384
MFT zone size : 196 MB (0% of drive)
MFT mirror start : 1

Meta-Data files
---------------

 

[RMerlin]

That's not quite true. Resources required to manage file system (file table + optionally journals) depend not only on the partition size but on number of files and cluster size also.

The partition size isn't the only factor indeed, but you're more likely to have more files on a large disk than a small one.

Also note that NTFS and ext are a bit different in how they handle things there.