Hi, I can see at lot of places in the kernel code, sector_t and long have been used interchangeably. Since sector_t is defined as u64 or unsigned long it will be issue for large file block numbers.
Searching google I found that there have been discussions regarding this and some patch submitted too for some modules (links below), but the current latest stable kernel still seems to have this. As there appears to be printing issues with using sector_t can anyone tell whether we need the cleanup in existing Filesystem code or not ? Previous patches : 1) http://lwn.net/Articles/8437/ 2) http://osdir.com/ml/file-systems.ext2.devel/2006-05/msg00037.html Below are some of the codes where they are used. 547 int ext2_get_block(struct inode *inode, sector_t iblock, struct buffer_head *bh_result, int create) 548 { 549 int err = -EIO; 550 int offsets[4]; 551 Indirect chain[4]; 552 Indirect *partial; 553 unsigned long goal; 554 int left; 555 int boundary = 0; 556 int depth = ext2_block_to_path(inode, iblock, offsets, &boundary); .......... ........... 196 static int ext2_block_to_path(struct inode *inode, 197 long i_block, int offsets[4], int *boundary) 198 { ......... ......... 52 int V1_minix_get_block(struct inode * inode, long block, 53 struct buffer_head *bh_result, int create) 54 { ............. ............. -- Thanks a lot in advance. Thanks & Regards, ******************************************** Manish Katiyar ( http://mkatiyar.googlepages.com ) 3rd Floor, Fair Winds Block EGL Software Park Off Intermediate Ring Road Bangalore 560071, India *********************************************** -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to [EMAIL PROTECTED] Please read the FAQ at http://kernelnewbies.org/FAQ
