[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8738if4jab.fsf@devron.myhome.or.jp>
Date: Wed, 19 Mar 2014 00:29:32 +0900
From: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To: Namjae Jeon <linkinjeon@...il.com>
Cc: akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Namjae Jeon <namjae.jeon@...sung.com>,
Amit Sahrawat <a.sahrawat@...sung.com>
Subject: Re: [PATCH v4 5/6] fat: permit to return phy block number by fibmap in fallocated region
Namjae Jeon <linkinjeon@...il.com> writes:
> +int fat_bmap2(struct inode *inode, sector_t sector,
> + unsigned long *mapped_blocks, struct buffer_head *bh_result,
> + int create, sector_t *bmap)
> +{
> + struct super_block *sb = inode->i_sb;
> + sector_t last_block;
> + const unsigned long blocksize = sb->s_blocksize;
> + const unsigned char blocksize_bits = sb->s_blocksize_bits;
> +
> + BUG_ON(create != 0);
> +
> + *bmap = 0;
> + *mapped_blocks = 0;
> +
> + last_block = (MSDOS_I(inode)->i_disksize + (blocksize - 1))
> + >> blocksize_bits;
> +
> + if (sector >= last_block)
> + return 0;
> +
> + return fat_get_mapped_cluster(inode, sector, last_block, mapped_blocks,
> + bmap);
Maybe, we are better to merge fat_bmap2() and fat_get_block_bmap()?
fat_bmap2() seems to be pointless.
--
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists