All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Nebojsa Trpkovic <trx.lists@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: "data=writeback" and TRIM don't get along
Date: Wed, 07 Apr 2010 23:10:40 -0500	[thread overview]
Message-ID: <4BBD5740.4070101@redhat.com> (raw)
In-Reply-To: <4BBD3365.90306@gmail.com>

Nebojsa Trpkovic wrote:
> On 04/08/10 03:22, Eric Sandeen wrote:
>> How does it fail?
>>
>> Surely a bug.  :)  If you can provide details we'll look into it.
>> (perhaps it's obvious on first try but still worth saying exactly
>> what problematic behavior you saw, when reporting a bug you
>> encountered)
> 
> Well, I've done a simple test, described like:
> 
> "get the used sectors for a file
> hdparm --fibmap filename
> read a sector from the file eg. with
> sudo hdparm --read-sector 66385920 /dev/sda
> delete the file and sync
> rm filename;sync
> and read the sector a second time"

Ok, thanks, perfect test & explanation.

Well the good news is, at least it's nothing like discarding
the wrong block.  :)

Long explanation:

in ext4_free_blocks():

        /* 
         * We need to make sure we don't reuse the freed block until
         * after the transaction is committed, which we can do by
         * treating the block as metadata, below.  We make an
         * exception if the inode is to be written in writeback mode
         * since writeback mode has weak data consistency guarantees.
         */
        if (!ext4_should_writeback_data(inode))
                flags |= EXT4_FREE_BLOCKS_METADATA;


so here we don't set this flag for writeback mode.

Later in that function we do:

        if ((flags & EXT4_FREE_BLOCKS_METADATA) && ext4_handle_valid(handle)) {
...
		ext4_mb_free_metadata(handle, &e4b, new_entry);


ext4_mb_free_metadata adds to t_private_list:

        /* Add the extent to transaction's private list */
        spin_lock(&sbi->s_md_lock);
        list_add(&new_entry->list, &handle->h_transaction->t_private_list);
        spin_unlock(&sbi->s_md_lock);

Once we finally get to release_blocks_on_commit, only things on t_private_list
ultimately get discarded.

Anyway, at the root of this is right now the discard really only happens for
things flagged as metadata, which is a pretty funky thing to do.

(and indeed if you have a unique xattr block, you'll see it get discarded
even with data=writeback).

I'll have to think about the right way to do this... it seems pretty
convoluted to me right now.

-Eric

  reply	other threads:[~2010-04-08  4:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-08  0:50 "data=writeback" and TRIM don't get along Nebojsa Trpkovic
2010-04-08  1:22 ` Eric Sandeen
2010-04-08  1:37   ` Nebojsa Trpkovic
2010-04-08  4:10     ` Eric Sandeen [this message]
2010-04-08  4:37       ` Eric Sandeen
2010-04-08  4:47         ` Eric Sandeen
2010-04-08 11:48           ` Nebojsa Trpkovic
2010-04-08 15:32             ` Eric Sandeen
2010-04-08 16:21               ` Nebojsa Trpkovic
2010-04-08 16:34                 ` Eric Sandeen
2010-04-08  7:17     ` Dmitry Monakhov
2010-04-08 11:47       ` Nebojsa Trpkovic

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=4BBD5740.4070101@redhat.com \
    --to=sandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=trx.lists@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.