Karel Zak [Mon, 21 Mar 2022 12:19:38 +0000 (13:19 +0100)]
agetty: add support for LOGIN_PLAIN_PROMPT
login(1) and agetty(8) are usually used together to log-in user. The
initial login prompt is printed by agetty. login(1) can suppress
hostname in the prompt by LOGIN_PLAIN_PROMPT=no (/etc/login.defs), but
for agetty it's necessary to use --nohostname. It's pretty unfriendly
for system admins. Let's share the same setting between all tools.
Stanislav Brabec [Fri, 25 Mar 2022 08:26:48 +0000 (09:26 +0100)]
flock: Decribe limitations of flock: deadlock, NFS, CIFS
The flock(1) does not refer to limitations of flock(2). Provide an
documentation entry point for solving of problems with flock on NFS
and CIFS and mention risk of deadlock.
Signed-off-by: Stanislav Brabec <sbrabec@suse.cz> Signed-off-by: Karel Zak <kzak@redhat.com>
Andreas Hindborg [Wed, 16 Mar 2022 08:39:05 +0000 (09:39 +0100)]
blkzone: Do not print zone capacity if not supported
If `blkzone` is built against kernel headers that do not define
`BLK_ZONE_REP_CAPACITY`, `blkzone report` will use zone size when printing zone
capacity. This patch changes the behavior of `blockzone report` in this case to
omit the capacity field instead of using the potentially wrong value.
Signed-off-by: Andreas Hindborg <andreas.hindborg@wdc.com>
Michael Trapp [Thu, 10 Mar 2022 12:18:52 +0000 (13:18 +0100)]
libuuid: extend cache in uuid_generate_time_generic()
Improve throughput and reduce clock sequence increments
for high load situation with time based version 1 uuids.
In a high load scenario, where an application continiously reads time
based version 1 uuids from uuidd, we have noticed the following
behaviour.
The application reads more uuids as there are available in the
corresponding timeframe and each bulk request results in an increment of
the clock sequence because of the 'step back' in time. Due to the
14bit size of the clock sequence this also results in overflows of
the clock sequence.
As uuidd calls
uuid_generate_time_safe()
uuid_generate_time_generic()
the default value for the bulk request in the '#ifdef HAVE_TLS' section
of uuid_generate_time_generic() is set to 1000.
Extending the 'cache' of uuid_generate_time_generic() by increasing
the default of num to 1000000 doesn't solve the issue, but reduces
the clock sequence increments by factor 1000 and it also improves
the uuid throughput in our setup by factor 3-4.
It might be possible to implement a cache for
UUIDD_OP_BULK_TIME_UUID
UUIDD_OP_TIME_UUID
in the uuidd request handling, but it would not be as simple as this fix
in uuid_generate_time_generic().
Karel Zak [Fri, 4 Mar 2022 08:53:49 +0000 (09:53 +0100)]
Merge branch 'new-gpt-types' of https://github.com/gyakovlev/util-linux
* 'new-gpt-types' of https://github.com/gyakovlev/util-linux:
libfdisk: add new verity root and /usr part types
libfdisk: add new root and /usr part types
Karel Zak [Mon, 28 Feb 2022 10:25:30 +0000 (11:25 +0100)]
Merge branch 'lsfd-tests' of https://github.com/masatake/util-linux
* 'lsfd-tests' of https://github.com/masatake/util-linux:
tests: (lsfd) don't check an unused program
tests: (lsfd) don't use findmnt to verify device numbers
tests: (lsfd) improve the help messages of test_mkfds helper command
losetup: don't skip adding a new device if it already has a device node
Linux plans to deprecate the auto-creation of block devices based on
access to the device node starting from kernel 5.18. Without that feature
losetup will fail to create the loop device if a device node already
exists, but the loop device to back it in the kernel does not exist yet.
This is a scenario that should not happen in modern udev based
distributions, but apparently there still are various scripts around that
manually call the superfluous mknod.
Change losetup to unconditionally call loopcxt_add_device when a specific
device node is specified on the command line. If the loop device
already exists the LOOP_CTL_ADD ioctl will fail, but given that losetup
ignores the return value from loopcxt_add_device that failure has no
further effect.
Reported-by: Luis Chamberlain <mcgrof@kernel.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Signed-off-by: Karel Zak <kzak@redhat.com>
Masatake YAMATO [Sat, 26 Feb 2022 18:42:09 +0000 (03:42 +0900)]
tests: (lsfd) don't use findmnt to verify device numbers
This change tries to fix the failures in testing reported in:
* https://lkml.org/lkml/2022/1/31/1333, and
* https://lkml.org/lkml/2022/2/2/171
The original test cases depended on a wrong assumption; if M and M'
are the same, D and D' are the same, too. Here, M is a mnt_id in
/proc/$pid/mountinfo. D is the device number for M in
/proc/$pid/mountinfo. M' is the mnt_id value in
/proc/$pid/fdinfo/$fd. D' is the device number reported by stat
syscall for /proc/$pid/fd/$fd.
The original test compared the device numbers reported by findmnt and
lsfd. findmnt retrieves a device number from /proc/$pid/mountinfo.
lsfd retrieves a device number from stat syscall.
This assumption is not correct for a file on an overlay file system
whose block devices behind lowerdir and upperdir are different.
Using findmnt is not suitable for comparing device numbers.
This change uses stat command instead of findmnt to retrieve the
device number.
projects / thirdparty / util-linux.git / log
