On Fri, 24 May 2013 17:37:12 -0400, Jörn Engel wrote: > On Sat, 25 May 2013 02:01:04 +0400, Vyacheslav Dubeyko wrote: >> On May 24, 2013, at 11:01 PM, Jörn Engel wrote: >> > On Fri, 24 May 2013 23:30:10 +0400, Vyacheslav Dubeyko wrote: >> >> On May 24, 2013, at 9:54 PM, Jörn Engel wrote: >> >>> On Fri, 24 May 2013 17:32:52 +0400, Vyacheslav Dubeyko wrote: >> >>>> >> >>>> Subject: [PATCH v5 2/2] nilfs2: use atomic_long_t type for inodes_count >> >>> ... >> >>>> The cp_inodes_count and cp_blocks_count are represented as >> >>>> __le64 type in on-disk structure (struct nilfs_checkpoint). >> >>> >> >>> Isn't atomic_long_t defined to be 32bit on 32bit architectures? >> >> >> >> As I understand, yes. >> > >> > And it doesn't concern you to use a 32bit memory structure to >> > represent a 64bit on-disk structure? ;) >> >> I suppose that you mean possibility to mount NILFS2 volume under 32 bit architecture >> after working with this volume under 64 bit architecture. Am I correct? >> >> Have you any concrete remarks about code of the patch? Feel free to offer your vision. > > Replace atomic_long_t with atomic64_t and replace the various accessor > functions. The on-disk data structure is 64bit, so of course you use > a 64bit in-memory structure. > > Does it really take a vision to come up with this idea? Things are not so simple. It is not guaranteed that 32-bit architectures can handle 64-bit on-disk values. (Think ino_t, page index, or nrpages. These are defined with "unsigned long".) However, these "inodes_count" and "blocks_count" are directly corresponding to their on-disk counterparts, so using atomic64_t looks more intuitive for most people; using atomic_long_t for these was confusing. Ok, I agree. Vyacheslav, could you please consider taking in Jörn's comment ? With regards, Ryusuke Konishi -- 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
