> i would give the same device for *any* type of software since the > whole operating system including the kernel itself these days is built > with shared modules and you hardly gain anything measureable just > because one piece of your system is statically compiled > > when it's mostly interesting on very slow embedded devices where it > makes a small difference in startup time when a lower amount of files > needs to be loadedNevertheless, the default build of smbd produces almost twenty builtin modules, such as vfs_posixacl... Why would that be?
Am 12.03.2016 um 20:31 schrieb Miguel Medalha:>> i would give the same device for *any* type of software since the >> whole operating system including the kernel itself these days is built >> with shared modules and you hardly gain anything measureable just >> because one piece of your system is statically compiled >> >> when it's mostly interesting on very slow embedded devices where it >> makes a small difference in startup time when a lower amount of files >> needs to be loaded > > Nevertheless, the default build of smbd produces almost twenty builtin > modules, such as vfs_posixacl... Why would that be?i guess because many things won't work out-of-the-box without it may make sense to build others which you really use on every machine statically to not need to add them in your smb.conf on the other hand doing so and then try to re-use your smb.conf somewhere else with a differnt build may bring some headaches because they are not loaded - so it depends but as your question was about performance: no difference -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20160312/efb86e71/signature.sig>
> i guess because many things won't work out-of-the-box without > > it may make sense to build others which you really use on every > machine statically to not need to add them in your smb.conf > > on the other hand doing so and then try to re-use your smb.conf > somewhere else with a differnt build may bring some headaches because > they are not loaded - so it depends > > but as your question was about performance: no differenceYes, my question was about performance because I already had made my mind about convenience in some cases ;-) Thank you for your answers. Best regards.
> it may make sense to build others which you really use on every > machine statically to not need to add them in your smb.confThat's what I expected, too. Since then I made some experiences. I built samba 4.3.6 with a static vfs_acl_xattr module. It is builtin alright, it is listed under "Builtin modules" at the output of "smbd -b". Then: -- Comment"vfs objects = acl_xattr" from a share in smb.conf -- Restart all Samba services -- From Windows, create a folder "newfolder" in that same share -- Run "getfattr -n security.NTACL newfolder". getfattr outputs "security.NTACL: No such attribute" -- delete folder "newfolder" -- In smb.conf, remove comment from "vfs objects = acl_xattr" under the same share -- Restart all Samba services -- From Windows, create a folder "newfolder" in that same share -- Run "getfattr -n security.NTACL folder". getfattr finds the extended attribute and presents it correctly. So, it looks like our expectations about this didn't come to fruition. Shouldn't the builtin module do its job normally?