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

Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom: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.
zfs database
add a comment |
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
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
add a comment |
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
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
zfs database
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
add a comment |
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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