- 14 Apr, 2023 10 commits
-
-
Jan Kara authored
Now that ext4_writepages() makes sure all journalled data is committed and checkpointed, sync_filesystem() call done by dquot_quota_on() is enough for quota IO to see uptodate data. So drop special handling of journalled data from ext4_quota_on(). Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20230329154950.19720-10-jack@suse.czSigned-off-by:
Theodore Ts'o <tytso@mit.edu>
-
Jan Kara authored
Now that ext4_writepages() makes sure journalled data is on stable storage, write_inode_now() call in iput_final() is enough to make pagecache pages with journalled data really clean (data committed and checkpointed). So we can drop special handling of journalled data in ext4_evict_inode(). Signed-off-by:
-
Jan Kara authored
The handling of journalled data in ext4_zero_range() is incomplete. We do not need to commit running transaction but we rather need to checkpoint pages with journalled data. If we don't, journal tail can be advanced beyond transaction containing the journalled data and if we then crash before committing the transaction doing the zeroing we will have inconsistent (too old) data in the file. Make sure file pages with journalled data are properly checkpointed before removing them from the page cache. Signed-off-by:
-
Jan Kara authored
Now that filemap_write_and_wait() makes sure pages with journalled data are safely on disk, ext4_collapse_range() and ext4_insert_range() do not need special handling of journalled data. Signed-off-by:
-
Jan Kara authored
Now that ext4_writepages() make sure all pages with journalled data are stable on disk, we don't need special handling of journalled data in ext4_sync_file(). Signed-off-by:
-
Jan Kara authored
When journalling data we currently just walk over pages, journal those that are marked for delayed dirtying (only pinned pages dirtied behing our back these days) and checkpoint other dirty pages. Because some pages may be part of running transaction the result is that after filemap_write_and_wait() we are not guaranteed pages are stable on disk. Thus places that want to flush current pagecache content need to jump through hoops to make sure journalled data is not lost. This is manageable in cases completely controlled by ext4 (such as extent shifting operations or inode eviction) but it gets ugly for stuff like fsverity. Furthermore it is rather error prone as people often do not realize journalled data needs special handling. So change ext4_writepages() to commit transaction with inode's data before going through the writeback loop in WB_SYNC_ALL mode. As a result filemap_write_and_wait() is now really getting pages to stable storage and makes pagecache pages safe to reclaim. Consequently we can remove the special handling of journalled data from several places in follow up patches. Note that this will make fsync(2) for journalled data more expensive as we will end up not only committing the transaction we need but also checkpointing the data (which we may have previously skipped if the data was part of the running transaction). If we really cared, we would need to introduce special VFS function for writing out & invalidating page cache for a range, use ->launder_page callback to perform checkpointing, and use it from all the places that need this functionality. But at this point I'm not convinced the complexity is worth it. Signed-off-by:
-
Jan Kara authored
With journalled data it can happen that checkpointing code will write out page contents without clearing the page dirty bit. The logic in ext4_page_nomap_can_writeout() then results in us never calling mpage_submit_page() and thus clearing the dirty bit. Drop the optimization with ext4_page_nomap_can_writeout() and just always call to mpage_submit_page(). ext4_bio_write_page() knows when to redirty the page and the additional clearing & setting of page dirty bit for ordered mode writeout is not that expensive to jump through the hoops for it. Signed-off-by:
-
Jan Kara authored
Currently we clear page dirty bit when we checkpoint some buffers from a page with journalled data or when we perform delayed dirtying of a page in ext4_writepages(). In a quest to simplify handling of journalled data we want to keep page dirty as long as it has either buffers to checkpoint or journalled dirty data. So make sure to keep page dirty in ext4_writepages() if it still has journalled data attached to it. Signed-off-by:
-
Jan Kara authored
Currently pages with journalled data written by write(2) or modified by block zeroing during truncate(2) are not marked as dirty. They are dirtied only once the transaction commits. This however makes writeback code think inode has no pages to write and so ext4_writepages() is not called to make pages with journalled data persistent. Mark pages with journalled data dirty (similarly as it happens for writes through mmap) so that writeback code knows about them and ext4_writepages() can do what it needs to to the inode. Signed-off-by:
-
Jan Kara authored
When invalidating buffers under the partial tail page, jbd2_journal_invalidate_folio() returns -EBUSY if the buffer is part of the committing transaction as we cannot safely modify buffer state. However if the buffer is already invalidated (due to previous invalidation attempts from ext4_wait_for_tail_page_commit()), there's nothing to do and there's no point in returning -EBUSY. This fixes occasional warnings from ext4_journalled_invalidate_folio() triggered by generic/051 fstest when blocksize < pagesize. Fixes: 53e87268 ("ext4: fix deadlock in journal_unmap_buffer()") Signed-off-by:
-
- 06 Apr, 2023 30 commits
-
-
Matthew Wilcox authored
This is an implementation of fsverity_operations read_merkle_tree_page, so it must still return the precise page asked for, but we can use the folio API to reduce the number of conversions between folios & pages. Signed-off-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20230324180129.1220691-30-willy@infradead.orgSigned-off-by:
-
Matthew Wilcox authored
Use the folio API and support folios of arbitrary sizes. Signed-off-by:
-
Matthew Wilcox authored
Use a folio throughout. Does not support large folios due to an array sized for MAX_BUF_PER_PAGE, but it does remove a few calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Iterate once per folio, not once per page. Signed-off-by:
-
Matthew Wilcox authored
Convert to the folio API, saving a few calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
All the callers now have a folio, so pass that in and operate on folios. Removes four calls to compound_head(). Signed-off-by:
Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20230324180129.1220691-25-willy@infradead.orgSigned-off-by:
-
Matthew Wilcox authored
This definitely doesn't include support for large folios; there are all kinds of assumptions about the number of buffers attached to a folio. But it does remove several calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Remove a few calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Its one caller already uses a folio. Signed-off-by:
-
Matthew Wilcox authored
Use folio APIs throughout. Saves many calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Remove a call to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Convert the incoming page to a folio to remove a few calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Convert the incoming struct page to a folio. Replaces two implicit calls to compound_head() with one explicit call. Signed-off-by:
-
Matthew Wilcox authored
Remove a lot of calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Convert the incoming page to a folio so that we call compound_head() only once instead of seven times. Signed-off-by:
-
Matthew Wilcox authored
All callers now have a folio, so pass it and use it. The folio may be large, although I doubt we'll want to use a large folio for an inline file. Signed-off-by:
-
Matthew Wilcox authored
Saves a number of calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Saves a number of calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Saves a number of calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Saves a number of calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
Use the folio API in this function, saves a few calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
The only caller now has a folio so pass it in directly and avoid the call to page_folio() at the beginning. Signed-off-by:
-
Matthew Wilcox authored
All callers now have a folio so we can pass one in and use the folio APIs to support large folios as well as save instructions by eliminating a call to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
All callers now have a folio so we can pass one in and use the folio APIs to support large folios as well as save instructions by eliminating calls to compound_head(). Signed-off-by:
-
Matthew Wilcox authored
The page/folio is only used to extract the buffers, so this is a simple change. Signed-off-by:
-
Matthew Wilcox authored
Prepare ext4 to support large folios in the page writeback path. Also set the actual error in the mapping, not just -EIO. Signed-off-by:
-
Matthew Wilcox authored
Remove several calls to compound_head() and the last caller of set_page_writeback_keepwrite(), so remove the wrapper too. Also export bio_add_folio() as this is the first caller from a module. Signed-off-by:
-
Matthew Wilcox authored
fscrypt_is_bounce_folio() is the equivalent of fscrypt_is_bounce_page() and fscrypt_pagecache_folio() is the equivalent of fscrypt_pagecache_page(). Signed-off-by:
-
Matthew Wilcox authored
This particular combination of flags is used by most filesystems in their ->write_begin method, although it does find use in a few other places. Before folios, it warranted its own function (grab_cache_page_write_begin()), but I think that just having specialised flags is enough. It certainly helps the few places that have been converted from grab_cache_page_write_begin() to __filemap_get_folio(). Signed-off-by:
-
Ojaswin Mujoo authored
Earlier, inode PAs were stored in a linked list. This caused a need to periodically trim the list down inorder to avoid growing it to a very large size, as this would severly affect performance during list iteration. Recent patches changed this list to an rbtree, and since the tree scales up much better, we no longer need to have the trim functionality, hence remove it. Signed-off-by:
Ojaswin Mujoo <ojaswin@linux.ibm.com> Reviewed-by:
-
