Re: posix_fallocate behavior in glibc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 30, 2024 at 07:03:50PM +0200, Florian Weimer wrote:
> > The only relevant exception is probably ext4 in ext2/ext3 mode, where
> > the latter might still have users left running real workloads on it
> > and not using it for usb disks or VM images.
> 
> Why doesn't the kernel perform allocation in these cases?  There doesn't
> seem to be a file-system-specific reason why it's impossible to do.

Because in general it's a really stupid idea.  You don't get a better
allocation patter, but you are writing every block twice, making things
significantly slower and wearing the device out in the process if it
is flash based.

> At the very least, we should have a variant of ftruncate that never
> truncates, likely under the fallocate umbrella.  It seems that that's
> how posix_fallocate is used sometimes, for avoiding SIGBUS with mmap.
> To these use cases, whether extents are allocated or not does not
> matter.

I don't see how that is related.

> If we removed the fallback code from glibc today, it would just be
> EOPNOTSUPP that leaks to applications, so it's structurally the same
> issue.

Not really.  EOPNOTSUPP is a valid error code, that has historically
been returned by other operating systems and even other libc
implementations for Linux





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux