public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: [PATCH 15/19] mkfs: don't treat files as though they are block devices
Date: Thu, 21 Apr 2016 16:13:55 -0400	[thread overview]
Message-ID: <57193483.8000700@sandeen.net> (raw)
In-Reply-To: <CACj3i73aW53YyEsZERZnSWHJ3y9cW85sA15KdoesCbx9wKsbPg@mail.gmail.com>



On 4/21/16 8:43 AM, Jan Tulak wrote:
> On Thu, Apr 21, 2016 at 11:39 AM, Jan Tulak <jtulak@redhat.com <mailto:jtulak@redhat.com>>wrote:
> 
>     From: Dave Chinner <dchinner@redhat.com <mailto:dchinner@redhat.com>>
> 
>     THIS PATCH HAS KNOWN ISSUES - it fails xfs/206 and xfs/216 tests, as it
>     shrinks a file instead just not using it entirely, when -d size is used.
> 
> 
> ​So the shrinking is happening here:
> 3127        /*
> 3128         * If the data area is a file, then grow it out to its final size
> 3129         * so that the reads for the end of the device in the mount code
> 3130         * will succeed.
> 3131         */
> 3132        if (xi.disfile && ftruncate64(xi.dfd, dblocks * blocksize) < 0) {​
>  
> 
> Before the patch, xi.disfile was 0 and so it didn't shrink the file
> to the size of the new FS. Now, what is the correct solve to this?
> Tests are written for the old behaviour, but this shrinking seems to
> be an intentional thing. It seems that the FS works ok even when this
> truncating is not applied, so I think that I should remove this chunk
> (or change it to xi.dcreate=1 only), and keep the old behaviour.
> 
> What do you think about it, guys?

Can't remove it; that would break the other side of things, if you try
to mkfs.xfs -d size=2g on an existing 1g file... mount tries to do
IO to the last block, and if it's not truncated out, that will fail
(as the comment says).

I suppose the simple way to fix it is to only truncate up, never down.

i.e. truncate to max(dblocks * blocksize, st_size) or
if (xi.disfile && st_size <  dblocks * blocksize) { truncate ... }

-Eric



> Cheers,
> Jan
> 
> 
> 
> -- 
> Jan Tulak
> jtulak@redhat.com <mailto:jtulak@redhat.com> / jan@tulak.me <mailto:jan@tulak.me>
> 
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2016-04-21 20:14 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-21  9:39 [PATCH 00/19 v2] mkfs cleaning Jan Tulak
2016-04-21  9:39 ` [PATCH 01/19] xfsprogs: use common code for multi-disk detection Jan Tulak
2016-04-21  9:39 ` [PATCH 02/19] mkfs: sanitise ftype parameter values Jan Tulak
2016-04-21  9:39 ` [PATCH 03/19] mkfs: Sanitise the superblock feature macros Jan Tulak
2016-05-02 23:06   ` Eric Sandeen
2016-05-04  0:48     ` Eric Sandeen
2016-04-21  9:39 ` [PATCH 04/19] mkfs: validate all input values Jan Tulak
2016-04-21  9:39 ` [PATCH 05/19] mkfs: factor boolean option parsing Jan Tulak
2016-04-21  9:39 ` [PATCH 06/19] mkfs: validate logarithmic parameters sanely Jan Tulak
2016-04-21  9:39 ` [PATCH 07/19] mkfs: structify input parameter passing Jan Tulak
2016-04-21  9:39 ` [PATCH 08/19] mkfs: getbool is redundant Jan Tulak
2016-05-02 23:08   ` Eric Sandeen
2016-04-21  9:39 ` [PATCH 09/19] mkfs: use getnum_checked for all ranged parameters Jan Tulak
2016-04-21  9:39 ` [PATCH 10/19] mkfs: add respecification detection to generic parsing Jan Tulak
2016-04-21  9:39 ` [PATCH 11/19] mkfs: table based parsing for converted parameters Jan Tulak
2016-05-02 23:09   ` Eric Sandeen
2016-04-21  9:39 ` [PATCH 12/19] mkfs: merge getnum Jan Tulak
2016-04-21  9:39 ` [PATCH 13/19] mkfs: encode conflicts into parsing table Jan Tulak
2016-05-02 23:11   ` Eric Sandeen
2016-05-03 23:39   ` Eric Sandeen
2016-05-04  0:47     ` Eric Sandeen
2016-04-21  9:39 ` [PATCH 14/19] mkfs: add string options to generic parsing Jan Tulak
2016-05-02 23:11   ` Eric Sandeen
2016-04-21  9:39 ` [PATCH 15/19] mkfs: don't treat files as though they are block devices Jan Tulak
2016-04-21 12:43   ` Jan Tulak
2016-04-21 20:13     ` Eric Sandeen [this message]
2016-04-22  7:46       ` Jan Tulak
2016-04-22  7:49   ` [PATCH 15/19 v2] " Jan Tulak
2016-04-29 14:47     ` [PATCH 15/19 v3] " Jan Tulak
2016-04-29 19:11       ` Eric Sandeen
2016-05-03  9:59         ` Jan Tulak
2016-05-02 23:13   ` [PATCH 15/19] " Eric Sandeen
2016-04-21  9:39 ` [PATCH 16/19] mkfs: move spinodes crc check Jan Tulak
2016-04-21  9:39 ` [PATCH 17/19] mkfs: unit conversions are case insensitive Jan Tulak
2016-04-21  9:39 ` [PATCH 18/19] mkfs: add optional 'reason' for illegal_option Jan Tulak
2016-04-21  9:39 ` [PATCH 19/19] mkfs: conflicting values with disabled crc should fail Jan Tulak
2016-04-28  8:29 ` [RFC PATCH] xfstests: Add mkfs input validation tests Jan Tulak
2016-04-29  1:59   ` Dave Chinner
2016-04-29 14:42     ` Jan Tulak
2016-05-02 23:05 ` [PATCH 00/19 v2] mkfs cleaning Eric Sandeen
2016-05-10  6:10 ` Dave Chinner
2016-06-01 13:19   ` Jan Tulak
2016-06-03  0:53     ` Dave Chinner
2016-06-03  9:20       ` Jan Tulak
2016-06-03 12:09         ` Jan Tulak
2016-06-04  0:32           ` Dave Chinner
2016-06-06  7:42             ` Jan Tulak
  -- strict thread matches above, loose matches on Subject: below --
2016-03-24 11:15 [PATCH 00/19] " jtulak
2016-03-24 11:15 ` [PATCH 15/19] mkfs: don't treat files as though they are block devices jtulak
2016-04-08  0:25   ` Eric Sandeen
2016-04-08  0:32     ` Eric Sandeen
2016-04-08 14:58     ` Jan Tulak
2016-04-08 15:50       ` Eric Sandeen
2016-04-08 15:56         ` Jan Tulak
2016-04-09  4:12       ` Eric Sandeen
2016-04-13 15:43         ` Jan Tulak
2016-04-14  9:49       ` Jan Tulak
2016-04-20  9:51         ` Jan Tulak
2016-04-20 13:17           ` Jan Tulak
2016-04-20 16:53             ` Eric Sandeen
2016-04-21  9:22               ` Jan Tulak

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=57193483.8000700@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox