On Tue, Nov 3, 2009 at 6:21 AM, Gordan Bobic
<address@hidden> wrote:
On 02/11/2009 21:18, Anand Babu Periasamy wrote:
Gordan Bobic wrote:
It would appear that this requires fuse-devel to build, at least as an
RPM. My understanding was that 3.0 doesn't require fuse libraries and
talks directly to the kernel module. Is that an error in my
understanding or an error in the spec file for building the RPMs?
Hi Gordan, you are correct. GlusterFS 3.0 does not require fuse library.
It directly talks
to fuse kernel module. Csaba Henk (fuse maintainer) implemented this
functionality.
He is part of GlusterFS team, dedicated to enhancing fuse kernel module.
This approach
makes installation relatively easier and improves performance as well.
Well Gordan problem is ours, thanks for pointing it .. it needs to be fixed. fuse-devel
is not a requirement.
Key highlights of 3.0 are
* Background self-healing: Applications won't be blocked any more during
healing operation.
* Checksum based healing: Rsync like healing mechanism to heal only the
inconsistent blocks within a file.
* Healing on the fly: Files can be healed even when the files are open
and application is performing active I/O.
* Generation numbers: Self-healing can now reliably handle tricky corner
cases (such as "rm -rf" bug).
Thanks, I already got a blurb on the subject from Harsha last week. :)
All of the above are very useful in a virtualization and database
environment, where files
are very large and applications need to run non-stop.
I'd still say that healing on open files should be been a requirement for 1.0, not to mention outright erroneous behaviour (the mentioned rm -rf bug). But better late than never. ;)
I'll check the bugs I reported against 2.0.x this week and report back on how many of them don't show up any more.
Thanks
Harshavardhana
Gordan