On 07/26/2018 10:23 AM, Eric Blake wrote:
Hmm - that thread also mentions FALLOC_FL_NO_HIDE_STALE, which is a new
flag not present/documented on Fedora 28. I wonder if it helps, too.
Even more odd - that flag has been proposed to the kernel since 2012 but
still not mentioned in the F28 man
Am 26.07.2018 um 19:34 hat Nir Soffer geschrieben:
> On Thu, Jul 26, 2018 at 7:58 PM Kevin Wolf wrote:
> > Am 26.07.2018 um 18:46 hat Nir Soffer geschrieben:
> > > I don't think we should depend on undocumented kernel code.
> >
> > Yes, the man page says "filesystem blocks" instead of just
On 07/26/2018 12:34 PM, Nir Soffer wrote:
Anyway this looks the same level of documentation as FALLOC_FL_ZERO_RANGE,
so if we are ok with using it, FALLOC_FL_PUNCH_HOLE is fine.
Does this change mean that oVirt can start to enable discard for VM when
disks are using wipe-after-delete?
On Thu, Jul 26, 2018 at 7:58 PM Kevin Wolf wrote:
> Am 26.07.2018 um 18:46 hat Nir Soffer geschrieben:
> > On Thu, Jul 26, 2018 at 7:10 PM Eric Blake wrote:
> >
> > > On 07/26/2018 10:33 AM, Kevin Wolf wrote:
> > >
> > > >
> > > > As far as I know, the comment you quoted is accurate for
Am 26.07.2018 um 18:46 hat Nir Soffer geschrieben:
> On Thu, Jul 26, 2018 at 7:10 PM Eric Blake wrote:
>
> > On 07/26/2018 10:33 AM, Kevin Wolf wrote:
> >
> > >
> > > As far as I know, the comment you quoted is accurate for BLKDISCARD and
> > > BLKZEROOUT, but not for the fallocate() flags.
> >
On Thu, Jul 26, 2018 at 7:10 PM Eric Blake wrote:
> On 07/26/2018 10:33 AM, Kevin Wolf wrote:
>
> >
> > As far as I know, the comment you quoted is accurate for BLKDISCARD and
> > BLKZEROOUT, but not for the fallocate() flags.
> >
>
> I sure wish the man pages were more explicit on what
On 07/26/2018 10:33 AM, Kevin Wolf wrote:
As far as I know, the comment you quoted is accurate for BLKDISCARD and
BLKZEROOUT, but not for the fallocate() flags.
I sure wish the man pages were more explicit on what guarantees each
flag offers.
Hmm - that thread also mentions
Am 26.07.2018 um 17:23 hat Eric Blake geschrieben:
> On 07/26/2018 10:06 AM, Kevin Wolf wrote:
>
> > > > +#ifdef CONFIG_FALLOCATE_PUNCH_HOLE
> > > > +ret = do_fallocate(s->fd, FALLOC_FL_PUNCH_HOLE |
> > > > FALLOC_FL_KEEP_SIZE,
> > > > + aiocb->aio_offset,
On 07/26/2018 10:06 AM, Kevin Wolf wrote:
+#ifdef CONFIG_FALLOCATE_PUNCH_HOLE
+ret = do_fallocate(s->fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
+ aiocb->aio_offset, aiocb->aio_nbytes);
Umm, doesn't this have to use FALLOC_FL_ZERO_RANGE? FALLOC_FL_PUNCH_HOLE
Am 26.07.2018 um 16:28 hat Eric Blake geschrieben:
> On 07/26/2018 06:33 AM, Kevin Wolf wrote:
> > The BLKDISCARD ioctl doesn't guarantee that the discarded blocks read as
> > all-zero afterwards, so don't try to abuse it for zero writing. We try
> > to only use this if BLKDISCARDZEROES tells us
On 07/26/2018 06:33 AM, Kevin Wolf wrote:
The BLKDISCARD ioctl doesn't guarantee that the discarded blocks read as
all-zero afterwards, so don't try to abuse it for zero writing. We try
to only use this if BLKDISCARDZEROES tells us that it is safe, but this
is unreliable on older kernels and a
The BLKDISCARD ioctl doesn't guarantee that the discarded blocks read as
all-zero afterwards, so don't try to abuse it for zero writing. We try
to only use this if BLKDISCARDZEROES tells us that it is safe, but this
is unreliable on older kernels and a constant 0 in newer kernels. In
other words,
12 matches
Mail list logo
