lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 07 Sep 2006 20:21:27 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: re-reading the partition table on a "busy" drive

Currently, the kernel refuses to re-read partition table
from a drive which has usage count > 0.  Motivation for
this is pretty clear (to not mess up with already open
devices/partitions/filesystems, if I got it right ;),
but this also is pretty annoying -- in order to change
unrelated, yet unused partitions on root drive, one has
to reboot the machine.

I wonder if it's possible to actually read the new partition
table, compare it with previous, and apply changes IF they
don't conflict with currently open partitions?  Say, if we
have sda1 and sda2, sda1 is open/mounted, and new partition
table does not have sda2, but sda1 is unchanged - it's pretty
safe to apply new partition table, without affecting mounted
sda1.  Ditto for adding new partitions.

Yes, a line should be drawn somewhere - say, if sda3 was
mounted, and we removed unused sda2, but sda3 (which becomes
sda2 with new table) is intact, we should not apply new
table.

Is it possible to implement such a feature?  I mean, is it
easy to know which *partitions* (subdevices?) of the whole
device are currently in use, as opposed to the whole drive?

Thanks.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ