Greg,
On Tue, 22 Jan 2019 at 16:24, Greg Kroah-Hartman
wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> There is no need to save the dentries for t
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
There is no need to save the dentries for the debugfs files, so drop
those variables to save a bit of space and make
Hi,
On Thu, 2014-03-06 at 12:10 -0800, Joe Perches wrote:
> Joe Perches (3):
> gfs2: Use pr_ more consistently
> gfs2: Use fs_ more often
> gfs2: Convert gfs2_lm_withdraw to use fs_err
>
> fs/gfs2/dir.c| 14
> fs/gfs2/glock.c | 8 +++--
> fs/gfs2/lock_dlm.c | 9 ++
Joe Perches (3):
gfs2: Use pr_ more consistently
gfs2: Use fs_ more often
gfs2: Convert gfs2_lm_withdraw to use fs_err
fs/gfs2/dir.c| 14
fs/gfs2/glock.c | 8 +++--
fs/gfs2/lock_dlm.c | 9 +++--
fs/gfs2/main.c | 2 ++
fs/gfs2/ops_fstype.c | 25 ++---
---
lxc-dave/fs/gfs2/inode.c |1 +
1 file changed, 1 insertion(+)
diff -puN fs/gfs2/inode.c~gfs-check-nlink-count fs/gfs2/inode.c
--- lxc/fs/gfs2/inode.c~gfs-check-nlink-count 2007-02-09 14:26:59.0
-0800
+++ lxc-dave/fs/gfs2/inode.c2007-02-09 14:26:59.0 -0800
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> +static inline void glock_put(struct gfs2_glock *gl)
> +{
> + if (atomic_read(&gl->gl_count) == 1)
> + gfs2_glock_schedule_for_reclaim(gl);
> + gfs2_assert(gl->gl_sbd, atomic_read(&gl->gl_count) > 0,);
> + a
On 9/6/05, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Tuesday 06 September 2005 02:55, Dmitry Torokhov wrote:
> > On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
> > > On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > > > do you think it is a bit premature to dismiss so
On Maw, 2005-09-06 at 02:48 -0400, Daniel Phillips wrote:
> On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > do you think it is a bit premature to dismiss something even without
> > ever seeing the code?
>
> You told me you are using a dlm for a single-node application, is there
> a
On Fri, Sep 02, 2005 at 11:17:08PM +0200, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> >
> > > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > > > possibly gain (or vice versa)
> > >
On Tuesday 06 September 2005 02:55, Dmitry Torokhov wrote:
> On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
> > On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > > do you think it is a bit premature to dismiss something even without
> > > ever seeing the code?
> >
> > You t
On Tuesday 06 September 2005 01:48, Daniel Phillips wrote:
> On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> > do you think it is a bit premature to dismiss something even without
> > ever seeing the code?
>
> You told me you are using a dlm for a single-node application, is there
>
On Tuesday 06 September 2005 01:05, Dmitry Torokhov wrote:
> do you think it is a bit premature to dismiss something even without
> ever seeing the code?
You told me you are using a dlm for a single-node application, is there
anything more I need to know?
Regards,
Daniel
-
To unsubscribe from t
On Monday 05 September 2005 19:37, Joel Becker wrote:
> OCFS2, the new filesystem, is fully general purpose. It
> supports all the usual stuff, is quite fast...
So I have heard, but isn't it time to quantify that? How do you think you
would stack up here:
http://www.caspur.it/Files/2005/01
On Monday 05 September 2005 23:58, Daniel Phillips wrote:
> On Tuesday 06 September 2005 00:07, Dmitry Torokhov wrote:
> > On Monday 05 September 2005 23:02, Daniel Phillips wrote:
> > > By the way, you said "alpha server" not "alpha servers", was that just a
> > > slip? Because if you don't have a
On Tuesday 06 September 2005 00:07, Dmitry Torokhov wrote:
> On Monday 05 September 2005 23:02, Daniel Phillips wrote:
> > By the way, you said "alpha server" not "alpha servers", was that just a
> > slip? Because if you don't have a cluster then why are you using a dlm?
>
> No, it is not a slip. T
On Monday 05 September 2005 23:02, Daniel Phillips wrote:
>
> By the way, you said "alpha server" not "alpha servers", was that just a
> slip?
> Because if you don't have a cluster then why are you using a dlm?
>
No, it is not a slip. The application is running on just one node, so we
do not r
On Monday 05 September 2005 22:03, Dmitry Torokhov wrote:
> On Monday 05 September 2005 19:57, Daniel Phillips wrote:
> > On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
> > > On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> > > > On Monday 05 September 2005 10:14, Lars Marowsk
On Monday 05 September 2005 19:57, Daniel Phillips wrote:
> On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
> > On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> > > On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> > > > On 2005-09-03T01:57:31, Daniel Phillips <[EM
On Monday 05 September 2005 12:18, Dmitry Torokhov wrote:
> On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> > On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> > > On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > > > The only current users of dlms are
On Mon, Sep 05, 2005 at 10:24:03PM +0200, Bernd Eckenfels wrote:
> The whole point of the orcacle cluster filesystem as it was described in old
> papers was about pfiles, control files and software, because you can easyly
> use direct block access (with ASM) for tablespaces.
OCFS, the orig
On Sun, Sep 04, 2005 at 09:37:15AM +0100, Alan Cox wrote:
> I am curious why a lock manager uses open to implement its locking
> semantics rather than using the locking API (POSIX locks etc) however.
Because it is simple (how do you fcntl(2) from a shell fd?), has no
ranges (what do you do
Alan Cox <[EMAIL PROTECTED]> wrote:
>
> On Llu, 2005-09-05 at 12:53 -0700, Andrew Morton wrote:
> > > - How are they ref counted
> > > - What are the cleanup semantics
> > > - How do I pass a lock between processes (AF_UNIX sockets wont work now)
> > > - How do I poll on a lock coming free.
On Llu, 2005-09-05 at 12:53 -0700, Andrew Morton wrote:
> > - How are they ref counted
> > - What are the cleanup semantics
> > - How do I pass a lock between processes (AF_UNIX sockets wont work now)
> > - How do I poll on a lock coming free.
> > - What are the semantics of lock ownership
>
On Mon, Sep 05, 2005 at 10:24:03PM +0200, Bernd Eckenfels wrote:
> On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
> > That is the whole point why OCFS exists ;-)
>
> The whole point of the orcacle cluster filesystem as it was described in old
> papers was about pfiles, control
On Mon, Sep 05, 2005 at 04:16:31PM +0200, Lars Marowsky-Bree wrote:
> That is the whole point why OCFS exists ;-)
The whole point of the orcacle cluster filesystem as it was described in old
papers was about pfiles, control files and software, because you can easyly
use direct block access (with A
Alan Cox <[EMAIL PROTECTED]> wrote:
>
> On Llu, 2005-09-05 at 02:19 -0700, Andrew Morton wrote:
> > > create_lockspace()
> > > release_lockspace()
> > > lock()
> > > unlock()
> >
> > Neat. I'd be inclined to make them syscalls then. I don't suppose anyone
> > is likely to object i
r functions in the "full" spec(1) that we
didn't even attempt, either because we didn't require direct
user<->kernel access or we just didn't need the function. As for the
rather thick set of parameters expected in dlm calls, we managed to get
dlmlock down to *ahe
On Sad, 2005-09-03 at 21:46 -0700, Andrew Morton wrote:
> Actually I think it's rather sick. Taking O_NONBLOCK and making it a
> lock-manager trylock because they're kinda-sorta-similar-sounding? Spare
> me. O_NONBLOCK means "open this file in nonblocking mode", not "attempt to
> acquire a clust
On Llu, 2005-09-05 at 02:19 -0700, Andrew Morton wrote:
> > create_lockspace()
> > release_lockspace()
> > lock()
> > unlock()
>
> Neat. I'd be inclined to make them syscalls then. I don't suppose anyone
> is likely to object if we reserve those slots.
If the locks are not file descript
On Monday 05 September 2005 10:49, Daniel Phillips wrote:
> On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> > On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > > The only current users of dlms are cluster filesystems. There are zero
> > > users of the userspace
On Monday 05 September 2005 10:14, Lars Marowsky-Bree wrote:
> On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The only current users of dlms are cluster filesystems. There are zero
> > users of the userspace dlm api.
>
> That is incorrect...
Application users Lars, sorry i
On 2005-09-03T01:57:31, Daniel Phillips <[EMAIL PROTECTED]> wrote:
> The only current users of dlms are cluster filesystems. There are zero users
> of the userspace dlm api.
That is incorrect, and you're contradicting yourself here:
> What does have to be resolved is a common API for node man
On 2005-09-03T09:27:41, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> Oh thats interesting, I never thought about putting data files (tablespaces)
> in a clustered file system. Does that mean you can run supported RAC on
> shared ocfs2 files and anybody is using that?
That is the whole point why O
On Mon, Sep 05, 2005 at 12:09:23AM -0700, Mark Fasheh wrote:
> Btw, I'm curious to know how useful folks find the ext3 mount options
> errors=continue and errors=panic. I'm extremely likely to implement the
> errors=read-only behavior as default in OCFS2 and I'm wondering whether the
> other two ar
On Mon, Sep 05, 2005 at 10:27:35AM +0200, Pavel Machek wrote:
>
> There's a better reason, too. I do swsusp. Then I'd like to boot with
> / mounted read-only (so that I can read my config files, some
> binaries, and maybe suspended image), but I absolutely may not write
> to disk at this point, be
Hi,
On Sun, 2005-09-04 at 21:33, Pavel Machek wrote:
> > - read-only mount
> > - "specatator" mount (like ro but no journal allocated for the mount,
> > no fencing needed for failed node that was mounted as specatator)
>
> I'd call it "real-read-only", and yes, that's very usefull
> mount. Cou
On Mon, Sep 05, 2005 at 02:19:48AM -0700, Andrew Morton wrote:
> David Teigland <[EMAIL PROTECTED]> wrote:
> > Four functions:
> > create_lockspace()
> > release_lockspace()
> > lock()
> > unlock()
>
> Neat. I'd be inclined to make them syscalls then. I don't suppose anyone
> is likely t
On Monday 05 September 2005 05:19, Andrew Morton wrote:
> David Teigland <[EMAIL PROTECTED]> wrote:
> > On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
> > > David Teigland <[EMAIL PROTECTED]> wrote:
> > > > We export our full dlm API through read/write/poll on a misc device.
> > >
David Teigland <[EMAIL PROTECTED]> wrote:
>
> On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
> > David Teigland <[EMAIL PROTECTED]> wrote:
> > >
> > > We export our full dlm API through read/write/poll on a misc device.
> > >
> >
> > inotify did that for a while, but we ended up g
On Mon, Sep 05, 2005 at 01:54:08AM -0700, Andrew Morton wrote:
> David Teigland <[EMAIL PROTECTED]> wrote:
> >
> > We export our full dlm API through read/write/poll on a misc device.
> >
>
> inotify did that for a while, but we ended up going with a straight syscall
> interface.
>
> How fat is
On Mon, Sep 05, 2005 at 10:58:08AM +0200, J?rn Engel wrote:
> #define gfs2_assert(sdp, assertion) do { \
> if (unlikely(!(assertion))) { \
> printk(KERN_ERR "GFS2: fsid=\n", (sdp)->sd_fsname); \
> BUG();
On Mon, 5 September 2005 11:47:39 +0800, David Teigland wrote:
>
> Joern already suggested moving this out of line and into a function (as it
> was before) to avoid repeating string constants. In that case the
> function, file and line from BUG aren't useful. We now have this, does it
> look ok?
David Teigland <[EMAIL PROTECTED]> wrote:
>
> We export our full dlm API through read/write/poll on a misc device.
>
inotify did that for a while, but we ended up going with a straight syscall
interface.
How fat is the dlm interface? ie: how many syscalls would it take?
-
To unsubscribe from
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> > +void gfs2_glock_hold(struct gfs2_glock *gl)
> > +{
> > + glock_hold(gl);
> > +}
> >
> > eh why?
On 9/5/05, David Teigland <[EMAIL PROTECTED]> wrote:
> You removed the comment stating exactly why, see below. If that's not a
On Sun, Sep 04, 2005 at 10:33:44PM +0200, Pavel Machek wrote:
> Hi!
>
> > - read-only mount
> > - "specatator" mount (like ro but no journal allocated for the mount,
> > no fencing needed for failed node that was mounted as specatator)
>
> I'd call it "real-read-only", and yes, that's very usef
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> +static unsigned int handle_roll(atomic_t *a)
> +{
> + int x = atomic_read(a);
> + if (x < 0) {
> + atomic_set(a, 0);
> + return 0;
> + }
> + return (unsigned int)x;
> +}
>
> this is just p
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> +void gfs2_glock_hold(struct gfs2_glock *gl)
> +{
> + glock_hold(gl);
> +}
>
> eh why?
You removed the comment stating exactly why, see below. If that's not a
accepted technique in the kernel, say so and I'll be happy to ch
On Sat, Sep 03, 2005 at 10:41:40PM -0700, Andrew Morton wrote:
> Joel Becker <[EMAIL PROTECTED]> wrote:
> >
> > > What happens when we want to add some new primitive which has no
> > > posix-file analog?
> >
> > The point of dlmfs is not to express every primitive that the
> > DLM has. dlm
; 0,);
> >
> > > what is gfs2_assert() about anyway? please just use BUG_ON directly
> > > everywhere
> >
> > When a machine has many gfs file systems mounted at once it can be useful
> > to know which one failed. Does the following look ok?
> >
&
On Sun, Sep 04, 2005 at 10:33:44PM +0200, Pavel Machek wrote:
> > - read-only mount
> > - "specatator" mount (like ro but no journal allocated for the mount,
> > no fencing needed for failed node that was mounted as specatator)
>
> I'd call it "real-read-only", and yes, that's very usefull
> mou
Hi!
> - read-only mount
> - "specatator" mount (like ro but no journal allocated for the mount,
> no fencing needed for failed node that was mounted as specatator)
I'd call it "real-read-only", and yes, that's very usefull
mount. Could we get it for ext3, too?
On Sunday 04 September 2005 03:28, Andrew Morton wrote:
> If there is already a richer interface into all this code (such as a
> syscall one) and it's feasible to migrate the open() tricksies to that API
> in the future if it all comes unstuck then OK. That's why I asked (thus
> far unsuccessfully
>takelock domainxxx lock1
>do sutff
>droplock domainxxx lock1
>
> When someone kills the shell, the lock is leaked, becuase droplock isn't
> called.
Why not open the lock resource (or the lock space) instead of
individual locks as file? It then looks like this:
open lock
On Sun, Sep 04, 2005 at 02:18:36AM -0700, Andrew Morton wrote:
> take-and-drop-lock -d domainxxx -l lock1 -e "do stuff"
Ahh, but then you have to have lots of scripts somewhere in
path, or do massive inline scripts. especially if you want to take
another lock in there somewhere.
Joel Becker <[EMAIL PROTECTED]> wrote:
>
> I can't see how that works easily. I'm not worried about a
> tarball (eventually Red Hat and SuSE and Debian would have it). I'm
> thinking about this shell:
>
> exec 7 do stuff
> exec 7
> If someone kills the shell while stu
On Sun, Sep 04, 2005 at 01:18:05AM -0700, Andrew Morton wrote:
> > I thought I stated this in my other email. We're not intending
> > to extend dlmfs.
>
> Famous last words ;)
Heh, of course :-)
> I don't buy the general "fs is nice because we can script it" argument,
> really. You
Mark Fasheh <[EMAIL PROTECTED]> wrote:
>
> On Sun, Sep 04, 2005 at 12:23:43AM -0700, Andrew Morton wrote:
> > > What would be an acceptable replacement? I admit that O_NONBLOCK ->
> > > trylock
> > > is a bit unfortunate, but really it just needs a bit to express that -
> > > nobody over here care
Joel Becker <[EMAIL PROTECTED]> wrote:
>
> On Sun, Sep 04, 2005 at 12:28:28AM -0700, Andrew Morton wrote:
> > If there is already a richer interface into all this code (such as a
> > syscall one) and it's feasible to migrate the open() tricksies to that API
> > in the future if it all comes unstuck
On Sun, Sep 04, 2005 at 12:23:43AM -0700, Andrew Morton wrote:
> > What would be an acceptable replacement? I admit that O_NONBLOCK -> trylock
> > is a bit unfortunate, but really it just needs a bit to express that -
> > nobody over here cares what it's called.
>
> The whole idea of reinterpretin
On Sun, Sep 04, 2005 at 12:28:28AM -0700, Andrew Morton wrote:
> If there is already a richer interface into all this code (such as a
> syscall one) and it's feasible to migrate the open() tricksies to that API
> in the future if it all comes unstuck then OK.
> That's why I asked (thus far unsucces
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>
> If the only user is their tools I would say let it go ahead and be cute, even
> sickeningly so. It is not supposed to be a general dlm api, at least that
> is
> my understanding. It is just supposed to be an interface for their tools.
> Of co
Mark Fasheh <[EMAIL PROTECTED]> wrote:
>
> On Sat, Sep 03, 2005 at 09:46:53PM -0700, Andrew Morton wrote:
> > Actually I think it's rather sick. Taking O_NONBLOCK and making it a
> > lock-manager trylock because they're kinda-sorta-similar-sounding? Spare
> > me. O_NONBLOCK means "open this file
On Sunday 04 September 2005 00:46, Andrew Morton wrote:
> Daniel Phillips <[EMAIL PROTECTED]> wrote:
> > The model you came up with for dlmfs is beyond cute, it's downright
> > clever.
>
> Actually I think it's rather sick. Taking O_NONBLOCK and making it a
> lock-manager trylock because they're k
On Sat, Sep 03, 2005 at 09:46:53PM -0700, Andrew Morton wrote:
> Actually I think it's rather sick. Taking O_NONBLOCK and making it a
> lock-manager trylock because they're kinda-sorta-similar-sounding? Spare
> me. O_NONBLOCK means "open this file in nonblocking mode", not "attempt to
> acquire
On Sun, Sep 04, 2005 at 01:52:29AM -0400, Daniel Phillips wrote:
> You do have ->release and ->make_item/group.
->release is like kobject release. It's a free callback, not a
callback from close.
> If I may hand you a more substantive argument: you don't support user-driven
> creation of
On Sat, Sep 03, 2005 at 10:41:40PM -0700, Andrew Morton wrote:
> Are you saying that the posix-file lookalike interface provides access to
> part of the functionality, but there are other APIs which are used to
> access the rest of the functionality? If so, what is that interface, and
> why cannot
On Sunday 04 September 2005 01:00, Joel Becker wrote:
> On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
> > Clearly, I ought to have asked why dlmfs can't be done by configfs. It
> > is the same paradigm: drive the kernel logic from user-initiated vfs
> > methods. You already hav
Joel Becker <[EMAIL PROTECTED]> wrote:
>
> > What happens when we want to add some new primitive which has no posix-file
> > analog?
>
> The point of dlmfs is not to express every primitive that the
> DLM has. dlmfs cannot express the CR, CW, and PW levels of the VMS
> locking scheme.
On Sun, Sep 04, 2005 at 12:51:10AM -0400, Daniel Phillips wrote:
> Clearly, I ought to have asked why dlmfs can't be done by configfs. It is
> the
> same paradigm: drive the kernel logic from user-initiated vfs methods. You
> already have nearly all the right methods in nearly all the right pl
On Sat, Sep 03, 2005 at 09:46:53PM -0700, Andrew Morton wrote:
> It would be much better to do something which explicitly and directly
> expresses what you're trying to do rather than this strange "lets do this
> because the names sound the same" thing.
So, you'd like a new flag name? Tha
Daniel Phillips <[EMAIL PROTECTED]> wrote:
>
> The model you came up with for dlmfs is beyond cute, it's downright clever.
Actually I think it's rather sick. Taking O_NONBLOCK and making it a
lock-manager trylock because they're kinda-sorta-similar-sounding? Spare
me. O_NONBLOCK means "open t
On Sunday 04 September 2005 00:30, Joel Becker wrote:
> You asked why dlmfs can't go into sysfs, and I responded.
And you got me! In the heat of the moment I overlooked the fact that you and
Greg haven't agreed to the merge yet ;-)
Clearly, I ought to have asked why dlmfs can't be done by confi
On Sun, Sep 04, 2005 at 12:22:36AM -0400, Daniel Phillips wrote:
> It is 640 lines.
It's 450 without comments and blank lines. Please, don't tell
me that comments to help understanding are bloat.
> I said "configfs" in the email to which you are replying.
To wit:
> Daniel Phillips said
On Saturday 03 September 2005 23:06, Joel Becker wrote:
> dlmfs is *tiny*. The VFS interface is less than his claimed 500
> lines of savings.
It is 640 lines.
> The few VFS callbacks do nothing but call DLM
> functions. You'd have to replace this VFS glue with sysfs glue, and
> probably save
On Sat, Sep 03, 2005 at 06:32:41PM -0700, Andrew Morton wrote:
> If there's duplicated code in there then we should seek to either make the
> code multi-purpose or place the common or reusable parts into a library
> somewhere.
Regarding sysfs and configfs, that's a whole 'nother
conversati
Joel Becker <[EMAIL PROTECTED]> wrote:
>
> On Sat, Sep 03, 2005 at 06:21:26PM -0400, Daniel Phillips wrote:
> > that fit the configfs-nee-sysfs model? If it does, the payoff will be
> about
> > 500 lines saved.
>
> I'm still awaiting your merge of ext3 and reiserfs, because you
> can s
On Sat, Sep 03, 2005 at 06:21:26PM -0400, Daniel Phillips wrote:
> that fit the configfs-nee-sysfs model? If it does, the payoff will be about
> 500 lines saved.
I'm still awaiting your merge of ext3 and reiserfs, because you
can save probably 500 lines having a filesystem that can creat
On Saturday 03 September 2005 02:46, Wim Coekaerts wrote:
> On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
> > On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> > > As far as userspace dlm apis go, dlmfs already abstracts away a large
> > > part of the dlm interaction...
> >
On Saturday 03 September 2005 06:35, David Teigland wrote:
> Just a new version, not a big difference. The ondisk format changed a
> little making it incompatible with the previous versions. We'd been
> holding out on the format change for a long time and thought now would be
> a sensible time to
On Sat, Sep 03, 2005 at 08:14:00AM +0200, Arjan van de Ven wrote:
> On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote:
> > On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote:
> > > Alan Cox <[EMAIL PROTECTED]> wrote:
> > > > > - Why GFS is
In article <[EMAIL PROTECTED]> you wrote:
> for ocfs we have tons of production customers running many terabyte
> databases on a cfs. why ? because dealing with the raw disk froma number
> of nodes sucks. because nfs is pretty broken for a lot of stuff, there
> is no consistency across nodes when e
On Fri, Sep 02, 2005 at 11:17:08PM +0200, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> >
> > Again, that's not a technical reason. It's _a_ reason, sure. But what are
> > the technical reasons for merging gfs[2], ocfs2, both or neit
On Sat, Sep 03, 2005 at 02:42:36AM -0400, Daniel Phillips wrote:
> On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> > As far as userspace dlm apis go, dlmfs already abstracts away a large part
> > of the dlm interaction...
>
> Dumb question, why can't you use sysfs for this instead of rolli
On Friday 02 September 2005 20:16, Mark Fasheh wrote:
> As far as userspace dlm apis go, dlmfs already abstracts away a large part
> of the dlm interaction...
Dumb question, why can't you use sysfs for this instead of rolling your own?
Side note: you seem to have deleted all the 2.6.12-rc4 patche
On Saturday 03 September 2005 02:14, Arjan van de Ven wrote:
> On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote:
> > On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote:
> > > Alan Cox <[EMAIL PROTECTED]> wrote:
> > > > > - Why GFS is better
On Sat, 2005-09-03 at 13:18 +0800, David Teigland wrote:
> On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote:
> > Alan Cox <[EMAIL PROTECTED]> wrote:
> > > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > &
s. There are zero users
of the userspace dlm api. Therefore, the (g)dlm userspace interface actually
has nothing to do with the needs of gfs. It should be taken out the gfs
patch and merged later, when or if user space applications emerge that need
it. Maybe in the meantime it will be possibl
use BUG_ON directly
> > everywhere
>
> When a machine has many gfs file systems mounted at once it can be useful
> to know which one failed. Does the following look ok?
>
> #define gfs2_assert(sdp, assertion) \
> do {
On Thu, Sep 01, 2005 at 01:21:04PM -0700, Andrew Morton wrote:
> Alan Cox <[EMAIL PROTECTED]> wrote:
> > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > > possibly gain (or vice versa)
> > >
> > > - Relative merits
On Fri, Sep 02, 2005 at 11:17:08PM +0200, Andi Kleen wrote:
> The only thing that should be probably resolved is a common API
> for at least the clustered lock manager. Having multiple
> incompatible user space APIs for that would be sad.
As far as userspace dlm apis go, dlmfs already abstracts awa
I have to correct an error in perspective, or at least in the wording of
it, in the following, because it affects how people see the big picture in
trying to decide how the filesystem types in question fit into the world:
>Shared storage can be more efficient than network file
>systems like NFS
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > > possibly gain (or vice versa)
> > >
> > > - Relative merits of the two offerings
> >
> > You missed the
use BUG_ON directly
> > everywhere
>
> When a machine has many gfs file systems mounted at once it can be useful
> to know which one failed. Does the following look ok?
>
> #define gfs2_assert(sdp, assertion) \
> do {
On Thu, Sep 01, 2005 at 01:35:23PM +0200, Arjan van de Ven wrote:
> + gfs2_assert(gl->gl_sbd, atomic_read(&gl->gl_count) > 0,);
> what is gfs2_assert() about anyway? please just use BUG_ON directly
> everywhere
When a machine has many gfs file systems mounted at on
On Thu, Sep 01, 2005 at 06:56:03PM +0100, Christoph Hellwig wrote:
> Whether the gfs2 code is mergeable is a completely different question,
> and it seems at least debatable to submit a filesystem for inclusion
I actually asked what needs to be done for merging. We appreciate the
feedback and ar
king for technical reasons, please.
> > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > possibly gain (or vice versa)
> >
> > - Relative merits of the two offerings
>
> You missed the important one - people actively use it and have been
I just started looking at gfs. To understand it you'd need to look at it
from the entire cluster solution point of view.
This is a good document from David. It's not about GFS in particular but
about the architecture of the cluster.
http://people.redhat.com/~teigland/sca
On Thu, Sep 01, 2005 at 04:28:30PM +0100, Alan Cox wrote:
> > That's GFS. The submission is about a GFS2 that's on-disk incompatible
> > to GFS.
>
> Just like say reiserfs3 and reiserfs4 or ext and ext2 or ext2 and ext3
> then. I think the main point stil
On Thursday 01 September 2005 06:46, David Teigland wrote:
> I'd like to get a list of specific things remaining for merging.
Where are the benchmarks and stability analysis? How many hours does it
survive cerberos running on all nodes simultaneously? Where are the
testimonials from users? Ho
On Thursday 01 September 2005 10:49, Alan Cox wrote:
> On Iau, 2005-09-01 at 03:59 -0700, Andrew Morton wrote:
> > - Why GFS is better than OCFS2, or has functionality which OCFS2 cannot
> > possibly gain (or vice versa)
> >
> > - Relative merits of the two offerings
&
1 - 100 of 210 matches
Mail list logo
