Re: [PATCH 04/10] AXFS: axfs_inode.c

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <jaredeh@...>
Cc: <Linux-kernel@...>, <linux-embedded@...>, linux-mtd <linux-mtd@...>, Jörn Engel <joern@...>, <tim.bird@...>, <cotte@...>, <nickpiggin@...>
Date: Thursday, August 21, 2008 - 8:21 pm

Jared Hulbert wrote:


This implies inode_numbers are unique in AXFS?  If so you can get rid of 
  the axfs_iget5_set/test logic.  This is only necessary for filesystems 
with non-unique inode numbers like cramfs.


If inode_numbers are unique, use iget_locked here.


What's the reason for splitting this into two lines, rather than

inode->i_size = AXFS_GET_INODE_FILE_SIZE(sbi, ino);



No unique per inode time?  Will cause problems using AXFS for archives 
etc. where preserving timestamps is important.



Unnecessary, set by iget_locked/iget_locked5


One to one mapping between inode number and inode name?  No hard link 
support...?


Are "." and ".." stored in the directory?  If not then axfs_readdir 
should fabricate them to avoid confusing applications that expect 
readdir(3) to return them.




Use min() or min_t()


I assume compressed blocks can be larger than PAGE_CACHE_SIZE?  This 
suffers from the rather obvious inefficiency that you decompress a big 
block > PAGE_CACHE_SIZE, but only copy one PAGE_CACHE_SIZE page out of 
it.  If multiple files are being read simultaneously (a common 
occurrence), then each is going to replace your one cached uncompressed 
block (sbi->current_cnode_index), leading to decompressing the same 
blocks over and over again on sequential file access.

readpage file A, index 1 -> decompress block X
readpage file B, index 1 -> decompress block Y (replaces X)
readpage file A, index 2 -> repeated decompress of block X (replaces Y)
readpage file B, index 2 -> repeated decompress of block Y (replaces X)

and so on.


Again, min() or min_t().  Lots of these.

Phillip
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 04/10] AXFS: axfs_inode.c, Jared Hulbert, (Thu Aug 21, 1:45 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Phillip Lougher, (Thu Aug 21, 8:21 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Jared Hulbert, (Thu Aug 21, 11:27 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Phillip Lougher, (Thu Aug 21, 11:46 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Arnd Bergmann, (Thu Aug 21, 8:17 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Phillip Lougher, (Thu Aug 21, 10:22 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Arnd Bergmann, (Fri Aug 22, 6:00 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Phillip Lougher, (Fri Aug 22, 1:08 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Jörn, (Fri Aug 22, 1:19 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Jared Hulbert, (Fri Aug 22, 2:04 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Jared Hulbert, (Thu Aug 21, 11:23 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Phillip Lougher, (Thu Aug 21, 11:29 pm)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Jared Hulbert, (Thu Aug 21, 11:06 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Arnd Bergmann, (Thu Aug 21, 11:12 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Arnd Bergmann, (Thu Aug 21, 7:35 am)
Re: [PATCH 04/10] AXFS: axfs_inode.c, Carsten Otte, (Thu Aug 21, 4:35 am)