On Wed, 09 Aug 2006 18:20:43 -0700 Mingming Cao <cmm@xxxxxxxxxx> wrote: > > Define SECTOR_FMT to print sector_t in proper format > > ... > > #define HAVE_SECTOR_T > typedef u64 sector_t; > +#define SECTOR_FMT "%llu" We've thus-far avoided doing this. In fact a similar construct in device-mapper was recently removed. Unlike many other attempts, this one appears to be correct (people usually get powerpc wrong, due to its u64=unsigned long). That being said, I'm not really sure we want to add this. It produces rather nasty-looking source code and thus far we've just used %llu and we've typecasted the sector_t to `unsigned long long'. That happens in a lot of places in the kernel and perhaps we don't want to start innovating in ext4 ;) That also being said... does a 32-bit sector_t make any sense on a 48-bit-blocknumber filesystem? I'd have thought that we'd just make ext4 depend on 64-bit sector_t and be done with it. Consequently, sector_t should largely vanish from ext4 and JBD2, except for those places where it interfaces with the VFS and the block layer. Internally it should just use 64-bit quantities. That could be u64, but I'd suggest that the fs simply open-code `unsigned long long' so that we don't need to play any gams at all when passing these things into printk. Finally, perhaps the code is printing block numbers too much ;) <Notices E3FSBLK, wonders how that snuck through> I'd suggest that "[patch] ext3: remove E3FSBLK" be written and merged before we clone ext4, too... - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
