[Dovecot] 1.0 roadmap
I've read about one month back this list's messages. I've still 216 messages from this year marked as "unread" which I should look into more (+258 older ones). Also I've 180 "unread" messages in my INBOX also which might contain something useful. So those messages could still contain something that should be added to this list.
Anyway looking at my current TODO, I think the following things should be fixed before v1.0. Additions, comments, patches and such welcome. :)
Help would be welcome in checking if these bugs are still there:
Thunderbird+POP3 DELE error. Was this fixed already? Could someone try this? See http://www.dovecot.org/list/dovecot/2005-June/007497.html and the rest of the thread. Basically put thousands of messages into mailbox, start downloading them and see if error comes.
Solaris sendfile is broken? Is it? Can someone try? You can test it with maildir by setting mail_save_crlf=yes, saving a somewhat large mail and FETCHing it (and truss that it really uses sendfile)
passdb passwd + passdb shadow -> passdb_password isn't reset to NULL (ie. probably doesn't allow logging in if the shadow password is correct?)
maildir: rename foo foo.xyz -> infinite loop possible? (doesn't seem so? why did I think it could be? look at the code)
Important:
- dict-server should have some config file which lists the allowed dicts
- LDA: empty mail gives an error.
- deliver: delivering mail to box smaller than mbox_min_index_size give close() errors
- mbox: CRLFs in headers break the mbox
- index: when mailbox is deleted/renamed and someone else had it open, we get stat() error messages in log file. Handle at least the most common places where it happens.
- lib-storage
- limit folder hierarchy levels? user can now create eg. a/a/a/a/... and then start renaming them from end to beginning, which probably will at some point start causing syscall failures which will fill up logs.
Probably should be done:
- mbox: dirty mode should be stored to index
- quota code should probably be always doing some quota_set_critical() instead of using mail_storage_set_critical(), so that quota_last_error() would work properly
- rfc2557 support for BODYSTRUCTURE, as specified by RFC3501
- keywords: add some limits to how many there can be
- don't return \* in PERMANENTFLAGS when we're full
- mbox: how well does dirty sync + status work? it reads the last mail every time? not very good..
- maildir: we probably shouldn't do duplicate detection/fixing?.. or at least stat() the old file before trying, because we might have just previously seen the old file and then new file and then we try to fix it..
Hello,
- Thunderbird+POP3 DELE error. Was this fixed already? Could someone try this? See http://www.dovecot.org/list/dovecot/2005-June/007497.html and the rest of the thread. Basically put thousands of messages into mailbox, start downloading them and see if error comes.
we are running dovecot-1.0.beta2 for several months now and this error seems to be solved. I don't know what caused it but it didn't happen again with this release (and hopefully newer ones that we haven't installed yet). I successfully downloaded more than 5000 messages through pop3 at once.
Regards Marten
Oh, and I forgot to mention. Please test the latest nightly snapshot (or CVS directly). I did a lot of changes today and I'd want to release beta9 soon. And I guess I should after that do a rc1 release instead of beta10.
Yes an RC1 release! As long as Dovecot has much Postfix support! for Quota and Maildirs!
--- Timo Sirainen <tss@iki.fi> wrote:
Oh, and I forgot to mention. Please test the latest nightly snapshot (or CVS directly). I did a lot of changes today and I'd want to release beta9 soon. And I guess I should after that do a rc1 release instead of beta10.
Going to RC numbering would be good. It will help ensure that distros don't decide to use your old 0.9xx stuff. Dovecot has been RC quality for a long time.
Timo Sirainen wrote:
Oh, and I forgot to mention. Please test the latest nightly snapshot (or CVS directly). I did a lot of changes today and I'd want to release beta9 soon. And I guess I should after that do a rc1 release instead of beta10.
hi,
On 2006-06-12 01:30:36 +0300, Timo Sirainen wrote:
Oh, and I forgot to mention. Please test the latest nightly snapshot (or CVS directly). I did a lot of changes today and I'd want to release beta9 soon. And I guess I should after that do a rc1 release instead of beta10.
JFYI: If you use SUSE Linux you can easily grab the dovecot-snapshot package from the openSUSE Build service [1]. The explaination for the user is at [2]. If you dont want to add the source to your package manager you can grab the rpms directly from [3].
Packages are build for: SUSE_SLES-9 SuSE_Linux_9.3 SuSE_Linux_10.0 SuSE_Linux_10.1 SuSE_Linux_Factory
additionally it is build for Fedora_Core_5/i586 but i didnt have a chance to test it there yet.
I will keep the package in sync with CVS atleast once a day.
Of course you can find there the normal dovecot package (updated to 1.0.beta8) aswell. :)
hope this helps
darix[1] http://en.opensuse.org/Build_Service [2] http://en.opensuse.org/Build_Service/User [3] http://software.opensuse.org/download/server:/mail/
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
Hi,
I have a problem with fs quota which I can still reproduce on latest CVS snapshot (dovecot-20060612.tar.gz).
My OS is a Debian Sarge with 2.6.15 kernel.
# lsmod|grep quota quota_v2 10240 0
# mount|grep sda9 /dev/sda9 on /home type xfs (rw,usrquota) I also tried on 1.0beta8 with reiserfs partition with same results.
# cat /etc/mtab |grep sda9 /dev/sda9 /home xfs rw,usrquota 0 0
# repquota -u /dev/sda9 *** Report for user quotas on device /dev/sda9 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace
root -- 608085656 0 0 3938317 0 0 dumitru -- 1964720 5242880 5451776 28558 0 0
# cat /etc/dovecot/dovecot.conf |egrep -v '^ *(#|$)' protocols = imap imaps pop3 pop3s disable_plaintext_auth = no log_timestamp = "%Y-%m-%d %H:%M:%S " mail_extra_groups = mail protocol imap { mail_plugins = quota imap_quota mail_plugin_dir = /usr/lib/dovecot/modules/imap } protocol pop3 { pop3_uidl_format = %v.%u } auth default { mechanisms = plain passdb pam { } userdb passwd { } user = root } plugin { quota = fs }
All my mail is in /home/dumitru/Maildir.
I'm using Display Quota plugin for Mozilla Thunderbird (https://addons.mozilla.org/thunderbird/881/) to see quota usage. When I access my mailbox by IMAP, Thunderbird reports that no storage quota are enforced on server.
From logs: Jun 12 17:06:07 debian dovecot: imap-login: Login: user=<dumitru>, method=plain, rip=10.2.5.6, lip=10.2.5.4 Jun 12 17:06:07 debian dovecot: IMAP(dumitru): quotactl(Q_GETQUOTA, /dev/sda9) failed: Invalid argument
Is this a dovecot bug or I am doing something wrong?
Regards, Dumitru
Timo Sirainen wrote:
Oh, and I forgot to mention. Please test the latest nightly snapshot (or CVS directly). I did a lot of changes today and I'd want to release beta9 soon. And I guess I should after that do a rc1 release instead of beta10.
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
Jun 12 17:06:07 debian dovecot: IMAP(dumitru): quotactl(Q_GETQUOTA, /dev/sda9) failed: Invalid argument
I guess this is wrong or something. I don't have quota enabled anywhere so I can't really test the code myself.
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
# strace -tt repquota -u /dev/sda9
17:44:30.978591 execve("/usr/sbin/repquota", ["repquota", "-u",
"/dev/sda9"], [/* 20 vars */]) = 0
17:44:30.978804 uname({sys="Linux", node="debian", ...}) = 0
17:44:30.979041 brk(0) = 0x806b000
17:44:30.979112 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fcb000
17:44:30.979221 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.979341 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No
such file or directory)
17:44:30.979453 open("/etc/ld.so.cache", O_RDONLY) = 4
17:44:30.979539 fstat64(4, {st_mode=S_IFREG|0644, st_size=53743, ...}) = 0
17:44:30.979669 old_mmap(NULL, 53743, PROT_READ, MAP_PRIVATE, 4, 0) =
0xb7fbd000
17:44:30.979788 close(4) = 0
17:44:30.979850 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.979946 open("/lib/tls/libc.so.6", O_RDONLY) = 4
17:44:30.980041 read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000"..., 512) = 512
17:44:30.980156 fstat64(4, {st_mode=S_IFREG|0755, st_size=1254660, ...}) = 0
17:44:30.980285 old_mmap(NULL, 1264972, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 4, 0) = 0xb7e88000
17:44:30.980412 old_mmap(0xb7fb2000, 36864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x129000) = 0xb7fb2000
17:44:30.980536 old_mmap(0xb7fbb000, 7500, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fbb000
17:44:30.980663 close(4) = 0
17:44:30.980754 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e87000
17:44:30.980970 set_thread_area({entry_number:-1 -> 6,
base_addr:0xb7e87460, limit:1048575, seg_32bit:1, contents:0,
read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
17:44:30.981057 munmap(0xb7fbd000, 53743) = 0
17:44:30.981187 open("/usr/lib/locale/locale-archive",
O_RDONLY|O_LARGEFILE) = 4
17:44:30.981293 fstat64(4, {st_mode=S_IFREG|0644, st_size=290576, ...}) = 0
17:44:30.981412 mmap2(NULL, 290576, PROT_READ, MAP_PRIVATE, 4, 0) =
0xb7e40000
17:44:30.981502 close(4) = 0
17:44:30.981583 brk(0) = 0x806b000
17:44:30.981636 brk(0x808c000) = 0x808c000
17:44:30.981714 brk(0) = 0x808c000
17:44:30.981848 open("/etc/nsswitch.conf", O_RDONLY|O_LARGEFILE) = 4
17:44:30.982005 fstat64(4, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
17:44:30.982120 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fca000
17:44:30.982208 read(4, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
17:44:30.982307 close(4) = 0
17:44:30.982361 munmap(0xb7fca000, 4096) = 0
17:44:30.982459 rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
17:44:30.982567 stat64("/proc/fs/xfs/stat", {st_mode=S_IFREG|0444,
st_size=0, ...}) = 0
17:44:30.982721 stat64("/proc/sys/fs/quota", {st_mode=S_IFDIR|0555,
st_size=0, ...}) = 0
17:44:30.982871 rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
17:44:30.982958 open("/etc/mtab", O_RDONLY) = 4
17:44:30.983040 fstat64(4, {st_mode=S_IFREG|0644, st_size=355, ...}) = 0
17:44:30.983176 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fca000
17:44:30.983242 read(4, "/dev/sda1 / ext3 rw,errors=remou"..., 4096) = 355
17:44:30.983393 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sda9", 0,
0xbf89efd0) = 0
17:44:30.983482 lstat64("/home", {st_mode=S_IFDIR|0755, st_size=8192,
...}) = 0
17:44:30.983608 statfs64("/home", 84, {f_type=0x58465342, f_bsize=4096,
f_blocks=363377600, f_bfree=210609614, f_bavail=210609614,
f_files=1453641472, f_ffree=1449674596, f_fsid={2057, 0}, f_namelen=255,
f_frsize=4096}) = 0
17:44:30.983744 stat64("/dev/sda9", {st_mode=S_IFBLK|0660,
st_rdev=makedev(8, 9), ...}) = 0
17:44:30.983959 stat64("/home", {st_mode=S_IFDIR|0755, st_size=8192,
...}) = 0
17:44:30.984106 read(4, "", 4096) = 0
17:44:30.984189 close(4) = 0
17:44:30.984257 munmap(0xb7fca000, 4096) = 0
17:44:30.984318 stat64("/dev/sda9", {st_mode=S_IFBLK|0660,
st_rdev=makedev(8, 9), ...}) = 0
17:44:30.984487 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sda9", 0,
0xbf8e10d0) = 0
17:44:30.984560 stat64("/dev/sda9", {st_mode=S_IFBLK|0660,
st_rdev=makedev(8, 9), ...}) = 0
17:44:30.984703 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sda9", 0,
0xbf8e10d0) = 0
17:44:30.984793 open("/usr/share/locale/locale.alias", O_RDONLY) = 4
17:44:30.984887 fstat64(4, {st_mode=S_IFREG|0644, st_size=2539, ...}) = 0
17:44:30.985005 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fca000
17:44:30.985088 read(4, "# Locale name alias data base.\n#"..., 4096) = 2539
17:44:30.985241 read(4, "", 4096) = 0
17:44:30.985298 close(4) = 0
17:44:30.985352 munmap(0xb7fca000, 4096) = 0
17:44:30.985487 open("/usr/share/locale/en_RO/LC_MESSAGES/quota.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
17:44:30.985594 open("/usr/share/locale/en/LC_MESSAGES/quota.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
17:44:30.985710 open("/usr/share/locale/en_US/LC_MESSAGES/quota.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
17:44:30.985821 open("/usr/share/locale/en_GB/LC_MESSAGES/quota.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
17:44:30.985940 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136,
2), ...}) = 0
17:44:30.986077 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fca000
17:44:30.986164 write(1, "*** Report for user quotas on de"..., 47***
Report for user quotas on device /dev/sda9) = 47
17:44:30.986293 write(1, "Block grace time: 7days; Inode g"..., 49Block
grace time: 7days; Inode grace time: 7days) = 49
17:44:30.986381 write(1, " Block li"...,
64 Block limits File limits) = 64
17:44:30.986475 write(1, "User used soft "...,
71User used soft hard grace used soft hard
grace) = 71
17:44:30.986570 write(1, "--------------------------------"...,
71----------------------------------------------------------------------)
= 71
17:44:30.986669 open("/etc/nsswitch.conf", O_RDONLY) = 4
17:44:30.986788 fstat64(4, {st_mode=S_IFREG|0644, st_size=465, ...}) = 0
17:44:30.986940 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fc9000
17:44:30.987046 read(4, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) = 465
17:44:30.987157 read(4, "", 4096) = 0
17:44:30.987214 close(4) = 0
17:44:30.987309 munmap(0xb7fc9000, 4096) = 0
17:44:30.987398 open("/etc/ld.so.cache", O_RDONLY) = 4
17:44:30.987470 fstat64(4, {st_mode=S_IFREG|0644, st_size=53743, ...}) = 0
17:44:30.987603 old_mmap(NULL, 53743, PROT_READ, MAP_PRIVATE, 4, 0) =
0xb7e32000
17:44:30.987728 close(4) = 0
17:44:30.987807 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.987928 open("/lib/tls/libnss_compat.so.2", O_RDONLY) = 4
17:44:30.988025 read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0000\22\0"..., 512) = 512
17:44:30.988138 fstat64(4, {st_mode=S_IFREG|0644, st_size=28616, ...}) = 0
17:44:30.988272 old_mmap(NULL, 31628, PROT_READ|PROT_EXEC, MAP_PRIVATE,
4, 0) = 0xb7fc2000
17:44:30.988374 old_mmap(0xb7fc9000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x6000) = 0xb7fc9000
17:44:30.988507 close(4) = 0
17:44:30.988572 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.988668 open("/lib/tls/libnsl.so.1", O_RDONLY) = 4
17:44:30.988762 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
<\0\000"..., 512) = 512
17:44:30.988881 fstat64(4, {st_mode=S_IFREG|0644, st_size=73304, ...}) = 0
17:44:30.989014 old_mmap(NULL, 80544, PROT_READ|PROT_EXEC, MAP_PRIVATE,
4, 0) = 0xb7e1e000
17:44:30.989142 old_mmap(0xb7e2f000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x11000) = 0xb7e2f000
17:44:30.989265 old_mmap(0xb7e30000, 6816, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7e30000
17:44:30.989398 close(4) = 0
17:44:30.989538 munmap(0xb7e32000, 53743) = 0
17:44:30.989639 open("/etc/ld.so.cache", O_RDONLY) = 4
17:44:30.989713 fstat64(4, {st_mode=S_IFREG|0644, st_size=53743, ...}) = 0
17:44:30.989826 old_mmap(NULL, 53743, PROT_READ, MAP_PRIVATE, 4, 0) =
0xb7e32000
17:44:30.989938 close(4) = 0
17:44:30.990010 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.990097 open("/lib/tls/libnss_nis.so.2", O_RDONLY) = 4
17:44:30.990182 read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\34\0"..., 512) = 512
17:44:30.990304 fstat64(4, {st_mode=S_IFREG|0644, st_size=33440, ...}) = 0
17:44:30.990424 old_mmap(NULL, 36620, PROT_READ|PROT_EXEC, MAP_PRIVATE,
4, 0) = 0xb7e15000
17:44:30.990520 old_mmap(0xb7e1d000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x7000) = 0xb7e1d000
17:44:30.990621 close(4) = 0
17:44:30.990708 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
17:44:30.990816 open("/lib/tls/libnss_files.so.2", O_RDONLY) = 4
17:44:30.990898 read(4,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\35"..., 512) = 512
17:44:30.990997 fstat64(4, {st_mode=S_IFREG|0644, st_size=34748, ...}) = 0
17:44:30.991117 old_mmap(NULL, 38044, PROT_READ|PROT_EXEC, MAP_PRIVATE,
4, 0) = 0xb7e0b000
17:44:30.991234 old_mmap(0xb7e14000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 4, 0x8000) = 0xb7e14000
17:44:30.991334 close(4) = 0
17:44:30.991429 munmap(0xb7e32000, 53743) = 0
17:44:30.991525 open("/etc/passwd", O_RDONLY) = 4
17:44:30.991623 fcntl64(4, F_GETFD) = 0
17:44:30.991679 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
17:44:30.991772 _llseek(4, 0, [0], SEEK_CUR) = 0
17:44:30.991859 fstat64(4, {st_mode=S_IFREG|0644, st_size=1363, ...}) = 0
17:44:30.991977 mmap2(NULL, 1363, PROT_READ, MAP_SHARED, 4, 0) = 0xb7fc1000
17:44:30.992071 _llseek(4, 1363, [1363], SEEK_SET) = 0
17:44:30.992169 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 0,
0xbf8e1090) = 0
17:44:30.992283 write(1, "root -- 608085656 0 "...,
73root -- 608085656 0 0 3938317 0 0) = 73
17:44:30.992366 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 1,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992461 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 2,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992546 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 3,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992628 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 4,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992710 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 5,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992791 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 6,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992875 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 7,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.992977 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 8,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993063 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 9,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993148 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 10,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993233 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 13,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993314 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 33,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993395 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 34,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993500 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 38,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993603 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 39,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993686 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 41,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993770 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 65534,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993854 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 102,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.993960 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 100,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994047 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 101,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994146 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 103,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994227 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 106,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994308 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 109,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994386 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 104,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994489 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 1000,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994575 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 111,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994656 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 105,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.994739 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 1048,
0xbf8e1090) = 0
17:44:30.994863 write(1, "dumitru -- 1964720 5242880 545"...,
71dumitru -- 1964720 5242880 5451776 28558 0 0) = 71
17:44:30.994946 quotactl(Q_XGETQUOTA|USRQUOTA, "/dev/sda9", 113,
0xbf8e1090) = -1 ENOENT (No such file or directory)
17:44:30.995026 fstat64(4, {st_mode=S_IFREG|0644, st_size=1363, ...}) = 0
17:44:30.995170 munmap(0xb7fc1000, 1363) = 0
17:44:30.995227 close(4) = 0
17:44:30.995286 write(1, "\n", 1) = 1
17:44:30.995407 write(1, "\n", 1) = 1
17:44:30.995482 munmap(0xb7fca000, 4096) = 0
17:44:30.995545 exit_group(0) = ?
Jun 12 17:06:07 debian dovecot: IMAP(dumitru): quotactl(Q_GETQUOTA, /dev/sda9) failed: Invalid argument
I guess this is wrong or something. I don't have quota enabled anywhere so I can't really test the code myself.
Regards, Dumitru
On Mon, 2006-06-12 at 17:56 +0300, Dumitru Negara wrote:
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
17:44:30.984487 quotactl(Q_XGETQSTAT|USRQUOTA, "/dev/sda9", 0, 0xbf8e10d0) = 0
This looks pretty much what I'm doing. What if you strace Dovecot, what's different in its call? For example change in protocol imap section:
mail_executable = strace -o /tmp/log /usr/local/libexec/dovecot/imap
or just strace -p imappid..
On Mon, 2006-06-12 at 17:56 +0300, Dumitru Negara wrote:
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
So I looked through repquota's sources and it looks like XFS has its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used. Patches welcome.
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:56 +0300, Dumitru Negara wrote:
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9 Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
So I looked through repquota's sources and it looks like XFS has its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used. Patches welcome.
OK, let's do it again :) ... with ext3 partition.
I copied my home to /var which is an ext3 fs.
# mount|grep sda6 /dev/sda6 on /var type ext3 (rw,usrquota)
# cat /etc/mtab |grep sda6 /dev/sda6 /var ext3 rw,usrquota 0 0
# quotaoff -p /var group quota on /var (/dev/sda6) is off user quota on /var (/dev/sda6) is on
# repquota -u /dev/sda6|grep dumitru dumitru -- 559868 5242880 5451776 16397 0 0
/etc/dovecot/dovecot.conf: ... mail_executable = /usr/bin/strace -o /tmp/dovecot.log /usr/lib/dovecot/imap ... Output of strace:
... gettimeofday({1150135839, 275393}, {4294967116, 0}) = 0 read(0, "3 getquotaroot \"INBOX.ITC\"\r\n", 4074) = 28 setsockopt(1, SOL_TCP, TCP_CORK, [1], 4) = 0 stat64("/var/home/dumitru/Maildir/.INBOX.ITC", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 lstat64("/var/home/dumitru/Maildir/.INBOX.ITC/cur", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 lstat64("/var/home/dumitru/Maildir/.INBOX.ITC/new", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 lstat64("/var/home/dumitru/Maildir/.INBOX.ITC/tmp", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 stat64("/var/home/dumitru/Maildir/.INBOX.ITC", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 stat64("/var/home/dumitru/Maildir/.INBOX.ITC", {st_mode=S_IFDIR|S_ISGID|0700, st_size=4096, ...}) = 0 stat64("/var/home/dumitru/Maildir/.INBOX.ITC/dovecot-shared", 0xbfd4bdb0) = -1 ENOENT (No such file or directory) time(NULL) = 1150135839 quotactl(Q_GETQUOTA|USRQUOTA, "/dev/sda6", 1048, {0, 135123624, 3086145476, 3086145476, 135123520, 135078840, 3218390664, 134938342}) = -1 EINVAL (Invalid argument) write(2, "\1Equotactl(Q_GETQUOTA, /dev/sda6"..., 59) = 59 gettimeofday({1150135839, 276398}, NULL) = 0 write(1, "* QUOTAROOT \"INBOX.ITC\" \"\"\r\n* BA"..., 101) = 101 setsockopt(1, SOL_TCP, TCP_CORK, [0], 4) = 0 gettimeofday({1150135839, 276578}, NULL) = 0 ...
Log: Jun 12 21:10:39 debian dovecot: imap-login: Login: user=<dumitru>, method=plain, rip=10.2.5.3, lip=10.2.5.4 Jun 12 21:10:39 debian dovecot: IMAP(dumitru): quotactl(Q_GETQUOTA, /dev/sda6) failed: Invalid argument
Dumitru
On Jun 12, 2006, at 9:48 PM, Dumitru Negara wrote:
So I looked through repquota's sources and it looks like XFS has
its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used.
Patches welcome.OK, let's do it again :) ... with ext3 partition. ..
Well, I think my answer is still the same. Someone who actually knows
how the filesystem quota stuff is supposed to work could fix it. I
don't see it important enough to waste spending time on.
Quoting Timo Sirainen <tss@iki.fi>:
On Jun 12, 2006, at 9:48 PM, Dumitru Negara wrote:
So I looked through repquota's sources and it looks like XFS has its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used. Patches welcome.
OK, let's do it again :) ... with ext3 partition. ..
Well, I think my answer is still the same. Someone who actually knows how the filesystem quota stuff is supposed to work could fix it. I
don't see it important enough to waste spending time on.
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2. Dovecot seems to handle UFS correctly. But if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better suited for hobbyists. I sure wish we had known this from the start.
-- Shameless self-promotion follows... ... or does it?
FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 /////////////////////////////////////////////////////////////////
On Mon, 2006-06-12 at 14:53 -0700, Chris H. wrote:
if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better suited for hobbyists. I sure wish we had known this from the start.
It appears you have a funny definition of the term "production systems". Consider using the definition that the rest of the world uses, and you'll have a much easier time communicating.
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
man, 12,.06.2006 kl. 14.53 -0700, skrev Chris H.:
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2. Dovecot seems to handle UFS correctly. But if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better suited for hobbyists. I sure wish we had known this from the start.
While I "need" xfs quotas badly, and in some way is in the same boat as you, I must say Timo really, really, really is free to do what ever he wants with his spare time. If you had paid big dollars for dovecot, I could have understood your frustration, but now you're just being silly.
-Stian
Quoting Stian Jordet <liste+dovecot@jordet.net>:
man, 12,.06.2006 kl. 14.53 -0700, skrev Chris H.:
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2. Dovecot seems to handle UFS correctly. But if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better suited for hobbyists. I sure wish we had known this from the start.
While I "need" xfs quotas badly, and in some way is in the same boat as you, I must say Timo really, really, really is free to do what ever he wants with his spare time. If you had paid big dollars for dovecot, I could have understood your frustration, but now you're just being silly.
-Stian I couldn't agree with you more. It *is* up to Tim as to what he will/ won't do. I never made *any* objection to that. The *only* point I was making here, is that I wish that I had known that it would ultimately be *my* responsibility to insure that Dovecot remains reliable/ useable on my chosen OS (FreeBSD). Given it's wide usage (FreeBSD) and years of experience with UW-IMAP I felt relatively confident that Dovecot would follow suit in an effort to remain competitive with UW-IMAP. In summary; as I clearly stated above; I wish I had known in advance that it would be ultimately be my responsibility to insure that Dovecot remained usable on our OS.
'nuff said.
-- Shameless self-promotion follows... ... or does it?
FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 /////////////////////////////////////////////////////////////////
On Jun 13, 2006, at 12:53 AM, Chris H. wrote:
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to
trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2. Dovecot seems to handle UFS correctly. But if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better
suited for hobbyists. I sure wish we had known this from the start.
Well, I'm sorry that you feel that way, but before switching I would
have supposed that you had checked that Dovecot does everything you
need it to do. Especially because UW-IMAP doesn't even *try* to
support the QUOTA extension that you obviously need so much, and that
Dovecot at least even tries to support it even if not in every single
operating system (or file system).
Doveocot isn't owned by any single company. I don't think the web
page even tries to claim anything like it anywhere. Are you saying
that I should devote my entire life to the one thing that *you*
yourself consider important to Dovecot? Even though most other people
don't really care about it?
I think I do pretty well at balancing what other people want for
Dovecot, what people (companies) pay for me to develop Dovecot to do
and what I myself want Dovecot to become. I guess in recent months
I've become worse at this since I've needed more time for school, but
in general I don't think I've done too badly.
Now, from you I've seen 3 mails within the whole Doveocot's life
time. If you had actually EVER contributed to Dovecot in any way in
its entire life time I might have replied differently. If you in no
way contribute to an open source project, you can't expect commercial
support out of it without paying for it for someone. And there are
most likely a lot of companies that would accept your money if you
wanted it (including the one I work for).
I'm happy to fix this problem for you, the standard company fee being
120 EUR/hour. Possibly even less if you can convince my supervisors
to accept it. Estimate for fixing it is about 6 hours (since I have
to install a system where I have quota). I don't think you can get
much better support than this elsewhere.
Just don't misunderstand this as me not doing anything unless someone
pays for it. For most of the last 4 years I've written Dovecot for
free without getting a single cent for it. I still do, but only as
long as I consider the changes to be important. If you have a
different opinion on the imporance, see the paragraph above.
On Jun 13, 2006, at 2:08 AM, Timo Sirainen wrote:
Just don't misunderstand this as me not doing anything unless
someone pays for it. For most of the last 4 years I've written
Dovecot for free without getting a single cent for it. I still do,
but only as long as I consider the changes to be important.
Almost forgot: and fun. Important or fun. I've a lot of things
planned for Dovecot v2.0 that I'm going to implement at my own time.
Unless of course someone pays for it, but so far it doesn't seem
likely. The main web page will btw. show a couple of sponsor
companies within a few days in case you're interested in seeing them. :)
Quoting Timo Sirainen <tss@iki.fi>:
On Jun 13, 2006, at 12:53 AM, Chris H. wrote:
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2. Dovecot seems to handle UFS correctly. But if we had known that we were required to write our own code to stay onboard with Dovecot, we would have *never* made the switch. It appears that Dovecot is not an appropriate choice for Production systems. But rather; better suited for hobbyists. I sure wish we had known this from the start.
Well, I'm sorry that you feel that way, but before switching I would
have supposed that you had checked that Dovecot does everything you
need it to do. Especially because UW-IMAP doesn't even *try* to
support the QUOTA extension that you obviously need so much, and that Dovecot at least even tries to support it even if not in every single operating system (or file system). Couldn't agree more. I chose to switch to Dovecot *because* it is *so* much more advanced. Make no mistake; I believe Dovecot is *superiour* to UW-IMAP.Doveocot isn't owned by any single company. I don't think the web
page even tries to claim anything like it anywhere. Are you saying
that I should devote my entire life to the one thing that *you*
yourself consider important to Dovecot? Even though most other people don't really care about it? Not at all. I couldn't be more grateful for the time you've spent and the benifit that I (and others) enjoy because of it. It never occured to me to be ungrateful. I never indicated I wasn't grateful for the work you've already done. I was meerly expressing concern that I would be required to perform maintenance that is beyond my time constraints to manage, in order to continue to use (and enjoy) all Dovecot has to offer -- Please see dissappointed.I think I do pretty well at balancing what other people want for
Dovecot, what people (companies) pay for me to develop Dovecot to do
and what I myself want Dovecot to become. I guess in recent months
I've become worse at this since I've needed more time for school, but in general I don't think I've done too badly. I never felt (or expressed) otherwise.Now, from you I've seen 3 mails within the whole Doveocot's life
time. If you had actually EVER contributed to Dovecot in any way in
its entire life time I might have replied differently. If you in no
way contribute to an open source project, you can't expect commercial support out of it without paying for it for someone. And there are
most likely a lot of companies that would accept your money if you
wanted it (including the one I work for). Well, it might be of interest to you to know that I am on several development teams and as such am responsible for several mailing lists. On all of which I *frequntly* recommend switching to Dovecot as a solution for troubles that administrators encounter with other mail servers. As a matter of fact, I recently joined a team of developers that will be producing an all-inclusive CMS. That will provide far and beyond what any other CMS can offer to date. I insisted that it track Dovecot closely, as email service will be a part of it's offerings.I'm happy to fix this problem for you, the standard company fee being 120 EUR/hour. Possibly even less if you can convince my supervisors
to accept it. Estimate for fixing it is about 6 hours (since I have
to install a system where I have quota). I don't think you can get
much better support than this elsewhere.Just don't misunderstand this as me not doing anything unless someone pays for it. For most of the last 4 years I've written Dovecot for
free without getting a single cent for it. I still do, but only as
long as I consider the changes to be important. If you have a
different opinion on the imporance, see the paragraph above.
Let me summarize here by letting you know that it should have been obvious that I was experssing my disappointmnet. As I have grown *very* pleased with Dovecot and all it has to offer. I *never* expressed otherwise. Because of this, it should have been clear that that I couldn't have been more greatful for the work (and quality) you have provided thus far with Dovecot. I _never_ felt _you_ were responsible for my every whim. I was only concerned that given the comments you made to another poster on this list. That I would ultimately be forced to drop Dovecot as my (our) chosen mail server.
Best wishes.
--
FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 /////////////////////////////////////////////////////////////////
On Mon, 12 Jun 2006, Chris H. (and others) wrote:
Dunno, but it seems that some of you could actually hire someone to do the quota-on-all-filesystems research, then present the results or maybe contribute to the quota plugin?
dovecot is open source and free-as-in-speach after all.
Bye,
-- Steffen Kaiser
On Mon, Jun 12, 2006 at 02:53:38PM -0700, Chris H. wrote:
But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2.
Sorry to bring this to you, but UFS2 has been default on FreeBSD since 5.1 RELEASE. It also came to NetBSD around 2.0, but I'm not sure if it's default over there.
-- Riemer Palstra Amsterdam, The Netherlands riemer@palstra.com http://www.palstra.com/
Wow. We never should have switched from UW-IMAP to Dovecot. Having a 750,000 user base. We made the switch to Dovecot in an effort to trim a little overhead on our systems. But our OS (FreeBSD 5.4 - UFS) version is rapidly reaching EOL. All future versions will default to UFS2.
Curious, seeing as I'm working on a large mail system atm. Why are you using FS quota's? Having been awhile since I used FS quota's, it is my understanding, that each user that has a FS quota, must be on the system as a 'real' user. With that many users, I would expect that you would have some sort of user backend (LDAP, SQL...) and they would be 'virtual' to the system.
Regardless of if they are virtual, or 'real' users, why not use the dovecot Maildir++ Quota's? They work, regardless of FS, are supported be a number of MTA's as well, and "Just Work". Do you REALLY need FS quota's for emails? I'm just trying to understand why you need FS quotas.
Tim
Linux Counter user #273956
On Mon, 2006-06-12 at 21:56 +0300, Timo Sirainen wrote:
On Jun 12, 2006, at 9:48 PM, Dumitru Negara wrote:
So I looked through repquota's sources and it looks like XFS has
its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used.
Patches welcome.OK, let's do it again :) ... with ext3 partition. ..
Well, I think my answer is still the same. Someone who actually knows
how the filesystem quota stuff is supposed to work could fix it. I
don't see it important enough to waste spending time on.
It's the switch to quota v2 that's messing this up- all the dqb_* struct elements moved from uint32 to uint64. To make it possible to compile things on both old and new Linux systems, I use the defines manually:
#ifndef _LINUX_QUOTA_VERSION struct fake_dq_struct { u_int64_t dqb_bhardlimit; /* absolute limit on disk quota blocks alloc */ u_int64_t dqb_bsoftlimit; /* preferred limit on disk quota blocks */ u_int64_t dqb_curspace; /* current quota block count */ u_int64_t dqb_ihardlimit; /* maximum # allocated inodes */ u_int64_t dqb_isoftlimit; /* preferred inode limit */ u_int64_t dqb_curinodes; /* current # allocated inodes */ u_int64_t dqb_btime; /* time limit for excessive disk use */ u_int64_t dqb_itime; /* time limit for excessive files */ u_int32_t dqb_valid; /* bitmask of QIF_* constants */ };
struct fake_dq_struct fake_dq;#endif struct dqblk dq;
Then I get the quotas using:
#ifndef _LINUX_QUOTA_VERSION r = quotactl(0x80000700, q_special, uid, (caddr_t)&fake_dq); if (r != -1) { /* use fake_dq... */ return; } #endif r = quotactl(QCMD(Q_GETQUOTA,USRQUOTA), q_special,uid,(caddr_t)&dq); if (r != -1) { /* use dq ... */ return; }
/* failure */(where q_special is the block special path)
I don't have any XFS volumes, so hopefully someone who does can sew this together with XFS's method and resolve the mess that is quota on UNIX.
As an alternate: what about using get_quota_command= or something that would print out the correct quota using the system's own quota command?
-- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
On Mon, 2006-06-12 at 18:39 +0300, Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:56 +0300, Dumitru Negara wrote:
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
So I looked through repquota's sources and it looks like XFS has its own Q_XGETQSTAT quota command which needs to be used with it. I think I'm not going to bother figuring out how it's supposed to be used. Patches welcome.
It's not that hard. Here's some example code:
#include <sys/quota.h> #include <xfs/xqm.h>
#define FS_WHATEVER 0 #define FS_XFS 1
int getquot(char *dev, uid_t uid, struct dqblk *dq, int fstype) { fs_disk_quota_t fdq;
switch(fstype) {
case FS_XFS:
if (quotactl(QCMD(Q_XGETQUOTA, USRQUOTA),
dev, uid, (caddr_t)&fdq) < 0)
return -1;
dq->dqb_bhardlimit = fdq.d_blk_hardlimit;
dq->dqb_bsoftlimit = fdq.d_blk_softlimit;
dq->dqb_ihardlimit = fdq.d_ino_hardlimit;
dq->dqb_isoftlimit = fdq.d_ino_softlimit;
dq->dqb_curblocks = fdq.d_bcount;
dq->dqb_curinodes = fdq.d_icount;
dq->dqb_btime = fdq.d_btimer;
dq->dqb_itime = fdq.d_itimer;
break;
default:
if (quotactl(QCMD(Q_GETQUOTA, USRQUOTA),
dev, uid, (caddr_t)dq) < 0)
return -1;
break;
}
return 0;}
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Timo Sirainen wrote:
On Mon, 2006-06-12 at 17:12 +0300, Dumitru Negara wrote:
# repquota -u /dev/sda9
Could you run it through strace and show me the quotactl() call it does? Or does it do a quotactl() call at all?
Jun 12 17:06:07 debian dovecot: IMAP(dumitru): quotactl(Q_GETQUOTA, /dev/sda9) failed: Invalid argument
This is the same situation I'm seeing on RHEL 3
I guess this is wrong or something. I don't have quota enabled anywhere so I can't really test the code myself.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEjiOqE2gsBSKjZHQRAkYgAJ0dAcDipfEXO+j4yBEHQt0VqEh8fwCePcMt Dol5NRxE0AYdwY58rdtZjTA= =qWMK -----END PGP SIGNATURE-----
Timo Sirainen wrote:
I guess this is wrong or something. I don't have quota enabled anywhere so I can't really test the code myself.
I don't know if it would make it more likely for you to look at it, but I would be very happy to give you an account on a linux system with both xfs and "normal" quota filesystems.
-Stian
hi,
What about epoll and inotify on linux?
darix
-- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
On Mon, 2006-06-12 at 01:18 +0200, Marcus Rueckert wrote:
hi,
What about epoll
I don't see it as a major problem since you can always use poll instead. Would be nice if someone who actually knew something about epoll looked at the problems. :)
and inotify on linux?
Doesn't it work perfectly already?
(06.06.12 kl.01:25) Timo Sirainen skrev följande till dovecot@dovecot.org:
- Thunderbird+POP3 DELE error. Was this fixed already? Could someone try this? See http://www.dovecot.org/list/dovecot/2005-June/007497.html and the rest of the thread. Basically put thousands of messages into mailbox, start downloading them and see if error comes.
The problem was that dovecot could in some circumstance (in SEARCH i guess) report the same message identity twice.
Thunderbird does not check this and consequently tries to delete the same message twice.
I checked that it worked when you fixed it.
(BTW. We are now running beta7 in production :-)
Thanks, Jens
'In theory, there is no difference between theory and practice.
But, in practice, there is.' Jens Låås Email: jens.laas@data.slu.se
Department of Computer Services, SLU Phone: +46 18 67 35 15
Vindbrovägen 1
P.O. Box 7079
S-750 07 Uppsala
SWEDENOn Sun, 2006-06-11 at 17:25, Timo Sirainen wrote:
Anyway looking at my current TODO, I think the following things should be fixed before v1.0. Additions, comments, patches and such welcome. :)
Just in case it got lost, I'll repeat the request for a mode where mail delivery normally happens in mbox format but users can optionally have maildir storage and dovecot would transparently move system deliveries into the maildir INBOX. Pop users who download/delete probably wouldn't bother, imap users with large mailboxes probably would.
-- Les Mikesell lesmikesell@gmail.com
On Mon, 2006-06-12 at 08:05 -0500, Les Mikesell wrote:
On Sun, 2006-06-11 at 17:25, Timo Sirainen wrote:
Anyway looking at my current TODO, I think the following things should be fixed before v1.0. Additions, comments, patches and such welcome. :)
Just in case it got lost, I'll repeat the request for a mode where mail delivery normally happens in mbox format but users can optionally have maildir storage and dovecot would transparently move system deliveries into the maildir INBOX. Pop users who download/delete probably wouldn't bother, imap users with large mailboxes probably would.
So, a mode in which dovecot looks at /var/mail/user and moves the mails into maildir whenever user logs in? I think that belongs to the same category of features as "move /var/mail/user into ~/mbox" and possibly even the same as "fetch mails using POP3 from another server for the INBOX automatically". All of these are very low on my TODO list.
On Mon, 2006-06-12 at 08:08, Timo Sirainen wrote:
Anyway looking at my current TODO, I think the following things should be fixed before v1.0. Additions, comments, patches and such welcome. :)
Just in case it got lost, I'll repeat the request for a mode where mail delivery normally happens in mbox format but users can optionally have maildir storage and dovecot would transparently move system deliveries into the maildir INBOX. Pop users who download/delete probably wouldn't bother, imap users with large mailboxes probably would.
So, a mode in which dovecot looks at /var/mail/user and moves the mails into maildir whenever user logs in?
Not just when they log in - it should be monitored for new deliveries.
I think that belongs to the same category of features as "move /var/mail/user into ~/mbox" and possibly even the same as "fetch mails using POP3 from another server for the INBOX automatically". All of these are very low on my TODO list.
From dovecot's perspective it should serve most of the same purposes as an LDA in terms of not having deliveries screw up your indexes and you must already have functions to do all the low-level gunk. What's the down side?
-- Les Mikesell lesmikesell@gmail.com
On Mon, 2006-06-12 at 08:39 -0500, Les Mikesell wrote:
Just in case it got lost, I'll repeat the request for a mode where mail delivery normally happens in mbox format but users can optionally have maildir storage and dovecot would transparently move system deliveries into the maildir INBOX. Pop users who download/delete probably wouldn't bother, imap users with large mailboxes probably would.
So, a mode in which dovecot looks at /var/mail/user and moves the mails into maildir whenever user logs in?
Not just when they log in - it should be monitored for new deliveries.
Yea, that's what I meant actually :)
I think that belongs to the same category of features as "move /var/mail/user into ~/mbox" and possibly even the same as "fetch mails using POP3 from another server for the INBOX automatically". All of these are very low on my TODO list.
From dovecot's perspective it should serve most of the same purposes as an LDA in terms of not having deliveries screw up your indexes
I'm not sure what you mean with this. Delivering the mails to a temporary mailbox and copying them from there to the real mailbox at least use much more disk I/O than what is saved by having the index files always being up-to-date.
and you must already have functions to do all the low-level gunk. What's the down side?
That the actual code needs to be added and the configuration needs to be somewhere. Perhaps this should be a plugin. Then it doesn't mess up the code and settings.
On Mon, 2006-06-12 at 16:45 +0300, Timo Sirainen wrote:
From dovecot's perspective it should serve most of the same purposes as an LDA in terms of not having deliveries screw up your indexes
I'm not sure what you mean with this. Delivering the mails to a temporary mailbox and copying them from there to the real mailbox at least use much more disk I/O than what is saved by having the index files always being up-to-date.
System delivery is "someone else's problem" but the point is that you only have the duplicate work if you specifically want it. That is, if most users pop and delete they won't have any of the extra file creation overhead of maildirs, which I think makes an overall win, and the transition for those who use imap becomes transparent instead of needing an awkward coordination between changing delivery methods, converting the existing mailbox, and changing receiving methods with delivery stopped while that happens.
-- Les Mikesell lesmikesell@gmail.com
On Mon, 12 Jun 2006, Timo Sirainen wrote:
I'm not sure what you mean with this. Delivering the mails to a temporary mailbox and copying them from there to the real mailbox at least use much more disk I/O than what is saved by having the index files always being up-to-date.
I think such mode is on your TODO list a long time (I remember you've posted a list where it was called "slurp" /var/mail/<<uid>> into INBOX). The actual reason for me to like this feature of UW-Imap is that you can have the INBOX (well the temporary one) without quota, whereas the mailboxes in general are limited by quota.
We have a fairly stable amount of people, who never check their mailboxes or forget to delete mails or whatever, but who are to be placed into mailing lists - otherwise they could mourn "we never get this valuable information!". Those over-quota replies are really cumbersome.
Another downside of this slurp mode is that all processing the LDA performs must be performed in the same way by Dovecot (or its plugin), e.g. Sieve filtering :-)
Bye,
-- Steffen Kaiser
Hi Timo,
I'd like to add complete Public Shared Folders for virtual users (as discussed previously on list) to the wish list.
Main problems with ACL implementation currently are: line 1: Unknown ACL 'k'
- Namespace prefixes are currently ignored, therefore vfile global acl's must be used which are less flexible
- Unable to use anything more than lrwsiea acl listing in vfile. Adding any more of the ACLs, for example k, dovecot reports: dovecot: IMAP(user1@domain.com): ACL file /etc/dovecot-acls/Management
- Global ACLs stop other non-ACL restricted public namespace directories working (in my configuration)
UPDATE: apparently 2) is fixed with b8 but I haven't had a chance to test.
Gavin
On Mon, 2006-06-12 at 01:25 +0300, Timo Sirainen wrote:
I've read about one month back this list's messages. I've still 216 messages from this year marked as "unread" which I should look into more (+258 older ones). Also I've 180 "unread" messages in my INBOX also which might contain something useful. So those messages could still contain something that should be added to this list.
Anyway looking at my current TODO, I think the following things should be fixed before v1.0. Additions, comments, patches and such welcome. :)
Help would be welcome in checking if these bugs are still there:
Thunderbird+POP3 DELE error. Was this fixed already? Could someone try this? See http://www.dovecot.org/list/dovecot/2005-June/007497.html and the rest of the thread. Basically put thousands of messages into mailbox, start downloading them and see if error comes.
Solaris sendfile is broken? Is it? Can someone try? You can test it with maildir by setting mail_save_crlf=yes, saving a somewhat large mail and FETCHing it (and truss that it really uses sendfile)
passdb passwd + passdb shadow -> passdb_password isn't reset to NULL (ie. probably doesn't allow logging in if the shadow password is correct?)
maildir: rename foo foo.xyz -> infinite loop possible? (doesn't seem so? why did I think it could be? look at the code)
Important:
- dict-server should have some config file which lists the allowed dicts
- LDA: empty mail gives an error.
- deliver: delivering mail to box smaller than mbox_min_index_size give close() errors
- mbox: CRLFs in headers break the mbox
- index: when mailbox is deleted/renamed and someone else had it open, we get stat() error messages in log file. Handle at least the most common places where it happens.
- lib-storage
- limit folder hierarchy levels? user can now create eg. a/a/a/a/... and then start renaming them from end to beginning, which probably will at some point start causing syscall failures which will fill up logs.
Probably should be done:
- mbox: dirty mode should be stored to index
- quota code should probably be always doing some quota_set_critical() instead of using mail_storage_set_critical(), so that quota_last_error() would work properly
- rfc2557 support for BODYSTRUCTURE, as specified by RFC3501
- keywords: add some limits to how many there can be
- don't return \* in PERMANENTFLAGS when we're full
- mbox: how well does dirty sync + status work? it reads the last mail every time? not very good..
- maildir: we probably shouldn't do duplicate detection/fixing?.. or at least stat() the old file before trying, because we might have just previously seen the old file and then new file and then we try to fix it..
participants (18)
-
Alan Premselaar
-
Chris H.
-
Dumitru Negara
-
Fintec
-
Geo Carncross
-
Jakob Hirsch
-
Jens Laas
-
Les Mikesell
-
Marc Perkel
-
Marcus Rueckert
-
Marten Lehmann
-
Matt
-
Miquel van Smoorenburg
-
Riemer Palstra
-
Steffen Kaiser
-
Stian Jordet
-
Timo Sirainen
-
Timothy White