Re: [lustre-discuss] PFL not working on 2.10 client
I don’t think we need to have PFL working immediately, and since we have plans
to upgrade the client at some point, I will just wait and see what happens
after the upgrade.
--
Rick Mohr
Senior HPC System Administrator
National Institute for Computational Sciences
http://www.nics.tennessee.edu
> On Apr 23, 2019, at 4:59 AM, Andreas Dilger wrote:
>
> Does this still fail with 2.10.1 or a later client? It may just be a bug in
> "lfs" or the client, not an interop problem per-se. If it doesn't fail with a
> newer client then it probably isn't worthwhile to track down.
>
> If you _really_ need to get this working with the 2.10.0 client you could try
> the "lfs" binary (and possibly liblustreapi.so) from a newer client.
> Otherwise, upgrading the kernel modules to 2.10.0+patch is not much different
> than upgrading to 2.10.6 or 2.10.7 to fix this problem.
>
> Cheers, Andreas
>
> On Apr 22, 2019, at 15:15, Mohr Jr, Richard Frank wrote:
>>
>>
>> I was trying to play around with some PFL layout today, and I ran into an
>> issue. I have a file system running Lustre 2.10.6 and a client with 2.10.0
>> installed. I created a PFL with this command:
>>
>> [rfmohr@sip-login1 rfmohr]$ lfs setstripe -E 4M -c 2 -E 100M -c 4 comp_file
>>
>> It did not return any errors, so I tried to query the layout:
>>
>> [rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
>> comp_file has no stripe info
>>
>> And if I write any data to it, I end up with a file that uses the system’s
>> default stripe count:
>>
>> [rfmohr@sip-login1 rfmohr]$ dd if=/dev/zero of=comp_file bs=1M count=50
>> 50+0 records in
>> 50+0 records out
>> 52428800 bytes (52 MB) copied, 0.0825892 s, 635 MB/s
>>
>> [rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
>> comp_file
>> lmm_stripe_count: 1
>> lmm_stripe_size: 1048576
>> lmm_pattern: 1
>> lmm_layout_gen:0
>> lmm_stripe_offset: 3
>> obdidx objid objid group
>>3265665 0x40dc1 0
>>
>> I could not find a JIRA ticket that looked similar to this. Is this a known
>> bug? Or some odd interop issue? When I tried the command on another file
>> system that uses 2.10.3 on the servers and clients, I got the expected
>> behavior:
>>
>> -bash-4.2$ lfs setstripe -E 4M -c 2 -E 64M -c 4 comp_file
>>
>> -bash-4.2$ lfs getstripe comp_file
>> comp_file
>> lcm_layout_gen: 2
>> lcm_entry_count: 2
>> lcme_id: 1
>> lcme_flags: init
>> lcme_extent.e_start: 0
>> lcme_extent.e_end: 4194304
>> lmm_stripe_count: 2
>> lmm_stripe_size: 1048576
>> lmm_pattern: 1
>> lmm_layout_gen:0
>> lmm_stripe_offset: 6
>> lmm_objects:
>> - 0: { l_ost_idx: 6, l_fid: [0x10006:0x8f84d:0x0] }
>> - 1: { l_ost_idx: 7, l_fid: [0x10007:0x8f72d:0x0] }
>>
>> lcme_id: 2
>> lcme_flags: 0
>> lcme_extent.e_start: 4194304
>> lcme_extent.e_end: 67108864
>> lmm_stripe_count: 4
>> lmm_stripe_size: 1048576
>> lmm_pattern: 1
>> lmm_layout_gen:65535
>> lmm_stripe_offset: -1
>>
>> --
>> Rick Mohr
>> Senior HPC System Administrator
>> National Institute for Computational Sciences
>> http://www.nics.tennessee.edu
>>
>> ___
>> lustre-discuss mailing list
>> lustre-discuss@lists.lustre.org
>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Re: [lustre-discuss] PFL not working on 2.10 client
Rick,
Does this still fail with 2.10.1 or a later client? It may just be a bug in
"lfs" or the client, not an interop problem per-se. If it doesn't fail with a
newer client then it probably isn't worthwhile to track down.
If you _really_ need to get this working with the 2.10.0 client you could try
the "lfs" binary (and possibly liblustreapi.so) from a newer client. Otherwise,
upgrading the kernel modules to 2.10.0+patch is not much different than
upgrading to 2.10.6 or 2.10.7 to fix this problem.
Cheers, Andreas
On Apr 22, 2019, at 15:15, Mohr Jr, Richard Frank wrote:
>
>
> I was trying to play around with some PFL layout today, and I ran into an
> issue. I have a file system running Lustre 2.10.6 and a client with 2.10.0
> installed. I created a PFL with this command:
>
> [rfmohr@sip-login1 rfmohr]$ lfs setstripe -E 4M -c 2 -E 100M -c 4 comp_file
>
> It did not return any errors, so I tried to query the layout:
>
> [rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
> comp_file has no stripe info
>
> And if I write any data to it, I end up with a file that uses the system’s
> default stripe count:
>
> [rfmohr@sip-login1 rfmohr]$ dd if=/dev/zero of=comp_file bs=1M count=50
> 50+0 records in
> 50+0 records out
> 52428800 bytes (52 MB) copied, 0.0825892 s, 635 MB/s
>
> [rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
> comp_file
> lmm_stripe_count: 1
> lmm_stripe_size: 1048576
> lmm_pattern: 1
> lmm_layout_gen:0
> lmm_stripe_offset: 3
>obdidx objid objid group
> 3265665 0x40dc1 0
>
> I could not find a JIRA ticket that looked similar to this. Is this a known
> bug? Or some odd interop issue? When I tried the command on another file
> system that uses 2.10.3 on the servers and clients, I got the expected
> behavior:
>
> -bash-4.2$ lfs setstripe -E 4M -c 2 -E 64M -c 4 comp_file
>
> -bash-4.2$ lfs getstripe comp_file
> comp_file
> lcm_layout_gen: 2
> lcm_entry_count: 2
>lcme_id: 1
>lcme_flags: init
>lcme_extent.e_start: 0
>lcme_extent.e_end: 4194304
> lmm_stripe_count: 2
> lmm_stripe_size: 1048576
> lmm_pattern: 1
> lmm_layout_gen:0
> lmm_stripe_offset: 6
> lmm_objects:
> - 0: { l_ost_idx: 6, l_fid: [0x10006:0x8f84d:0x0] }
> - 1: { l_ost_idx: 7, l_fid: [0x10007:0x8f72d:0x0] }
>
>lcme_id: 2
>lcme_flags: 0
>lcme_extent.e_start: 4194304
>lcme_extent.e_end: 67108864
> lmm_stripe_count: 4
> lmm_stripe_size: 1048576
> lmm_pattern: 1
> lmm_layout_gen:65535
> lmm_stripe_offset: -1
>
> --
> Rick Mohr
> Senior HPC System Administrator
> National Institute for Computational Sciences
> http://www.nics.tennessee.edu
>
> ___
> lustre-discuss mailing list
> lustre-discuss@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
[lustre-discuss] PFL not working on 2.10 client
I was trying to play around with some PFL layout today, and I ran into an
issue. I have a file system running Lustre 2.10.6 and a client with 2.10.0
installed. I created a PFL with this command:
[rfmohr@sip-login1 rfmohr]$ lfs setstripe -E 4M -c 2 -E 100M -c 4 comp_file
It did not return any errors, so I tried to query the layout:
[rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
comp_file has no stripe info
And if I write any data to it, I end up with a file that uses the system’s
default stripe count:
[rfmohr@sip-login1 rfmohr]$ dd if=/dev/zero of=comp_file bs=1M count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.0825892 s, 635 MB/s
[rfmohr@sip-login1 rfmohr]$ lfs getstripe comp_file
comp_file
lmm_stripe_count: 1
lmm_stripe_size: 1048576
lmm_pattern: 1
lmm_layout_gen:0
lmm_stripe_offset: 3
obdidx objid objid group
3 2656650x40dc10
I could not find a JIRA ticket that looked similar to this. Is this a known
bug? Or some odd interop issue? When I tried the command on another file
system that uses 2.10.3 on the servers and clients, I got the expected behavior:
-bash-4.2$ lfs setstripe -E 4M -c 2 -E 64M -c 4 comp_file
-bash-4.2$ lfs getstripe comp_file
comp_file
lcm_layout_gen: 2
lcm_entry_count: 2
lcme_id: 1
lcme_flags: init
lcme_extent.e_start: 0
lcme_extent.e_end: 4194304
lmm_stripe_count: 2
lmm_stripe_size: 1048576
lmm_pattern: 1
lmm_layout_gen:0
lmm_stripe_offset: 6
lmm_objects:
- 0: { l_ost_idx: 6, l_fid: [0x10006:0x8f84d:0x0] }
- 1: { l_ost_idx: 7, l_fid: [0x10007:0x8f72d:0x0] }
lcme_id: 2
lcme_flags: 0
lcme_extent.e_start: 4194304
lcme_extent.e_end: 67108864
lmm_stripe_count: 4
lmm_stripe_size: 1048576
lmm_pattern: 1
lmm_layout_gen:65535
lmm_stripe_offset: -1
--
Rick Mohr
Senior HPC System Administrator
National Institute for Computational Sciences
http://www.nics.tennessee.edu
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
