David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
You can drop the lock, do the invalidation,
Hmmm... There's a danger of incurring a race by doing that. Consider two
processes both trying to write to a dirty page for which writeback will be
rejected:
(1) The first process get
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 Mon, May 14, 2007 at 08:00:11PM +, Pavel Machek wrote:
> Hi!
>
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > Following are two patches which have been sitting for some time in -mm.
> >
> > Where "some time" == "nearly six months".
> >
> > We need help considering, reviewing
Yeah, seems you've locked it down, :D. I've written 600GB of data now,
and anything is still fine.
Will let it run overnight, and fill the whole 11T. I'll post the result
tomorrow
Thanks a lot though.
Jeff
> -Original Message-
> From: Neil Brown [mailto:[EMAIL PROTECTED]
> Sent: Thurs
On Thursday May 17, [EMAIL PROTECTED] wrote:
>
> Uhm, I just noticed something.
> 'chunk' is unsigned long, and when it gets shifted up, we might lose
> bits. That could still happen with the 4*2.75T arrangement, but is
> much more likely in the 2*5.5T arrangement.
Actually, it cannot be a probl
> What is the nature of the corruption? Is it data in a file
> that is wrong when you read it back, or does the filesystem
> metadata get corrupted?
The corruption is in fs metadata, jfs is completely destroied, after
Umount, fsck does not recogonize it as jfs anymore. Xfs gives kernel
Crash,
On Wednesday May 16, [EMAIL PROTECTED] wrote:
> On Thu, 17 May 2007, Neil Brown wrote:
>
> > On Thursday May 17, [EMAIL PROTECTED] wrote:
> >>
> >>> The only difference of any significance between the working
> >>> and non-working configurations is that in the non-working,
> >>> the component devi
On Thu, 17 May 2007, Neil Brown wrote:
On Thursday May 17, [EMAIL PROTECTED] wrote:
The only difference of any significance between the working
and non-working configurations is that in the non-working,
the component devices are larger than 2Gig, and hence have
sector offsets greater than 32
On Thursday May 17, [EMAIL PROTECTED] wrote:
> I tried the patch, same problem show up, but no bug_on report
>
> Is there any other things I can do?
>
What is the nature of the corruption? Is it data in a file that is
wrong when you read it back, or does the filesystem metadata get
corrupted?
>On Wednesday May 16, [EMAIL PROTECTED] wrote:
> > If CIFS provides some fix-length identifier for files, then
> > you might be able to do it
>
> Most CIFS servers (Windows on NTFS, Samba etc.) can return a "unique
> identifier" (a 64 bit inode number), in conjunction with the volume id,
> that
> If CIFS provides some fix-length identifier for files, then
> you might be able to do it
Most CIFS servers (Windows on NTFS, Samba etc.) can return a "unique
identifier" (a 64 bit inode number), in conjunction with the volume id,
that is probably good enough ... right? This can be returned o
I tried the patch, same problem show up, but no bug_on report
Is there any other things I can do?
Jeff
> Yes, I meant 2T, and yes, the components are always over 2T.
> So I'm at a complete loss. The raid0 code follows the same
> paths and does the same things and uses 64bit arithmetic wher
On Thursday May 17, [EMAIL PROTECTED] wrote:
>
> > The only difference of any significance between the working
> > and non-working configurations is that in the non-working,
> > the component devices are larger than 2Gig, and hence have
> > sector offsets greater than 32 bits.
>
> Do u mean 2T
> The only difference of any significance between the working
> and non-working configurations is that in the non-working,
> the component devices are larger than 2Gig, and hence have
> sector offsets greater than 32 bits.
Do u mean 2T here?, but in both configuartion, the component devices ar
On Wednesday May 16, [EMAIL PROTECTED] wrote:
> Here is the information of the created raid0. Hope it is enough.
Thanks.
Everything looks fine here.
The only difference of any significance between the working and
non-working configurations is that in the non-working, the component
devices are lar
On Wednesday May 16, [EMAIL PROTECTED] wrote:
> Any ideas what are the minimum export operation(s) that cifs would need to
> add to export under nfsd? It was not clear to me after reading the
> Exporting document in Documentation directory.
You need to be able to map a dentry to a filehandle (y
On Wed, May 16, 2007 at 07:21:16AM -0500, Dave Kleikamp wrote:
> On Wed, 2007-05-16 at 13:16 +1000, David Chinner wrote:
> > On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote:
>
> > > Following changes were made to the previous version:
> > > 1) Added description before sys_fallocate(
On Wed, May 16, 2007 at 11:19:29AM +0100, David Howells wrote:
>
> However, page_mkwrite() isn't told which bit of the page is going to be
> written to. This means it has to ask prepare_write() to make sure the whole
> page is filled in. In other words, offset and to must be equal (in AFS I set
You will definitely meet the same problem. As very large hardware disk
becomes more and more popular, this will become a big issue for software
raid.
Jeff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, 17 May 2007 6:04 a.m.
To: Andreas Dilger
Cc:
Problem is that is only happens when you actually write data to the
raid. You need the actual space to reproduce the problem.
Jeff
-Original Message-
From: Jan Engelhardt [mailto:[EMAIL PROTECTED]
Sent: Thursday, 17 May 2007 6:17 a.m.
To: [EMAIL PROTECTED]
Cc: Andreas Dilger; Jeff Zheng
On Wed, May 16, 2007 at 12:03:57PM -0500, Steven French wrote:
> I thought that until a few days ago, a sequence like the following (two
> nfs servers exporting the same clustered data)
>
> on client 1 lock range A through B of file1 (exported from nfs server 1)
> on client 2 lock range A through
Quoting Jan Engelhardt ([EMAIL PROTECTED]):
>
> On May 16 2007 10:38, Bharata B Rao wrote:
> >>
> >> >+lookup_union:
> >> >+ do {
> >> >+ struct vfsmount *mnt = find_mnt(topmost);
> >> >+ UM_DEBUG_DCACHE("name=\"%s\", inode=%p, device=%s\n",
> >> >+ topmost
On May 16 2007 10:38, Bharata B Rao wrote:
>>
>> >+lookup_union:
>> >+ do {
>> >+ struct vfsmount *mnt = find_mnt(topmost);
>> >+ UM_DEBUG_DCACHE("name=\"%s\", inode=%p, device=%s\n",
>> >+ topmost->d_name.name, topmost->d_inode,
>> >+
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
Nick Piggin <[EMAIL PROTECTED]> wrote:
> You can drop the lock, do the invalidation,
Hmmm... There's a danger of incurring a race by doing that. Consider two
processes both trying to write to a dirty page for which writeback will be
rejected:
(1) The first process gets EKEYREJECTED from the s
On May 16 2007 11:04, [EMAIL PROTECTED] wrote:
>
> I'm getting ready to setup a similar machine that will have 3x10TB (3 15 disk
> arrays with 750G drives), but won't be ready to try this for a few more days.
You could emulate it with VMware. Big disks are quite "cheap" when
they are not allocate
On Wed, 16 May 2007, Bill Davidsen wrote:
Jeff Zheng wrote:
Here is the information of the created raid0. Hope it is enough.
If I read this correctly, the problem is with JFS rather than RAID?
he had the same problem with xfs.
David Lang
-
To unsubscribe from this list: send the line "u
On Wed, 16 May 2007, Andreas Dilger wrote:
On May 16, 2007 11:09 +1200, Jeff Zheng wrote:
We are using two 3ware disk array controllers, each of them is connected
8 750GB harddrives. And we build a software raid0 on top of that. The
total capacity is 5.5TB+5.5TB=11TB
We use jfs as the file-sy
So did we just get your issues sorted? I _think_ *snip* is the
Howells code for "OK", but I can never be sure ;)
FWIW, as a rule, ClearPageUptodate should never be done by anyone,
least of all a filesystem on regular file pagecache. I need to go
through and audit this stuff... but so much backlog
Hello, Nick
This is new version of the patch.
reiserfs_prepare_write and reiserfs_commit_write are still there, but they do
not show themselves in any struct address_space_operations instance.
xattrs and ioctl use them directly.
From: Vladimir Saveliev <[EMAIL PROTECTED]>
Convert reiserfs to
On Wed, 16 May 2007 10:15:35 -0700, Andrew Morton wrote:
> On Wed, 16 May 2007 19:01:14 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
>
> > This patch introduces a new flag, I_SYNC and seperates out all sync()
> > users of I_LOCK to use the new flag instead.
>
> gack, you like sticking your head in
Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > VM in a way that people are not unhappy with :)
>
> I'm hoping you intended one less negative ;)
Or did you mean one fewer negative? :-)
David
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAI
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > How do you do a write-through cache for shared-writable mmap?
>
> For shared writable mmap? I don't know...
You can't do write-through caching for shared-writable mmap because the writes
go directly into the pagecache once the page is made writable, at
Hugh Dickins wrote:
> On Thu, 17 May 2007, Nick Piggin wrote:
>> ... and I don't want to change the
>> VM in a way that people are not unhappy with :)
>
> I'm hoping you intended one less negative ;)
Or one more...
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
I can't call invalidate_inode_pages() or similar because that might
incorrectly kill one of B's writes (or someone else's writes); besides,
the on-server file hasn't changed.
Why would that kill anyone's writes?
Because invalidat
Hugh Dickins wrote:
On Thu, 17 May 2007, Nick Piggin wrote:
... and I don't want to change the
VM in a way that people are not unhappy with :)
I'm hoping you intended one less negative ;)
Derrr... I'm an idiot!
--
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
On Thu, 17 May 2007, Nick Piggin wrote:
>
> ... and I don't want to change the
> VM in a way that people are not unhappy with :)
I'm hoping you intended one less negative ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Mo
Jeff Zheng wrote:
Here is the information of the created raid0. Hope it is enough.
If I read this correctly, the problem is with JFS rather than RAID? Have
you tried not mounting the JFS filesystem but just starting the array
which crashes, so you can read bits of it, etc, and verify that t
On Wed, 16 May 2007 19:01:14 +0200 Jörn Engel <[EMAIL PROTECTED]> wrote:
> This patch introduces a new flag, I_SYNC and seperates out all sync()
> users of I_LOCK to use the new flag instead.
gack, you like sticking your head in dark and dusty holes.
If we're going to do this then please let's g
I thought that until a few days ago, a sequence like the following (two
nfs servers exporting the same clustered data)
on client 1 lock range A through B of file1 (exported from nfs server 1)
on client 2 lock range A through C of file 1 (exported from nfs server 2)
on client 1 write A through B
Hugh Dickins wrote:
On Wed, 16 May 2007, Nick Piggin wrote:
Andrew Morton wrote:
I need to work out what to do with
mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-
While others are busy coming up with new silly names, here is something
substantial to worry about.
Patches fixes a deadlock problem well enough for LogFS to survive. The
problem itself is generic and seems to be ancient. Shaggy has code in
JFS from about 2.4.20 that seems to work around the dea
Nick Piggin <[EMAIL PROTECTED]> wrote:
> > I can't call invalidate_inode_pages() or similar because that might
> > incorrectly kill one of B's writes (or someone else's writes); besides,
> > the on-server file hasn't changed.
>
> Why would that kill anyone's writes?
Because invalidate_inode_page
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, 16 May 2007, Nick Piggin wrote:
> Andrew Morton wrote:
> > I need to work out what to do with
> >
> > mm-fix-fault-vs-invalidate-race-for-linear-mappings.patch
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear.patch
> > mm-merge-populate-and-nopage-into-fault-fixes-nonlinear-doc-
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
In general (modulo bugs and crazy filesystems), you're not allowed to have
!uptodate pages mapped into user addresses because that implies the user
would be allowed to see garbage.
Ths situation I have to deal with is a tricky one.
Nick Piggin <[EMAIL PROTECTED]> wrote:
> In general (modulo bugs and crazy filesystems), you're not allowed to have
> !uptodate pages mapped into user addresses because that implies the user
> would be allowed to see garbage.
Ths situation I have to deal with is a tricky one. Consider:
(1) Use
On Wed, May 16, 2007 at 09:55:41AM -0500, Steven French wrote:
> Any ideas what are the minimum export operation(s) that cifs would need to
> add to export under nfsd? It was not clear to me after reading the
> Exporting document in Documentation directory.
>
> (some users had wanted to export
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 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
Any ideas what are the minimum export operation(s) that cifs would need to
add to export under nfsd? It was not clear to me after reading the
Exporting document in Documentation directory.
(some users had wanted to export files from Windows servers to nfs clients
files by putting an nfs server
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 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 May 16, 2007 11:09 +1200, Jeff Zheng wrote:
> We are using two 3ware disk array controllers, each of them is connected
> 8 750GB harddrives. And we build a software raid0 on top of that. The
> total capacity is 5.5TB+5.5TB=11TB
>
> We use jfs as the file-system, we have a test application that
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
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Dave is using prepare_write here to ensure blocks are allocated in the
given range. The filesystem's ->nopage function must ensure it is uptodate
before allowing it to be mapped.
Which is fine... assuming it's called. For blockdev
Hi!
> Pathname matching, transition table loading, profile loading and
> manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor is misdesigned and works with paths when it should have
worked with handles'.
If you solve the 'new file problem', aa becomes
Hi!
> Set the LOOKUP_CONTINUE flag when checking parent permissions. This allows
> permission functions to tell between parent and leaf checks.
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
I guess you should sign this off.
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1409,6 +1409,
Hi!
> The underlying functions by which the AppArmor LSM hooks are implemented.
>
> Signed-off-by: John Johansen <[EMAIL PROTECTED]>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> +#include "inline.h"
Select a better name for include?
> +static inline void aa_permerror2result(int p
> Module parameters, LSM hooks, initialization and teardown.
>
> Signed-off-by: John Johansen <[EMAIL PROTECTED]>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> +/* Maximum pathname length before accesses will start getting rejected */
> +unsigned int apparmor_path_max = 2 * PATH_MAX
David Howells wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
I would strongly suggest you used (0, PAGE_CACHE_SIZE) for the range,
That tells prepare_write() that the region to be modified is the whole page -
which is incorrect. We're going to change a little bit of it.
You don't know how
David Woodhouse <[EMAIL PROTECTED]> wrote:
> Really? Is it _really_ going to be modified?
Well, generic_file_buffered_write() doesn't check the success of the copy
before calling commit_write(), presumably because it uses
fault_in_pages_readable() first.
David
-
To unsubscribe from this list: se
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
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Dave is using prepare_write here to ensure blocks are allocated in the
> given range. The filesystem's ->nopage function must ensure it is uptodate
> before allowing it to be mapped.
Which is fine... assuming it's called. For blockdev-based filesystems, t
Nick Piggin <[EMAIL PROTECTED]> wrote:
> I would strongly suggest you used (0, PAGE_CACHE_SIZE) for the range,
That tells prepare_write() that the region to be modified is the whole page -
which is incorrect. We're going to change a little bit of it.
Hmmm... Thinking about it again, I probably
On Wed, May 16, 2007 at 11:04:11PM +1000, Nick Piggin wrote:
> Chris Mason wrote:
> >On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
> >
> >>On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> >>
> >>>The start and end points passed to block_prepare_write() delimit the
> >>>
Chris Mason wrote:
On Wed, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
The start and end points passed to block_prepare_write() delimit the region of
the page that is going to be modified. This means that prepare_write()
do
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, May 16, 2007 at 08:09:19PM +0800, David Woodhouse wrote:
> On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> > The start and end points passed to block_prepare_write() delimit the region
> > of
> > the page that is going to be modified. This means that prepare_write()
> > doesn't
On Wed, May 16, 2007 at 08:57:21AM +0200, Christoph Hellwig wrote:
> On Tue, May 15, 2007 at 02:49:14PM -0700, [EMAIL PROTECTED] wrote:
> > fs/cifs/export.c |3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff -puN fs/cifs/export.c~knfsd-exportfs-add-exportfsh-header-fix
>
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 Mon, May 14, 2007 at 04:06:36PM +1000, [EMAIL PROTECTED] wrote:
> Cc: [EMAIL PROTECTED]
> Cc: Linux Filesystems
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Found a problem in ext2 pagecache directory handling. Trivial fix follows.
Longer-term, it might be better to rework these things a b
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, 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 Wed, May 16, 2007 at 07:21:16AM -0500, Dave Kleikamp wrote:
> On Wed, 2007-05-16 at 13:16 +1000, David Chinner wrote:
> > On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote:
>
> > > Following changes were made to the previous version:
> > > 1) Added description before sys_fallocate(
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 Tue, May 15, 2007 at 05:42:46PM -0700, Mingming Cao wrote:
> On Wed, 2007-05-16 at 01:33 +0530, Amit K. Arora wrote:
> > This patch implements sys_fallocate() and adds support on i386, x86_64
> > and powerpc platforms.
>
> > @@ -1137,6 +1148,8 @@ struct inode_operations {
> > ssize_t (*list
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, 2007-05-16 at 13:16 +1000, David Chinner wrote:
> On Wed, May 16, 2007 at 01:33:59AM +0530, Amit K. Arora wrote:
> > Following changes were made to the previous version:
> > 1) Added description before sys_fallocate() definition.
> > 2) Return EINVAL for len<=0 (With new draft that Ulric
On Wed, 2007-05-16 at 11:19 +0100, David Howells wrote:
> The start and end points passed to block_prepare_write() delimit the region of
> the page that is going to be modified. This means that prepare_write()
> doesn't need to fill it in if the page is not up to date.
Really? Is it _really_ goi
David Howells wrote:
Implement shared-writable mmap for AFS.
The key with which to access the file is obtained from the VMA at the point
where the PTE is made writable by the page_mkwrite() VMA op and cached in the
affected page.
If there's an outstanding write on the page made with a different
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 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
David Howells wrote:
David Chinner <[EMAIL PROTECTED]> wrote:
+ ret = block_prepare_write(page, 0, end, get_block);
As I understand the way prepare_write() works, this is incorrect.
I think it is actually OK.
The start and end points passed to block_prepare_write() delimit the re
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
David Chinner <[EMAIL PROTECTED]> wrote:
> + ret = block_prepare_write(page, 0, end, get_block);
As I understand the way prepare_write() works, this is incorrect.
The start and end points passed to block_prepare_write() delimit the region of
the page that is going to be modified. This means
Implement shared-writable mmap for AFS.
The key with which to access the file is obtained from the VMA at the point
where the PTE is made writable by the page_mkwrite() VMA op and cached in the
affected page.
If there's an outstanding write on the page made with a different key, then
page_mkwrite
1 - 100 of 105 matches
Mail list logo
