All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Tulak <jtulak@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>, xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] mkfs.xfs: always use underlying fs sector size when mkfs'ing a file
Date: Fri, 19 Jun 2015 03:01:58 -0400 (EDT)	[thread overview]
Message-ID: <1047428563.16839742.1434697318546.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <5582DC45.9050101@sandeen.net>



----- Original Message -----
> From: "Eric Sandeen" <sandeen@sandeen.net>
> To: "Jan Tulak" <jtulak@redhat.com>, "Eric Sandeen" <sandeen@redhat.com>
> Cc: "xfs-oss" <xfs@oss.sgi.com>
> Sent: Thursday, June 18, 2015 4:57:09 PM
> Subject: Re: [PATCH] mkfs.xfs: always use underlying fs sector size when	mkfs'ing a file
> 
> On 6/18/15 6:03 AM, Jan Tulak wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Eric Sandeen" <sandeen@redhat.com>
> >> To: "xfs-oss" <xfs@oss.sgi.com>
> >> Sent: Thursday, June 18, 2015 1:26:33 AM
> >> Subject: [PATCH] mkfs.xfs: always use underlying fs sector size when
> >> mkfs'ing	a file
> >>
> >> If we are mkfs'ing a file, and that file is on a 4k sector filesystem,
> >> we should make the fs image file with the same sector size, or things
> >> may fail when they try to do direct IO in 512 byte chunks (depending
> >> on whether it is a 512e or "hard" 4k device).
> >>
> >> Earlier commits attempted this to some degree:
> >>
> >> 5a7d59 xfsprogs: try to handle mkfs of a file on 4k sector device
> >> 3800a2 mkfs.xfs: don't call blkid_get_topology on existing regular files
> >>
> >> but inexplicably missed the case where mkfs.xfs with "-d file" was
> >> specified.
> >>
> >> One more try; in get_topology(), try to get the underlying fs sector
> >> size in *all* cases where we are mkfs'ing a file, and set the sector size
> >> accordingly.
> >>
> >> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> >> ---
> >>
> >> (This does it for 512e as well as hard 4k drives, but I think that's
> >> probably ok?  If not, perhaps we should go further and attempt to
> >> discern logical and physical sectors for the device under the
> >> filesystem.  Is it worth it?  Not sure it is.)
> >>
> >> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> >> index e2a052d..e44c390 100644
> >> --- a/mkfs/xfs_mkfs.c
> >> +++ b/mkfs/xfs_mkfs.c
> >> @@ -462,31 +462,34 @@ static void get_topology(
> >>  	struct fs_topology	*ft,
> >>  	int			force_overwrite)
> >>  {
> >> -	if (!xi->disfile) {
> >> -		char *dfile = xi->volname ? xi->volname : xi->dname;
> >> -		struct stat statbuf;
> >> +	struct stat statbuf;
> >> +	char *dfile = xi->volname ? xi->volname : xi->dname;
> >>  
> >> -		/*
> >> -		 * If our target is a regular file, and xi->disfile isn't
> >> -		 * set (i.e. no "-d file" invocation), use platform_findsizes
> >> -		 * to try to obtain the underlying filesystem's requirements
> >> -		 * for direct IO; we'll set our sector size to that if possible.
> >> -		 */
> >> -		if (!stat(dfile, &statbuf) && S_ISREG(statbuf.st_mode)) {
> >> -			int fd;
> >> -			long long dummy;
> >> -
> >> -			fd = open(dfile, O_RDONLY);
> >> -			if (fd >= 0) {
> >> -				platform_findsizes(dfile, fd, &dummy,
> >> -						   &ft->lsectorsize);
> >> -				close(fd);
> >> -			}
> >> -		} else {
> >> -			blkid_get_topology(dfile, &ft->dsunit, &ft->dswidth,
> >> -					   &ft->lsectorsize, &ft->psectorsize,
> >> -					   force_overwrite);
> >> +	/*
> >> +	 * If our target is a regular file, use platform_findsizes
> >> +	 * to try to obtain the underlying filesystem's requirements
> >> +	 * for direct IO; we'll set our sector size to that if possible.
> >> +	 */
> >> +	if (xi->disfile ||
> >> +	    (!stat(dfile, &statbuf) && S_ISREG(statbuf.st_mode))) {
> >> +		int fd;
> >> +		int flags = O_RDONLY;
> >> +		long long dummy;
> >> +
> >> +		/* with xi->disfile we may not have the file yet! */
> >> +		if (xi->disfile)
> >> +			flags |= O_CREAT;
> >> +
> >> +		fd = open(dfile, flags, 0666);
> >> +		if (fd >= 0) {
> >> +			platform_findsizes(dfile, fd, &dummy, &ft->lsectorsize);
> >> +			close (fd);
> >>  		}
> >> +
> >> +	} else {
> >> +		blkid_get_topology(dfile, &ft->dsunit, &ft->dswidth,
> >> +				   &ft->lsectorsize, &ft->psectorsize,
> >> +				   force_overwrite);
> >>  	}
> >>  
> >>  	if (xi->rtname && !xi->risfile) {
> >>
> > 
> > This changes get_topology only for ENABLE_BLKID branch of #ifdef. Is
> > that intentional, i.e. we don't expect anyone not using ENABLE_BLKID?
> > Because otherwise, if mkfs is compiled without ENABLE_BLKID, then all
> > we get is:
> 
> Hm, yeah, good point.  I always forget about this.  :(  I can send V2.
> 
> And sorry if this overlaps w/ your changes- 

No problem. :-)

Cheers,
Jan

-- 
Jan Tulak
jtulak@redhat.com

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

  reply	other threads:[~2015-06-19  7:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-17 23:26 [PATCH] mkfs.xfs: always use underlying fs sector size when mkfs'ing a file Eric Sandeen
2015-06-18 11:03 ` Jan Tulak
2015-06-18 14:57   ` Eric Sandeen
2015-06-19  7:01     ` Jan Tulak [this message]
2015-06-19 15:09   ` Christoph Hellwig
2015-06-19 15:17     ` Eric Sandeen
2015-06-19 15:21       ` Christoph Hellwig
2015-06-19 15:24         ` Eric Sandeen
2015-06-19 17:09 ` PATCH V2] " Eric Sandeen

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=1047428563.16839742.1434697318546.JavaMail.zimbra@redhat.com \
    --to=jtulak@redhat.com \
    --cc=sandeen@redhat.com \
    --cc=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 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.