Commit Graph

3 Commits

Author SHA1 Message Date
Kirk McKusick
c7996ddf80 Create a new GEOM utility, gunion(8).
The gunion(8) utility is used to track changes to a read-only disk on
a writable disk. Logically, a writable disk is placed over a read-only
disk. Write requests are intercepted and stored on the writable
disk. Read requests are first checked to see if they have been
written on the top (writable disk) and if found are returned. If
they have not been written on the top disk, then they are read from
the lower disk.

The gunion(8) utility can be especially useful if you have a large
disk with a corrupted filesystem that you are unsure of how to
repair. You can use gunion(8) to place another disk over the corrupted
disk and then attempt to repair the filesystem. If the repair fails,
you can revert all the changes in the upper disk and be back to the
unchanged state of the lower disk thus allowing you to try another
approach to repairing it. If the repair is successful you can commit
all the writes recorded on the top disk to the lower disk.

Another use of the gunion(8) utility is to try out upgrades to your
system. Place the upper disk over the disk holding your filesystem
that is to be upgraded and then run the upgrade on it. If it works,
commit it; if it fails, revert the upgrade.

Further details can be found in the gunion(8) manual page.

Reviewed by: Chuck Silvers, kib (earlier version)
tested by:   Peter Holm
Differential Revision: https://reviews.freebsd.org/D32697
2022-02-28 16:36:08 -08:00
Alexander Motin
86c06ff886 Remove GEOM_SCHED class and gsched tool.
This code was not actively maintained since it was introduced 10 years ago.
It lacks support for many later GEOM features, such as direct dispatch,
unmapped I/O, stripesize/stripeoffset, resize, etc.  Plus it is the only
remaining use of GEOM nstart/nend request counters, used there to implement
live insertion/removal, questionable by itself.  Plus, as number of people
commented, GEOM is not the best place for I/O scheduler, since it has
limited information about layers both above and below it, required for
efficient scheduling.  Plus with the modern shift to SSDs there is just no
more significant need for this kind of scheduling.

Approved by:	imp, phk, luigi
Relnotes:	yes
2019-12-29 21:16:03 +00:00
Brad Davis
9ad8ab5438 Add a file missed in r335645.
Approved by:	brooks, allanjude (mentor)
Differential Revision:	https://reviews.freebsd.org/D15360
2018-06-25 21:54:39 +00:00