Thank you!
Depending on how complex your tool is, it may be better to use
llapi_layout_from_file() or llapi_layout_from_xattr() to parse the
binary layout directly from the file, rather than printing it out and
then parsing the text again in userspace.
at first the tool should be runable by
On Jan 23, 2023, at 10:01, Anna Fuchs
mailto:anna.fu...@uni-hamburg.de>> wrote:
Thanks!
Is it planned to introduce some metric propagation to the user?
For advanced users who are benchmarking stuff on remote systems it remains
unclear which performance to expect if they can not access
> Additionally, how can a user find out the mapping of all available OSTs to
> OSSs easily?
I've used variations on
grep -Fe failover_nids: -e current_connection: /proc/fs/lustre/*c/*/import
___
lustre-discuss mailing list
Thanks!
Is it planned to introduce some metric propagation to the user?
For advanced users who are benchmarking stuff on remote systems it
remains unclear which performance to expect if they can not access
underlaying hardware metrics.
Sure, they can ask the admin to share the config, but it
Hi Anna,
Beyond the number and size of OSTs and MDTs there isn't much information about
the underlying storage available on the client.
The "lfs df -v" command will print a "f" at the end for flash (non-rotational)
devices, if the storage is properly configured. The "osc*.imports " parameter
Hi,
is it possible for a user (no root, so ssh to server) to find out the
configuration of an OST?
How many devices are there in one OST 'pool' (for both ldiskfs and ZFS)
and even which type of devices they are (nvme, ssd, hdd)? Maybe even
speeds and raid-levels?
Additionally, how can a
