On Wed, Jan 26, 2011 at 8:59 AM, Steven Whitehouse wrote:
> Nevertheless, I agree that it would be nice to be able to move the
> inodes around freely. I'm not sure that the cost of the required extra
> layer of indirection would be worth it though, in terms of the benefits
> gained.
>
If the cos
On Wed, Jan 26, 2011 at 8:36 AM, Gordan Bobic wrote:
> Wendy Cheng wrote:
>
>> GFS2 fragments very soon and very badly ! Its blocks are all over the
>> device due to the nature of how the resource group works. That slows down
>> *every* thing, particularly for backup applications. A production dep
Hi,
On Wed, 2011-01-26 at 08:16 -0800, Wendy Cheng wrote:
> On 01/26/2011 02:19 AM, Steven Whitehouse wrote:
> >
> > I don't know of any reason why the inode number should be related to
> > back up. The reason why it was suggested that the inode number should be
> > independent of the physical blo
Wendy Cheng wrote:
GFS2 fragments very soon and very badly ! Its blocks are all over the
device due to the nature of how the resource group works. That slows
down *every* thing, particularly for backup applications. A production
deployment will encounter this issue very soon and they'll find t
On 01/26/2011 02:19 AM, Steven Whitehouse wrote:
I don't know of any reason why the inode number should be related to
back up. The reason why it was suggested that the inode number should be
independent of the physical block number was in order to allow
filesystem shrink without upsetting (for e
Hi,
On Tue, 2011-01-25 at 09:16 -0800, Wendy Cheng wrote:
> On Tue, Jan 25, 2011 at 2:01 AM, Steven Whitehouse
> wrote:
>
> >> On Mon, Jan 24, 2011 at 6:55 PM, Jankowski, Chris
> >> wrote:
> >> > A few comments, which might contrast uses of GFS2 and XFS in enterprise
> >> > class production e
Hi,
On Tue, 2011-01-25 at 15:27 -0800, Wendy Cheng wrote:
> On Tue, Jan 25, 2011 at 11:34 AM, yvette hirth wrote:
> > Rafa Grimán wrote:
> >
> >> Yes that is true. It's a bit blurry because some file systems have
> >> features others have so "classifying" them is quite difficult.
> >
> > i'm amaz
On Tue, Jan 25, 2011 at 11:34 AM, yvette hirth wrote:
> Rafa Grimán wrote:
>
>> Yes that is true. It's a bit blurry because some file systems have
>> features others have so "classifying" them is quite difficult.
>
> i'm amazed at the conversation that has taken place by me simply asking a
> quest
> -Original Message-
> From: linux-cluster-boun...@redhat.com
> [mailto:linux-cluster-boun...@redhat.com]
> On Behalf Of yvette hirth
> Subject: Re: [Linux-cluster] gfs2 v. zfs?
>
> ls -lhad /foo/stuff/moreStuff/*
>
> is where response time increases by a m
Rafa Grimán wrote:
Yes that is true. It's a bit blurry because some file systems have features
others have so "classifying" them is quite difficult.
i'm amazed at the conversation that has taken place by me simply asking
a question.
*Thank You* all for all of this info!
we've traced the re
m
> >>
> >> [mailto:linux-cluster-boun...@redhat.com]
> >>
> >> > On Behalf Of Wendy Cheng
> >> > Subject: Re: [Linux-cluster] gfs2 v. zfs?
> >> >
> >> > I would love to get an education here. From usage model point of view,
> &
On Tue, Jan 25, 2011 at 2:01 AM, Steven Whitehouse wrote:
>> On Mon, Jan 24, 2011 at 6:55 PM, Jankowski, Chris
>> wrote:
>> > A few comments, which might contrast uses of GFS2 and XFS in enterprise
>> > class production environments:
>> >
>> > 3.
>> > GFS2 provides only tar(1) as a backup mecha
Jankowski, Chris wrote:
[...]
It would require development of:
- GFS2 specific dump(8)
- GFS2 specific freeze and thaw commands
- CLVM wide snapshots
- more efficient DLM
It certainly is possible to do. Digital/Compaq/HP TruCluster Cluster File
System (CFS) built on top of AdvFS had all of thes
Hi,
On Mon, 2011-01-24 at 20:37 -0800, Wendy Cheng wrote:
> Comments in-line ...
>
> On Mon, Jan 24, 2011 at 6:55 PM, Jankowski, Chris
> wrote:
> > A few comments, which might contrast uses of GFS2 and XFS in enterprise
> > class production environments:
> >
> > 1.
> > SAN snapshot is not a pan
Comments in-line ...
On Mon, Jan 24, 2011 at 6:55 PM, Jankowski, Chris
wrote:
> A few comments, which might contrast uses of GFS2 and XFS in enterprise class
> production environments:
>
> 1.
> SAN snapshot is not a panacea, as it is only crash consistent and only within
> a single LUN.
> If yo
>I don't have any intention to start a flame and/or religion war.
>However, I'm hoping people could relax a little bit about this "rule",
>if it is a rule at all ... Check out:
>http://en.wikipedia.org/wiki/Posting_style#Top-posting to see what it
>says. You may find it interesting.
No war to star
>-Original Message-
>From: linux-cluster-boun...@redhat.com
>[mailto:linux-cluster-boun...@redhat.com] On Behalf Of Jeff Sturm
>Sent: Tuesday, 25 January 2011 09:02
>To: linux clustering
>Subject: Re: [Linux-cluster] gfs2 v. zfs?
>> -Original Message-
>
On Mon, Jan 24, 2011 at 5:06 PM, Joseph L. Casale
wrote:
>> A. Because it breaks the flow and reads backwards.
>
>> Q. Why is top posting considered harmful?
>
> Hope that was informative:)
> jlc
>
I don't have any intention to start a flame and/or religion war.
However, I'm hoping people could
>BTW, I never understand why top-post is evil ? Isn't it making some
>emails hard to read ?
People on these lists take their precious time to help you almost always
with nothing in return, often allowing you (me, us, everyone who uses
them) the luxury of getting our job that we are paid for done.
Of Wendy Cheng
>> > Subject: Re: [Linux-cluster] gfs2 v. zfs?
>> >
>> > I would love to get an education here. From usage model point of view,
>> > what is the
>> > difference between a "parallel file system" and a "cluster file
>> &
On Monday 24 January 2011 22:58 Jeff Sturm wrote
> > -Original Message-
> > From: linux-cluster-boun...@redhat.com
>
> [mailto:linux-cluster-boun...@redhat.com]
>
> > On Behalf Of Wendy Cheng
> > Subject: Re: [Linux-cluster] gfs2 v. zfs?
> >
&g
Hi :)
On Monday 24 January 2011 22:37 Wendy Cheng wrote
> I would love to get an education here. From usage model point of view,
> what is the difference between a "parallel file system" and a "cluster
> file system" ? i.e., when to use a parallel file system and when to
> use a cluster file syst
> -Original Message-
> From: linux-cluster-boun...@redhat.com
[mailto:linux-cluster-boun...@redhat.com]
> On Behalf Of Wendy Cheng
> Subject: Re: [Linux-cluster] gfs2 v. zfs?
>
> Guess GFS2 is out as an "enterprise" file system ? W/out a workable
backup so
> -Original Message-
> From: linux-cluster-boun...@redhat.com
[mailto:linux-cluster-boun...@redhat.com]
> On Behalf Of Wendy Cheng
> Subject: Re: [Linux-cluster] gfs2 v. zfs?
>
> I would love to get an education here. From usage model point of view,
what is the
>
Guess GFS2 is out as an "enterprise" file system ? W/out a workable
backup solution, it'll be seriously limited. I have been puzzled why
CLVM is slow to add this feature.
-- Wendy
On Mon, Jan 24, 2011 at 1:07 PM, Nicolas Ross
wrote:
>> I would guess this "enumeration" means "walk"; e.g. doing ba
I would love to get an education here. From usage model point of view,
what is the difference between a "parallel file system" and a "cluster
file system" ? i.e., when to use a parallel file system and when to
use a cluster file system ?
.. Wendy
On Mon, Jan 24, 2011 at 1:10 PM, Rafa Grimán wrot
Hi :)
On Monday 24 January 2011 21:25 Wendy Cheng wrote
> Sometime ago, the following was advertised:
>
> "ZFS is not a native cluster, distributed, or parallel file system and
> cannot provide concurrent access from multiple hosts as ZFS is a local
> file system. Sun's Lustre distributed filesys
I would guess this "enumeration" means "walk"; e.g. doing backup. One
of the most-liked features that ZFS offers is snapshots. So I would
suggest telling GFS2 users/customers to use LVM snapshot AND making
sure GFS2 works well with Linux LVMm snapshot.
AFAIK, clustered volume group doesn't suppo
On Mon, Jan 24, 2011 at 11:48 AM, Steven Whitehouse wrote:
>> our five-node cluster is working fine, the clustering software is great,
>> but when accessing gfs2-based files, enumeration can be very slow...
>>
> What do you mean be "enumeration can be very slow" ? It might be
> possible to slightl
Sometime ago, the following was advertised:
"ZFS is not a native cluster, distributed, or parallel file system and
cannot provide concurrent access from multiple hosts as ZFS is a local
file system. Sun's Lustre distributed filesystem will adapt ZFS as
back-end storage for both data and metadata i
On 01/24/2011 07:51 PM, yvette hirth wrote:
Gordan Bobic wrote:
On 01/24/2011 07:16 PM, yvette hirth wrote:
hi all,
does anyone have any performance comparisons of gfs2 v. zfs?
our five-node cluster is working fine, the clustering software is great,
but when accessing gfs2-based files, enumer
Gordan Bobic wrote:
On 01/24/2011 07:16 PM, yvette hirth wrote:
hi all,
does anyone have any performance comparisons of gfs2 v. zfs?
our five-node cluster is working fine, the clustering software is great,
but when accessing gfs2-based files, enumeration can be very slow...
The comparison is
Hi,
On Mon, 2011-01-24 at 19:16 +, yvette hirth wrote:
> hi all,
>
> does anyone have any performance comparisons of gfs2 v. zfs?
>
Not that I'm aware of
> our five-node cluster is working fine, the clustering software is great,
> but when accessing gfs2-based files, enumeration can be ver
On 01/24/2011 07:16 PM, yvette hirth wrote:
hi all,
does anyone have any performance comparisons of gfs2 v. zfs?
our five-node cluster is working fine, the clustering software is great,
but when accessing gfs2-based files, enumeration can be very slow...
The comparison is a bit like comparing
hi all,
does anyone have any performance comparisons of gfs2 v. zfs?
our five-node cluster is working fine, the clustering software is great,
but when accessing gfs2-based files, enumeration can be very slow...
thanks!
yvette
--
Linux-cluster mailing list
Linux-cluster@redhat.com
https://www
35 matches
Mail list logo
