Displaying 3 results from an estimated 3 matches for "ocfs2_should_order_data".
2008 Sep 04
4
[PATCH 0/3] ocfs2: Switch over to JBD2.
ocfs2 currently uses the Journaled Block Device (JBD) for its
journaling. This is a very stable and tested codebase. However, JBD
is limited by architecture to 32bit block numbers. This means an ocfs2
filesystem is limited to 2^32 blocks. With a 4K blocksize, that's 16TB.
People want larger volumes.
Fortunately, there is now JBD2. JBD2 adds 64bit block number support
and some other
2011 Jun 24
10
[PATCH 0/9] remove i_alloc_sem V2
i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining
rw_semaphore that can be released by a different thread than the one that
locked it, and it''s use case in the core direct I/O code is more like a
counter given that the writers already have external serialization.
This series removes it in favour of a simpler counter scheme, thus getting
rid
2009 Feb 13
44
[PATCH 0/40] ocfs2: Detach ocfs2 metadata I/O from struct inode
The following series of patches attempts to detach metadata I/O from
struct inode. They are currently tied together pretty tightly.
Metadata reads happen via the ocfs2_read_blocks() functions, writes via
both jbd2 and ocfs2_write_blocks().
- Each inode has a cache of associated metadata blocks stored on its
ip_metadata_cache member. The ocfs2_read/write_blocks() functions
take a struct