using ways. In this case,
> cleancache_flush_inode and cleancache_flush_page rather sound like they
> might write those things to backing store.
I'd like to mention about *_{get,put}_page too. In linux get/put is not
meaning read/write. There is {get,put}_page those are refcount stuff
(
ly's swapcache.)
Well, anyway, I guess force enabling this for mostly unused sb can just
add cache-write overhead and call for unpleasing reclaim to backend
(because of limited space of backend) like updatedb.
And already there is in FAQ though, I also have interest about async
interface becau
existing cleancache hooks will work for this and I am
> working on a cleancache backend called RAMster that will
> be a good foundation to access other asynchronous devices.
> See: http://marc.info/?l=linux-mm&m=130013567810410&w=2
Thanks for info.
--
OGAWA Hirofumi
--
To unsu
E) {
> + down_write(&MSDOS_I(inode)->truncate_lock);
> truncate_setsize(inode, attr->ia_size);
> fat_truncate_blocks(inode, attr->ia_size);
> + up_write(&MSDOS_I(inode)->truncate_lock);
> }
>
> setattr_copy(inode, attr);
>
--
OGAWA Hirofumi
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OGAWA Hirofumi writes:
> Christoph Hellwig writes:
>
>> Add a new rw_semaphore to protect bmap against truncate. Previous
>> i_alloc_sem was abused for this, but it's going away in this series.
>
> In FAT case, ->i_mutex was better. But, last time I saw, shm
ase).
Otherwise, IMO it would be bad than nothing. Because, of course, if
there are such codes, we can't ignore those anymore until remove
codes completely for e.g. security reasons. And IMHO, those cache
managements to such operations are not so easy.
Thanks.
--
OGAWA Hirofumi
--
To uns
error, or emulate it by zero fill.
Thanks.
--
OGAWA Hirofumi
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
