https://bugs.exim.org/show_bug.cgi?id=3040
Bug ID: 3040
Summary: Spoolfile error on close should not lead to 250 OK
Product: Exim
Version: N/A
Hardware: All
OS: Linux
Status: NEW
Severity: wishlist
Priority: medium
Component: Mail Receipt
Assignee: unallocated@exim.org
Reporter: max@internet.ru
CC: exim-dev@lists.exim.org
When bad things happen on close() of -D file, it might be preferable for sender
to resend the message, and for recipient to receive a duplicate along with
possibly corrupted one, than to just deliver possibly corrupted (if existing)
message.
Looking at linux kernel source[1], there are several .flush handlers[2] defined
for
various filesystems' struct file_operations:
1) nfs, orangefs, cifs, smb2, fuse[3] -- does the flushing and returns the
result
2) ecryptfs, overlayfs -- calls flush for underlying file
3) f2fs -- always returns 0
Some filesystems may want to delay persisting data to the underlying storage
for as long as possible. In the generic case there are paths when flush handler
is never called at all (i.e. mmap()/edit/munmap()), but one may write a
filesystem tied specifically to a fixed version of exim. It could even remove
local dentries for the message files once exim is done with receiving them, and
do some locking on its own. This will allow storing spool files on a
replicated storage cluster and externally managing the queue, but demands
careful testing on upgrades in return.
I have implemented a sufficiently broken fuse fs[4] that allows to reproduce
the error on spoolfile close scenario. It needs more love, doesn't even have
readdir() support yet, nor a correct enough setattr() implementation, and
supports up to 100 inodes. I can iterate on it if requested, but this can
trigger the issue nontheless.
-----
[1] git grep -P '\.flush\s+?=' fs/
[2] explicitly called in filp_flush() in close() syscall implementation
[3]
https://github.com/libfuse/libfuse/blob/05b696edb347dc555f937c1439ffda6a1c40416e/include/fuse_lowlevel.h#L603
[4]
https://github.com/darkwrat/errclosefs/tree/72b8f575fcdc139bc30be52dacc85029588ebbe3
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Bug ID: 3040
Summary: Spoolfile error on close should not lead to 250 OK
Product: Exim
Version: N/A
Hardware: All
OS: Linux
Status: NEW
Severity: wishlist
Priority: medium
Component: Mail Receipt
Assignee: unallocated@exim.org
Reporter: max@internet.ru
CC: exim-dev@lists.exim.org
When bad things happen on close() of -D file, it might be preferable for sender
to resend the message, and for recipient to receive a duplicate along with
possibly corrupted one, than to just deliver possibly corrupted (if existing)
message.
Looking at linux kernel source[1], there are several .flush handlers[2] defined
for
various filesystems' struct file_operations:
1) nfs, orangefs, cifs, smb2, fuse[3] -- does the flushing and returns the
result
2) ecryptfs, overlayfs -- calls flush for underlying file
3) f2fs -- always returns 0
Some filesystems may want to delay persisting data to the underlying storage
for as long as possible. In the generic case there are paths when flush handler
is never called at all (i.e. mmap()/edit/munmap()), but one may write a
filesystem tied specifically to a fixed version of exim. It could even remove
local dentries for the message files once exim is done with receiving them, and
do some locking on its own. This will allow storing spool files on a
replicated storage cluster and externally managing the queue, but demands
careful testing on upgrades in return.
I have implemented a sufficiently broken fuse fs[4] that allows to reproduce
the error on spoolfile close scenario. It needs more love, doesn't even have
readdir() support yet, nor a correct enough setattr() implementation, and
supports up to 100 inodes. I can iterate on it if requested, but this can
trigger the issue nontheless.
-----
[1] git grep -P '\.flush\s+?=' fs/
[2] explicitly called in filp_flush() in close() syscall implementation
[3]
https://github.com/libfuse/libfuse/blob/05b696edb347dc555f937c1439ffda6a1c40416e/include/fuse_lowlevel.h#L603
[4]
https://github.com/darkwrat/errclosefs/tree/72b8f575fcdc139bc30be52dacc85029588ebbe3
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/