linux-kernel - Re: [PATCH v2] fat: editions to support fat

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]

Date:	Mon, 22 Oct 2012 08:54:19 +0900
From:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
To:	Namjae Jeon <linkinjeon@...il.com>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Ravishankar N <cyberax82@...il.com>,
	Amit Sahrawat <amit.sahrawat83@...il.com>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH v2] fat: editions to support fat_fallocate()

Namjae Jeon <linkinjeon@...il.com> writes:

>> The expectation of fallocate() is just for space reservation? If it was
>> just for space reservation, I'm not sure, why TV applications can't
>> reserve in userland without any kernel help (I wonder who interrupts TV
>> application). I feel a bit, it may be more lightweight than fallocate(),
>> and more reliable than out of spec fallocate().
>>
>> I'm still not sure why apps really want fallocate() on FAT.
> Yes, it is for user space reservation.
>
>>>From the application perspective it is needed to realize in advance
> how much space is needed for that file write – so the requirement is
> precisely that the space reserved is entirely for me and no other I/O
> operation in that time should consume the space.
>
> Of course, as you said, space can be pre-allocated from user space by
> doing expanding truncate.
> Main drawbacks for reserving through USER space:
> 1) If we need to allocate 1GB space -> seek (1GB) and write -> it will
> ZEROUT the 1GB area (which is very time consuming) just for reserving
> space.
> 2) The Application must always be aware of the SEEK OFFSET - otherwise
> the APPEND WRITE will never occur and file is closed/opened (Append
> mode) again for writing – it will instead start writing from the end
> of file which is past the reserved space. So, this will also result in
> losing space in such case – if application is not keeping track of
> OFFSET
> 3) If suppose from user space we are doing expanding truncate of 1GB
> and suppose it fails after 256MB of allocation - in that case it did
> allocation of 256MB blocks - did ZEROUT for all these blocks and then
> returned failure - which is not optimal for just allocation of space.
>
> While if we make use of FALLOCATE
> 1)	It allows reserving the space in advance without any delay.
> 2)	Since, the space is reserved in advance. So, if suppose space is
> reserved for 1hour TV recording than any other application in the
> background cannot cause recording to fail in case of “no free space”
> left as it already pre-allocated space. Only other Applications will
> close.
> 3)	It allows for APPEND write to continue smoothly without actually
> keeping track of the file state, offset.
> 4)	Initially when the disk is not fragmented. It allows the
> possibility to get contiguous blocks and thus reducing fragmentation
> for that file.

OK.

Should TV recorder make sure it is reserving space with fallocate() for
each open() (or first open() after mount())? What fsck is going to do?
Or how to know fallocated space or corrupted space?

Does this break the linux fat driver doesn't know about this
fallocate()?  If so, it sounds like to be easy to break existent
drivers.

Thanks.
-- 
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/