FAQ SearchLogin
Tuxera Home
View unanswered posts | View active topics It is currently Fri May 14, 2021 15:41



Post new topic Reply to topic  [ 3 posts ] 
NTFS cluster size vs FUSE blksize 
Author Message

Joined: Sat Aug 06, 2011 13:19
Posts: 4
Post NTFS cluster size vs FUSE blksize
Hello,

How is FUSE blksize related to NTFS cluster size?

Code:
$ sudo ntfsinfo -m /dev/sda9 | sed '/^MFT/{Q}'
Volume Information
   Name of device: /dev/sda9
   Device state: 11
   Volume Name: dt-data
   Volume State: 1
   Volume Version: 3.1
   Sector Size: 512
   Cluster Size: 65536
   Volume Size in Clusters: 13115519
vs
Code:
$ sudo mount /dev/sda9 /dt-data/
$ grep /dev/sda9 /proc/mounts
/dev/sda9 /dt-data fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
$ tail -5 /var/log/daemon.log
Aug  6 13:29:34 debian ntfs-3g[5824]: Version 2010.3.6 integrated FUSE 27
Aug  6 13:29:34 debian ntfs-3g[5824]: Mounted /dev/sda9 (Read-Write, label "dt-data", NTFS 3.1)
Aug  6 13:29:34 debian ntfs-3g[5824]: Cmdline options: rw
Aug  6 13:29:34 debian ntfs-3g[5824]: Mount options: rw,silent,allow_other,nonempty,relatime,fsname=/dev/sda9,blkdev,blksize=4096
Aug  6 13:29:34 debian ntfs-3g[5824]: Ownership and permissions disabled, configuration type 1

Wouldn't it be more optimal to have a block size of fuseblk equal to cluster size of ntfs volume? How this block size is used internally?
Everything works the way it is now, so maybe even blksize doesn't matter at all?

I'll be grateful for detailed answers.


Sat Aug 06, 2011 13:46
Profile
NTFS-3G Lead Developer

Joined: Tue Sep 04, 2007 17:22
Posts: 1286
Post Re: NTFS cluster size vs FUSE blksize
Hi,

Quote:
Wouldn't it be more optimal to have a block size of fuseblk equal to cluster size of ntfs volume?

What ntfs-3g actually does is setting the fuseblk to the smallest value of cluster size and system page size. I do not know why the limitation to the system page size has been set.
Quote:
Cluster Size: 65536

I suppose you have a specific reason to use big clusters.

If your applications are also using big buffers, you might take advantage of using the option "big_writes" available in recent advanced ntfs-3g versions, to use big buffers along the way.

Regards

Jean-Pierre


Sat Aug 06, 2011 21:51
Profile

Joined: Sat Aug 06, 2011 13:19
Posts: 4
Post Re: NTFS cluster size vs FUSE blksize
jpa wrote:
Quote:
Wouldn't it be more optimal to have a block size of fuseblk equal to cluster size of ntfs volume?

What ntfs-3g actually does is setting the fuseblk to the smallest value of cluster size and system page size. I do not know why the limitation to the system page size has been set.
So for ntfs-3g fuse's blksize = min(cluster_size, pagesize) by design? Then it sounds ok, as I am AMD64 user on 64-bit linux.
Code:
$ getconf PAGESIZE
4096
Or it should be actually more as your second sentence may suggest?

Quote:
Quote:
Cluster Size: 65536

I suppose you have a specific reason to use big clusters.
Sure it seems big, as it's not 128TB+ partition just a mere 800GB one, but having virtual disks and other big files on it rather justifies that choice.

jpa wrote:
If your applications are also using big buffers, you might take advantage of using the option "big_writes" available in recent advanced ntfs-3g versions, to use big buffers along the way.
Advanced ntfs-3g according to the page is rather stable, but "problems may have crept in", thus I hesitate to use it. OTOH I may "risk" running more recent normal ntfs-3g (2011.4.12AR.4-2 from wheezy on my debian squeeze). After all there were some improvements through the year.


Sun Aug 07, 2011 00:08
Profile
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 


Who is online

Users browsing this forum: No registered users and 3 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:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Original forum style by Vjacheslav Trushkin.