[Gluster-users] File Size and Brick Size
wongmlb at gmail.com
Tue Sep 27 18:46:22 UTC 2016
Thanks for introducing the sharding feature to me.
It does seems to resolve the problem i was encountering earlier. But I have
1 question, do we expect the checksum of the file to be different if i copy
from directory A to a shard-enabled volume?
[xxxxx at ip-172-31-1-72 ~]$ sudo sha1sum /var/tmp/oVirt-Live-4.0.4.iso
[xxxxx at ip-172-31-1-72 ~]$ sudo rsync -avH /var/tmp/oVirt-Live-4.0.4.iso
sending incremental file list
sent 1373802342 bytes received 31 bytes 30871963.44 bytes/sec
total size is 1373634560 speedup is 1.00
[xxxxx at ip-172-31-1-72 ~]$ sudo sha1sum /mnt/oVirt-Live-4.0.4.iso
On Mon, Sep 26, 2016 at 6:42 PM, Ravishankar N <ravishankar at redhat.com>
> On 09/27/2016 05:15 AM, ML Wong wrote:
> Have anyone in the list who has tried copying file which is bigger than
> the individual brick/replica size?
> Test Scenario:
> Distributed-Replicated volume, 2GB size, 2x2 = 4 bricks, 2 replicas
> Each replica has 1GB
> When i tried to copy file this volume, by both fuse, or nfs mount. i get
> I/O error.
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/vg0-brick1 1017M 33M 985M 4% /data/brick1
> /dev/mapper/vg0-brick2 1017M 109M 909M 11% /data/brick2
> lbre-cloud-dev1:/sharevol1 2.0G 141M 1.9G 7% /sharevol1
> [xxxxxx at cloud-dev1 ~]$ du -sh /var/tmp/ovirt-live-el7-3.6.2.iso
> 1.3G /var/tmp/ovirt-live-el7-3.6.2.iso
> [melvinw at lbre-cloud-dev1 ~]$ sudo cp /var/tmp/ovirt-live-el7-3.6.2.iso
> cp: error writing ‘/sharevol1/ovirt-live-el7-3.6.2.iso’: Input/output
> cp: failed to extend ‘/sharevol1/ovirt-live-el7-3.6.2.iso’: Input/output
> cp: failed to close ‘/sharevol1/ovirt-live-el7-3.6.2.iso’: Input/output
> Does the mount log give you more information? It it was a disk full issue,
> the error you would get is ENOSPC and not EIO. This looks like something
> I know, we have experts in this mailing list. And, i assume, this is a
> common situation where many Gluster users may have encountered. The worry
> i have what if you have a big VM file sitting on top of Gluster volume ...?
> It is recommended to use sharding (http://blog.gluster.org/2015/
> 12/introducing-shard-translator/) for VM workloads to alleviate these
> kinds of issues.
> Any insights will be much appreciated.
> Gluster-users mailing listGluster-users at gluster.orghttp://www.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-users