I have started playing around with Lustre changelogs, and I have noticed a
behavior with the “lctl changelog_deregister” command that I don’t understand.
I tried running a little test by enabling changelogs on my MDS server:
[root@server ~]# lctl --device orhydra-MDT changelog_register
orhy
The route selection algorithm looks at:
1. Priority
2. Hop count
3. Number of bytes in transit (or queued)
4. Number of credits available
5. Which was used last
So, everything else being equal, step 5 will ensure round-robin. But there are
several other factors that are considered first.
At lea
Hi,
I was wondering if someone can help me with the following question about
LNETs:
When three writes are issued from a compute node to an OST, is it right
that the order in which the LNETs (corresponding to that OST) are used to
route the data from the compute node to the OST is the sequence in
Hmm, option-testing leads to more confusion:
With this 922GB-sdb1 I do
mkfs.lustre --reformat --mgs --mdt ... /dev/sdb1
The output of the command says
Permanent disk data:
Target: test0:MDT
...
device size = 944137MB
formatting backing filesystem ldiskfs on /dev/sdb1
target
Hi all,
what is the relation between raw device size and size of a formatted MDT? Size of inodes + free space
= raw size?
The example:
MDT device has 922 GB in /proc/partions.
Formatted under Lustre 2.5.3 with default values for mkfs.lustre resulted in a 'df -h' MDT of 692G and
more importan
