.
This is wrong. If I_DIRTY_DATASYNC is set, the inode needs to be
written even for datasync.
How about the patch below?
Jörn
--
Audacity augments courage; hesitation, fear.
-- Publilius Syrus
Signed-off-by: Jörn Engel [EMAIL PROTECTED]
---
fs/ext3/fsync.c |3 ++-
fs/ext4/fsync.c |3 ++-
2 files
On Thu, 15 November 2007 18:59:19 -0800, Andrew Morton wrote:
On Fri, 16 Nov 2007 11:47:27 +0900 Hisashi Hifumi [EMAIL PROTECTED] wrote:
Currently fdatasync is identical to fsync in ext3,4.
I think fdatasync should skip journal flush in data=ordered and
data=writeback mode
because this
On Mon, 9 July 2007 08:11:22 +0400, Alexey Dobriyan wrote:
If CONFIG_EXT2_FS_POSIX_ACL is not configured, ext2_clear_inode() will be
empty
function. However, there still will be call and immediate return which can be
avoided.
[...]
+#ifdef CONFIG_EXT2_FS_POSIX_ACL
static void
On Mon, 9 July 2007 22:01:48 +0400, Alexey Dobriyan wrote:
Yes. Note that ext2_clear_inode() is referenced from ext2_sops, so even
empty, it leaves traces in resulting kernel.
Is that your opinion or have you actually measured a difference?
I strongly suspect that compilers are smart enough
On Mon, 9 July 2007 17:02:20 -0500, Dave Kleikamp wrote:
It's not a direct call to a static function. It is called as a
super_ops method. I don't think the overhead is very significant, but
it doesn't look like it could do any harm.
Ah, I missed that fact. Yep, looks fine to me.
Jörn
--
On Fri, 27 April 2007 14:10:03 +0200, Heiko Carstens wrote:
After long discussions where at least two possible implementations
were suggested that would work on _all_ architectures you chose one
which doesn't and causes extra effort.
I believe the long discussion also showed that every
On Mon, 9 April 2007 12:21:15 -0500, Eric Sandeen wrote:
Phillip Susi wrote:
When the filesystem is told to mount the disk read only, that means it
should not write to it.
It means the filesystem should not be writeable when it is mounted.
This is not the same as saying that the
On Tue, 10 April 2007 07:27:18 -0400, Theodore Tso wrote:
I suppose what you could do is to read in the journal, and use it to
create an remapping table so that when you want to read block #5126,
and block number 5126 is in the journal, to read the journal version
of the block instead of the
On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote:
Heiko Carstens writes:
If possible I'd prefer the six-32-bit-args approach.
It does mean extra unnecessary work for 64-bit platforms, though...
Wouldn't that work be confined to fallocate()? If I understand Heiko
correctly, the
On Wed, 7 March 2007 09:51:35 +0100, Jan Kara wrote:
I'll probably first write some userspace fs-reorganizer to find out how
much these changes in layout are able to give you in performance (i.e.
whether it's worth the effort of more complicated kernel online
defragmenter).
Have tried
On Mon, 5 March 2007 01:36:36 +0100, Arnd Bergmann wrote:
Using the current glibc implementation on a compressed file system ideally
should be a very expensive no-op because you won't actually allocate much
space for a file when writing zeroes to it. You also don't benefit of a
contiguous
On Mon, 5 March 2007 00:32:14 +, Anton Altaparmakov wrote:
I don't know how your compression algorithm works [...]
LogFS is designed for flash media, so it does not have to worry much
about reducing disk seeks. It is log-structured, which simplifies
compression further.
When writing a
On Sun, 4 March 2007 14:38:13 -0800, Ulrich Drepper wrote:
When you do it like this, who can the kernel/filesystem *guarantee* that
when the data is written there actually is room on the harddrive?
What you described seems like using truncate/ftruncate to increase the
file's size. That is
On Wed, 25 October 2006 14:41:18 -0400, Jeff Garzik wrote:
On Wed, Oct 25, 2006 at 08:36:56PM +0200, Jan Kara wrote:
Yes, but there's a question of the interface to this operation. How to
specify which indirect block I mean? Obviously we could introduce
separate call for remapping
14 matches
Mail list logo
