This moves access to f2fs_dentry_block's dentry list and filename list
behind a macro, as their locations depend on block size.
Since struct f2fs_dentry_block no longer represents the full block, use
F2FS_BLKSIZE instead of sizeof(struct f2fs_dentry_block)
Signed-off-by: Daniel Rosenberg
---
fs
This converts f2fs_nat_block and f2fs_sit_block to be variable length
arrays. This does not change the way they are accessed, but removes a
misleading statment that these sizes are fixed, as opposed to deriving
from F2FS_BLKSIZE
Signed-off-by: Daniel Rosenberg
---
include/f2fs_fs.h | 20
This converts inodes, direct nodes, and indirect nodes over to not being
based on a 4K page size. f2fs_inode's i_nids field should now be
accessed via a macro, as it's location depends on block size.
Access to direct nodes and indirect nodes is unchanged.
The node footer's location is also based
This adds support for different block sizes to f2fs-tools.
The first patch redefines all block size based constants to be based on the
block size. After this patch, you should be able to compile a version of
f2fs-tools that works for a given blocksize by just setting F2FS_BLKSIZE_BITS
in f2fs_fs.h
This splits off access to the summary block's journal and footer into a
macro call, as their location is dependent on block size. Because of
this you should use F2FS_BLKSIZE instead of sizeof(struct summary_block)
Signed-off-by: Daniel Rosenberg
---
fsck/f2fs.h| 4 +--
fsck/fsck.c
This splits off access to the orphan block's footer into a macro call
as its location is dependent on block size. Because of this, you should
use F2FS_BLKSIZE instead of sizeof(struct f2fs_orphan_block)
Signed-off-by: Daniel Rosenberg
---
fsck/fsck.c | 4 ++--
fsck/main.c
This converts the various block size based constants to be defined in
terms of the block size. This makes it possible to change the block size
by changing only F2FS_BLKSIZE_BITS in f2fs_fs.h
Signed-off-by: Daniel Rosenberg
---
fsck/dir.c | 2 +-
fsck/dump.c | 4 +-
f
This adds support for 4K and 16K block size using the same binary.
mkfs can choose block size via the -b option, with other tools getting
the blocksize from the superblock.
On mount time, we can't rely on block size for the location for the
superblock, since that information is in the superblock.
On Mon, Aug 28, 2023 at 1:27 PM Jaegeuk Kim wrote:
>
> This patch somehow reveals struct size assertions.
> You can get it when running fsck from the used f2fs partition.
>
Seems the binary I was testing had the asserts set to noops. I was
missing the 2 bytes from n_nats/n_sits, and had a few nat/
On Mon, Aug 28, 2023 at 11:08 AM Jaegeuk Kim wrote:
>
> Hi Daniel,
>
> Could you please check this?
>
> mount.c: In function ‘move_one_curseg_info’:
> mount.c:3037:9: warning: ‘memcpy’ offset [0, 3583] is out of the bounds [0,
> 0] of object ‘buf’ with type ‘struct f2fs_summary_block’ [-Warray-bo
This patch somehow reveals struct size assertions.
You can get it when running fsck from the used f2fs partition.
On 08/25, Daniel Rosenberg wrote:
> This adds support for 4K and 16K block size using the same binary.
> mkfs can choose block size via the -b option, with other tools getting
> the bl
On 08/25, Daniel Rosenberg wrote:
> This converts f2fs_nat_block and f2fs_sit_block to be variable length
> arrays. This does not change the way they are accessed, but removes a
> misleading statment that these sizes are fixed, as opposed to deriving
> from F2FS_BLKSIZE
>
> Signed-off-by: Daniel R
Hi Daniel,
Could you please check this?
mount.c: In function ‘move_one_curseg_info’:
mount.c:3037:9: warning: ‘memcpy’ offset [0, 3583] is out of the bounds [0, 0]
of object ‘buf’ with type ‘struct f2fs_summary_block’ [-Warray-bounds]
3037 | memcpy(curseg->sum_blk, &buf, SUM_ENTRIES_SIZ
Hello:
This patch was applied to jaegeuk/f2fs.git (dev)
by Jaegeuk Kim :
On Thu, 24 Aug 2023 09:08:31 -0700 you wrote:
> From: Daeho Jeong
>
> Use the finish zone command first when a zone should be closed.
>
> Signed-off-by: Daeho Jeong
> ---
> fs/f2fs/segment.c | 19 +--
>
Hello:
The following patches were marked "accepted", because they were applied to
jaegeuk/f2fs.git (dev):
Patch: [f2fs-dev] f2fs: use finish zone command when closing a zone
Submitter: Daeho Jeong
Committer: Jaegeuk Kim
Patchwork: https://patchwork.kernel.org/project/f2fs/list/?series=779
On Fri 25-08-23 15:32:47, Christian Brauner wrote:
> On Wed, Aug 23, 2023 at 12:48:11PM +0200, Jan Kara wrote:
> > Hello,
> >
> > this is a v3 of the patch series which implements the idea of
> > blkdev_get_by_*()
> > calls returning bdev_handle which is then passed to blkdev_put() [1]. This
> >
On Mon 28-08-23 20:57:53, Chao Yu wrote:
> On 2023/8/23 18:48, Jan Kara wrote:
> > Convert f2fs to use bdev_open_by_dev/path() and pass the handle around.
>
> Hi Jan,
>
> Seems it will confilct w/ below commit, could you please take a look?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jae
On Sat, Aug 26, 2023 at 03:28:52AM +0100, Al Viro wrote:
> I mean, look at claim_swapfile() for example:
> p->bdev = blkdev_get_by_dev(inode->i_rdev,
>FMODE_READ | FMODE_WRITE | FMODE_EXCL, p);
> if (IS_ERR(p->bdev)) {
>
On Fri, Aug 25, 2023 at 03:47:56PM +0200, Jan Kara wrote:
> I can see the appeal of not having to introduce the new bdev_handle type
> and just using struct file which unifies in-kernel and userspace block
> device opens. But I can see downsides too - the last fput() happening from
> task work make
On Mon, Aug 28, 2023 at 02:56:15PM +0100, Al Viro wrote:
> The first failure exit does not need any work - the caller had not bumped
> ->ki_pos; the second one (after that 'if (err < 0) {' line) does and that's
> where the patch upthread adds iocb->ki_pos -= buffered_written.
>
> Or am I completel
With below script, redundant compress extension will be parsed and added
by parse_options(), because parse_options() doesn't check whether the
extension is existed or not, fix it.
1. mount -t f2fs -o compress_extension=so /dev/vdb /mnt/f2fs
2. mount -t f2fs -o remount,compress_extension=so /mnt/f2
Call trace:
__memcpy+0x128/0x250
f2fs_read_multi_pages+0x940/0xf7c
f2fs_mpage_readpages+0x5a8/0x624
f2fs_readahead+0x5c/0x110
page_cache_ra_unbounded+0x1b8/0x590
do_sync_mmap_readahead+0x1dc/0x2e4
filemap_fault+0x254/0xa8c
f2fs_filemap_fault+0x2c/0x104
__do_fault+0x7c/0x238
do_handle_mm_f
With below mount option and testcase, it hangs kernel.
1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs
2. touch /mnt/f2fs/file
3. chattr +c /mnt/f2fs/file
4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1
5. sync
6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc
7. syn
This patch covers sanity check logic on cluster w/ CONFIG_F2FS_CHECK_FS,
otherwise, there will be performance regression while querying cluster
mapping info.
Callers of f2fs_is_compressed_cluster() only care about whether cluster
is compressed or not, rather than # of valid blocks in compressed cl
On Mon, Aug 28, 2023 at 02:30:23PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> > That part is somewhat fishy - there's a case where you return a positive
> > value
> > and advance ->ki_pos by more than that amount. I really wonder if all
> > calle
On Mon, Aug 28, 2023 at 02:32:59PM +0200, Christoph Hellwig wrote:
> On Sun, Aug 27, 2023 at 10:45:18PM +0100, Al Viro wrote:
> > IOW, I suspect that the right thing to do would be something along the lines
> > of
>
> The idea looks sensible to me, but we'll also need to do it for the
> filemap_wr
> So besides my last fput() worry about I think this could work and would be
> probably a bit nicer than what I have. But before going and redoing the whole
> series let me gather some more feedback so that we don't go back and forth.
> Christoph, Christian, Jens, any opinion?
I'll be a bit under
On 2023/8/23 18:48, Jan Kara wrote:
Convert f2fs to use bdev_open_by_dev/path() and pass the handle around.
Hi Jan,
Seems it will confilct w/ below commit, could you please take a look?
https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev&id=51bf8d3c81992ae57beeaf22d
On Sun, Aug 27, 2023 at 10:45:18PM +0100, Al Viro wrote:
> IOW, I suspect that the right thing to do would be something along the lines
> of
The idea looks sensible to me, but we'll also need to do it for the
filemap_write_and_wait_range failure case.
___
On Sun, Aug 27, 2023 at 08:41:22PM +0100, Al Viro wrote:
> That part is somewhat fishy - there's a case where you return a positive value
> and advance ->ki_pos by more than that amount. I really wonder if all callers
> of ->write_iter() are OK with that. Consider e.g. this:
This should not exis
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly rac
31 matches
Mail list logo
