Re: CVS commit: src/sys/dev/dm
On May,Tuesday 18 2010, at 5:42 PM, Matthias Scheler wrote: > On Tue, May 18, 2010 at 03:10:41PM +, Adam Hamsik wrote: >> Log Message: >> Add support for DIOCCACHESYNC ioctl for dm devices. Add new sync function >> pointer to dm_target_t because that is the only part of dm which know real >> block device. disk_ioctl_switch parses whole device table and for every >> entry it calls particular sync routine which propagates DIOCCACHESYNC >> to real disk. > > What happens if a logical volume consists of two slice of one physical > device? Will the physical device get flushed twice? Yes and there is no easy way how to not do that. Regards Adam.
Re: CVS commit: src/sys/dev/dm
On Tue, May 18, 2010 at 03:10:41PM +, Adam Hamsik wrote: > Log Message: > Add support for DIOCCACHESYNC ioctl for dm devices. Add new sync function > pointer to dm_target_t because that is the only part of dm which know real > block device. disk_ioctl_switch parses whole device table and for every > entry it calls particular sync routine which propagates DIOCCACHESYNC > to real disk. What happens if a logical volume consists of two slice of one physical device? Will the physical device get flushed twice? Kind regards -- Matthias Scheler http://zhadum.org.uk/
Re: CVS commit: src/lib/libpthread
On Mon, May 17, 2010 at 07:35:37PM +0200, Matthias Drochner wrote: > Also, the xrefs are not sorted strictly alphabetically but > in some logical order which is good imo. The Xrefs are generally a symptom of the manual page format. As D. Holland well said, the "man -k is so 1980s". In my opinion we could have more introductory sections that connect the pages in a more logical manner.[1] Just listing the manual pages in the intro-sections is not enough. For example, I think memoryallocators(9) and atomic_ops(3) are good examples. The latter highlights also nicely and briefly the rationale, which is often entirely missing in the man-pages. (Often the question particularly in the kernel is: why? Not how.) So in the long run we could have e.g. libc(3) or kernel(9). Another option could be a book-like index, which I already mentioned on d...@. - Jukka. [1] It would be interesting to use e.g. Graphviz to see what kind of a spider web the Xrefs really are.
