mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitri Monakhov <dmonakhov@openvz.org>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: truncate blocks outside i_size after generic_file_direct_write error
Date: Mon, 20 Oct 2008 17:43:07 +0400	[thread overview]
Message-ID: <m3r66bidqs.fsf@dmon-lap.sw.ru> (raw)
In-Reply-To: <x498wsj302t.fsf@segfault.boston.devel.redhat.com> (Jeff Moyer's message of "Mon\, 20 Oct 2008 08\:47\:22 -0400")

Jeff Moyer <jmoyer@redhat.com> writes:

> Dmitri Monakhov <dmonakhov@openvz.org> writes:
>
>> We need to remove block that was allocated in generic_file_direct_write()
>> if we fail. We have to do it *regardless* to blocksize. At least ext2,
>> ext3 and reiserfs interpret (i_size < biggest block) condition as error.
>> Fsck will complain about wrong i_size. Then fsck will fix the error
>> by changing i_size according to the biggest block. This is bad because
>> this blocks contain gurbage from previous write attempt. And result in
>> data corruption.
>>
>> In order to call vmtruncate() we have to hold host->i_mutex. This is true
>> for generic_file_aio_write(). In fact occasionally it is also true for all
>> generic_file_aio_write_nolock() callers except blockdev. But this situation
>> may change someday. This patch fix only generic_write_aio_write() case.
>> BTW: update generic_file_direct_write's comment with currently outdated.
>
> Do you have a test case for this, by any chance?
Off courre.
####TESTCASE_BEGIN
$touch /mnt/test/BIG_FILE
## at this moment /mnt/test/BIG_FILE size and blocks equal to zero
open("/mnt/test/BIG_FILE", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3
write(3, "aaaaaaaaaaaa"..., 104857600) = -1 ENOSPC (No space left on device)
## size and block sould't be changed because write op failed.
$stat /mnt/test/BIG_FILE
File: `/mnt/test/BIG_FILE'
Size: 0 Blocks: 110896 IO Block: 1024 regular empty file
<<<<<<<<^^^^^^^^^^^^^^^^^^^^^^^^^^^^^file size is less than biggest block idx
Device: fe07h/65031d Inode: 14 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-01-24 20:03:38.000000000 +0300
Modify: 2007-01-24 20:03:38.000000000 +0300
Change: 2007-01-24 20:03:39.000000000 +0300

#fsck.ext3 -f /dev/VG/test
e2fsck 1.39 (29-May-2006)
Pass 1: Checking inodes, blocks, and sizes
Inode 14, i_size is 0, should be 56556544. Fix<y>? yes
Pass 2: Checking directory structure
....
#####TESTCASE_END

>
> Cheers,
>
> Jeff

      reply	other threads:[~2008-10-20 13:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-19 14:03 Dmitri Monakhov
2008-10-19 14:03 ` [PATCH 2/2] ocfs2: truncate outstanding block after direct io failure Dmitri Monakhov
2008-10-20 12:47 ` [PATCH 1/2] fs: truncate blocks outside i_size after generic_file_direct_write error Jeff Moyer
2008-10-20 13:43   ` Dmitri Monakhov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3r66bidqs.fsf@dmon-lap.sw.ru \
    --to=dmonakhov@openvz.org \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®