[opensuse-kernel] posix_fadvise and tmpfs
Hi: calling posix_fadvise with advice POSIX_FADV_WILLNEED on a tmpfs filesystem returns EINVAL.. I know that it will have no effect since stuff written there is already in the page cache, but shouldn't it return 0 acting like a no-op instead ? whom to blame here the kernel, libc , posix ? -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Sun 04-12-11 19:42:12, Cristian Rodríguez wrote:
Hi:
Hi,
calling posix_fadvise with advice POSIX_FADV_WILLNEED on a tmpfs filesystem returns EINVAL..
I assume you are talking about 12.1 kernel, right?
I know that it will have no effect since stuff written there is already in the page cache, but shouldn't it return 0 acting like a no-op instead ?
Yes that will work. Or we can do a "readahead" (pre faulting the memory).
whom to blame here the kernel, libc , posix ?
This is a side effect of 276aad6 merged in 3.1-rc1. I have noticed this while backporting tmpfs/shmem rework and was wondering what will break by the change. To be honest, fadvise is just an advice and so the error value shouldn't be a big deal and the application should just cope with that. On the other hand this is an userspace visible change so we should probably do something about that. Where do you see this as a problem? I can cook up a patch but will need some justification which I have a hard time to come up with ;) -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 05/12/11 07:55, Michal Hocko wrote:
On Sun 04-12-11 19:42:12, Cristian Rodríguez wrote:
Hi:
Hi,
calling posix_fadvise with advice POSIX_FADV_WILLNEED on a tmpfs filesystem returns EINVAL..
I assume you are talking about 12.1 kernel, right?
Current kernel:head 3.2.0-rc3-4-desktop
This is a side effect of 276aad6 merged in 3.1-rc1. I have noticed this while backporting tmpfs/shmem rework and was wondering what will break by the change.
Ahh, ok.
Where do you see this as a problem? I can cook up a patch but will need some justification which I have a hard time to come up with ;)
I was learning about this stuff and wrote some hello world test and found that the behavior was inconsistent (and undocumented) when running it in different partitions. (first in /tmp --> tmpfs, then /var/tmp --> SSD ext4) I have not found a real world app that breaks, but wouldn't be surprised if some do. ;) Thanks for the clarification. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Mon 05-12-11 11:02:55, Cristian Rodríguez wrote:
On 05/12/11 07:55, Michal Hocko wrote: [...]
Where do you see this as a problem? I can cook up a patch but will need some justification which I have a hard time to come up with ;)
I was learning about this stuff and wrote some hello world test and found that the behavior was inconsistent (and undocumented) when running it in different partitions. (first in /tmp --> tmpfs, then /var/tmp --> SSD ext4)
I see
I have not found a real world app that breaks, but wouldn't be surprised if some do. ;)
I can hardly imagine such an app ;) It sounds really strange that you would fail (in what ever way) just because you are not able to set a hint which is not guaranteed to be acted upon on. I do agree that EINVAL is just a terrible way to communicate that but this is how we do it for ages so the change needs a _really_ good usecase.
Thanks for the clarification.
Welcome -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 05/12/11 12:10, Michal Hocko wrote:
I do agree that EINVAL is just a terrible way to communicate that but this is how we do it for ages so the change needs a _really_ good usecase.
I don't have a really good usecase, however I do believe it needs to be documented somewhere ;-) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (2)
-
Cristian Rodríguez
-
Michal Hocko