similar to: 3.0.5 RDMA clients seem broken

Hi, We have recently upgraded our gluster to 3.2.5 and have encountered the following error. Gluster seems somehow confused about one of the files it should be serving up, specifically /projects/philex/PE/2010/Oct18/arch07/BalbacFull_250_200_03Mar_3.png If I go to that directory and simply do an ls *.png I get ls: BalbacFull_250_200_03Mar_3.png: Structure needs cleaning (along with a listing

OK - finished some tests over tcp and ironed out a lot of problems. rdma is next; should be snap now.... [I must admit that this is my 1st foray into the land of IB, so some of the following may be obvious to a non-naive admin..] except that while I can create and start the volume with rdma as transport: ================================== root at pbs3:~ 622 $ gluster volume info glrdma

Hi all! What's the best way to stop the CLIENT process for Gluster? We have dual systems, where the Gluster servers also act as clients, so both, glusterd and glusterfsd are running on the system. Stopping the server app. works via "/etc/init.d/glusterd stop" but the client is stopped how? I need to unmount the filesystem from the server in order to do a fsck on the ext4 volume;

Hello gluster-verse! I'm about to see if GlusterFS can handle a large amount of clients, this was not at all in plans when we initially selected and setup our current configuration. What sort of experience do you (the collective "you" as in y'all) have with a large client to storage brick server ratio? (~1330:1) Where do you see things going awnry? Most of this will be reads

Hi folks: Firewire was not supported in 4.0 due to the upstream provider not including it. Is it in 4.1? Or is it still out of the mainline upstream kernel provider? What about centosplus? Centosplus has been listed as unsupported. I presume this means that they are/were one-off builds with missing functionality (e.g. xfs, etc), and are not updated. Is this the case? I am looking

Howdy, are any of the Gluster folks going to SC10 next week? Mike

I have been tweaking and researching for a while now and can't seem to get "good" performance out of Gluster. I'm using Gluster to replace an NFS server (c1.xlarge) that serves files to an array of web servers, all in EC2. In my tests Gluster is significantly slower than NFS on average. I'm using a distributed replicated volume on two (m1.large) bricks: Volume Name: ebs

Hi all, I am having problems with painfully slow directory listings on a freshly created replicated volume. The configuration is as follows: 2 nodes with 3 replicated drives each. The total volume capacity is 5.6T. We would like to expand the storage capacity much more, but first we need to figure this problem out. Soon after loading up about 100 MB of small files (about 300kb each), the

Our webserver is configured as such: The actual website files, php, html ,css and so on. Or on a dedicated non-glusterfs ext4 partition. However, the website access Videos and especially image files on a gluster mounted directory. The write performance for our backend gluster storage is not that important. Since it only comes into play when someone uploads a video or image. However, the files

We're considering implementing gluster for a genomics cluster, and it seems to have some theoretical advantages that so far seem to have been borne out in some limited testing, mod some odd problems with an inability to delete dir trees. I'm about to test with the latest beta that was promised to clear up these bugs, but as I'm doing that, answers to these Qs would be

GlusterFS newbie (less than a week) here. Running GlusterFS 3.2.6 servers on Dell PE2900 systems with four 3.16 GHz Xeon cores and 16 GB memory under CentOS 5.8. For this test, I have a distributed volume of one brick only, so no replication. I have made performance measurements with both dd and Bonnie++, and they confirm each other; here I report only the dd numbers (using bs=1024k). File

Suppose I start building nodes with (say) 24 drives each in them. Would the standard/recommended approach be to make each drive its own filesystem, and export 24 separate bricks, server1:/data1 .. server1:/data24 ? Making a distributed replicated volume between this and another server would then have to list all 48 drives individually. At the other extreme, I could put all 24 drives into some

Hi, I've been migrating data from an old striped 3.0.x gluster install to a 3.3 beta install. I copied all the data to a regular XFS partition (4K blocksize) from the old gluster striped volume and it totaled 9.2TB. With the old setup I used the following option in a "volume stripe" block in the configuration file in a client : volume stripe type cluster/stripe option

A bit off topic, but having trouble again with the 64-bit libs when trying to compile this short fortran code to build a shared object. Can anyone offer an explaination of what is meant by the relocation bit, and how to fix it? I've tried the -fPIC, but apparently I either didn't have it in the right place or it does not work. Be glad to take this offline if somone could help me.

On Tue, Nov 08, 2005 at 08:04:54AM -0800, Bryan J. Smith wrote: > > > NAS offers safe concurent access (generally, there might be > > some NAS devices outthere that do not). NAS device will > > manage file system internally, and export it over NFS or > > SMB protocols to the clients. > > Such NAS' are a combined host+storage aka

Hi everyone I have installed 3.3.1-1 from the Debian repository you provide. I am using a simple 2 node cluster and running in replication mode. The connection between the nodes is limited to 100MB/sec (that's bits not bytes!). Usage will be mainly for read access and since there is always a local copy available [ exactly 2 replicas on exactly 2 machines ] I expect very fast read

I can't seem to get the read and write performance better than approximately 40MB/s on an ext2 file system. IMO, this is horrible performance for a 6-drive, hardware RAID 5 array. Please have a look at what I'm doing and let me know if anybody has any suggestions on how to improve the performance... System specs: ----------------- 2 x 2.8GHz Xeons 6GB RAM 1 3ware 9500S-12 2 x 6-drive,

Despite Joe Landman's sage advice to the contrary, I'm trying to convince an IPoIB volume to service requests from a GbE client via some /etc/hosts manipulation. (This may or may not be related to the automount problems we're having as well.) This has worked (and continues to work) well on another cluster with a slightly older version of gluster - the 3.3.0qa42 version on both server

On 4/11/19 4:01 AM, Yuval Shaia wrote: > +++ b/drivers/infiniband/hw/virtio/Kconfig > @@ -0,0 +1,6 @@ > +config INFINIBAND_VIRTIO_RDMA > + tristate "VirtIO Paravirtualized RDMA Driver" > + depends on NETDEVICES && ETHERNET && PCI && INET > + ---help--- > + This driver provides low-level support for VirtIO Paravirtual > + RDMA adapter.

On Thu, Apr 11, 2019 at 02:01:56PM +0300, Yuval Shaia wrote: > diff --git a/include/standard-headers/linux/virtio_ids.h b/include/standard-headers/linux/virtio_ids.h > index 6d5c3b2d4f..bd2c699450 100644 > --- a/include/standard-headers/linux/virtio_ids.h > +++ b/include/standard-headers/linux/virtio_ids.h > @@ -43,5 +43,6 @@ > #define VIRTIO_ID_INPUT 18 /* virtio input