On Wed, May 23, 2007 at 05:14:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> > > I'm just a German. Forgive me if I drink lesser beverages.
> >
> > You should definitely change that.
>
> Change being German? Not a bad idea, actually.
You cook up really tasty shnaps, in small quantities
On Wed, 23 May 2007 19:07:32 +0400, Evgeniy Polyakov wrote:
> On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED])
> wrote:
> > On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
>
> And what if it is 33 bits? Or it is not allowed?
Not allowed. Both number and size
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
> >
> > In that case segment size must be more than 32 bits, or below
> > transformation will not be correct?
>
> Must it? If segment size is just 20bit
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
>
> In that case segment size must be more than 32 bits, or below
> transformation will not be correct?
Must it? If segment size is just 20bit then the filesystem may only be
52bit. Or 51bit when using signed values.
> segsize is
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
In that case segment size must be more than 32 bits, or below
transformation will not be correct?
Must it? If segment size is just 20bit then the filesystem may only be
52bit. Or 51bit when using signed values.
segsize is long,
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
In that case segment size must be more than 32 bits, or below
transformation will not be correct?
Must it? If segment size is just 20bit then the
On Wed, 23 May 2007 19:07:32 +0400, Evgeniy Polyakov wrote:
On Wed, May 23, 2007 at 02:58:41PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
On Sun, 20 May 2007 21:30:52 +0400, Evgeniy Polyakov wrote:
And what if it is 33 bits? Or it is not allowed?
Not allowed. Both number and size of
On Wed, May 23, 2007 at 05:14:04PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
I'm just a German. Forgive me if I drink lesser beverages.
You should definitely change that.
Change being German? Not a bad idea, actually.
You cook up really tasty shnaps, in small quantities it is good
On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
> On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
> >
> > Is logfs 32bit fs or 674bit, since although you use 64bit values for
> > offsets, area management and strange converstions like described below
>
On Thu, May 17, 2007 at 07:10:19PM +0200, Jörn Engel ([EMAIL PROTECTED]) wrote:
On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from
On Saturday 19 May 2007 5:24 am, Jan Engelhardt wrote:
>
> On May 19 2007 02:15, Rob Landley wrote:
> >> > +
> >> > +static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
> >> > +{
> >> > +return container_of(inode, struct logfs_inode, vfs_inode);
> >> > +}
> >>
> >> Do
On Sat, May 19, 2007 at 05:17:32PM +0100, Jamie Lokier ([EMAIL PROTECTED])
wrote:
> > So, log2fs... Sounds great to me.
>
> Why Log2? Logarithmic scaling is just logarithmic scaling. Does the
> filesystem use 2-ary trees or anything else which gives particular
> meaning to 2?
Sizes used in
David Weinehall wrote:
> > It is also the filesystem that tries to scale logarithmically, as Arnd
> > has noted. Maybe I should call it Log2 to emphesize this point. Log1
> > would be horrible scalability.
>
> So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just
Dongjun Shin wrote:
There are so many flash-based storage and some disposable storages,
as you pointed out, have poor quality. I think it's mainly because these
are not designed for good quality, but for lowering the price.
The reliability seems to be appropriate to the common use. I'm
On Wed, May 16, 2007 at 03:53:19PM +0200, Jörn Engel wrote:
> On Wed, 16 May 2007 09:41:10 -0400, John Stoffel wrote:
> > Jörn> On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
> >
> > Jörn> How many of you have worked for IBM before? Vowels are not
> > evil. ;)
> >
> > Nope, they're
Kevin Bowling wrote:
On 5/16/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
>
> My experience is that no matter which name I pick, people will
> complain
> anyway. Previous suggestions included:
> jffs3
> jefs
> engelfs
> poofs
> crapfs
>
On May 19 2007 02:15, Rob Landley wrote:
>> > +
>> > +static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
>> > +{
>> > + return container_of(inode, struct logfs_inode, vfs_inode);
>> > +}
>>
>> Do these need to be uppercase?
>
>I'm trying to keep it clear in my head...
>
>When do
On Tuesday 15 May 2007 4:37 pm, Andrew Morton wrote:
> > +static inline struct logfs_super *LOGFS_SUPER(struct super_block *sb)
> > +{
> > + return sb->s_fs_info;
> > +}
> > +
> > +static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
> > +{
> > + return container_of(inode,
On Tuesday 15 May 2007 4:37 pm, Andrew Morton wrote:
+static inline struct logfs_super *LOGFS_SUPER(struct super_block *sb)
+{
+ return sb-s_fs_info;
+}
+
+static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
+{
+ return container_of(inode, struct logfs_inode,
On May 19 2007 02:15, Rob Landley wrote:
+
+static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
+{
+ return container_of(inode, struct logfs_inode, vfs_inode);
+}
Do these need to be uppercase?
I'm trying to keep it clear in my head...
When do you need to say
Kevin Bowling wrote:
On 5/16/07, David Woodhouse [EMAIL PROTECTED] wrote:
On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
My experience is that no matter which name I pick, people will
complain
anyway. Previous suggestions included:
jffs3
jefs
engelfs
poofs
crapfs
sweetfs
On Wed, May 16, 2007 at 03:53:19PM +0200, Jörn Engel wrote:
On Wed, 16 May 2007 09:41:10 -0400, John Stoffel wrote:
Jörn On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
Jörn How many of you have worked for IBM before? Vowels are not
evil. ;)
Nope, they're not. I just
Dongjun Shin wrote:
There are so many flash-based storage and some disposable storages,
as you pointed out, have poor quality. I think it's mainly because these
are not designed for good quality, but for lowering the price.
The reliability seems to be appropriate to the common use. I'm
David Weinehall wrote:
It is also the filesystem that tries to scale logarithmically, as Arnd
has noted. Maybe I should call it Log2 to emphesize this point. Log1
would be horrible scalability.
So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just logarithmic
On Sat, May 19, 2007 at 05:17:32PM +0100, Jamie Lokier ([EMAIL PROTECTED])
wrote:
So, log2fs... Sounds great to me.
Why Log2? Logarithmic scaling is just logarithmic scaling. Does the
filesystem use 2-ary trees or anything else which gives particular
meaning to 2?
Sizes used in on-disk
On Saturday 19 May 2007 5:24 am, Jan Engelhardt wrote:
On May 19 2007 02:15, Rob Landley wrote:
+
+static inline struct logfs_inode *LOGFS_INODE(struct inode *inode)
+{
+return container_of(inode, struct logfs_inode, vfs_inode);
+}
Do these need to be uppercase?
On Fri, 2007-05-18 at 08:17 +0200, Jan Engelhardt wrote:
> > AFAIK, the camera stops writing to the flash card and automatically
> > turns off when it's low on battery (before empty).
>
> But then, one should also consider the case where a cam is connected to
> AC and someone inadvertently trips
On May 18 2007 09:01, Dongjun Shin wrote:
> On 5/18/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
>>
>> Hmm.. so operating your camera on batteries should be against the
>> warranty, since batteries commonly run empty while storing pictures?
>
> AFAIK, the camera stops writing to the flash card
On May 17 2007 21:00, Kyle Moffett wrote:
>> > > Opinions?
>> >
>> > Why would we need another btree, when there is lib/rbtree.c? Or does
>> > yours do something fundamentally different?
>>
>> It is not red-black tree, it is b+ tree.
>
> It might be better to use the prefix "bptree" to help
On May 17 2007 21:00, Kyle Moffett wrote:
Opinions?
Why would we need another btree, when there is lib/rbtree.c? Or does
yours do something fundamentally different?
It is not red-black tree, it is b+ tree.
It might be better to use the prefix bptree to help prevent confusion. A
On May 18 2007 09:01, Dongjun Shin wrote:
On 5/18/07, Pavel Machek [EMAIL PROTECTED] wrote:
Hmm.. so operating your camera on batteries should be against the
warranty, since batteries commonly run empty while storing pictures?
AFAIK, the camera stops writing to the flash card and
On Fri, 2007-05-18 at 08:17 +0200, Jan Engelhardt wrote:
AFAIK, the camera stops writing to the flash card and automatically
turns off when it's low on battery (before empty).
But then, one should also consider the case where a cam is connected to
AC and someone inadvertently trips on the
On May 17, 2007, at 13:45:33, Evgeniy Polyakov wrote:
On Thu, May 17, 2007 at 07:26:07PM +0200, Jan Engelhardt
([EMAIL PROTECTED]) wrote:
My plan was to move this code to lib/ sooner or later. If you
consider it useful in its current state, I can do it immediatly.
And if someone else
Hi,
On 5/18/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Hi!
Hmm.. so operating your camera on batteries should be against the
warranty, since batteries commonly run empty while storing pictures?
AFAIK, the camera stops writing to the flash card and automatically
turns off when it's low on
Jörn Engel wrote:
> > Almost all your static functions start with logfs_, why not this one?
>
> Because after a while I discovered how silly it is to start every
> function with logfs_. That prefix doesn't add much unless the function
> has global scope. What I didn't do was remove the prefix
On Thu, 17 May 2007 23:36:13 +0200, Arnd Bergmann wrote:
> On Thursday 17 May 2007, Pekka Enberg wrote:
> >
> > So any sane way to enable compression is on per-inode basis which makes
> > me still wonder why you need per-object compression.
>
> 1. it doesn't require user interaction, the file
On Thursday 17 May 2007, Pekka Enberg wrote:
>
> Jörn Engel wrote:
> > Compressing random data will actually enlarge it. If that happens I
> > simply store the verbatim uncompressed data instead and mark it as such.
> >
> > There is also demand for a user-controlled bit in the inode to disable
On Thu, 17 May 2007 23:00:20 +0200, Arnd Bergmann wrote:
>
> Just using nanoseconds probably doesn't gain you much after all
> then. You could however just have separate 32 bit fields in the
> inode for seconds and nanoseconds, that will result in the exact
> same layout that you have right now,
On Thursday 17 May 2007, Jörn Engel wrote:
>
> > Why not just store 64 bit nanoseconds? that would avoid the problem
> > with ns overflow and the year-2038 bug. OTOH, that would require
> > a 64 bit integer division when reading the data, so it gets you
> > a runtime overhead.
>
> I like the
Jörn Engel wrote:
Compressing random data will actually enlarge it. If that happens I
simply store the verbatim uncompressed data instead and mark it as such.
There is also demand for a user-controlled bit in the inode to disable
compression completely. All those .jpg, .mpg, .mp3, etc. just
Hi!
> >Yes. These things are almost always implemented _very_
> >badly by the same
> >kind of crack-smoking hobo they drag in off the streets
> >to write BIOSen.
> >
> >It's bog-roll technology; if you fancy a laugh try
> >doing some real
> >reliability tests on them time some. Powerfail
On Thu, 17 May 2007 17:08:51 +0200, Arnd Bergmann wrote:
> On Tuesday 15 May 2007, Jörn Engel wrote:
> > Add LogFS, a scalable flash filesystem.
>
> Sorry for not commenting earlier, there were so many discussions on version
> two that I wanted to wait for the fallout of that instead of
On Thu, May 17, 2007 at 07:26:07PM +0200, Jan Engelhardt ([EMAIL PROTECTED])
wrote:
> >My plan was to move this code to lib/ sooner or later. If you consider
> >it useful in its current state, I can do it immediatly. And if someone
> >else merged a superior btree library I'd happily remove mine
On May 16 2007 02:06, Jörn Engel wrote:
>
>> > +/* memtree.c */
>> > +void btree_init(struct btree_head *head);
>> > +void *btree_lookup(struct btree_head *head, long val);
>> > +int btree_insert(struct btree_head *head, long val, void *ptr);
>> > +int btree_remove(struct btree_head *head, long
On May 16 2007 15:53, Jörn Engel wrote:
>
>My experience is that no matter which name I pick, people will complain
>anyway. Previous suggestions included:
[...]
>
>Plus today:
>FFFS
>flashfs
>fredfs
>bob
>shizzle
>
>Imo they all suck. LogFS also sucks, but it allows me to make a stupid
>joke
On May 16 2007 22:06, CaT wrote:
>On Wed, May 16, 2007 at 01:50:03PM +0200, J??rn Engel wrote:
>> On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
>> >
>> > But if akpm can't pronounce it, how about FFFS for faster flash
>> > filesystem ;-)
>>
>> How many of you have worked for IBM
On May 16 2007 14:55, Jörn Engel wrote:
>On Wed, 16 May 2007 16:29:22 +0400, Evgeniy Polyakov wrote:
>> On Wed, May 16, 2007 at 01:50:03PM +0200, Jörn Engel ([EMAIL PROTECTED])
>> wrote:
>> > On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
>> > >
>> > > But if akpm can't pronounce it,
On May 16 2007 13:09, Jörn Engel wrote:
>On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
>>
>> Personally I'd just go for 'JFFS3'. After all, it has a better claim to
>> the name than either of its predecessors :)
>
>Did you ever see akpm's facial expression when he tried to pronounce
On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
>
> Is logfs 32bit fs or 674bit, since although you use 64bit values for
> offsets, area management and strange converstions like described below
> from offset into segment number are performed in 32bit?
> Is it enough for SSD for
Hi Jörn.
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from offset into segment number are performed in 32bit?
Is it enough for SSD for example to be 32bit only? Or if it is 64bit,
could you please
On Tuesday 15 May 2007, Jörn Engel wrote:
> Add LogFS, a scalable flash filesystem.
Hi Jörn,
Sorry for not commenting earlier, there were so many discussions on version
two that I wanted to wait for the fallout of that instead of duplicating
all the comments.
Here are a few things I notice
On Thu, 17 May 2007 16:43:59 +0800, David Woodhouse wrote:
>
> > As I mentioned, some techniques like log-structured filesystem could
> > perform generally better on any kind of flash-based storage with FTL.
> > Although there are many kinds of FTL, it is commonly true that
> > it performs well
On Tuesday 15 May 2007, Jörn Engel wrote:
>
> > I've been semi watching this, and the only comment I really can give
> > is that I hate the name. To me, logfs implies a filesystem for
> > logging purposes, not for Flash hardware with wear leveling issues to
> > be taken into account.
>
> Yeah,
On Thu, 2007-05-17 at 09:12 +, Pavel Machek wrote:
> Nah, it would lead to Jorn disappearing misteriously and _Pavel_
> accused of murder ;-).
Are you suggesting that you would murder Jörn (you misspelled his name)
merely for the heinous crime of using his own name?
Your Luddism was already
> >> My experience is that no matter which name I pick,
> >people will
> >> complain
> >> anyway. Previous suggestions included:
> >> jffs3
> >> jefs
> >> engelfs
> >> poofs
> >> crapfs
> >> sweetfs
> >> cutefs
> >> dynamic journaling fs - djofs
> >> tfsfkal - the file system formerly known as
On Thu, 2007-05-17 at 17:20 +0900, Dongjun Shin wrote:
> There are, of course, cases where direct access are better.
> However, as the demand for capacity, reliability and high performance
> for the flash storage increases, the use of FTL with embedded controller
> would be inevitable.
>
> - The
On 5/17/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
Yes. These things are almost always implemented _very_ badly by the same
kind of crack-smoking hobo they drag in off the streets to write BIOSen.
It's bog-roll technology; if you fancy a laugh try doing some real
reliability tests on them
On Thu, 2007-05-17 at 15:12 +0900, Dongjun Shin wrote:
> The current trend of flash-based device is to hide the flash-specific details
> from the host OS. The flash memory is encapsulated in a package
> which contains a dedicated controller where a small piece of software (F/W or
> FTL)
> runs
On Thu, 2007-05-17 at 15:12 +0900, Dongjun Shin wrote:
The current trend of flash-based device is to hide the flash-specific details
from the host OS. The flash memory is encapsulated in a package
which contains a dedicated controller where a small piece of software (F/W or
FTL)
runs and
On 5/17/07, David Woodhouse [EMAIL PROTECTED] wrote:
Yes. These things are almost always implemented _very_ badly by the same
kind of crack-smoking hobo they drag in off the streets to write BIOSen.
It's bog-roll technology; if you fancy a laugh try doing some real
reliability tests on them
On Thu, 2007-05-17 at 17:20 +0900, Dongjun Shin wrote:
There are, of course, cases where direct access are better.
However, as the demand for capacity, reliability and high performance
for the flash storage increases, the use of FTL with embedded controller
would be inevitable.
- The
My experience is that no matter which name I pick,
people will
complain
anyway. Previous suggestions included:
jffs3
jefs
engelfs
poofs
crapfs
sweetfs
cutefs
dynamic journaling fs - djofs
tfsfkal - the file system formerly known as logfs
Can we call it jörnfs? :)
On Thu, 2007-05-17 at 09:12 +, Pavel Machek wrote:
Nah, it would lead to Jorn disappearing misteriously and _Pavel_
accused of murder ;-).
Are you suggesting that you would murder Jörn (you misspelled his name)
merely for the heinous crime of using his own name?
Your Luddism was already
On Tuesday 15 May 2007, Jörn Engel wrote:
I've been semi watching this, and the only comment I really can give
is that I hate the name. To me, logfs implies a filesystem for
logging purposes, not for Flash hardware with wear leveling issues to
be taken into account.
Yeah, well, ...
On Thu, 17 May 2007 16:43:59 +0800, David Woodhouse wrote:
As I mentioned, some techniques like log-structured filesystem could
perform generally better on any kind of flash-based storage with FTL.
Although there are many kinds of FTL, it is commonly true that
it performs well under
On Tuesday 15 May 2007, Jörn Engel wrote:
Add LogFS, a scalable flash filesystem.
Hi Jörn,
Sorry for not commenting earlier, there were so many discussions on version
two that I wanted to wait for the fallout of that instead of duplicating
all the comments.
Here are a few things I notice while
Hi Jörn.
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from offset into segment number are performed in 32bit?
Is it enough for SSD for example to be 32bit only? Or if it is 64bit,
could you please
On Thu, 17 May 2007 20:03:11 +0400, Evgeniy Polyakov wrote:
Is logfs 32bit fs or 674bit, since although you use 64bit values for
offsets, area management and strange converstions like described below
from offset into segment number are performed in 32bit?
Is it enough for SSD for example to
On May 16 2007 13:09, Jörn Engel wrote:
On Wed, 16 May 2007 12:54:14 +0800, David Woodhouse wrote:
Personally I'd just go for 'JFFS3'. After all, it has a better claim to
the name than either of its predecessors :)
Did you ever see akpm's facial expression when he tried to pronounce
JFFS2?
On May 16 2007 14:55, Jörn Engel wrote:
On Wed, 16 May 2007 16:29:22 +0400, Evgeniy Polyakov wrote:
On Wed, May 16, 2007 at 01:50:03PM +0200, Jörn Engel ([EMAIL PROTECTED])
wrote:
On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
But if akpm can't pronounce it, how about FFFS
On May 16 2007 22:06, CaT wrote:
On Wed, May 16, 2007 at 01:50:03PM +0200, J??rn Engel wrote:
On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
But if akpm can't pronounce it, how about FFFS for faster flash
filesystem ;-)
How many of you have worked for IBM before? Vowels
On May 16 2007 15:53, Jörn Engel wrote:
My experience is that no matter which name I pick, people will complain
anyway. Previous suggestions included:
[...]
Plus today:
FFFS
flashfs
fredfs
bob
shizzle
Imo they all suck. LogFS also sucks, but it allows me to make a stupid
joke and keep my
On May 16 2007 02:06, Jörn Engel wrote:
+/* memtree.c */
+void btree_init(struct btree_head *head);
+void *btree_lookup(struct btree_head *head, long val);
+int btree_insert(struct btree_head *head, long val, void *ptr);
+int btree_remove(struct btree_head *head, long val);
These
On Thu, May 17, 2007 at 07:26:07PM +0200, Jan Engelhardt ([EMAIL PROTECTED])
wrote:
My plan was to move this code to lib/ sooner or later. If you consider
it useful in its current state, I can do it immediatly. And if someone
else merged a superior btree library I'd happily remove mine and
On Thu, 17 May 2007 17:08:51 +0200, Arnd Bergmann wrote:
On Tuesday 15 May 2007, Jörn Engel wrote:
Add LogFS, a scalable flash filesystem.
Sorry for not commenting earlier, there were so many discussions on version
two that I wanted to wait for the fallout of that instead of duplicating
Hi!
Yes. These things are almost always implemented _very_
badly by the same
kind of crack-smoking hobo they drag in off the streets
to write BIOSen.
It's bog-roll technology; if you fancy a laugh try
doing some real
reliability tests on them time some. Powerfail testing
is a good
Jörn Engel wrote:
Compressing random data will actually enlarge it. If that happens I
simply store the verbatim uncompressed data instead and mark it as such.
There is also demand for a user-controlled bit in the inode to disable
compression completely. All those .jpg, .mpg, .mp3, etc. just
On Thursday 17 May 2007, Jörn Engel wrote:
Why not just store 64 bit nanoseconds? that would avoid the problem
with ns overflow and the year-2038 bug. OTOH, that would require
a 64 bit integer division when reading the data, so it gets you
a runtime overhead.
I like the idea. Do
On Thu, 17 May 2007 23:00:20 +0200, Arnd Bergmann wrote:
Just using nanoseconds probably doesn't gain you much after all
then. You could however just have separate 32 bit fields in the
inode for seconds and nanoseconds, that will result in the exact
same layout that you have right now, but
On Thursday 17 May 2007, Pekka Enberg wrote:
Jörn Engel wrote:
Compressing random data will actually enlarge it. If that happens I
simply store the verbatim uncompressed data instead and mark it as such.
There is also demand for a user-controlled bit in the inode to disable
On Thu, 17 May 2007 23:36:13 +0200, Arnd Bergmann wrote:
On Thursday 17 May 2007, Pekka Enberg wrote:
So any sane way to enable compression is on per-inode basis which makes
me still wonder why you need per-object compression.
1. it doesn't require user interaction, the file system
Jörn Engel wrote:
Almost all your static functions start with logfs_, why not this one?
Because after a while I discovered how silly it is to start every
function with logfs_. That prefix doesn't add much unless the function
has global scope. What I didn't do was remove the prefix from
Hi,
On 5/18/07, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
Hmm.. so operating your camera on batteries should be against the
warranty, since batteries commonly run empty while storing pictures?
AFAIK, the camera stops writing to the flash card and automatically
turns off when it's low on
On May 17, 2007, at 13:45:33, Evgeniy Polyakov wrote:
On Thu, May 17, 2007 at 07:26:07PM +0200, Jan Engelhardt
([EMAIL PROTECTED]) wrote:
My plan was to move this code to lib/ sooner or later. If you
consider it useful in its current state, I can do it immediatly.
And if someone else
On Wed, 16 May 2007 19:17:18 +, Pavel Machek wrote:
>
> In kernel fsck
>
> > --- /dev/null 2007-04-18 05:32:26.652341749 +0200
> > +++ linux-2.6.21logfs/fs/logfs/progs/fsck.c 2007-05-15 00:54:22.0
> > +0200
> > @@ -0,0 +1,332 @@
> > +/*
> > + * fs/logfs/prog/fsck.c-
Hi!
In kernel fsck
> --- /dev/null 2007-04-18 05:32:26.652341749 +0200
> +++ linux-2.6.21logfs/fs/logfs/progs/fsck.c 2007-05-15 00:54:22.0
> +0200
> @@ -0,0 +1,332 @@
> +/*
> + * fs/logfs/prog/fsck.c - filesystem check
> + *
> + * As should be obvious for Linux kernel code,
On Wed, 16 May 2007 23:49:55 +0800, David Woodhouse wrote:
>
> Utility is a factor of the underlying design -- a filesystem designed
> for flash really isn't suited to block devices.
I can think of at least three examples where LogFS would indeed make
sense on block devices.
Jörn
--
Happiness
On Wed, 2007-05-16 at 08:34 -0700, Andrew Morton wrote:
> Reduced testability, mainly. Also potentially reduced usefulness.
CONFIG_MTD has never been a barrier to testability. JFFS2 depends on MTD
and had _most_ of its early testing and development done on the 'fake'
mtdram device.
Utility is a
On Wed, 16 May 2007 20:07:18 +0800 David Woodhouse <[EMAIL PROTECTED]> wrote:
> > It's strange and a bit regrettable that an fs would have dependency on MTD,
> > really.
>
> Why? Other file systems has dependencies on BLOCK or on NET. It seems
> entirely normal to me.
Reduced testability,
On 5/16/07, David Woodhouse <[EMAIL PROTECTED]> wrote:
On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
>
> My experience is that no matter which name I pick, people will
> complain
> anyway. Previous suggestions included:
> jffs3
> jefs
> engelfs
> poofs
> crapfs
> sweetfs
> cutefs
>
On Wed, May 16, 2007 at 03:53:19PM +0200, J??rn Engel wrote:
> Imo they all suck. LogFS also sucks, but it allows me to make a stupid
> joke and keep my logfs.org domain.
Well if stupid jokes are a goer there's always gordonfs. :)
*hides*
--
"To the extent that we overreact, we proffer
On Wed, 2007-05-16 at 22:04 +0800, David Woodhouse wrote:
> On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
> >
> > My experience is that no matter which name I pick, people will
> > complain
> > anyway. Previous suggestions included:
> > jffs3
> > jefs
> > engelfs
> > poofs
> > crapfs
> >
On Wed, 2007-05-16 at 15:53 +0200, Jörn Engel wrote:
>
> My experience is that no matter which name I pick, people will
> complain
> anyway. Previous suggestions included:
> jffs3
> jefs
> engelfs
> poofs
> crapfs
> sweetfs
> cutefs
> dynamic journaling fs - djofs
> tfsfkal - the file system
On Wed, 16 May 2007 09:41:10 -0400, John Stoffel wrote:
> Jörn> On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
>
> Jörn> How many of you have worked for IBM before? Vowels are not
> evil. ;)
>
> Nope, they're not. I just think that LogFS isn't descriptive enough,
> or more
On Wed, 16 May 2007 15:36:44 +0300, Pekka Enberg wrote:
> On 5/16/07, Jörn Engel <[EMAIL PROTECTED]> wrote:
> >
> >More trouble?
>
> Forgot to add (see below). Seems logfs_segment_read would be simpler
> too if you fixed this.
Would it? I think that code would still be needed, although possibly
On Wed, 16 May 2007 15:08:15 +0300, Pekka Enberg wrote:
> On 5/16/07, Jamie Lokier <[EMAIL PROTECTED]> wrote:
> >Given that the filesystem is still 'experimental', I'd concentrate on
> >getting it stable before worrying about immutable and xattrs unless
> >they are easy.
>
> We will run into
On Wed, 16 May 2007 16:29:22 +0400, Evgeniy Polyakov wrote:
> On Wed, May 16, 2007 at 01:50:03PM +0200, Jörn Engel ([EMAIL PROTECTED])
> wrote:
> > On Wed, 16 May 2007 12:34:34 +0100, Jamie Lokier wrote:
> > >
> > > But if akpm can't pronounce it, how about FFFS for faster flash
> > >
On Wed, 16 May 2007 13:25:48 +0100, Jamie Lokier wrote:
>
> Is LogFS really slower than JFFS2 in practice?
Not sure. I ran a benchmark before adding compression support in QEMU
with a lightning-fast device. So the results should differ quite a bit
from practice.
On 5/16/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
Forgot to add (see below). Seems logfs_segment_read would be simpler
too if you fixed this.
Blah. Just to be clear: I forgot to add a "(see below)" text in the
original review comment.
-
To unsubscribe from this list: send the line
On 5/16/07, Jörn Engel <[EMAIL PROTECTED]> wrote:
> > +/* FIXME: all this mess should get replaced by using the page cache */
> > +static void fixup_from_wbuf(struct super_block *sb, struct logfs_area
> *area,
> > + void *read, u64 ofs, size_t readlen)
> > +{
>
> Indeed. And I think
1 - 100 of 168 matches
Mail list logo
