linux-kernel - Re: [PATCH 11/16] f2fs: add inode operations for special inodes

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 for Android: free password hash cracker in your pocket

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

Date:	Sun, 14 Oct 2012 16:06:54 +0400
From:	Vyacheslav Dubeyko <slava@...eyko.com>
To:	Jaegeuk Kim <jaegeuk.kim@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	김재극 <jaegeuk.kim@...sung.com>,
	viro@...iv.linux.org.uk, 'Theodore Ts'o' <tytso@....edu>,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	chur.lee@...sung.com, cm224.lee@...sung.com,
	jooyoung.hwang@...sung.com
Subject: Re: [PATCH 11/16] f2fs: add inode operations for special inodes


On Oct 14, 2012, at 11:09 AM, Jaegeuk Kim wrote:

> 2012-10-14 (일), 02:21 +0400, Vyacheslav Dubeyko:
>> On Oct 14, 2012, at 12:52 AM, Arnd Bergmann wrote:
>> 
>>> On Friday 05 October 2012, 김재극 wrote:
>>>> +const char *media_ext_lists[] = {
>>>> +       "jpg",
>>>> +       "gif",
>>>> +       "png",
>>>> +       "avi",
>>>> +       "divx",
>>>> +       "mp4",
>>>> +       "mp3",
>>>> ...
>>> 
>>>> + * Set multimedia files as cold files for hot/cold data separation
>>>> + */
>>>> +static inline void set_cold_file(struct inode *inode, const unsigned char *name)
>>>> +{
>>>> +       const char **extlist = media_ext_lists;
>>>> +
>>>> +       while (*extlist) {
>>>> +               if (!is_multimedia_file(name, *extlist)) {
>>>> +                       F2FS_I(inode)->is_cold = 1;
>>>> +                       break;
>>>> +               }
>>>> +               extlist++;
>>>> +       }
>>>> +}
>>> 
>>> This is a very clever way of categorizing files by their name, but I wonder if hardcoding
>>> the list of file name extensions at in the kernel source is the best strategy. Generally
>>> I would consider this to be a policy that should be configurable by the user.
>>> 
>>> Unfortunately I can't think of a good interface to configure this, but maybe someone
>>> else has a useful idea. Maybe the list can be stored in the superblock and get written
>>> at mkfs time from the same defaults, but with the option of overriding it using
>>> a debugfs tool.
>>> 
>> 
>> By the way, how about extended attributes? It is possible to save in extended attribute a hint about file's content nature during creation operation or later. Moreover, extended attribute gives possibility to change hint after renaming operation, for example.
>> 
> 
> I think xattr is not a proper way to communicate between file system and
> users.

I don't understand why you think that xattr is not proper way. Extended attributes are the way of adding some additional properties to filesystem object, from my point of view.

> How about fadvise()?
> 

The fadvise() is a good suggestion. But, as I can understand, such solution requires using fadvise() during application implementation. So, from one point of view, it exists many applications that doesn't use fadvise() and, from another point of view, developers change style of coding not so easy.

Extended attributes are more flexible way, from my point of view. The xattr gives possibility to make hint to filesystem at any time and without any dependencies with application's functional opportunities. Documented way of using such extended attributes gives to user flexible way of manipulation of filesystem behavior (but I remember that you don't believe in an user :-)).

So, I think that fadvise() and extended attributes can be complementary solutions.

Anyway, hardcoding or saving in filesystem list of file extensions is a nasty way. It can be not safe or hardly understandable by users the way of reconfiguration filesystem by means of tunefs or debugfs with the purpose of file extensions addition in such "black-box" as TV or smartphones, from my point of view.

With the best regards,
Vyacheslav Dubeyko.

>> With the best regards,
>> Vyacheslav Dubeyko.
>> 
>>> 	Arnd
>>> --
>>> 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/
>> 
>> --
>> 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/
> 
> -- 
> Jaegeuk Kim
> Samsung
> 
> --
> 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/

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