All of lore.kernel.org
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Lutz Vieweg <lvml@5t9.de>,
	util-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-xfs@oss.sgi.com
Cc: Lukas Czerner <lczerner@redhat.com>
Subject: Re: fstrim on newly created filesystem tries to discard data beyond the last sector of a device
Date: Mon, 24 Nov 2014 10:23:13 +0100	[thread overview]
Message-ID: <20141124092313.GA926@x2.net.home> (raw)
In-Reply-To: <20141121212044.GB32316@vapier.wh0rd.info>

On Fri, Nov 21, 2014 at 04:20:44PM -0500, Mike Frysinger wrote:
> On 21 Nov 2014 18:09, Lutz Vieweg wrote:
> > The relevant strace output of the above fstrim command:
> > > stat("/mnt/PFexp1", {st_mode=S_IFDIR|0755, st_size=6, ...}) = 0
> > > open("/mnt/PFexp1", O_RDONLY)           = 3
> > > ioctl(3, FITRIM, 0x7fff0733a4c0)        = -1 EIO (Input/output error)
> 
> that hasn't decoded the ioctl (send a patch for that), but guess is that you're 
> passing down the default:
> 	range.start = 0;
> 	range.minlen = 0;
> 	range.len = UULONG_MAX;
> 
> in which case the expectation is the kernel layers will take care of trimming 
> everything and not die when it hits the end of the device.


Yep, it's fine to specify such range, xfs_ioc_trim():

    end = start + BTOBBT(range.len) - 1;
    ...

	if (end > XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks) - 1)
		end = XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks)- 1;

it really seems like kernel issue. (CC: to Lukas).

 Karel


-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2014-11-24  9:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-10 16:07 fstrim: "fitrim ioctl failed: input/output error" -> "Logical block address out of range" Lutz Vieweg
2014-11-18 10:32 ` fstrim tries to discard data beyond the last sector of a device Lutz Vieweg
2014-11-18 11:03   ` Karel Zak
2014-11-21 16:44     ` Lutz Vieweg
2014-11-21 17:09   ` fstrim on newly created filesystem " Lutz Vieweg
2014-11-21 17:09     ` Lutz Vieweg
2014-11-21 21:20     ` Mike Frysinger
2014-11-21 21:20       ` Mike Frysinger
2014-11-24  9:23       ` Karel Zak [this message]
2014-11-24 12:25     ` Lukáš Czerner
2014-11-24 19:30       ` Lutz Vieweg
2014-11-24 19:30         ` Lutz Vieweg
2014-11-24 19:43         ` Bernd Schubert
2014-11-24 19:43           ` Bernd Schubert
2014-11-24 20:03           ` Lutz Vieweg
2014-11-24 20:03             ` Lutz Vieweg
2014-11-24 20:18             ` Bernd Schubert
2014-11-24 21:24     ` Dave Chinner
2014-11-24 21:24       ` Dave Chinner

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=20141124092313.GA926@x2.net.home \
    --to=kzak@redhat.com \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=lvml@5t9.de \
    --cc=util-linux@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 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.