On Thu, 2005-08-11 at 14:06 +0800, David Teigland wrote:
> On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>
> > * + if (create)
> > + down_write(&ip->i_rw_mutex);
> > + else
> > + down_read(&ip->i_rw_mutex);
> >
> > why do you use a rwsem and not a regular
On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
> * + if (create)
> + down_write(&ip->i_rw_mutex);
> + else
> + down_read(&ip->i_rw_mutex);
>
> why do you use a rwsem and not a regular semaphore? You are aware that
> rwsems are far more expensive th
On Aug 10, 2005, at 09:26:26, AJ Lewis wrote:
On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote:
On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote:
So for every directory hierarchy on a shared filesystem, each
user needs
to have the complete list of bindmount
On Wed, Aug 10, 2005 at 12:11:10PM +0100, Christoph Hellwig wrote:
> On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote:
> > So for every directoy hiearchy on a shared filesystem, each user needs
> > to have the complete list of bindmounts needed, and automatically resync
> > that a
On Wed, Aug 10, 2005 at 01:09:17PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T12:05:11, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > What would a syntax look like which in your opinion does not remove
> > > totally valid symlink targets for magic mushroom bullshit? Prefix with
> > >
On 2005-08-10T12:05:11, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > What would a syntax look like which in your opinion does not remove
> > totally valid symlink targets for magic mushroom bullshit? Prefix with
> > // (which, according to POSIX, allows for implementation-defined
> > behaviour
On Wed, Aug 10, 2005 at 01:02:59PM +0200, Lars Marowsky-Bree wrote:
> What would a syntax look like which in your opinion does not remove
> totally valid symlink targets for magic mushroom bullshit? Prefix with
> // (which, according to POSIX, allows for implementation-defined
> behaviour)? Somethi
On 2005-08-10T11:54:50, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> It works now. Unlike context link which steal totally valid symlink
> targets for magic mushroom bullshit.
Right, that is a valid concern. Avoiding context dependent symlinks
entirely certainly is one possible path around thi
On Wed, Aug 10, 2005 at 12:34:24PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T11:32:56, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > Would a generic implementation of that higher up in the VFS be more
> > > acceptable?
> > No. Use mount --bind
>
> That's a working and less complex
On 2005-08-10T11:32:56, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > Would a generic implementation of that higher up in the VFS be more
> > acceptable?
> No. Use mount --bind
That's a working and less complex alternative for upto how many places
at once? That works for non-root users how...
On Wed, Aug 10, 2005 at 12:30:41PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-10T08:03:09, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > > Kindly lose the "Context Dependent Pathname" crap.
> > Same for ocfs2.
>
> Would a generic implementation of that higher up in the VFS be more
> accep
On 2005-08-10T08:03:09, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > Kindly lose the "Context Dependent Pathname" crap.
> Same for ocfs2.
Would a generic implementation of that higher up in the VFS be more
acceptable?
It's not like context-dependent symlinks are an arbitary feature, but
rath
On Tue, Aug 09, 2005 at 04:20:45PM +0100, Al Viro wrote:
> On Tue, Aug 02, 2005 at 03:18:28PM +0800, David Teigland wrote:
> > Hi, GFS (Global File System) is a cluster file system that we'd like to
> > see added to the kernel. The 14 patches total about 900K so I won't send
> > them to the list u
On Tue, Aug 02, 2005 at 03:18:28PM +0800, David Teigland wrote:
> Hi, GFS (Global File System) is a cluster file system that we'd like to
> see added to the kernel. The 14 patches total about 900K so I won't send
> them to the list unless that's requested. Comments and suggestions are
> welcome.
On Mon, 8 August 2005 12:05:25 +0200, Arjan van de Ven wrote:
> On Mon, 2005-08-08 at 17:57 +0800, David Teigland wrote:
> > >
> > > Please drop the extra braces.
> >
> > Here and elsewhere we try to keep unused stuff off the stack. Are you
> > suggesting that we're being overly cautious, or do
On Mon, 2005-08-08 at 17:57 +0800, David Teigland wrote:
> >
> > Please drop the extra braces.
>
> Here and elsewhere we try to keep unused stuff off the stack. Are you
> suggesting that we're being overly cautious, or do you just dislike the
> way it looks?
nice theory. In practice gcc 3.x sti
On Wed, Aug 03, 2005 at 09:44:06AM +0300, Pekka Enberg wrote:
> > +uint32_t gfs2_hash(const void *data, unsigned int len)
> > +{
> > + uint32_t h = 0x811C9DC5;
> > + h = hash_more_internal(data, len, h);
> > + return h;
> > +}
>
> Is there a reason why you cannot use or ?
See gfs2_h
On Fri, Aug 05, 2005 at 03:14:15PM +0800, David Teigland wrote:
> On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
> > * +++ b/fs/gfs2/fixed_div64.h 2005-08-01 14:13:08.009808200 +0800
> > e why?
>
> I'm not sure, actually, apart from the comments:
>
> do_div: /* For i
On Mer, 2005-08-03 at 16:33 +0200, Andi Kleen wrote:
> > http://redhat.com/~teigland/gfs2/20050801/gfs2-full.patch
> > http://redhat.com/~teigland/gfs2/20050801/broken-out/
>
> I would suggest to not merge this before not all the code has not been
> reviewed by some experienced linux developer fro
On Fri, Aug 05, 2005 at 12:07:50PM +0200, J?rn Engel wrote:
> On Fri, 5 August 2005 17:44:52 +0800, David Teigland wrote:
> > Do we go a step beyond this and use say the crc32() function from
> > linux/crc32.h? Is this _function_ as standard and unchanging as the table
> > of crcs? In my tests it
On Fri, 5 August 2005 17:44:52 +0800, David Teigland wrote:
>
> linux/lib/crc32table.h : crc32table_le[] is the same as our crc_32_tab[].
> This looks like a standard that's not going to change, as you've said, so
> including crc32table.h and getting rid of our own table would work fine.
>
> Do w
On Fri, Aug 05, 2005 at 09:34:38AM +0200, Arjan van de Ven wrote:
> On Fri, 2005-08-05 at 15:14 +0800, David Teigland wrote:
> > On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
> >
> > > * +static const uint32_t crc_32_tab[] = .
> > > why do you duplicate this? The kernel has
On Fri, 2005-08-05 at 10:28 +0200, Jan Engelhardt wrote:
> >The gfs2_disk_hash() function and the crc table on which it's based are a
> >part of gfs2_ondisk.h: the ondisk metadata specification. This is a bit
> >unusual since gfs uses a hash table on-disk for its directory structure.
> >This heade
>The gfs2_disk_hash() function and the crc table on which it's based are a
>part of gfs2_ondisk.h: the ondisk metadata specification. This is a bit
>unusual since gfs uses a hash table on-disk for its directory structure.
>This header, including the hash function/table, must be included by user
>s
On Fri, 2005-08-05 at 15:14 +0800, David Teigland wrote:
> On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>
> > * +static const uint32_t crc_32_tab[] = .
> > why do you duplicate this? The kernel has a perfectly good set of
> > generic crc32 tables/functions just fine
>
> T
Mike Christie wrote:
> David Teigland wrote:
>
>>On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>>
>>
>>>* Why are you using bufferheads extensively in a new filesystem?
>>
>>
>>bh's are used for metadata, the log, and journaled data which need to be
>>written at the block granu
David Teigland wrote:
> On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
>
>>* Why are you using bufferheads extensively in a new filesystem?
>
>
> bh's are used for metadata, the log, and journaled data which need to be
> written at the block granularity, not page.
>
In a scs
On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
> * +static const uint32_t crc_32_tab[] = .
> why do you duplicate this? The kernel has a perfectly good set of
> generic crc32 tables/functions just fine
The gfs2_disk_hash() function and the crc table on which it's based are
On Wed, Aug 03, 2005 at 12:37:44PM +0200, Lars Marowsky-Bree wrote:
> On 2005-08-03T11:56:18, David Teigland <[EMAIL PROTECTED]> wrote:
>
> > > * Why use your own journalling layer and not say ... jbd ?
> > Here's an analysis of three approaches to cluster-fs journaling and their
> > pros/cons (in
David Teigland <[EMAIL PROTECTED]> writes:
> Hi, GFS (Global File System) is a cluster file system that we'd like to
> see added to the kernel. The 14 patches total about 900K so I won't send
> them to the list unless that's requested. Comments and suggestions are
> welcome. Thanks
>
> http://
On 2005-08-03T11:56:18, David Teigland <[EMAIL PROTECTED]> wrote:
> > * Why use your own journalling layer and not say ... jbd ?
> Here's an analysis of three approaches to cluster-fs journaling and their
> pros/cons (including using jbd): http://tinyurl.com/7sbqq
Very instructive read, thanks f
On Wed, Aug 03, 2005 at 11:17:09AM +0200, Arjan van de Ven wrote:
> On Wed, 2005-08-03 at 11:56 +0800, David Teigland wrote:
> > The point is you can define GFS2_ENDIAN_BIG to compile gfs to be BE
> > on-disk instead of LE which is another useful way to verify endian
> > correctness.
>
> that soun
On Wed, 2005-08-03 at 11:56 +0800, David Teigland wrote:
> The point is you can define GFS2_ENDIAN_BIG to compile gfs to be BE
> on-disk instead of LE which is another useful way to verify endian
> correctness.
that sounds wrong to be a compile option. If you really want to deal
with dual disk end
> I don't know anything about GFS, but expecting a filesystem author to
> use a journaling layer he does not want to is a bit arrogant.
good that I didn't expect that then.
I think it's fair enough to ask people if they can use it. If the answer
is "No because it doesn't fit our model " then that
Hi David,
Some more comments below.
Pekka
On 8/2/05, David Teigland <[EMAIL PROTECTED]> wrote:
> +/**
> + * inode_create - create a struct gfs2_inode
> + * @i_gl: The glock covering the inode
> + * @inum: The inode number
> + * @io_gl: the iopen glock to acquire/h
>> > because reiser got merged before jbd. Next question.
>>
>> That is the wrong reason. We use our own journaling layer for the
>> reason that Vivaldi used his own melody.
>>
>> [...] He might want to look at how reiser4 does wandering
>> logs instead of using jbd. but I would never claim
On Tue, Aug 02, 2005 at 01:16:53PM +0300, Pekka Enberg wrote:
> > +void *gmalloc_nofail_real(unsigned int size, int flags, char *file,
> > + unsigned int line)
> > +{
> > + void *x;
> > + for (;;) {
> > + x = kmalloc(size, flags);
> > + if (x)
> > +
On Aug 2, 2005, at 21:00:02, Hans Reiser wrote:
Arjan van de Ven wrote:
because reiser got merged before jbd. Next question.
That is the wrong reason. We use our own journaling layer for the
reason that Vivaldi used his own melody.
I don't know anything about GFS, but expecting a filesystem a
On Tue, Aug 02, 2005 at 09:45:24AM +0200, Arjan van de Ven wrote:
> * The on disk structures are defined in terms of uint32_t and friends,
> which are NOT endian neutral. Why are they not le32/be32 and thus
> endian-defined? Did you run bitwise-sparse on GFS yet ?
GFS has had proper endian handli
Arjan van de Ven wrote:
>On Tue, 2005-08-02 at 16:57 +0200, Jan Engelhardt wrote:
>
>
>>>* Why use your own journalling layer and not say ... jbd ?
>>>
>>>
>>Why does reiser use its own journalling layer and not say ... jbd ?
>>
>>
>
>because reiser got merged before jbd. Next question
On Tue, 2005-08-02 at 16:57 +0200, Jan Engelhardt wrote:
> >* Why use your own journalling layer and not say ... jbd ?
>
> Why does reiser use its own journalling layer and not say ... jbd ?
because reiser got merged before jbd. Next question.
Now the question for GFS is still a valid one; there
>* Why use your own journalling layer and not say ... jbd ?
Why does reiser use its own journalling layer and not say ... jbd ?
Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at htt
Hi David,
On 8/2/05, David Teigland <[EMAIL PROTECTED]> wrote:
> Hi, GFS (Global File System) is a cluster file system that we'd like to
> see added to the kernel. The 14 patches total about 900K so I won't send
> them to the list unless that's requested. Comments and suggestions are
> welcome.
On Tue, 2005-08-02 at 15:18 +0800, David Teigland wrote:
> Hi, GFS (Global File System) is a cluster file system that we'd like to
> see added to the kernel. The 14 patches total about 900K so I won't send
> them to the list unless that's requested. Comments and suggestions are
> welcome. Thanks
Hi, GFS (Global File System) is a cluster file system that we'd like to
see added to the kernel. The 14 patches total about 900K so I won't send
them to the list unless that's requested. Comments and suggestions are
welcome. Thanks
http://redhat.com/~teigland/gfs2/20050801/gfs2-full.patch
http:
45 matches
Mail list logo
