Best Of

Please direct all exam-related questions to the support team at [email protected]

ipcs is not dead. While you can configure a Linux system to not use System V IPCat all, I would not advise it as every time I look important constituents such as X and Gnome still use shared memory segments for example. And you will find a lot of applications that still use it. On the day where you find ipcs shows no usage, that will be different.

Also, please distinguish between System V init and System V IPC. Totally different things and that is where your confusion is coming in. System V is a an entire branch of the UNIX tree, half of it, and there are many things its name is attached to.

Hi @herecomesbrod ,

The most of times, having a look to the man page of the tool is useful. So, if we do "man lvcreate", this will show the following for "-s":

-s, --snapshot OriginalLogicalVolume{Name|Path}
Create a snapshot logical volume (or snapshot) for an existing, so called original logical volume (or origin). Snapshots provide a 'frozen image' of the contents of the origin while the origin can still be updated. They enable consistent backups and online recovery of removed/overwritten data/files. Thin snapshot is created when the origin is a thin volume and the size is not specified. Thin snapshot shares same blocks within the thin pool volume. The snapshot with the specified size does not need the same amount of storage the origin has. In a typical scenario, 15-20% might be enough. In case the snapshot runs out of storage, use lvextend(8) to grow it. Shrinking a snapshot is supported by lvreduce(8) as well. Run lvdisplay(8) on the snapshot in order to check how much data is allocated to it. Note that a small amount of the space you allocate to the snapshot is used to track the locations of the chunks of data, so you should allocate slightly more space than you actually need and monitor the rate at which the snapshot data is growing so you can avoid running out of space.

For, first thing we know now, is that a LVM snapshot will use (at the beginning at least) 15-20% of the original LVM volume size. And why's that? Because the snapshot works like a pointer to the blocks of the original lvm volume. So, when the original volume changes, the snapshot gets bigger because it needs to backup a bigger part of the original content (it uses a copy-on-write mechanism).

I found useful information here: https://www.clevernetsystems.com/lvm-snapshots-explained/
and here: https://serverfault.com/questions/41020/is-this-how-lvm-snapshots-work

I hope that helps.

Many regards,
Luis.

Hi @zhangwe,

You are correct, it does not work on latest Chrome version and it does not work on Edge browser either.

However, it works on Firefox and on older Chrome versions. Make sure you click on Advanced to be able to proceed.

Regards,-

-Chris

yes this is a valid point. note the "can be" in the sentence. There have been distributions which have forbid this.

Hello,

Thank you for the additional information. You did not follow Ex 8.1, step 13 properly. The step says to expose port 80 and create the deployment again. From your output, notice the last two lines I have quoted:

Ex 8.2, step 2
[email protected]:~$ kubectl -n accounting describe services
Name: service-lab
Namespace: accounting
Labels: system=secondary
Annotations:
Selector: system=secondary
Type: NodePort
IP: 10.97.208.233
Port: 8088/TCP
TargetPort: 8088/TCP

The traffic is being sent to 8088 instead of port 80.

Once the deployment has the port set to 80 you should be able to curl the pod IP, the ClusterIP, and then the NodePort. That is the order I would troubleshoot after the edit.

Regards,

It should read "Directly writing to disk from the command line (ignoring.." It was poorly phrased. This would mean doing something like "dd if=/dev/random of=/dev/sda1" or echo "Hello this is some message" > /dev/sda1" or "cp somefile /dev/sda1". All of these commands would wipe out whatever is in the beginning of the first partition on the disk; i.e., corrupting the superblock and making it unusable. In Linux this tends to be recoverable as there are multiple copies of the superblock on the disk, but believe me, you don't want to deal with this (and how hard it is to fix depends on the type of filesystem)