3 ms·

My vague understanding is there's some kind of inode lock on in-use libraries, and only a reboot releases them. Therefore files can't really be overwritten. New

by cmurf 8y ago

My vague understanding is there's some kind of inode lock on in-use libraries, and only a reboot releases them. Therefore files can't really be overwritten. New files (and inodes) are written elsewhere, and then moved into place as part of the reboot. Two things I don't understand: why updates are so slow; and why the updating can't be done out of band. Seems like it could be done either with hardlinks or using VSS, so that it's safe to do as a background process rather than effectively kicking the user off their own system for the entire duration. Both hardlinks and VSS have been around forever on NTFS. While ReFS supports volume snapshots (but not hardlinks), its rollout as a replacement for NTFS appears stalled, only being recommended for specific use cases that aren't the general purpose use case (system disk).

rincebrain 8y ago
1) The deleting in-place is just a different default than on e.g. Linux - both can let you delete/rename/etc files underneath it, but Windows defaults to making you explicitly set a property to permit this in your open() call equivalents, while Linux requires you explicitly lock things to prevent this. 2) Updates can be slow for a bunch of reasons. One of them is that the WU agent as shipped in e.g. Win7 SP1 had some nasty O(n^2) or worse operations that got fixed in [1] and later. One of the reasons the monthly rollups versus itemized bits were an enhancement is, if your install for each update is NUMUPDATES* O(start transaction + do install of update bits + swap into place + end transaction) , removing all but one of the start and end transactions is a nice speedup. As far as using hardlinks and VSS to stage and swap updates into place...that is a thing that WU does already, and has done for quite some time. ReFS also makes me sad because it has so much potential, but they rolled it out without being able to used for many use cases, so it's probably gonna stall and die. [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...

by cmurf 8y ago

rincebrain 8y ago

1) The deleting in-place is just a different default than on e.g. Linux - both can let you delete/rename/etc files underneath it, but Windows defaults to making you explicitly set a property to permit this in your open() call equivalents, while Linux requires you explicitly lock things to prevent this. 2) Updates can be slow for a bunch of reasons. One of them is that the WU agent as shipped in e.g. Win7 SP1 had some nasty O(n^2) or worse operations that got fixed in [1] and later. One of the reasons the monthly rollups versus itemized bits were an enhancement is, if your install for each update is NUMUPDATES* O(start transaction + do install of update bits + swap into place + end transaction) , removing all but one of the start and end transactions is a nice speedup. As far as using hardlinks and VSS to stage and swap updates into place...that is a thing that WU does already, and has done for quite some time. ReFS also makes me sad because it has so much potential, but they rolled it out without being able to used for many use cases, so it's probably gonna stall and die. [1] - https://support.microsoft.com/en-us/help/3161647/windows-update-client-for-windows-7-and-windows-server-2008-r2-june-20 https://support.microsoft.com/en-us/help/3161647/windows-upd...