On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to
suggest
you
Arnd Bergmann wrote:
On Friday 22 August 2008, Phillip Lougher wrote:
This looks very nice, but could use some comments about how the data is
actually stored on disk. It took me some time to figure out that it actually
allows to do tail merging into compressed blocks, which I was about to
On Thursday 21 August 2008, Jared Hulbert wrote:
+/* functions in other axfs files
**/
+int axfs_get_sb(struct file_system_type *, int, const char *, void *,
+ struct vfsmount *);
+void axfs_kill_super(struct super_block *);
+void
On Thursday 21 August 2008, Jared Hulbert wrote:
+ array_index = AXFS_GET_INODE_ARRAY_INDEX(sbi, ino_number);
+ array_index += page-index;
+
+ node_index = AXFS_GET_NODE_INDEX(sbi, array_index);
+ node_type = AXFS_GET_NODE_TYPE(sbi, array_index);
+
+ if
Squashfs has much larger block sizes than cramfs (last time I looked it was
limited to 4K blocks), and it compresses the metadata which helps to get
better compression. But tail merging (fragments in Squashfs terminology) is
obviously a major reason why Squashfs gets good compression.
The
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
Jared Hulbert wrote:
The memcpy in question copies a c_node to the page. The len is either
the max length of a c_node and size of the buffer I'm copying to
(PAGE_CACHE_SIZE) or it is the difference between the beginning of the
c_node in the c_block and the end of the c_block, whichever is
