Searched hist:738 (Results 1 - 7 of 7) sorted by relevance
| /freebsd-11-stable/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/ | ||
| H A D | zfs_znode.c | diff 339136 Wed Oct 03 15:03:08 MDT 2018 mav MFC r337202: MFV r337200: 9438 Holes can lose birth time info if a block has a mix of birth times Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. illumos/illumos-gate@738e2a3ce3b2579222d6855e7fe75b5bcfcddf8d Reviewed by: Matt Ahrens <matt@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> |
| H A D | dnode_sync.c | diff 339136 Wed Oct 03 15:03:08 MDT 2018 mav MFC r337202: MFV r337200: 9438 Holes can lose birth time info if a block has a mix of birth times Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. illumos/illumos-gate@738e2a3ce3b2579222d6855e7fe75b5bcfcddf8d Reviewed by: Matt Ahrens <matt@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> |
| H A D | dmu_object.c | diff 339136 Wed Oct 03 15:03:08 MDT 2018 mav MFC r337202: MFV r337200: 9438 Holes can lose birth time info if a block has a mix of birth times Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. illumos/illumos-gate@738e2a3ce3b2579222d6855e7fe75b5bcfcddf8d Reviewed by: Matt Ahrens <matt@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> |
| H A D | dnode.c | diff 339136 Wed Oct 03 15:03:08 MDT 2018 mav MFC r337202: MFV r337200: 9438 Holes can lose birth time info if a block has a mix of birth times Ultimately, the problem here is that when you truncate and write a file in the same transaction group, the dbuf for the indirect block will be zeroed out to deal with the truncation, and then written for the write. During this process, we will lose hole birth time information for any holes in the range. In the case where a dnode is being freed, we need to determine whether the block should be converted to a higher-level hole in the zio pipeline, and if so do it when the dnode is being synced out. illumos/illumos-gate@738e2a3ce3b2579222d6855e7fe75b5bcfcddf8d Reviewed by: Matt Ahrens <matt@delphix.com> Reviewed by: George Wilson <george.wilson@delphix.com> Approved by: Robert Mustacchi <rm@joyent.com> Author: Paul Dagnelie <pcd@delphix.com> |
| /freebsd-11-stable/usr.sbin/inetd/ | ||
| H A D | builtins.c | diff 157816 Mon Apr 17 16:35:58 MDT 2006 dwmalone Port 37 (RFC 738) style times are supposed to be a 32 bit time since 1900 in network byte order. Use a uint32_t to calculate and send the time, so that we don't need to know how big ints or longs are. I used uint32_t instead of int in the patch, on the off chance someone uses our inetd source on a system that doesnt 32 bit ints. PR: 95290 Submitted by: Bruce Becker <hostmaster@whois.gts.net> MFC after: 2 weeks |
| H A D | Makefile | diff 157816 Mon Apr 17 16:35:58 MDT 2006 dwmalone Port 37 (RFC 738) style times are supposed to be a 32 bit time since 1900 in network byte order. Use a uint32_t to calculate and send the time, so that we don't need to know how big ints or longs are. I used uint32_t instead of int in the patch, on the off chance someone uses our inetd source on a system that doesnt 32 bit ints. PR: 95290 Submitted by: Bruce Becker <hostmaster@whois.gts.net> MFC after: 2 weeks |
| /freebsd-11-stable/sys/dev/speaker/ | ||
| H A D | spkr.c | diff 738 Tue Nov 09 00:32:30 MST 1993 ache Fixed minor bug in M[LSN] interpretation, added octave-tracking. Added the slur-mark feature. Name of ioctl's include sys/spkr.h changed to machine/speaker.h |
Completed in 103 milliseconds