[Gluster-devel] missing files
David F. Robinson
david.robinson at corvidtec.com
Wed Feb 11 11:22:56 UTC 2015
Don't think it is the underlying file system. /data/brickxx is the underlying xfs. Performance to this is fine. When I created a volume it just puts the data in /data/brick/test2. The underlying filesystem shouldn't know/care that it is in a new directory.
Also, if I create a /data/brick/test2 volume and put data on it, it gets slow in gluster. But, writing to /data/brick is still fine. And, after test2 gets slow, I can create a /data/test3 volume that is empty and its speed is fine.
My knowledge is admittedly very limited here, but I don't see how it could be the underlying filesystem if the slowdown only occurs on the gluster mount and not on the underlying xfs filesystem.
David (Sent from mobile)
David F. Robinson, Ph.D.
President - Corvid Technologies
704.799.6944 x101 [office]
David.Robinson at corvidtec.com
> On Feb 11, 2015, at 12:18 AM, Justin Clift <justin at gluster.org> wrote:
>> On 11 Feb 2015, at 03:06, Shyam <srangana at redhat.com> wrote:
>> 2) We ran an strace of tar and also collected io-stats outputs from these volumes, both show that create and mkdir is slower on slow as compared to the fast volume. This seems to be the overall reason for slowness
> Any idea's on "why" the create and mkdir is slower?
> Wondering if it's a case of underlying filesystem parameters (for the bricks)
> + maybe physical storage structure having become badly optimised over time.
> eg if its on spinning rust, not ssd, and sector placement is now bad
> Any idea if there are tools that can analyse this kind of thing? eg meta
> data placement / fragmentation / on a drive for XFS/ext4
> + Justin
> GlusterFS - http://www.gluster.org
> An open source, distributed file system scaling to several
> petabytes, and handling thousands of clients.
> My personal twitter: twitter.com/realjustinclift
More information about the Gluster-devel