[Dovecot] AIX: mntctl implementation for NFS quota support
Hi Timo, Hello list,
I've played around with dovecot-1.1.1 on AIX to get quotas (especially NFS quotas) to work. I've found that dovecot doesn't implement handling of 'mntctl' and so it is unable to determine filesystem mountpoints on AIX correctly.
Your'll find more information about 'mntctl' here: http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.ai...
Okay...
I've added mntctl support to 'lib/mountpoint.c' today. My tests are looking good and so I'd like to share the patch. While I'm still not really familiar with dovecots memory management, I need someone who is familiar with it to have a look on my lines of code. Especially the usage or p_new, t_strconcat and p_free should be checked. :-)
To activate the patch you have to add "#define HAVE_VMOUNT_H 1" do 'config.h'. Maybe someone wants to alter configure* to do this automatically?
And of course Timo, if you find it useful, you may include the code in one of the next dovecot releases.
Regards, Ralf
Dipl.-Inform. (FH) Ralf Becker Rechenzentrum (r/ft) der FH Trier (Network|Mail|Web|Firewall) University of applied sciences Administrator Schneidershof, D-54293 Trier
Mail: beckerr@fh-trier.de Fon: +49 651 8103 499
Web: http://www.fh-trier.de/~beckerr Fax: +49 651 8103 214PubKey: http://www.fh-trier.de/~beckerr Crypto: GnuPG, S/MIME
Wenn Gott gewollt haette, dass E-Mail in HTML geschrieben wuerden, endeten Gebete traditionell mit </amen>. (Tom Listen)
On Jul 5, 2008, at 10:39 PM, Ralf Becker wrote:
I've added mntctl support to 'lib/mountpoint.c' today. My tests are
looking good and so I'd like to share the patch. While I'm still not really familiar with dovecots memory management,
I need someone who is familiar with it to have a look on my lines of
code. Especially the usage or p_new, t_strconcat and p_free should
be checked. :-)
I'd probably change the allocations a bit to avoid extra syscalls.
Something like:
// guess that 256 bytes is enough usually. use larger value if it's not. char mtab_static[256], *mtab = mtab_static;
count = mntctl(..); while (count == 0) { mtab = t_malloc(size); count = mntctl(..); } if (count < 0) { i_error("mntctl() failed: %m"); return -1; } ..etc..
Also change to HAVE_SYS_VMOUNT_H.
To activate the patch you have to add "#define HAVE_VMOUNT_H 1" do
'config.h'. Maybe someone wants to alter configure* to do this
automatically?
Just add sys/vmount.h to AC_CHECK_HEADERS() list.
Hi Timo,
I've added support for a static mtab buffer.
Unfortunately 256 Bytes are too small by far. In my case the required space is about 3 KByte. To avoid unnecessary memory allocation the static size is determined at configuration time by getting the current buffer size and adding space for about 5 mountpoints more. In addition 'configure' now checks for sys/vmount.h
Regards, Ralf
Timo Sirainen schrieb am 05.07.2008 22:04:
On Jul 5, 2008, at 10:39 PM, Ralf Becker wrote:
I've added mntctl support to 'lib/mountpoint.c' today. My tests are looking good and so I'd like to share the patch. While I'm still not really familiar with dovecots memory management, I need someone who is familiar with it to have a look on my lines of code. Especially the usage or p_new, t_strconcat and p_free should be checked. :-)
I'd probably change the allocations a bit to avoid extra syscalls. Something like:
// guess that 256 bytes is enough usually. use larger value if it's not. char mtab_static[256], *mtab = mtab_static;
count = mntctl(..); while (count == 0) { mtab = t_malloc(size); count = mntctl(..); } if (count < 0) { i_error("mntctl() failed: %m"); return -1; } ..etc..
Also change to HAVE_SYS_VMOUNT_H.
To activate the patch you have to add "#define HAVE_VMOUNT_H 1" do 'config.h'. Maybe someone wants to alter configure* to do this automatically?
Just add sys/vmount.h to AC_CHECK_HEADERS() list.
--
Dipl.-Inform. (FH) Ralf Becker Rechenzentrum (r/ft) der FH Trier (Network|Mail|Web|Firewall) University of applied sciences Administrator Schneidershof, D-54293 Trier
Mail: beckerr@fh-trier.de Fon: +49 651 8103 499
Web: http://www.fh-trier.de/~beckerr Fax: +49 651 8103 214PubKey: http://www.fh-trier.de/~beckerr Crypto: GnuPG, S/MIME
Wenn Gott gewollt haette, dass E-Mail in HTML geschrieben wuerden, endeten Gebete traditionell mit </amen>. (Tom Listen)
On Sun, 2008-07-06 at 18:41 +0200, Ralf Becker wrote:
Hi Timo,
I've added support for a static mtab buffer.
Unfortunately 256 Bytes are too small by far. In my case the required space is about 3 KByte. To avoid unnecessary memory allocation the static size is determined at configuration time by getting the current buffer size and adding space for about 5 mountpoints more. In addition 'configure' now checks for sys/vmount.h
Committed with a few changes, could you try if it still works? :) http://hg.dovecot.org/dovecot-1.1/rev/ecc57955b99d
- Some small coding style changes to make it more consistent with rest of Dovecot code
- Handle mntctl() returning failure
- Instead of just one mntctl() retry I added a while-loop. The required allocation size can change if more mounts are added, right? So there's otherwise a small race condition between the size checking and the actual allocation that could cause an unwanted failure. And I think it's pretty safe to assume that the kernel won't return values that will cause infinite looping. :)
Timo Sirainen schrieb am 20.07.2008 18:01:
Committed with a few changes, could you try if it still works? :) http://hg.dovecot.org/dovecot-1.1/rev/ecc57955b99d
There is a small compiling issue: --- dovecot-1.1.2-orig/src/lib/mountpoint.c 2008-07-20 17:56:16.000000000 +0200 +++ dovecot-1.1.2/src/lib/mountpoint.c 2008-07-21 01:02:15.000000000 +0200 @@ -123,7 +123,7 @@ for (i = 0; i < count && device_path == NULL; i++) { struct stat vst; const char *vmt_base = (const char *)vmt; - const char *vmt_base, *vmt_object, *vmt_stub, *vmt_hostname; + const char *vmt_object, *vmt_stub, *vmt_hostname; vmt_hostname = vmt_base + vmt->vmt_data[VMT_HOSTNAME].vmt_off; vmt_object = vmt_base + vmt->vmt_data[VMT_OBJECT].vmt_off;
- Instead of just one mntctl() retry I added a while-loop. The required allocation size can change if more mounts are added, right? So there's otherwise a small race condition between the size checking and the actual allocation that could cause an unwanted failure. And I think it's pretty safe to assume that the kernel won't return values that will cause infinite looping. :)
Yes, you're right. That looks perfect for me :-) -- ______________________________________________________________________ Dipl.-Inform. (FH) Ralf Becker Rechenzentrum (r/ft) der FH Trier (Network|Mail|Web|Firewall) University of applied sciences Administrator Schneidershof, D-54293 Trier Mail: beckerr@fh-trier.de Fon: +49 651 8103 499 Web: http://www.fh-trier.de/~beckerr Fax: +49 651 8103 214 PubKey: http://www.fh-trier.de/~beckerr Crypto: GnuPG, S/MIME ______________________________________________________________________ Wenn Gott gewollt haette, dass E-Mail in HTML geschrieben wuerden, endeten Gebete traditionell mit </amen>. (Tom Listen)
participants (2)
-
Ralf Becker
-
Timo Sirainen