linux-ext4 - Re: [RFC] Heads up on sys

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <0DA8B217-DDD4-4E05-B000-DEBE3BE55B94@cam.ac.uk>
Date:	Sun, 4 Mar 2007 20:11:17 +0000
From:	Anton Altaparmakov <aia21@....ac.uk>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Amit K. Arora" <aarora@...ux.vnet.ibm.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-ext4@...r.kernel.org, suparna@...ibm.com, cmm@...ibm.com,
	alex@...sterfs.com, suzuki@...ibm.com,
	Ulrich Drepper <drepper@...hat.com>
Subject: Re: [RFC] Heads up on sys_fallocate()

On 3 Mar 2007, at 22:45, Arnd Bergmann wrote:
> On Friday 02 March 2007 00:38:19 Christoph Hellwig wrote:
>>> Forgive me if I haven't put enough thought into it, but would it be
>>> useful to create a generic_fallocate() that writes zeroed pages  
>>> for any
>>> non-existent pages in the range?  I don't know how glibc currently
>>> implements posix_fallocate(), but maybe the kernel could do it more
>>> efficiently, even in generic code.  Maybe we don't care, since  
>>> the major
>>> file systems can probably do something better in their own code.
>>
>> I'd be more happy to have the write out zeroes loop in glibc.  And
>> glibc needs to have it anyway, for older kernels.
>
> A generic_fallocate makes sense to me iff we can do it in the kernel
> more significantly more efficiently than in glibc, e.g. by using only
> a single page in page cache instead of one for each page to be  
> preallocated.
>
> If  glibc is smart enough to do an optimal implementation, I fully  
> agree
> with you.

glibc cannot ever be smart enough because a file system driver will  
always know better and be able to do things in a much more optimized  
way.

For example on NTFS fallocate() only needs to involve the setting of  
a few bits in the volume block allocation bitmap (one bit for each  
logical block being allocated) and update the extent map in the on- 
disk inode to reflect that those blocks are now allocated to the  
inode.  Then it just needs to update the allocated size and  
optionally the data size (if fallocate wants to increase the file  
size rather than just the allocated size).  And that is it.  No  
zeroing needs to happen at all because we have not updated the  
initialized size of the inode!

glibc can only dream of an implementation like this.  (-;

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer, http://www.linux-ntfs.org/


-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html