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:	Tue, 16 Oct 2012 13:12:56 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Ravishankar N <cyberax82@...il.com>,
	Amit Sahrawat <amit.sahrawat83@...il.com>
Subject: Re: [PATCH v2] fat: editions to support fat_fallocate()

2012/10/15 OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>:
> Namjae Jeon <linkinjeon@...il.com> writes:
>
>> Implement preallocation via the fallocate syscall on VFAT partitions.
>> This patch is based on an earlier patch of the same name which had some
>> issues detailed below and did not get accepted. Refer
>> https://lkml.org/lkml/2007/12/22/130.
>>
>> a)The preallocated space was not persistent across remounts when the
>> FALLOC_FL_KEEP_SIZE flag was set. Also, writes to the file allocated new
>> clusters instead of using the preallocated area.
>>
>> Consider the scenario:
>> mount-->preallocate space for a file --> unmount.
>> In the old patch,the preallocated space was not reflected for that
>> file (verified using the 'du' command).
>>
>> This is now fixed with modifications to fat_fill_inode().
>
When we consider other filesystems like XFS and ext4,  the space which
is preallocated is reserved for the life-time of that file which is
persistent across(mount/umount).
So, we tried to make this as similar to the existent solution - as
that would keep the meaning of FALLOCATE - WITH_KEEP_SIZE as same
across all filesystems.

> What is real usage pattern of persistent across remounts on FAT?
Yes,  like a TORRENT FILE -> it reserves space in advance
even though the system can be rebooted/disk unmounted and remount
but the space still remains there - as long as the torrent exists
Or if Torrent case does not matches currently
Then, Consider a case for a TV series to be recorded
Since – we want all the parts to be recorded on the same file (i.e.,
APPEND write) – and in such cases there are chances of TV shutdown,
device unmount-mount again. So, we need to have the space to be remain
available in such cases.

> If once device was unmounted, we can't know the state of FS anymore, there are
> many implementations of FAT. And preallocation is not in the spec.
I agree, As you said before, we can make fat fallocate feature as
configurable – so this is entirely in the hands of USER.
>
> I worry to break something. And I guess the freeing preallocation on
> last close may fix the issue for usage.
Okay, we can avoid most of your concerns except suddenly unplugging usb device.
But fallocate behavior will be different with other filesystem.

How about to make fat fallocate with configuration to be used by users
is having needs?

Let me know your opinion :)

Thanks.
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/