Re: [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(4/24/12 2:18 AM), Nick Piggin wrote:
On 23 April 2012 21:47, Nick Piggin<npiggin@xxxxxxxxx> wrote:On 23 April 2012 18:23, James BottomleyExperience has taught me to be wary of fine grained hints: they tend to be more trouble than they're worth (the definitions are either inaccurate or so tediously precise that no-one can be bothered to read them). A small set of broad hints is usually more useable than a huge set of fine grained ones, so from that point of view, I like the O_HOT/O_COLD ones.So long as the implementations can be sufficiently general that large majority of "reasonable" application of the flags does not result in a slowdown, perhaps. But while defining the API, you have to think about these things and not just dismiss them completely. Read vs write can be very important for caches and tiers, same for random/linear, latency constraints, etc. These things aren't exactly a huge unwieldy matrix. We already have similar concepts in fadvise and such.I'm not saying it's necessarily a bad idea as such. But experience has taught me that if you define an API before having much experience of the implementation and its users, and without being able to write meaningful documentation for it, then it's going to be a bad API. So rather than pushing through these flags first, I think it would be better to actually do implementation work, and get some benchmarks (if not real apps) and have something working like that before turning anything into an API.
Fully agreed. I _guess_ O_COLD has an enough real world usefullness because a backup operation makes a lot of "write once read never" inodes. Moreover it doesn't have a system wide side effect. In the other hands, I don't imagine how O_HOT works yet. Beccause of, many apps want to run faster than other apps and it definitely don't work _if_ all applications turn on O_HOT for every open operations. So, I'm not sure why apps don't do such intentional abuse yet. So, we might need some API design discussions. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
[Reiser Filesystem Development] [Kernel Newbies] [Share Photos] [Security] [Netfilter] [Bugtraq] [Linux FS] [Photo] [Yosemite] [Yosemite News] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Samba] [Video 4 Linux] [Device Mapper] [Linux Resources]