Re: svn commit: r344562 - head/sys/ufs/ffs
On Tue, Feb 26, 2019, 12:49 AM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Mon, 25 Feb 2019, Jason Harmening wrote: > > > > > On 2/25/19 9:46 PM, Bruce Evans wrote: > > >> > > >> block_size <= PAGE_SIZE is very uncommon for ffs, even on systems > with > > >> large > > >> pages. MINBSIZE is 4096 in ffs (except in my version, it is 512). > The > > >> default is 32768 in newfs. I consider this excessive and only use it > for > > >> file systems with many files larger than 1GB, but it is the most > common > > >> size. > > >> It is larger than the large page size of 8192. > > > > > > I think this is a case of filesystem logical block size vs. media > sector > > > size, right? Here we're checking the devvp's block size, which I > think > > > should correspond to the sector size. I'd expect cases of that being > > > greater than PAGE_SIZE to be uncommon, in fact geli warns when that is > the > > > case. I probably should've made that clearer in the commit message. > > > > Yes, I missed that you are checking devvp. ffs_getpages() also checks > > devvp. > > > > So the bug has nothing to do with file system logical (fragment) or i/o > > (block) block size's, except file systems themselves won't work unless > > their i/o size is a multiple of the underlying devices (sector) i/o size. > > > > Are there physical disk with sector size > PAGE_SIZE now? > > I have been told that there are some sd/flash devices that > have a 16k physical sector size, I have not been able to > confirm that information though. > There are a number of drives that report 16k physical, but 4k sector size. Others vendors have suggested that 32k or 64k may be on the horizon. But all these drives still report an LBA size of 4k. The drive vendors I've talked to have indicated that a larger sector size is in the works, but so far they haven't indicated what that newer size will wind up being, or when it would appear in the market... The timing of when may be unknown, but it's quite likely the future will have to cope with a mismatch. Warner > It is easy to > > create virtual (md) disks with sector size > PAGE_SIZE, and this may even > > be useful for avoiding the related problem of having to access large fs > > blocks to do i/o to small md sectors. I think it is best to use > PAGE_SIZE > > blocks in all layers and sometimes combine these into clusters. > > > > Bruce > -- > Rod Grimes > rgri...@freebsd.org > > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344562 - head/sys/ufs/ffs
> On Mon, 25 Feb 2019, Jason Harmening wrote: > > > On 2/25/19 9:46 PM, Bruce Evans wrote: > >> > >> block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with > >> large > >> pages.?? MINBSIZE is 4096 in ffs (except in my version, it is 512).?? The > >> default is 32768 in newfs.?? I consider this excessive and only use it for > >> file systems with many files larger than 1GB, but it is the most common > >> size. > >> It is larger than the large page size of 8192. > > > > I think this is a case of filesystem logical block size vs. media sector > > size, right? Here we're checking the devvp's block size, which I think > > should correspond to the sector size. I'd expect cases of that being > > greater than PAGE_SIZE to be uncommon, in fact geli warns when that is the > > case. I probably should've made that clearer in the commit message. > > Yes, I missed that you are checking devvp. ffs_getpages() also checks > devvp. > > So the bug has nothing to do with file system logical (fragment) or i/o > (block) block size's, except file systems themselves won't work unless > their i/o size is a multiple of the underlying devices (sector) i/o size. > > Are there physical disk with sector size > PAGE_SIZE now? I have been told that there are some sd/flash devices that have a 16k physical sector size, I have not been able to confirm that information though. > It is easy to > create virtual (md) disks with sector size > PAGE_SIZE, and this may even > be useful for avoiding the related problem of having to access large fs > blocks to do i/o to small md sectors. I think it is best to use PAGE_SIZE > blocks in all layers and sometimes combine these into clusters. > > Bruce -- Rod Grimes rgri...@freebsd.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344562 - head/sys/ufs/ffs
On Mon, 25 Feb 2019, Jason Harmening wrote: On 2/25/19 9:46 PM, Bruce Evans wrote: block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with large pages.?? MINBSIZE is 4096 in ffs (except in my version, it is 512).?? The default is 32768 in newfs.?? I consider this excessive and only use it for file systems with many files larger than 1GB, but it is the most common size. It is larger than the large page size of 8192. I think this is a case of filesystem logical block size vs. media sector size, right? Here we're checking the devvp's block size, which I think should correspond to the sector size. I'd expect cases of that being greater than PAGE_SIZE to be uncommon, in fact geli warns when that is the case. I probably should've made that clearer in the commit message. Yes, I missed that you are checking devvp. ffs_getpages() also checks devvp. So the bug has nothing to do with file system logical (fragment) or i/o (block) block size's, except file systems themselves won't work unless their i/o size is a multiple of the underlying devices (sector) i/o size. Are there physical disk with sector size > PAGE_SIZE now? It is easy to create virtual (md) disks with sector size > PAGE_SIZE, and this may even be useful for avoiding the related problem of having to access large fs blocks to do i/o to small md sectors. I think it is best to use PAGE_SIZE blocks in all layers and sometimes combine these into clusters. Bruce___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344562 - head/sys/ufs/ffs
On 2/25/19 9:46 PM, Bruce Evans wrote: block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with large pages. MINBSIZE is 4096 in ffs (except in my version, it is 512). The default is 32768 in newfs. I consider this excessive and only use it for file systems with many files larger than 1GB, but it is the most common size. It is larger than the large page size of 8192. I think this is a case of filesystem logical block size vs. media sector size, right? Here we're checking the devvp's block size, which I think should correspond to the sector size. I'd expect cases of that being greater than PAGE_SIZE to be uncommon, in fact geli warns when that is the case. I probably should've made that clearer in the commit message. ffs_getpages() already has an almost-never-used special case for small block sizes. It uses vnode_pager_generic_getpages() when !use_buf_pager and the block_size <= PAGE_SIZE, else vfs_bio_getpages(). But block_size <= PAGE_SIZE is unusual, and !use_buf_pager is also unusual, and use_buf_pager is mostly a debugging sysctl, so little would be lost but using vfs_bio_getpages() unconditionally. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r344562 - head/sys/ufs/ffs
On Tue, 26 Feb 2019, Jason A. Harmening wrote: ... Log: FFS: allow sendfile(2) to work with block sizes greater than the page size Implement ffs_getpages_async(), which when possible calls the asynchronous flavor of the generic pager's getpages function. When the underlying block size is larger than the system page size, however, it will invoke the (synchronous) buffer cache pager, followed by a call to the client completion routine. This retains true asynchronous completion in the most common (block size <= page size) case, which is important for the performance of the new sendfile(2). The behavior in the larger block size case mirrors the default implementation of VOP_GETPAGES_ASYNC, which most other filesystems use anyway as they do not override the getpages_async method. block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with large pages. MINBSIZE is 4096 in ffs (except in my version, it is 512). The default is 32768 in newfs. I consider this excessive and only use it for file systems with many files larger than 1GB, but it is the most common size. It is larger than the large page size of 8192. ffs_getpages() already has an almost-never-used special case for small block sizes. It uses vnode_pager_generic_getpages() when !use_buf_pager and the block_size <= PAGE_SIZE, else vfs_bio_getpages(). But block_size <= PAGE_SIZE is unusual, and !use_buf_pager is also unusual, and use_buf_pager is mostly a debugging sysctl, so little would be lost but using vfs_bio_getpages() unconditionally. Bruce ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r344562 - head/sys/ufs/ffs
Author: jah
Date: Tue Feb 26 04:56:10 2019
New Revision: 344562
URL: https://svnweb.freebsd.org/changeset/base/344562
Log:
FFS: allow sendfile(2) to work with block sizes greater than the page size
Implement ffs_getpages_async(), which when possible calls the asynchronous
flavor of the generic pager's getpages function. When the underlying
block size is larger than the system page size, however, it will invoke
the (synchronous) buffer cache pager, followed by a call to the client
completion routine. This retains true asynchronous completion in the most
common (block size <= page size) case, which is important for the performance
of the new sendfile(2). The behavior in the larger block size case mirrors
the default implementation of VOP_GETPAGES_ASYNC, which most other
filesystems use anyway as they do not override the getpages_async method.
PR: 235708
Reported by: pho
Reviewed by: kib, glebius
MFC after:2 weeks
Differential Revision:https://reviews.freebsd.org/D19340
Modified:
head/sys/ufs/ffs/ffs_vnops.c
Modified: head/sys/ufs/ffs/ffs_vnops.c
==
--- head/sys/ufs/ffs/ffs_vnops.cTue Feb 26 04:50:46 2019
(r344561)
+++ head/sys/ufs/ffs/ffs_vnops.cTue Feb 26 04:56:10 2019
(r344562)
@@ -111,6 +111,7 @@ extern int ffs_rawread(struct vnode *vp, struct uio *u
static vop_fdatasync_t ffs_fdatasync;
static vop_fsync_t ffs_fsync;
static vop_getpages_t ffs_getpages;
+static vop_getpages_async_tffs_getpages_async;
static vop_lock1_t ffs_lock;
static vop_read_t ffs_read;
static vop_write_t ffs_write;
@@ -132,7 +133,7 @@ struct vop_vector ffs_vnodeops1 = {
.vop_fsync =ffs_fsync,
.vop_fdatasync =ffs_fdatasync,
.vop_getpages = ffs_getpages,
- .vop_getpages_async = vnode_pager_local_getpages_async,
+ .vop_getpages_async = ffs_getpages_async,
.vop_lock1 =ffs_lock,
.vop_read = ffs_read,
.vop_reallocblks = ffs_reallocblks,
@@ -154,7 +155,7 @@ struct vop_vector ffs_vnodeops2 = {
.vop_fsync =ffs_fsync,
.vop_fdatasync =ffs_fdatasync,
.vop_getpages = ffs_getpages,
- .vop_getpages_async = vnode_pager_local_getpages_async,
+ .vop_getpages_async = ffs_getpages_async,
.vop_lock1 =ffs_lock,
.vop_read = ffs_read,
.vop_reallocblks = ffs_reallocblks,
@@ -1742,3 +1743,25 @@ ffs_getpages(struct vop_getpages_args *ap)
return (vfs_bio_getpages(vp, ap->a_m, ap->a_count, ap->a_rbehind,
ap->a_rahead, ffs_gbp_getblkno, ffs_gbp_getblksz));
}
+
+static int
+ffs_getpages_async(struct vop_getpages_async_args *ap)
+{
+ struct vnode *vp;
+ struct ufsmount *um;
+ int error;
+
+ vp = ap->a_vp;
+ um = VFSTOUFS(vp->v_mount);
+
+ if (um->um_devvp->v_bufobj.bo_bsize <= PAGE_SIZE)
+ return (vnode_pager_generic_getpages(vp, ap->a_m, ap->a_count,
+ ap->a_rbehind, ap->a_rahead, ap->a_iodone, ap->a_arg));
+
+ error = vfs_bio_getpages(vp, ap->a_m, ap->a_count, ap->a_rbehind,
+ ap->a_rahead, ffs_gbp_getblkno, ffs_gbp_getblksz);
+ ap->a_iodone(ap->a_arg, ap->a_m, ap->a_count, error);
+
+ return (error);
+}
+
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
