search for: 17t

...02.dfci.harvard.edu:/mnt/data03 A df -h on the cortex-dr-001: Filesystem Size Used Avail Use% Mounted on /dev/md2 66G 4.6G 58G 8% / /dev/md0 71G 186M 68G 1% /opt tmpfs 5.9G 0 5.9G 0% /dev/shm /dev/sde1 17T 83G 17T 1% /mnt/data03 /dev/sdd1 39T 182G 38T 1% /mnt/data02 /dev/sdc1 39T 81G 39T 1% /mnt/data01 A df -h from the client: Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 12G 7.7G...

...t for all the bricks is ~163T. Close enough for me to believe everything is there. The total for used space in the df ?h of the mountpoint it 83T, roughly half what is used. Relevant lines from df ?h on server-A: Filesystem Size Used Avail Use% Mounted on /dev/sda1 59T 42T 17T 72% /bricks/data_A1 /dev/sdb1 59T 45T 14T 77% /bricks/data_A2 /dev/sdd1 59T 39M 59T 1% /bricks/data_A4 /dev/sdc1 59T 1.9T 57T 4% /bricks/data_A3 server-A:/dataeng 350T 83T 268T 24% /dataeng And on server-B: Filesystem Size Used Avail...

We noticed something similar. Out of interest, does du -sh . show the same size? -- Sam McLeod (protoporpoise on IRC) https://smcleod.net https://twitter.com/s_mcleod Words are my own opinions and do not necessarily represent those of my employer or partners. > On 31 Jan 2018, at 12:47 pm, Freer, Eva B. <freereb at ornl.gov> wrote: > > After OS update to CentOS 7.4 or RedHat

After OS update to CentOS 7.4 or RedHat 6.9 and update to Gluster 3.12.4, the ?df? command shows only part of the available space on the mount point for multi-brick volumes. All nodes are at 3.12.4. This occurs on both servers and clients. We have 2 different server configurations. Configuration 1: A distributed volume of 8 bricks with 4 on each server. The initial configuration had 4 bricks of

...1 (in [0]) 567 read(0, "", 8192) = 0 567 select(5, [4], [4], NULL, NULL) = 1 (out [4]) 567 write(4, "\0\0\0\5b\311R$\332K[9", 12) = 12 567 select(5, [4], [], NULL, NULL) = 1 (in [4]) 567 read(4, "\0\0\0\n\216\177\16\252\305\31\213y\373,[\2\10T\17t", 8192) = 20 567 select(5, [4], [1], NULL, NULL) = 1 (out [1]) 567 write(1, "\0", 1) = -1 EPIPE (Broken pipe) 567 --- SIGPIPE (Broken pipe) --- 567 write(1, "\0", 1) = -1 EPIPE (Broken pipe) 567 --- SIGPIPE (Broken pipe) --- 567...

...*"F-O;F9I9W5R M93HW.#,Z(&-H96-K:6YG(&9O<B!A($)31"!C;VUP871I8FQE(&EN<W1A;&P* M8V]N9FEG=7)E.C at S-CH@8VAE8VMI;F<@=VAE=&AE<B!B=6EL9"!E;G9I<F]N M;65N="!I<R!S86YE"F-O;F9I9W5R93HX.3,Z(&-H96-K:6YG('=H971H97(@ M;6%K92!S971S("1[34%+17T*8V]N9FEG=7)E.CDS.3H at 8VAE8VMI;F<@9F]R M('=O<FMI;F<@86-L;V-A;"TQ+C0*8V]N9FEG=7)E.CDU,CH at 8VAE8VMI;F<@ M9F]R('=O<FMI;F<@875T;V-O;F8*8V]N9FEG=7)E.CDV-3H at 8VAE8VMI;F<@ M9F]R('=O<FMI;F<@875T;VUA:V4M,2XT"F-O;F9I9W5R93HY-S at Z(&-H96-K M:6YG(&...

Hello list. I'm trying to rebuild the 2.6.9.67.0.20.EL kernel, but it fails even without modifications. How did I try it? Created a (non-root) build environment (not a mock ) Installed the kernel.scr.rpm and did a rpmbuild -ba --target=`uname -m` kernel-2.6.spec 2> prep-err.log | tee prep-out.log The build failed at the end: Processing files: kernel-xenU-devel-2.6.9-67.0.20.EL Checking