Re: [PATCH v7 08/22] Replace xip_truncate_page with dax_truncate_page

From: Jan Kara
Date: Wed Apr 09 2014 - 05:26:49 EST


On Wed 09-04-14 00:17:59, Jan Kara wrote:
> On Sun 23-03-14 15:08:34, Matthew Wilcox wrote:
> > +/**
> > + * dax_truncate_page - handle a partial page being truncated in a DAX file
> > + * @inode: The file being truncated
> > + * @from: The file offset that is being truncated to
> > + * @get_block: The filesystem method used to translate file offsets to blocks
> > + *
> > + * Similar to block_truncate_page(), this function can be called by a
> > + * filesystem when it is truncating an DAX file to handle the partial page.
> > + *
> > + * We work in terms of PAGE_CACHE_SIZE here for commonality with
> > + * block_truncate_page(), but we could go down to PAGE_SIZE if the filesystem
> > + * took care of disposing of the unnecessary blocks. Even if the filesystem
> > + * block size is smaller than PAGE_SIZE, we have to zero the rest of the page
> > + * since the file might be mmaped.
> Well, DAX mmap support pretty much relies on PAGE_CACHE_SIZE == block
> size (we cannot really map only a part of a physical page directly...). So
> the comment seems somewhat misleading.
I thought about this for a while and classical IO, truncation etc. could
easily work for blocksize < pagesize. And for mmap() you could just use
pagecache. Not sure if it's worth the complications though. Anyway we
should decide whether we don't care about blocksize < PAGE_CACHE_SIZE at
all, or whether we try to make things which can work reasonably easily
functional. In that case dax_truncate_page() needs some tweaking because it
currently assumes blocksize == PAGE_CACHE_SIZE.

Honza
> --
> 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
--
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/