How i can get the uuid in uefi of a partition which i have the device_handle of?
For example i'm iterating through the partitions in uefi and i want to get the uuid of the partition. (This is a gpt disk.)
A "GPT Partition Entry" has 2 GUIDs
PartitionTypeGUID Unique ID that defines the purpose and type of this
Partition. A value of zero defines that this partition entry is not
being used.
UniquePartitionGUID GUID that is unique for every partition entry.
Every partition ever created will have a unique GUID. This GUID must
be assigned when the GPT Partition Entry is created. The GPT Partition
Entry is created whenever the NumberOfPartitionEntr ies in the GPT
Header is increased to include a larger range of addresses.
I consider you are looking for the UniquePartitionGUID
If you have the partition associated device_handle then you can get the corresponding DevicePath i.e using gnu-efi
DevicePath=DevicePathFromHandle(partition_handle);
next you parse the DevicePath looking for a node as follow
-Generic Device Path Header- where
Type = Media Device Path (0x04)
Sub type = Hard Drive (0x01)
...
Partition Signature = partition GUID <<<<<<<<
Partition Format = GPT (0x02)
within this structure you'll find your needed GUID
Reference UEFI spec 2.5 (chapter 9)
In the GPT header at offset 56 is a 16-byte DiskGUID that can be used to uniquely identify the disk. (Efi specs 5.3.2).
Related
Can i smhow get index of a query response in DyanmoDB?
[hashKey exists, sortKey exists]
query { KeyCondExp = "hashKey = smthin1", FilterExp = "nonPrimeKey = smthin2" }
I need index of row according to sortKey for that selected document
When a DynamoDB Query request returns an item - in your example chosen by a specific filter - it will return the full item, including the sort key. If that is what you call "the index of row according to sortKey", then you are done.
If, however, by "index" you mean the numeric index - i.e., if the item is the 100th sort key in this partition (hash key), you want to return the number 100 - well, that you can't do. DynamoDB keeps rows inside a partition sorted by the sort key, but not numbered. You can insert an item in the middle of a million-row partition, and it will be inserted in the right place but DynamoDB won't bother to renumber the million-row list just to maintain numeric indexes.
But there is something else you should know. In the query you described, you are using a FilterExpression to return only specific rows out of the entire partition. With such a request, Amazon will charge you for reading the entire partition, not just the specific rows returned after the filter. If you're charged for reading the entire partition, you might as well just read it all, without a filter, and then you can actually count the rows and get the numeric index of the match if that's what you want. Reading the entire partition will cause you more work at the client (and more network traffic), but will not increase your DynamoDB RCU bill.
I have a guid which Sysinternals tools named Sysmon left.
It looks like this.
3/18 C591B94E-4BDD-5AAE-0000-001073B13706
4/4 C591B94E-1BFA-5AC5-0000-0010E76F3903
4/29 C591B94E-A33F-5AE5-0000-001074CA4C26
5/2(different windows account) C591B94E-E23B-5AE9-0000-0010DD40EF32
5/2(on the virtual machine) A15730FB-E3DA-5AE9-0000-0010AB2C0800
It's generated when the process is created(Event id 1) in my computer on different days and different environment.
And I Found the uuid format (https://en.wikipedia.org/wiki/Universally_unique_identifier)
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx(M indicate the UUID version, and the one to three most significant bits of digit N indicate the UUID variant)
According to this, my 3/18 example is C591B94E-4BDD-5AAE-0000-001073B13706. It means M is 5, N is 0, In other words, UUID version is 5, variant is 0. It means It's SHA-1 Hash Value(Version 5) and Variant is 0.
I really wonder what the other number does mean. Because the sysmon's documents says that guid is helpful for correlation BUT they never explain what does this number mean.
I can guess the first group is related to PC information. because only when I chanaged the PC(5/2 on the virtual machine) the first group is changed(C591B94E -> A15730FB). So I thought It's related to Mac or IP address. But even if I changed the MAC and IP address, It stayed A15730FB or C591B94E.
I'm sure the second group is related to time.
But I can't figure out what does this exactly mean.
The GUID does not specifically mean anything in itself. Its purpose is to allow you to correlate and filter process events when Windows reuses process IDs (in this way you can think of it as a completely unique process ID).
From: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
"Includes a process GUID in process create events to allow for correlation of events even when Windows reuses process IDs."
TitanDB 1.0.0 (on top of DynamoDB)
Gremlin 3
I've got a set of vertices with a label a. I have a property of type long on those vertices which corresponds to the time in milliseconds from 1970 UTC (timestamp of when the vertex was created.) When I pull back those vertices I want to be able to pull them back in decsending order.
How can I create an index on that property in the decr order in Titan Management System?
Documentation seems vague on that.
Closest thing I found is
public RelationTypeIndex buildPropertyIndex(PropertyKey key,
String name,
Order sortOrder,
PropertyKey... sortKeys)
But what do I put in as the key and sortKeys? I want to be able to pull the whole vertex ordered by the timestamp property
Edit: The only way I know of doing this at the minute is by duplicating that property on the edge and using a vertex centric index on the edge to increase the performance.
I do something similar as I order by the release date of a particular product. If you want to execute order().by("Value", decr) efficiently then I highly recommend reading into mixed indices specified here. Mixed indices allow these operations to be done quickly.
An example of what you may be looking for:
TitanGraph graph = TitanFactory.open(config);
TitanManagement mgmt = graph.openManagement();
PropertyKey key = mgmt.makePropertyKey("TimeStamp").dataType(Long.class).make();
mgmt.buildIndex("timeStampIndex", Vertex.class).addKey(key).buildMixedIndex("search");
mgmt.commit();
The above index lets me execute the following query very quickly:
g.V().order().by("TimeStamp", decr);
Which gets me the time stamps in descending order. The above traversal will work without indexing but can be slow in large graphs.
Is there a way to determine the number of nodes in a Cassandra cluster without first having a context?
I am trying to get that number to make sure that the user does not give me a replicating factor that is too large (i.e. says 10 with only 9 nodes.)
Important: At this point, the only interface I have is thrift in C.
Note: I looked into using the describe_ring() but unfortunately, the function forces you to have a valid context (so it describes the ring for that context and not the number of existing nodes in a Cassandra cluster.)
You can look at the system table using the Thrift protocol: system.peers. Here are listed all others nodes and their information, but not the local node. By counting the number of nodes in system.peers, the total node count is entries_count_in_peers + 1
Below is the structure (CQL) of the system.peers table
CREATE TABLE system.peers (
peer inet PRIMARY KEY,
data_center text,
host_id uuid,
preferred_ip inet,
rack text,
release_version text,
rpc_address inet,
schema_version uuid,
tokens set<text>
)
There is one partition (row key in Thrift terminology) per node
I have a question taken from pg 16 of IBM's Nested Relational Database White Paper, I'm confused why in the below CREATE command they use MV/MS/MS rather than MV/MV/MS, when both ORDER_#, and PART_# are one-to-many relationships.. I don't understand what value, vs sub-value means in non-1nf database design. I'd also like to know to know more about the ASSOC () clause.
Pg 16 of IBM's Nested Relational Database White Paper (slight whitespace modifications)
CREATE TABLE NESTED_TABLE (
CUST# CHAR (9) DISP ("Customer #),
CUST_NAME CHAR (40) DISP ("Customer Name"),
ORDER_# NUMBER (6) DISP ("Order #") SM ("MV") ASSOC ("ORDERS"),
PART_# NUMBER (6) DISP (Part #") SM ("MS") ASSOC ("ORDERS"),
QTY NUMBER (3) DISP ("Qty.") SM ("MS") ASSOC ("ORDERS")
);
The IBM nested relational databases implement nested tables as repeating attributes and
repeating groups of attributes that are associated. The SM clauses specify that the attribute is either repeating (multivalued--"MV") or a repeating group (multi-subvalued--"MS"). The ASSOC clause associates the attributes within a nested table. If desired, the IBM nested relational databases can support several nested tables within a base table. The following standard SQL statement would be required to process the 1NF tables of Figure 5 to produce the report shown in Figure 6:
SELECT CUSTOMER_TABLE.CUST#, CUST_NAME, ORDER_TABLE.ORDER_#, PART_#, QTY
FROM CUSTOMER_TABLE, ORDER_TABLE, ORDER_CUST
WHERE CUSTOMER_TABLE.CUST_# = ORDER_CUST.CUST_# AND ORDER_CUST.ORDER_# =
ORDER _TABLE.ORDER_#;
Nested Table
Customer # Customer Name Order # Part # Qty.
AA2340987 Zedco, Inc. 93-1123 037617 81
053135 36
93-1154 063364 32
087905 39
GV1203948 Alphabravo 93-2321 006776 72
055622 81
067587 29
MT1238979 Trisoar 93-2342 005449 33
036893 52
06525 29
93-4596 090643 33
I'll go ahead and answer my own question, while pursuing IBM's UniVerse SQL Administration for DBAs I came across code for CREATE TABLE on pg 55.
ACT_NO INTEGER FORMAT '5R' PRIMARY KEY
BADGE_NO INTEGER FORMAT '5R' PRIMARY KEY
ANIMAL_ID INTEGER FORMAT '5L' PRIMARY KEY
(see distracting side note below) This amused me at first, but essentially I believe this to be a column directive the same as a table directive like PRIMARY ( ACT_NO, BADGE_NO, ANIMAL_ID )
Later on page 5-19, I saw this
ALTER TABLE LIVESTOCK.T ADD ASSOC VAC_ASSOC (
VAC_TYPE KEY, VAC_DATE, VAC_NEXT, VAC_CERT
);
Which leads me to believe that tacking on ASSOC (VAC_ASSOC) to a column would be the same... like this
CREATE TABLE LIVESTOCK.T (
VAC_TYPE ... ASSOC ("VAC_ASSOC")
VAC_DATE ... ASSOC ("VAC_ASSOC")
VAC_NEXT ... ASSOC ("VAC_ASSOC")
VAC_cERT ... ASSOC ("VAC_ASSOC")
);
Anyway, I'm not 100% sure I'm right, but I'm guessing the order doesn't matter, and that rather than these being an intransitive association they're just a order-insensitive grouping.
Onward! With the second part of the question pertaining to MS and MV, I for the life of me can not figure out where the hell IBM got this syntax from. I believe it to be imaginary. I don't have access to a dev machine I can play on to test this out, but I can't find it (the term MV) in the old 10.1 or the new UniVerse 10.3 SQL Reference
side note for those not used to UniVerse the 5R and 5L mean 5 characters right or left justified. That's right a display feature built into the table meta data... Google for UniVerse FORMAT (or FMT) for more info.
Just so you know, Attribute, Multivalue and Sub-Multivalue comes from the way they structure their data.
Essentially, all data is stored in a tree of sorts.
UniVerse is a Multivalue Database. Generally, it does not work in the say way as Relational DBs of the SQL work function.
Each record can have multiple attributes.
Each attribute can have multiple multivalues.
Each multivalue can have multiple sub-multivalues.
So, if I have a record called FRED
Then, FRED<1,2,3> refers to the 1st attribute, 2 multivalue position and 3 subvalue position.
To read more about it, you need to learn more about how UniVerse works. The SQL section is just a side part of it. I suggest you read the other manuals to understand what you are working with.
EDIT
Essentially, the code above is telling you that:
There may be multiple orders per client. These are stored at an MV level in the 'table'
There may be multiple parts per order. These are stored at the MS level in the 'table'
There may be multiple qtys per order. These are stored at the MS level in the 'table'. since they are at the same level, although they are 1-n for orders, they are 1-1 in regards to parts.