hmmm... this would seem to conflict with the docs in the kernel, especially: "Write barriers enforce proper on-disk ordering of journal commits, making volatile disk write caches safe to use, at some performance penalty. If your disks are battery-backed in one way or another, I'm not worried about powerloss. The kernel docs seem to imply that data=[journaled,ordered] come with a performance hit. My results would indicate otherwise. Should I be seeing this kinda of Steve --

I'm in the process of evaluating various storage options for a large array (12TB) I'm creating. First. I will preface all of this by saying that I understand the note in the kernel docs about comparing file systems under various workloads, and I acknowledge that my exact methodology isn't perfect. But it works for what I'm doing. :) This array will be used for storage of large media files (up to 20-30GB per file). I'm testing using iozone with various file sizes ranging from 4GB to 32GB. I'm ...

Hello, I have a question about ext2/ext3. As I understand directory indexing is compatible feature, currently my implementations doesn't support HTree. I do some things (make kernel and libs) with FS and check it with e2fsck: it creates index (everything else is ok, exit status is 1). Then I do same things with FS and check again: HTree directory inode 23316 has an invalid root node. Is it OK for implementation without directory indexing? -- Evgeniy Ivanov --

Dmitry Monakhov <dmonakhov@openvz.org> writes: Oops. i've missed last 'u' in 'edu', the Ted's email. Add him to cc. BTW seems that there is only one reproducible bug is left after 227's xfstest case. The bug with wrong i_blocks count: Pass 1: Checking inodes, blocks, and sizes Inode 3855, i_blocks is 288, should be 304. Fix? no This will be the hardest one because i'm able to discover wrong blocks count only on fsck stage. I'm suspecting what quota charge is missed --