Hi all,
I'm trying to do a restripe after setting some nsds to metadataOnly and I
keep running into this error:
Scanning user file metadata ...
0.01 % complete on Wed Nov 1 15:36:01 2017 ( 40960 inodes with
total 531689 MB data processed)
Error processing user file metadata.
Check fi
system root. If you upgraded the file
> system to a newer version (so these files aren’t used) - There was a bug at
> one time where these didn’t get properly migrated during a restripe.
> Solution was to just remove them
>
>
>
>
>
> Bob Oesterlin
>
> Sr Princip
e been deleted, the inodes are freed up and you won’t see the (somewhat
> misleading) message
> about no space.
>
> — ddj
> Dave Johnson
> Brown University
>
> On Nov 2, 2017, at 10:43 AM, John Hanks wrote:
>
> Thanks all for the suggestions.
>
> Having our meta
t;
> Scott Fadden
> Spectrum Scale - Technical Marketing
> Phone: (503) 880-5833
> sfad...@us.ibm.com
> http://www.ibm.com/systems/storage/spectrum/scale
>
>
>
> - Original message -
> From: John Hanks
> Sent by: gpfsug-discuss-boun...@spectrumscale.org
>
move the last disk in a pool? If so did you empty the pool with
> a MIGRATE policy first?
>
>
> Scott Fadden
> Spectrum Scale - Technical Marketing
> Phone: (503) 880-5833
> sfad...@us.ibm.com
> http://www.ibm.com/systems/storage/spectrum/scale
>
>
>
> - Origi
> Fred Stock | IBM Pittsburgh Lab | 720-430-8821 <(720)%20430-8821>
> sto...@us.ibm.com
>
>
>
> From:John Hanks
> To:gpfsug main discussion list
> Date:11/02/2017 12:20 PM
> Subject:Re: [gpfsug-discuss] mmrestripefs &
Lab | 720-430-8821 <(720)%20430-8821>
> sto...@us.ibm.com
>
>
>
> From:John Hanks
> To:gpfsug main discussion list
> Date:11/02/2017 01:17 PM
> Subject:Re: [gpfsug-discuss] mmrestripefs "No space left
a LOT about all
the bits in the process. Many thanks to everyone who replied, I learn
something from this list every time I get near it.
Thank you,
jbh
On Thu, Nov 2, 2017 at 11:14 AM, John Hanks wrote:
> tsfindiconde tracked the file to user.quota, which somehow escaped my
> previous a
Hi,
We have a GPFS filesystem mounted on CentOS 7.4 as type gpfs, pretty
straightforward run of the mill stuff. But are seeing this odd behavior. If
I do this in a shell script, given a file called "a"
cat a a a a a a a a a a > /path/to/gpfs/mount/test
grep ATAG /path/to/gpfs/mount/test | wc -l
s
ltant IT Specialist
> Mobile Phone: +358503112585 <+358%2050%203112585>
> *https://www.youracclaim.com/user/luis-bolinches*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youracclaim.com_user_luis-2Dbolinches&d=DwMFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=1mZ896psa5caYzBeaugTlc7TtRejJp3uvKYxas3S7Xc&a
srv/gsfs0/projects/pipetest.tmp.txt: ASCII text, with very long lines
/home/griznog/pipetest.tmp.txt: ASCII text, with very long lines
I'll poke a little harder at grep next and see what the difference in
strace of each reveals.
Thanks,
jbh
On Wed, Feb 14, 2018 at 7:08 AM, wrote:
> On
grep is somehow using the file's size in its determination of binary
> status. I also see mmap in the strace so maybe there's some issue with
> mmap where some internal GPFS buffer is getting truncated
> inappropriately but leaving a bunch of null values which gets returned
> t
e’s your answer:
> http://www-01.ibm.com/support/docview.wss?uid=isg1IV87385
>
>
>
> Cheers,
>
> -Bryan
>
>
>
> *From:* gpfsug-discuss-boun...@spectrumscale.org [mailto:gpfsug-discuss-
> boun...@spectrumscale.org] *On Behalf Of *John Hanks
> *Sent:* Wednesday, Feb
13 matches
Mail list logo
