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
Hallo,
Michael Tokarev wrote:
> Currently, the kernel refuses to re-read partition table
> from a drive which has usage count > 0. Motivation for
> this is pretty clear ,
> pretty annoying -- in order to change
> to reboot the machine.
>
Yes, very interesting thing. While one will destroy its part.table, he can not
see until reboot, heh. But there were days, when grub used to install itself on
XFS partition (XFS isn't FAT-boot-record compatible) *silently*, but nothing
was wrong to me : it's linux-gnu ;D
I would love just little kernel boot parameter to configure it, or sysctl in
procfs.
> 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?
>
IMHO you've wrote much more here, then just for not-so-useless-solution, that
i've wrote above, unless you want another wind0s clever-heuristic with patches
from happy users to lkml: <http://article.gmane.org/gmane.linux.kernel/437388>
> Thanks.
>
> /mjt
--
-o--=O`C /. .\ (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)
>>
> Yes, very interesting thing. While one will destroy its part.table, he can not
> see until reboot, heh. But there were days, when grub used to install itself on
> XFS partition (XFS isn't FAT-boot-record compatible) *silently*, but nothing
> was wrong to me : it's linux-gnu ;D
People running XFS should know you cannot put boot code into the PBR.
Jan Engelhardt
--
On Thu, Sep 07, Michael Tokarev wrote:
> 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?
Its already there, see include/linux/blkpg.h
parted uses this interface, fdisk and others use the rereadpt ioctl.
Oleg Verych wrote:
[]
> My anwser to this question: if it's so "pretty annoying", just let it be
> "yes, do as i said !", not more and not less, just most ;).
Well, this whole question is already moot, as pointed out by Olaf.
Because kernel already supports add/delete single partition ioctls,
which is sufficient. For my needs I already wrote a tiny hack which
compares /proc/partitions with the output of `sfdisk -d' and re-adds
anything which changed. It should be possible to do the same with
parted instead of {sf,cf,f}disk without using that hack, but hell,
all those fdisks (parted included) sucks badly, each in its own way,
so all are being used for different parts of the task, including the
hack ;)
Thanks.
/mjt
>> My anwser to this question: if it's so "pretty annoying", just let it be
>> "yes, do as i said !", not more and not less, just most ;).
>
>Well, this whole question is already moot, as pointed out by Olaf.
>Because kernel already supports add/delete single partition ioctls,
>which is sufficient. For my needs I already wrote a tiny hack which
>compares /proc/partitions with the output of `sfdisk -d' and re-adds
>anything which changed. It should be possible to do the same with
>parted instead of {sf,cf,f}disk without using that hack, but hell,
>all those fdisks (parted included) sucks badly, each in its own way,
>so all are being used for different parts of the task, including the
>hack ;)
So something should write the perfect utility. There are people on this
list capable of this, like we have seen with git :)
Jan Engelhardt
--
Jan Engelhardt wrote:
>>>My anwser to this question: if it's so "pretty annoying", just let it be
>>>"yes, do as i said !", not more and not less, just most ;).
>>
>>Well, this whole question is already moot, as pointed out by Olaf.
>>Because kernel already supports add/delete single partition ioctls,
>>which is sufficient. For my needs I already wrote a tiny hack which
>>compares /proc/partitions with the output of `sfdisk -d' and re-adds
>>anything which changed. It should be possible to do the same with
>>parted instead of {sf,cf,f}disk without using that hack, but hell,
>>all those fdisks (parted included) sucks badly, each in its own way,
>>so all are being used for different parts of the task, including the
>>hack ;)
>
>
> So something should write the perfect utility. There are people on this
> list capable of this, like we have seen with git :)
As far as i can see, most of such was actually started by Linus,
including linux.....
> Jan Engelhardt
--
-o--=O`C /. .\ (+)
#oo'L O o |
<___=E M ^-- | (you're barking up the wrong tree)