[Added jbd2 Ccs. Sorry about the whole-patch-quote, but I want jbd2 folks to see what we're doing.] This is completely unsafe. Two reasons. First, you're checking the journal features after ocfs2_journal_load() has done recovery. This may or may not be safe; recovering a 32bit journal probably works even on a 64bit filesystem, and we shouldn't see that combination in the wild anyway. That's not so bad. Far worse is that you might recover a 64bit journal before you've checked the ...

They're not so dependent. They're based on the FS_IOC_[GS]ETFLAGS ioctl which even XFS translates its flags for. These ioctl flags must now remain invariant. Whilst they might have originated as Ext2/3/4 flags, they're now This can be argued one way or another, however aligning i_flags with something would probably be an improvement somewhere. Most of what I deal with is Ext3/4 based, and BTRFS-based is likely to become important too. David --

The ext[23] (and I suppose 4 as well) uses the process pid % 16 to define a 'color' for the process. New files first block goal depends on that 'color' - the goal is one of 16 different offsets in the block group where the new file's inode was allocated (usually the block group of its parent directory). The logic behind this allocator is that multiple files created concurrently in the same directory would have less chance of stepping over each other's allocations. I am not sure what you ...

In all of my recent tests, there has only been one file created, in the root directory of the freshly created and mounted file system. mkfs.ext[234] -b 65536 /dev/sda4 mount <some options tested> /dev/sda4 /DataVolume touch /DataVolume/hex.txt "for i in 1 2 3 4 5; do dd if=/hex.txt bs=64K; \ done >>/DataVolume/hex.txt" umount /DataVolume dumpe2fs /dev/sda4 >/<log file> where /hex.txt is a 1G file on the NFS root. I tried with, and without, orlov on ext3 (-o orlov and -o oldalloc) and ...

However, from the test description it looks like it is writing a file to the root dir, so there should be no parent-dir random spreading, right? -Eric --

Out of curiosity, what *are* the "common NAS benchmarks" in use today, and who chooses them? There have been times in the past when "common benchmarks" promulgated by reviewers have done active harm in the industry, driving disk drive manufacturers to chose unsafe defaults, all because the only thing people paid attention to was crappy benchmarks. Sometimes the right answer is to put a spotlight on deficient Delayed allocation is the default for ext4. If you are seeing random behaviour ...

that patch is rather simplistic, FWIW; at least for XFS it -hurt- perf due to the unwritten->written conversion and the relatively small, frequent preallocations. More smarts to merge up multiple 1-byte-writes into a large preallocation might help, as the bug mentions. But ... is something like it already in samba? that'd be nifty, but I wasn't aware of that. There is a preallocation-sounding switch but I think it doesn't do what you think it does. I'd have to go look up details, ...

Hi Amir, I really do appreciate the effort, the patch, and the ping. :) I'll have to set aside some time to give it a hard look, but linking it back to existing bugs of mine raises that priority, thanks. :) --

https://bugzilla.kernel.org/show_bug.cgi?id=15827 Dmitry Monakhov <dmonakhov@openvz.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are ...

https://bugzilla.kernel.org/show_bug.cgi?id=15742 Dmitry Monakhov <dmonakhov@openvz.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |CODE_FIX -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are ...