zfs record and tuning for NFS

[aurfalien]

Hi,

Does it makes sense to tune ZFS record size to NFS block sizes?

In other words, if my ZFS server were only an NFS server and clients were mounting with r/w size of 32,758, is it then logical to tune ZFS to accommodate?

My current value looks to be 128L.

I may enable AFP and will have to figure out its transfer block size eventually.

- aurf

[Richard Elling]

Post by aurfalien
Hi,
Does it makes sense to tune ZFS record size to NFS block sizes?

In most cases, no.

Post by aurfalien
In other words, if my ZFS server were only an NFS server and clients were mounting with r/w size of 32,758, is it then logical to tune ZFS to accommodate?
My current value looks to be 128L.

recordsize is the upper limit for file systems. The actual size depends on how the
application writes. If the application only writes 32k, then the recordsize for the files
will also be 32k.

Post by aurfalien
I may enable AFP and will have to figure out its transfer block size eventually.

dtrace is your friend :-)
-- richard

--

***@RichardElling.com
[phone]












-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[aurfalien]

Post by Richard Elling

Post by aurfalien
Hi,
Does it makes sense to tune ZFS record size to NFS block sizes?

In most cases, no.

Post by aurfalien
In other words, if my ZFS server were only an NFS server and clients were mounting with r/w size of 32,758, is it then logical to tune ZFS to accommodate?
My current value looks to be 128L.

recordsize is the upper limit for file systems. The actual size depends on how the
application writes. If the application only writes 32k, then the recordsize for the files
will also be 32k.

Post by aurfalien
I may enable AFP and will have to figure out its transfer block size eventually.

dtrace is your friend :-)

As you you Mr E :)

A real hoot that you are on this list for sure.

- aurf


-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Jim Klimov]

Post by Richard Elling
recordsize is the upper limit for file systems. The actual size depends on how the
application writes. If the application only writes 32k, then the recordsize for the files
will also be 32k.

May I inquire about this again? I was last told (by Bob I think) that
the smaller recordsizes are used for "tails" and small files. However
as a file is appended to the end, its tail block is reallocated with
COW and can grow up to the recordsize until the next logical block is
started and accounted for in the file. Likewise, replacement of small
pieces mid-file does reallocate the whole block. In fact, I tested
that with some simple dd scripting and ZDB interrogation, and found
this to be true. It may probably be possible to create counter-examples
with sparse files and increases of the file-size by blowing it up
mid-way, but at least for general use-cases, I think that if the
application writes 32k to a file 4 times, it would end up as one
128K block.

Thanks for any clarifications,
//Jim

[Richard Elling]

Post by Jim Klimov

Post by Richard Elling
recordsize is the upper limit for file systems. The actual size depends on how the
application writes. If the application only writes 32k, then the recordsize for the files
will also be 32k.

May I inquire about this again? I was last told (by Bob I think) that
the smaller recordsizes are used for "tails" and small files. However
as a file is appended to the end, its tail block is reallocated with
COW and can grow up to the recordsize until the next logical block is
started and accounted for in the file. Likewise, replacement of small
pieces mid-file does reallocate the whole block. In fact, I tested
that with some simple dd scripting and ZDB interrogation, and found
this to be true. It may probably be possible to create counter-examples
with sparse files and increases of the file-size by blowing it up
mid-way, but at least for general use-cases, I think that if the
application writes 32k to a file 4 times, it would end up as one
128K block.

Don't confuse buffered file I/O with NFS writes.
-- richard

--

***@RichardElling.com
[phone]












-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com

[Andrew Galloway]

If/when tuning NFS block sizes, also look at/keep in mind nfs:nfs3_size and
nfs:nfs4_size tuneables, if on illumos/Solaris.

- Andrew

Post by aurfalien
Hi,
Does it makes sense to tune ZFS record size to NFS block sizes?
In other words, if my ZFS server were only an NFS server and clients were
mounting with r/w size of 32,758, is it then logical to tune ZFS to
accommodate?
My current value looks to be 128L.
I may enable AFP and will have to figure out its transfer block size eventually.
- aurf
-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
https://www.listbox.com/member/archive/rss/182191/24484421-62d25f20
https://www.listbox.com/member/?&
Powered by Listbox: http://www.listbox.com

-------------------------------------------
illumos-zfs
Archives: https://www.listbox.com/member/archive/182191/=now
RSS Feed: https://www.listbox.com/member/archive/rss/182191/23047029-187a0c8d
Modify Your Subscription: https://www.listbox.com/member/?member_id=23047029&id_secret=23047029-2e85923f
Powered by Listbox: http://www.listbox.com