On Wed, 2018-09-12 at 11:24 +0200, Jan Kara wrote: > On Tue 11-09-18 09:42:45, Toshi Kani wrote: > > Ext4 mount path calls ext4_iget() to obtain the journal inode. This > > inode does not support DAX, and 'ext4_da_aops' needs to be set. It > > currently works for the DAX mount case because ext4_iget() always set > > 'ext4_da_aops' to any regular files. > > > > ext4_fill_super > > ext4_load_journal > > ext4_get_journal_inode > > ext4_iget > > > > In preparation to fix ext4_iget() to set 'ext4_dax_aops' for DAX files, > > update ext4_should_use_dax() to return false for the journal inode. > > > > Fixes: 5f0663bb4a64f588f0a2dd6d1be68d40f9af0086 > > Signed-off-by: Toshi Kani <[email protected]> > > Cc: Jan Kara <[email protected]> > > Cc: Dan Williams <[email protected]> > > Cc: "Theodore Ts'o" <[email protected]> > > Cc: Andreas Dilger <[email protected]> > > The journal inode is similar to any other 'system' inode we have in ext4. > We don't really expect any of the address space operations to be called for > it because we don't use page cache with these inodes. Very similar > situation is with e.g. quota files. So to me it seems this patch is not > really necessary. Or did you observe any bad effects without this patch?
Yes, without this change, mount fails with the error below. I believe .bmap operation in ext4_da_aops is necessary for this case. jbd2_journal_init_inode: Cannot locate journal superblock EXT4-fs (pmem1): Could not load journal inode > That being said I agree that it would be a good cleanup to define something > like ext4_is_system_inode() and disable DAX for these inodes just because > they are special. But I don't see a need for this as a part of your fix. Is there other system inode we need to check for? Thanks, -Toshi _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
