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>] [day] [month] [year] [list]
Date:	Wed, 6 Feb 2013 15:31:32 +0900
From:	Namjae Jeon <linkinjeon@...il.com>
To:	lsf-pc@...ts.linux-foundation.org
Cc:	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Nam-Jae Jeon <namjae.jeon@...sung.com>,
	Amit Sahrawat <a.sahrawat@...sung.com>,
	Jaegeuk Kim <jaegeuk.kim@...sung.com>
Subject: [LSF/MM TOPIC] f2fs: Dynamic Control of GC Thread at User Level and
 Stabilizing sudden eject behavior for SD Cards.

Hello.

I am considering the following subjects on f2fs. I'm not sure if it is
proper TOPIC.
Let me know opinions :)

1. Dynamic Control of GC Thread at User Level.
To cope with rapid increase in number of smart phone users and
increasing demands for different media application with Quality Of
Service (QoS) interaction on such devices,
it is becoming imperative to provide the necessary support at the
underlying filesystem layer also.
Currently, when we consider the Garbage collection behavior and its
execution period overlapping with the normal I/O - while garbage
collection is in progress it results in blocking the normal I/O Path,
i.e.,
it provides a sense of unresponsiveness to the user and could also
potentially feel like a hung state in the worst cases, resulting in
hard-reboot from the user.
So, in order to improve upon this behavior. We can introduce the
“dynamic control” concept for the Garbage collection.
It will allow the user to check the status of garbage at any time and
in-turn will also allow user to run the GC from the user interface.
It can be similar to the concept of checking the fragmentation level
of filesystem and running defragmentation and showing status
dynamically.
For a specific scenario we can have an example like this: When
Application is recording Video data on some storage device or showing
screen by decoding (TV) or may be the device is switching to idle
mode.
In such cases Application will have the intelligence that there is no
access to F2Fs partition at such intervals, and which partitions are
not used on such times. In such intervals if the Application user can
control the GC thread,
it will allows the F2FS partition be ready in advance and normal I/O
can run properly without any intervention from the GC thread.

2. Stabilizing sudden eject behavior for SD Cards
As a continuation to the usage of smart phone and related devices, the
trend is that the usage of SD cards on mobile devices in on increase.
It is a great challenge to have the content on SD cards intact as well
keep the system stable while using SD cards.
Currently, when F2FS formatted SD card is connected to the device and
I/O is in progress- there are several code paths in the F2FS
filesystem which tried to guarantee no failure for few routines.
But this results in abnormal situation, because initially F2FS design
did not take into account the sudden unplug behavior. As a result it
potentially left various paths which resulted in infinite looping even
in the case when the device is removed,
which in-turn actually results in hung state for the device as it is
not able to come out of the tight loop to handle other interrupts.
To combat such problem there is a need for redesign which allows both
guarantee for no failure in default routines and safe exit
routines/fallback path in case of unsafe device ejection.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ