Re: RFC: [PATCH] staging/lustre/llite: fix O_TMPFILE/O_LOV_DELAY_CREATE conflict

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 10, 2014 at 08:16:52PM +0000, Dilger, Andreas wrote:

> >>Instead of trying to find a non-conflicting O_LOV_DELAY_CREATE flag
> >>or define a Lustre-specific flag that isn't of use to most/any other
> >>filesystems, use (O_NOCTTY|FASYNC) as the new value.  These flag
> >>are not meaningful for newly-created regular files and should be
> >>OK since O_LOV_DELAY_CREATE is only meaningful for new files.

*shrug*

I can live with that; it's a kludge, but it's less broken than that
explicit constant - that one is a non-starter, since O_... flag
values are arch-dependent.

	I have another question about what you are doing there - the games
you are playing with crw_pos.  Is there any reason not to have ->ki_pos
updated immediately in lustre_generic_file_read()/lustre_generic_file_write()?

	These two are the only places in the entire tree where
generic_file_aio_{read,write}() does *not* have ppos argument
equal to &iocb->ki_pos and I would very much prefer to kill the
sucker off.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux