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
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 t
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 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 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
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
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
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 doubious
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 no
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
> swe
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, struct
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 o
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 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 pre
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 merge
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 fr
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 sy
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, b
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
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 wa
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 testin
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 duplicatin
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 va
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
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 be
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, ho
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 exampl
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 expl
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
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 un
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, w
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 q
> >> 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 l
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 c
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 t
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 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- fil
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, li
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, mainly
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
> dynami
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 the
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
> > s
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 form
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 accurately
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 troub
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
> > > filesystem.
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.
http://logfs.org/~joern/logfs/b
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 "unsubscrib
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 y
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
> > filesystem ;-)
>
> How many of you have worked for IBM before? Vowels are not
On Wed, 16 May 2007 13:21:11 +0300, Pekka J Enberg wrote:
>
> > +#define LOGFS_BUG(sb) do { \
> > + struct super_block *__sb = sb; \
> > + logfs_crash_dump(__sb); \
> > + BUG(); \
> > +} while(0)
>
> Note that BUG() can be a no-op so dumping
Artem Bityutskiy wrote:
> On Wed, 2007-05-16 at 12:34 +0100, Jamie Lokier wrote:
> > 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 :)
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 are not evil. ;)
>
> Group
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 trouble if the on-disk format is not flexible enough
to accommodate xattr
On Tue, 2007-05-15 at 13:37 -0700, Andrew Morton wrote:
> But it includes an MTD header file.
>
> Can this code be tested by people who don't have MTD hardware? We used to
> ahve a fake-mtd-on-a-blockdev thing, whcih was in a state of some
> disrepair. Maybe it got repaired. Or removed. I can'
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 are not evil. ;)
Grouping four or more consonants to name anything will cause similar
expressions o
Albert Cahalan wrote:
> Please don't forget the immutable bit. ("man lsattr")
> Having both, BSD-style, would be even better.
> The immutable bit is important for working around
> software bugs and "features" that damage files.
>
> I also can't find xattr support.
Imho,
Given that the filesystem
On Wed, 2007-05-16 at 12:34 +0100, Jamie Lokier wrote:
> 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
On Tue, 15 May 2007 19:37:36 -0700, Roland Dreier wrote:
>
> There are rather a lot of of FIXME comments, including scary stuff like
>
> > + /*
> > + * FIXME: this cannot be right but it does "fix" a bug of i_count
> > + * dropping too low. Needs more thought.
> > + */
> > + atomic_
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"? ;)
JFFS3
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"? ;)
Jörn
--
Fancy algorithms are sl
On Wed, 16 May 2007 07:22:54 +0200, Willy Tarreau wrote:
>
> On hard disks, yes, but as you suggested, there are lots of other flash
> devices interfaced as block devices. CompactFlash comes to mind, USB
> keys too. And on these ones, the most important is to reduce the number
> of writes and to s
Hi Joern,
> +#define LOGFS_BUG(sb) do { \
> + struct super_block *__sb = sb; \
> + logfs_crash_dump(__sb); \
> + BUG(); \
> +} while(0)
Note that BUG() can be a no-op so dumping something on disk might not make
sense there. This seems usefu
On Wed, May 16, 2007 at 02:06:31AM +0200, Jörn Engel wrote:
> On Tue, 15 May 2007 13:37:59 -0700, Andrew Morton wrote:
> > It's strange and a bit regrettable that an fs would have dependency on MTD,
> > really.
>
> It is and changing this wouldn't be too hard. All device access goes
> through fiv
On Tue, 2007-05-15 at 21:19 +0200, Jörn Engel wrote:
> On Tue, 15 May 2007 15:07:05 -0400, John Stoffel 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 hardwa
There are rather a lot of of FIXME comments, including scary stuff like
> +/*
> + * FIXME: this cannot be right but it does "fix" a bug of i_count
> + * dropping too low. Needs more thought.
> + */
> +atomic_inc(&old_dentry->d_inode->i_count);
and
> +int __logfs_write_
On Wed, 16 May 2007 02:06:31 +0200, Jörn Engel wrote:
>
> > > +
> > > + if (dest) {
> > > + /* symlink */
> > > + ret = logfs_inode_write(inode, dest, destlen, 0);
> > > + } else {
> > > + /* creat/mkdir/mknod */
> > > + ret = __logfs_write_inode(inode);
> > > + }
>
On Tue, 15 May 2007 19:26:17 -0400, Albert Cahalan wrote:
>
> Please don't forget the immutable bit. ("man lsattr")
> Having both, BSD-style, would be even better.
> The immutable bit is important for working around
> software bugs and "features" that damage files.
>
> I also can't find xattr sup
On Tue, 15 May 2007 13:37:59 -0700, Andrew Morton wrote:
> > +
> > +config LOGFS_FSCK
> > + bool "Run LogFS fsck at mount time"
> > + depends on LOGFS
> > + help
> > + Run a full filesystem check on every mount. If any errors are
> > + found, mounting the filesystem will fail. This
Please don't forget the immutable bit. ("man lsattr")
Having both, BSD-style, would be even better.
The immutable bit is important for working around
software bugs and "features" that damage files.
I also can't find xattr support.
-
To unsubscribe from this list: send the line "unsubscribe linux-
On Tue, 15 May 2007 17:19:20 +0200
J__rn Engel <[EMAIL PROTECTED]> wrote:
> Add LogFS, a scalable flash filesystem.
>
> ...
>
>
> +config LOGFS
> + tristate "Log Filesystem (EXPERIMENTAL)"
> + depends on EXPERIMENTAL
> + select ZLIB_INFLATE
> + select ZLIB_DEFLATE
> + help
>
On Tue, 15 May 2007 15:07:05 -0400, John Stoffel 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 Tue, 15 May 2007 20:37:25 +0200, Sam Ravnborg wrote:
> On Tue, May 15, 2007 at 05:19:20PM +0200, Jörn Engel wrote:
> > [ I have put everyone that gave comments to the last patch on Cc:. Hope
> > that doesn't offend anyone. ]
> >
> >
> > Add LogFS, a scalable flash filesystem.
>
> Have you ru
On Tue, May 15, 2007 at 05:19:20PM +0200, Jörn Engel wrote:
> [ I have put everyone that gave comments to the last patch on Cc:. Hope
> that doesn't offend anyone. ]
>
>
> Add LogFS, a scalable flash filesystem.
Have you run sparse on this code?
I do not recall if you have written something abo
Most of my homework is done. There are six items left plus another five
I believe should not get changed.
Changed:
o Kconfig description updated
o Spaces converted to tabs in Makefile
o Sorted/seperated #includes
o structures are __packed instead of packed, #define removed
o removed TRACE()
o 32
84 matches
Mail list logo
