search for: falloc_fl_no_hide_stale

Displaying 7 results from an estimated 7 matches for "falloc_fl_no_hide_stale".

2018 Jul 28
1
Re: [PATCH] file: Fix zero/trim with block device
...kernels support > FALLOC_FL_ZERO_RANGE on block devices, in a manner that leaves the > pages marked allocated (that is, no discard happens). The kernel > also supports FALLOC_FL_PUNCH_HOLE to guarantee a read-zeroes result > (using discard, if that works), and > FALLOC_FL_PUNCH_HOLE|FALLOC_FL_NO_HIDE_STALE (which only discards, > and no longer guarantees a read-zeroes result). But you are also > right that in all cases, the errno returned when the operation > cannot be supported is not always EOPNOSUPP. > > > > >Treat this error as EOPNOSUPP. > > > >Tested only o...
2018 Jul 27
4
[PATCH] file: Fix zero/trim with block device
When using block device on RHEL 7.5, file plugin fails to zero with this error (copied from strace): [pid 39551] fallocate(8, FALLOC_FL_ZERO_RANGE, 1536, 64000) = -1 ENODEV (No such device) This is expected error according to the manual: ENODEV fd does not refer to a regular file or a directory. (If fd is a pipe or FIFO, a different error results.) Treat this error as EOPNOSUPP. Tested only
2018 Jul 27
0
Re: [PATCH] file: Fix zero/trim with block device
...is out-of-date; newer kernels support FALLOC_FL_ZERO_RANGE on block devices, in a manner that leaves the pages marked allocated (that is, no discard happens). The kernel also supports FALLOC_FL_PUNCH_HOLE to guarantee a read-zeroes result (using discard, if that works), and FALLOC_FL_PUNCH_HOLE|FALLOC_FL_NO_HIDE_STALE (which only discards, and no longer guarantees a read-zeroes result). But you are also right that in all cases, the errno returned when the operation cannot be supported is not always EOPNOSUPP. > > Treat this error as EOPNOSUPP. > > Tested only on Fedora 28; I don't know how...
2018 Aug 02
2
Re: [PATCH 1/3] file: Avoid unsupported fallocate() calls
...> - int r = -1; > #ifdef FALLOC_FL_PUNCH_HOLE > struct handle *h = handle; > + int r = -1; > + > + if (h->can_punch_hole) { > + r = do_fallocate (h->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > + offset, count); Should we also use FALLOC_FL_NO_HIDE_STALE here, if it is available? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
2018 Aug 02
0
Re: [PATCH 1/3] file: Avoid unsupported fallocate() calls
...C_FL_PUNCH_HOLE > > struct handle *h = handle; > > + int r = -1; > > + > > + if (h->can_punch_hole) { > > + r = do_fallocate (h->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE, > > + offset, count); > > Should we also use FALLOC_FL_NO_HIDE_STALE here, if it is available? > We can add h->can_leave_stale, and use it if available. But I don't think it will give much with typical request size. Do you think it worth the effort? Nir
2018 Aug 03
10
[PATCH v2 0/4] file: Zero for block devices and older file systems
...ing bitwise math. - For BLKZEROOUT, treat ENOTTY as EOPNOTSUPP. Theoretically possible with a mix of new headers and old or strangely configured kernel. - Use default multi line comment style. - Fix few typos in comments and commit message Issues to explore later: - Eric suggested to use the new FALLOC_FL_NO_HIDE_STALE. Requires benchmarking with a system supporting this flag. - Eric suggested to use tri-state for can_* flags. I don't see a need at this point. - Eric suggested to add can_zero. I'm not sure about the semantics of this, and it has the same issue of can_trim, reporting dynamic value....
2018 Aug 02
10
[PATCH 0/3] file: Zero for block devices and older file systems
This is the second version to support efficient zero for block devices on older kernels (e.g. RHEL 7.5), and file systems that do not support yet FALLOC_FS_ZERO_RANGE (e.g. NFS 4.2). Changes since v1: - Split to smaller patches - Skip linux only includes on other systems - Skip code using BLKZEROOUT if the macro is not defined - Try BLKZEROOUT only if the offset and count are aligned to device