[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] GFS + iscsi target + LVM performance and file integrity

Sorry I got that, it's the file system integrity rather than "file/data" integrity.

The other thing on my mind is:
What would be the impact of adding more iscsi-target nodes to my LVM/GFS over SAN head?
Does it going to make an impact over file seek time (file lookup read/write) for the client machine accessing a file over GFS? 
f.e. a file's data can be stored on iscsi-target nodeA , some data on iscsi-target nodeX.

More disk space == more file lookup time?

in case such thing does not happens then why? How does it works?
Thanks and regards
Anuj Singh

On Wed, Apr 30, 2008 at 2:37 PM, अनुज Anuj Singh <anujhere gmail com> wrote:
Thanks for the reply.
I found this page, talking about simultaneous read/write to a single file system.

Red Hat GFS is commonly used in clusters of enterprise applications to provide high speed access to a consistent file system image across the server nodes. This allows the cluster nodes to simultaneously read and write to a single shared filesystem. Typical application clusters where Red Hat GFS is deployed today include:
-------------------------end of snap

Please can I have some technical idea, doc or flow chart type of thing regarding GFS mechanism.

Thanks and Regards
Anuj Singh.

On Wed, Apr 30, 2008 at 1:00 PM, Christine Caulfield <ccaulfie redhat com> wrote:
???? Anuj Singh wrote:
> Hi,
> I have a question related to GFS + LVM and iscsi.
> 1). I have a file test.txt on shared GFS file system, some user ramesh
> opens test.txt to read, at the same time some other user Smith on the
> network writes some data to test.txt file.
> What data will Ramesh see in test.txt file which is changed after he
> opened?
> How does GFS handles data integrity?

The same thing happens on GFS as would occur if you did that on a local
file system. GFS does not provide any additional data integrity features
over other file systems. If you can corrupt a file by writing to it from
two places using ext3 on one node, then the same thing will happen using
GFS, regardless of whether the processes are on the same or different nodes.

The point of GFS is not to provide data integrity, but /metadata/
integerity. ie, the filesystem itself does not become corrupted by two
nodes writing to the same inode or directory.

So, the basic rule is: if it would corrupt data if two people on the
same node did it on next3, then it will also corrupt data if two people
on different nodes did it on GFS.

I hope that's clear!


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]