konstantinbelousov:vm6

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
konstantinbelousov:vm6 [2010/04/24 21:49] – SUID/GUID clear implemented KonstantinBelousovkonstantinbelousov:vm6 [2022/06/08 00:51] (current) – Add Category: Stale (lastmod 2011) KubilayKocak
Line 19: Line 19:
 When file is modified, suid bit shall be dropped. Doing it by VOP_GETATTR/VOP_SETATTR is inefficient. VOP_EXTEND is guaranteed to be called at least once for each write, and filesystem may use the opportunity to clean the bits. ffs_extend() handle this. When file is modified, suid bit shall be dropped. Doing it by VOP_GETATTR/VOP_SETATTR is inefficient. VOP_EXTEND is guaranteed to be called at least once for each write, and filesystem may use the opportunity to clean the bits. ffs_extend() handle this.
  
-I introduced new VOP_EXTEND() that extends the file for new size. Default implementation does VOP_GETATTR/VOP_SETTATTR. On UFS, it only sets new size in inode, without allocating block for last byte. When extending the file that ended in fragment, the whole block or neccessary number of fragments at the previous end is reallocated, to keep the invariant that fragment is allowed only at direct blocks at end of file. Current fsck would treat such extended files as filesystem inconsistency, and return the size to pre-extend value.+I introduced new VOP_EXTEND() that extends the file for new size. Default implementation does VOP_GETATTR/VOP_SETTATTR. On UFS, custom implementation is provided, that sets new size in inode, without allocating block for last byte. When extending the file that ended in fragment, the whole block or neccessary number of fragments at the previous end is reallocated, to keep the invariant that fragment is allowed only at direct blocks at end of file. Current fsck would treat such extended files as filesystem inconsistency, and return the size to pre-extend value.
  
 Pressure on writers is another critical feature, both for performance and for responsivness of the system. I tried to do it simple, by counting number of pages dirtyfied by vnode_pager_write(), and doing the cleaning pass similar to the pageout launder if count of the pages becomes too big. Pressure on writers is another critical feature, both for performance and for responsivness of the system. I tried to do it simple, by counting number of pages dirtyfied by vnode_pager_write(), and doing the cleaning pass similar to the pageout launder if count of the pages becomes too big.
Line 78: Line 78:
  
 === fsync(2) and O_SYNC efficiency === === fsync(2) and O_SYNC efficiency ===
-fsync(2) and O_SYNC are implemented by vm_object_page_clean() for now. Jeff has the plan to make walking the list of object dirty pages and flushing them much more efficient. +fsync(2) and O_SYNC are implemented by vm_object_page_clean() for now. vm_object_page_clean() was rewritten recently.
 === Possible opt-in for vmio from fs === === Possible opt-in for vmio from fs ===
 I think that new i/o path should be explicitely allowed by mnt_kern_flags bit. I think that new i/o path should be explicitely allowed by mnt_kern_flags bit.
 +
 +----
 +
 +{{tag>Stale}}
  
  • konstantinbelousov/vm6.1272145792.txt.gz
  • Last modified: 2010/04/24 21:49
  • by KonstantinBelousov