2013/2/18 OGAWA Hirofumi :
> Namjae Jeon writes:
>
>>> Hm. My concerns are compatibility and reliability. Although We can
>>> change on-disk format if need, but I don't think it can be compatible
>>> and reliable. If so, who wants to use it? I feel there is no reason to
>>> use FAT if there is no
Namjae Jeon writes:
>> Hm. My concerns are compatibility and reliability. Although We can
>> change on-disk format if need, but I don't think it can be compatible
>> and reliable. If so, who wants to use it? I feel there is no reason to
>> use FAT if there is no compatible.
>>
>> Well, anyway,
2013/2/18 OGAWA Hirofumi :
> Andrew Bartlett writes:
>
>>> >> First, Thanks for your interest !
>>> >> A mismatch between inode size and reserved blocks can be either due to
>>> >> pre-allocation (after our changes) or due to corruption (sudden unplug
>>> >> of media etc).
>>> >> We don’t think
On Mon, 2013-02-18 at 20:36 +0900, OGAWA Hirofumi wrote:
> Andrew Bartlett writes:
> > Or, if we cannot make any changes to the on-disk format, what about
> > keeping such a database in memory, allocating some of the existing free
> > list to files that have had fallocate() called on them?
Andrew Bartlett writes:
>> >> First, Thanks for your interest !
>> >> A mismatch between inode size and reserved blocks can be either due to
>> >> pre-allocation (after our changes) or due to corruption (sudden unplug
>> >> of media etc).
>> >> We don’t think it is right to include only read
On Mon, 2013-02-18 at 20:36 +0900, OGAWA Hirofumi wrote:
Andrew Bartlett abart...@samba.org writes:
Or, if we cannot make any changes to the on-disk format, what about
keeping such a database in memory, allocating some of the existing free
list to files that have had fallocate() called on
2013/2/18 OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Andrew Bartlett abart...@samba.org writes:
First, Thanks for your interest !
A mismatch between inode size and reserved blocks can be either due to
pre-allocation (after our changes) or due to corruption (sudden unplug
of media etc).
Namjae Jeon linkinj...@gmail.com writes:
Hm. My concerns are compatibility and reliability. Although We can
change on-disk format if need, but I don't think it can be compatible
and reliable. If so, who wants to use it? I feel there is no reason to
use FAT if there is no compatible.
Well,
2013/2/18 OGAWA Hirofumi hirof...@mail.parknet.co.jp:
Namjae Jeon linkinj...@gmail.com writes:
Hm. My concerns are compatibility and reliability. Although We can
change on-disk format if need, but I don't think it can be compatible
and reliable. If so, who wants to use it? I feel there is no
On Thu, 2013-02-14 at 18:52 +0900, Namjae Jeon wrote:
> [snip]
> >> >
> >> > Thanks,
> >> Hi Andrew.
> >>
> >> First, Thanks for your interest !
> >> A mismatch between inode size and reserved blocks can be either due to
> >> pre-allocation (after our changes) or due to corruption (sudden unplug
>
[snip]
>> >
>> > Thanks,
>> Hi Andrew.
>>
>> First, Thanks for your interest !
>> A mismatch between inode size and reserved blocks can be either due to
>> pre-allocation (after our changes) or due to corruption (sudden unplug
>> of media etc).
>> We don’t think it is right to include only read
[snip]
Thanks,
Hi Andrew.
First, Thanks for your interest !
A mismatch between inode size and reserved blocks can be either due to
pre-allocation (after our changes) or due to corruption (sudden unplug
of media etc).
We don’t think it is right to include only read only support (i.e.
On Thu, 2013-02-14 at 18:52 +0900, Namjae Jeon wrote:
[snip]
Thanks,
Hi Andrew.
First, Thanks for your interest !
A mismatch between inode size and reserved blocks can be either due to
pre-allocation (after our changes) or due to corruption (sudden unplug
of media etc).
We
On Thu, 2013-02-14 at 15:44 +0900, Namjae Jeon wrote:
> 2013/2/14, Andrew Bartlett :
> > (apologies for the duplicate mail, I typo-ed the maintainers address)
> >
> > G'day,
> >
> > I've been looking into the patch "[v2] fat: editions to support
> > fat_fallocate()" and I wonder if there is a way
2013/2/14, Andrew Bartlett :
> (apologies for the duplicate mail, I typo-ed the maintainers address)
>
> G'day,
>
> I've been looking into the patch "[v2] fat: editions to support
> fat_fallocate()" and I wonder if there is a way we can split this issue
> in two, so that we get at least some of
(apologies for the duplicate mail, I typo-ed the maintainers address)
G'day,
I've been looking into the patch "[v2] fat: editions to support
fat_fallocate()" and I wonder if there is a way we can split this issue
in two, so that we get at least some of the patch into the kernel.
G'day,
I've been looking into the patch "[v2] fat: editions to support
fat_fallocate()" and I wonder if there is a way we can split this issue
in two, so that we get at least some of the patch into the kernel.
https://lkml.org/lkml/2012/10/13/75
https://patchwork.kernel.org/patch/1589161/
What
G'day,
I've been looking into the patch [v2] fat: editions to support
fat_fallocate() and I wonder if there is a way we can split this issue
in two, so that we get at least some of the patch into the kernel.
https://lkml.org/lkml/2012/10/13/75
https://patchwork.kernel.org/patch/1589161/
What
(apologies for the duplicate mail, I typo-ed the maintainers address)
G'day,
I've been looking into the patch [v2] fat: editions to support
fat_fallocate() and I wonder if there is a way we can split this issue
in two, so that we get at least some of the patch into the kernel.
2013/2/14, Andrew Bartlett abart...@samba.org:
(apologies for the duplicate mail, I typo-ed the maintainers address)
G'day,
I've been looking into the patch [v2] fat: editions to support
fat_fallocate() and I wonder if there is a way we can split this issue
in two, so that we get at least
On Thu, 2013-02-14 at 15:44 +0900, Namjae Jeon wrote:
2013/2/14, Andrew Bartlett abart...@samba.org:
(apologies for the duplicate mail, I typo-ed the maintainers address)
G'day,
I've been looking into the patch [v2] fat: editions to support
fat_fallocate() and I wonder if there is a
21 matches
Mail list logo
