Hiroyuki Machida <[EMAIL PROTECTED]> writes:
>>> - Utilize noop elevator to cancel unexpected operation reordering
>> Why don't you use the barrier?
>
> You mean that using requests with barrier flag is enough and there is
> no reason to specify IO-sched ?
>
> It is better to preserve order
Hi,
OGAWA Hirofumi wrote:
Hiroyuki Machida <[EMAIL PROTECTED]> writes:
We currently plan to add following features to address FAT corruption.
- Utilize standard 2.6 features as much as possible
- Implement as options of fat, vfat and uvfat
What is the uvfat? typo (xvfat)? Why
Hi,
I need to explain background information more. My descriptions tends
to be depend on some knowledge about current xvfat for 2.4 kernel.
I'm not a author of xvfat fo 2.4 kernel, but can explain little more.
Current xvfat for 2.4 is designed to some specific flash memory card
controller
Hi,
I need to explain background information more. My descriptions tends
to be depend on some knowledge about current xvfat for 2.4 kernel.
I'm not a author of xvfat fo 2.4 kernel, but can explain little more.
Current xvfat for 2.4 is designed to some specific flash memory card
controller
Hi,
OGAWA Hirofumi wrote:
Hiroyuki Machida [EMAIL PROTECTED] writes:
We currently plan to add following features to address FAT corruption.
- Utilize standard 2.6 features as much as possible
- Implement as options of fat, vfat and uvfat
What is the uvfat? typo (xvfat)? Why
Hiroyuki Machida [EMAIL PROTECTED] writes:
- Utilize noop elevator to cancel unexpected operation reordering
Why don't you use the barrier?
You mean that using requests with barrier flag is enough and there is
no reason to specify IO-sched ?
It is better to preserve order of updating
Hi!
> >[...]
> > Q3 : I'm not sure JBD can be used for FAT improvements. Do you
> >have any comments ?
>
> I might not be the best person to answer this, but this just seems so
> obvious:
>
> If you plan to let a recently hot-unplugged device to be used in another
> OS that doesn't
On Tuesday 19 July 2005 19:58, Etienne Lorrain wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
>
> What I would like is to treat completely differently writing to
> FAT (writing to a removeable drive) which need a
On Tuesday 19 July 2005 19:58, Etienne Lorrain wrote:
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete
Hi!
[...]
Q3 : I'm not sure JBD can be used for FAT improvements. Do you
have any comments ?
I might not be the best person to answer this, but this just seems so
obvious:
If you plan to let a recently hot-unplugged device to be used in another
OS that doesn't understand your
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
> What I would like is to treat completely differently writing to
> FAT (writing to a removeable drive) which need a complete "mount",
>
> I'd like to have a discussion about FAT robustness.
> Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete "mount",
and just reading quickly a file (a standard use of
Hiroyuki Machida <[EMAIL PROTECTED]> writes:
> We currently plan to add following features to address FAT corruption.
>
> - Utilize standard 2.6 features as much as possible
> - Implement as options of fat, vfat and uvfat
What is the uvfat? typo (xvfat)? Why is this an option (does it
Hiroyuki Machida [EMAIL PROTECTED] writes:
We currently plan to add following features to address FAT corruption.
- Utilize standard 2.6 features as much as possible
- Implement as options of fat, vfat and uvfat
What is the uvfat? typo (xvfat)? Why is this an option (does it have
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete mount,
and just reading quickly a file (a standard use of
Etienne Lorrain [EMAIL PROTECTED] wrote:
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete mount,
and just
Hiroyuki Machida wrote:
[...]
Q3 : I'm not sure JBD can be used for FAT improvements. Do you
have any comments ?
I might not be the best person to answer this, but this just seems so
obvious:
If you plan to let a recently hot-unplugged device to be used in another
OS that doesn't
Hiroyuki Machida wrote:
[...]
Q3 : I'm not sure JBD can be used for FAT improvements. Do you
have any comments ?
I might not be the best person to answer this, but this just seems so
obvious:
If you plan to let a recently hot-unplugged device to be used in another
OS that doesn't
Folks,
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
About few years ago, we added some features to FAT, called xvfat,
so that System and FAT have robustness against unexpected media hot
unplug and ability to let applications
Folks,
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
About few years ago, we added some features to FAT, called xvfat,
so that System and FAT have robustness against unexpected media hot
unplug and ability to let applications
20 matches
Mail list logo