meta-data, copy it into the softc structure.
When returning md(4) device details to the caller, include the file name in
any MD_PRELOAD type devices if it is set (first character is not NUL.)
In mdconfig, for "preload" type md(4) devices, if there is file config
available, print it in the file column of the output.
Reviewed by: brooks
Approved by: sjg (mentor)
MFC after: 1 month
Sponsored by: Juniper Networks, Inc.
Differential Revision: https://reviews.freebsd.org/D9529
1. "-u N" specified, no -f, and mdN found,
2. no -u, "-f /pathname" specified, and mdN associated with /pathname found,
3. "-u N" specified, "-f /pathname" specified, and both of them found,
4. "-l" specified and no -f,
5. "-l" specified, "-f /pathname" specified, and /pathname found.
otherwise return -1.
Spotted by: Julian H. Stacey
specified, only md(4) devices which have the specified file as backing
store are displayed.
- Use MD_NAME instead of "md".
- Use _PATH_DEV instead of "/dev/".
MFC after: 1 week
- The feature is dangerous because the kernel code didn't check
validity of the memory address provided from user space.
- It seems that mdconfig(8) never really supported attaching preloaded
memory disks.
- Preloaded memory disks are automatically attached during md(4)
initialization. Thus there shouldn't be much use for the feature.
PR: kern/169683
Discussed on: freebsd-hackers
by removing the ordering requirements and adding more descriptive error
messages; it also makes it more readable and maintainable.
Sponsored by: The FreeBSD Foundation
"mdconfig -f file", I decided that it would be easier to make mdconfig
DWIM than to teach my fingers to type the correct command line.
MFC after: 3 weeks
- Constify geom_config_get() name argument.
- Add void keyword for usage().
- Initialize mdunit to NULL.
- Don't call md_prthumanval() at all if length is NULL.
Approved by: trasz (mentor)
device number at creation time with -u option. Together with XMLizing
mdconfig(8), I broke this functionality.
This change is temporary. Complete fix will be commited soon.
Approved by: cognet (mentor)
a problem with listing large number of md(4) devices. Either 'list' or
'query' mode uses XML.
Additionally, new functionality was introduced. It's possible to pass
multiple devices to -u:
# ./mdconfig -l -u md0,md1
Approved by: cognet (mentor)
kernel is in the order the devices were made, which is not useful to
the user. Also, remove the "%d more" test since the kernel does not
return the complete count in md_pad[0] (maybe it should?).
Submitted by: Wojciech A. Koszek
device be created read+write, check to see if the backing store is read only
through the use of the access(2) system call. If this check fails returning
EACCES, EPERM or EROFS then gracefully downgrade the access to read only. Also
print a warning message to stderr, informing the user that the access mode
they requested is not available.
This behavior used to be handled by md(4) but was changed in revision 1.154
Discussed with: pjd, phk, Dario Freni <saturnero at freesbie dot org>
Reviewed by: phk
show file name for 'mdconfig -l -u <x>' command.
This allows to preserve API/ABI compatibility with version 0 (that's why
I changed version number back to 0) and will allow to merge this change
to RELENG_5.
MFC after: 5 days
After this change it should be possible to use very big md(4) devices.
- Clean up and simplify the code a bit.
- Use humanize_number(3) to print size of md(4) devices.
- Add 't' suffix which stands for terabyte.
- Make '-S' to really work with all types of devices.
- Other minor changes.
On vnode backed md(4) devices over a certain, currently undetermined
size relative to the buffer cache our "lemming-syncer" can provoke
a buffer starvation which puts the md thread to sleep on wdrain.
This generally tends to grind the entire system to a stop because the
event that is supposed to wake up the thread will not happen until a fair
bit of the piled up I/O requests in the system finish, and since a lot
of those are on a md(4) vnode backed device which is currently waiting
on wdrain until a fair amount of the piled up ... you get the picture.
The cure is to issue all VOP_WRITES on the vnode backing the device
with IO_SYNC.
In addition to more closely emulating a real disk device with a
non-lying write-cache, this makes the writes exempt from rate-limited
(there to avoid starving the buffer cache) and consequently prevents
the deadlock.
Unfortunately performance takes a hit.
Add "async" option to give people who know what they are doing the
old behaviour.
