Messages in this thread | | | Date | Thu, 1 Mar 2001 16:07:32 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [CFT][PATCH] Re: fat problem in 2.4.2 |
| |
On Thu, 1 Mar 2001, Roman Zippel wrote:
> Hi, > > On Thu, 1 Mar 2001, Alexander Viro wrote: > > > +static int generic_vm_expand(struct address_space *mapping, loff_t size) > > +{ > > + struct page *page; > > + unsigned long index, offset; > > + int err; > > + > > + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write) > > + return -ENOSYS; > > + > > + offset = (size & (PAGE_CACHE_SIZE-1)); /* Within page */ > > + index = size >> PAGE_CACHE_SHIFT; > > For affs I did basically the same with a small difference: > > offset = ((size-1) & (PAGE_CACHE_SIZE-1)) + 1; > index = (size-1) >> PAGE_CACHE_SHIFT; > > That works fine here and allocates a page in the cache more likely to be > used.
The only difference is in the case when size is a multiple of PAGE_CACHE_SHIFT, so most of the time it's the same, but yeah, this variant is probably nicer.
The problem with putting it into ->truncate() is obvious - handling errors. And doing the thing before vmtruncate() (in foo_notify_change(), whatever) is also PITA - you need to reproduce the rlimit handling. Not nice...
IOW, if it's worth doing at all it probably should be on expanding path in vmtruncate() - limit checks are already done, but old i_size is still not lost... Cheers, Al
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |