linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josef Bacik <josef@redhat.com>
To: Li Dongyang <lidongyang@novell.com>,
	David Sterba <dsterba@suse.cz>,
	chris.mason@oracle.com, linux-btrfs@vger.kernel.org,
	stable@kernel.org
Subject: Re: [PATCH] btrfs: fix crash when no drive supports DISCARD
Date: Fri, 20 May 2011 10:15:46 -0400	[thread overview]
Message-ID: <4DD67792.2060409@redhat.com> (raw)
In-Reply-To: <20110520115224.GW12709@twin.jikos.cz>

On 05/20/2011 07:52 AM, David Sterba wrote:
> On Wed, May 18, 2011 at 11:29:14AM +0800, Li Dongyang wrote:
>> Thanks for the fix, I thought EOPNOTSUPP could be useful by the caller
>> that time, and maybe we could do somthing like remove the discard
>> mount_opt in the fs_info so we can avoid calling it again.
> 
> I do not agree that discard should be removed from mount_opt, because
> one may add TRIM-capable devices later, it's a whole filesystem option,
> while. A disappeared discard mount option will probably cause panic
> in administrator's head.
> 
> However, if a drive does not support TRIM, the btrfs_issue_discard calls
> can take a shortcut and do not call up to blkdev_issue_discard (though
> it does return immediatelly), caching the state after first call. But
> this is matter of the lower level call (blkdev) and should not be
> propagated beyond to the extent "level" (ie. btrfs_discard_extent).
> 

There ought to just be a flag added to btrfs_device to say whether or
not it supports discard, and if we get back EOPNOTSUPP we stop putting
discards down on that device, that way if we have some devices that do
it and some that don't (like for instance if we do that tiered caching
with ssd's thing) we can make sure discard is actually done on drives
that care about it.  Thanks,

Josef

  reply	other threads:[~2011-05-20 14:15 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 15:27 Drive without DISCARD support crashes btrfs David Sterba
2011-05-17 16:00 ` [PATCH] btrfs: fix crash when no drive supports DISCARD David Sterba
2011-05-17 18:49   ` Chris Mason
2011-05-18  3:29   ` Li Dongyang
2011-05-20 11:52     ` David Sterba
2011-05-20 14:15       ` Josef Bacik [this message]
2011-05-21  8:26         ` Li Dongyang

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=4DD67792.2060409@redhat.com \
    --to=josef@redhat.com \
    --cc=chris.mason@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=lidongyang@novell.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=stable@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;
as well as URLs for NNTP newsgroup(s).