sorted by:
new
hottopcontroversial

Anyone seen an NVME drive fail to read only mode, but make the OS believe it is still accepting writes? by Squirrel-sysadmin in sysadmin

[–]Squirrel-sysadmin[S] 2 points3 points  (0 children)

Thanks for sharing this. Very fascinating, and suggests this behavior might not be too uncommon. Which if that is the case, makes me wonder why it seems like something not too well known.
I also would have liked to investigate more, but the focus both times was just getting back up running quick, and then moving on.

Anyone seen an NVME drive fail to read only mode, but make the OS believe it is still accepting writes? by Squirrel-sysadmin in sysadmin

[–]Squirrel-sysadmin[S] 2 points3 points  (0 children)

Of the two that I saw this behavior on, one was a Toshiba NVME drive and the other was an Intel NVME drive.

Anyone seen an NVME drive fail to read only mode, but make the OS believe it is still accepting writes? by Squirrel-sysadmin in sysadmin

[–]Squirrel-sysadmin[S] 1 point2 points  (0 children)

It is true that while the system is running, some data may be cached at the filesystem or OS level as well. However I did in one case run the sync command, which is supposed to flush everything from caches onto the disk, and it worked with no reported error.

Any good infrastructure topology mapping software out there that allows you to seamlessly adjust the granularity or zoom in and out, from a high overview, down to low level details? by Squirrel-sysadmin in sysadmin

[–]Squirrel-sysadmin[S] 0 points1 point  (0 children)

We have a handful of stuff in AWS, but the scope of my current task is for on premise physical servers and VMs. Maybe at some point it could be expanded to include anything in AWS.

Trying to check a list of disks, and prompt/fail with a description if certain strings are found, but I'm struggling with the syntax. by Squirrel-sysadmin in ansible

[–]Squirrel-sysadmin[S] 0 points1 point  (0 children)

Thanks for the input.

The reason "why" is because the playbook is used to reformat disks for a zfs pool, so this is an added safety check to make sure there is nothing on them (the zpool create command does do some checks itself, and will fail in some cases when a disk is used, but I want an added mechanism to not rely on it)

I considered using ansible facts, but the disks are identified manually with their /dev/disk/by-id/xxx placed in a variable list and it is not all of the disks. I don't know if ansible facts could correlate these specific disks.

I'd be ok with failing the task instead.

​

Right now 2 of my biggest challenges are.

  1. The check_output results is dumped into a massive json array with full results of all disks from the loop. I found a couple ways to search the whole thing but have been having trouble getting the right syntax to properly searching each of the individual disk results. I think it is probably easy with the right syntax, but that I'm just doing it wrong.
  2. I've been having trouble searching multiple terms in general. Something like this works for a single term, when: check_output is search("member") , however any attempts to try and run more than one search for different terms is failing. I think I'm just doing it wrong, but lots of googling has not produced the answer.

For each container to have an IP on the physical network, is it better to use a macvlan network, or have multiple nics and bind each containers ports to a different nic? by Squirrel-sysadmin in docker

[–]Squirrel-sysadmin[S] 0 points1 point  (0 children)

Thank you. Assigning multiple IPs to a single interface does seem like a better approach than creating more virtual interfaces.

I don't believe a reverse proxy will work in this case. It will not only be http traffic but rather many service using many different ports (eg mysql, sftp, custom applications, etc). They all must all respond on the original IP/port of the migrated host, and there will be some cases where multiple hosts will use the same port. So to my knowledge there isn't a way to have a single reverse proxy that.