Recommended recordsize for a zfs dataset hosting a Netatalk CNID backend database? (.AppleDB)

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








0















Which is the recommended record size for a zfs dataset hosting a Netatalk CNID backend database?? (.AppleDB)



The plan is to use a zfs dataset exclusively for the Netatalk CNID backend, and configure the recordsize property according.



CNID backend database is based in Berkeley DB.



Thanks.










share|improve this question
























  • Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

    – Andrew Henle
    Mar 7 at 10:31






  • 1





    Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

    – Dan
    Mar 7 at 21:12











  • However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

    – Dan
    Mar 7 at 21:13

















0















Which is the recommended record size for a zfs dataset hosting a Netatalk CNID backend database?? (.AppleDB)



The plan is to use a zfs dataset exclusively for the Netatalk CNID backend, and configure the recordsize property according.



CNID backend database is based in Berkeley DB.



Thanks.










share|improve this question
























  • Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

    – Andrew Henle
    Mar 7 at 10:31






  • 1





    Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

    – Dan
    Mar 7 at 21:12











  • However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

    – Dan
    Mar 7 at 21:13













0












0








0








Which is the recommended record size for a zfs dataset hosting a Netatalk CNID backend database?? (.AppleDB)



The plan is to use a zfs dataset exclusively for the Netatalk CNID backend, and configure the recordsize property according.



CNID backend database is based in Berkeley DB.



Thanks.










share|improve this question
















Which is the recommended record size for a zfs dataset hosting a Netatalk CNID backend database?? (.AppleDB)



The plan is to use a zfs dataset exclusively for the Netatalk CNID backend, and configure the recordsize property according.



CNID backend database is based in Berkeley DB.



Thanks.







zfs database






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 8 at 2:43







vicmarto

















asked Mar 7 at 7:27









vicmartovicmarto

207




207












  • Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

    – Andrew Henle
    Mar 7 at 10:31






  • 1





    Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

    – Dan
    Mar 7 at 21:12











  • However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

    – Dan
    Mar 7 at 21:13

















  • Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

    – Andrew Henle
    Mar 7 at 10:31






  • 1





    Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

    – Dan
    Mar 7 at 21:12











  • However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

    – Dan
    Mar 7 at 21:13
















Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

– Andrew Henle
Mar 7 at 10:31





Benchmark the performance of various ZFS recordsizes using your projected workload, and pick the best one.

– Andrew Henle
Mar 7 at 10:31




1




1





Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

– Dan
Mar 7 at 21:12





Typically, smaller block sizes are better for performance because they do not cause as much write amplification (updating a sub-block doesn't create a read-modify-write), but they are worse for compression. I would try 4K as a reasonable guess, but I agree there is no clear way to know without benchmarking your actual workload, since it appears BerkeleyDB can be configured to use block sizes from 512B to 64KB.

– Dan
Mar 7 at 21:12













However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

– Dan
Mar 7 at 21:13





However, you should at least make sure you use the same block size for both BerkeleyDB and your filesystem, and that both of those are larger than the block size your disks are using.

– Dan
Mar 7 at 21:13










0






active

oldest

votes












Your Answer








StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504852%2frecommended-recordsize-for-a-zfs-dataset-hosting-a-netatalk-cnid-backend-databas%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes















draft saved

draft discarded
















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504852%2frecommended-recordsize-for-a-zfs-dataset-hosting-a-netatalk-cnid-backend-databas%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown






Popular posts from this blog

Peggy Mitchell

Palaiologos

The Forum (Inglewood, California)