[Gluster-devel] Re: Problems while upgrading from 1.2.x to 1.3.x
krishna at zresearch.com
Wed Oct 24 07:43:10 UTC 2007
On 10/24/07, NovA <av.nova at gmail.com> wrote:
> Hi again!
> Well, using debug logging I've got some understanding... The problem
> is that files and directories on bricks has inconsistent inode numbers
> for new 1.3.x GlusterFS. Different files don't allowed to have the
> same inodes, which is typical situation in unifed GlusterFS 1.2
> volume. The question is, what is the client behavior in such a case?
> It could happen on working system, if one create a file on backend FS
> for example...
When you are using unify which uses NS to decide on the inode number,
it can not happen so that two files have same inode number because
the NS will be on the same filesystem. How did you conclude that two
files got the same inode number?
Can you paste your spec files? Can you make sure that both glusterfs
and glusterfsd are of the same version?
> And the more practical question: Is there a way to convert FS without
> recreating file structure? In my case, the data on GlusterFS 1.2 is
> too large to be saved on one HDD and then moved on new gluster
Yes, selfhealing should take care of it.
> Thanks in advance for any comments.
> 2007/10/23, NovA <av.nova at gmail.com>:
> > I'm trying to switch my GlusterFS unify storage from 1.2.tla184 to the
> > new 1.3.tla524... First attempt I've described earlier (
> > http://lists.gnu.org/archive/html/gluster-devel/2007-09/msg00004.html
> > ), but I couldn't experiment on production system till now.
> > So, I have working setup for 1.2.х GlusterFS unify with a lot of data
> > scattered on 10 servers. I want to replace GlusterFS to 1.3.x and keep
> > all data. Is this possible?
> > Now I've just updated FUSE to 2.7.0-glfs5, reinstalled GlusterFS,
> > changing spec files appropriately (see previous post) and got several
> > strange behaviors
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
More information about the Gluster-devel