"73e441b99a7795a894ec06f367d9b09debb62c04" (history) in projects: dflybsd-src

Project(s)

Full Search
Definition
Symbol
File Path
History
Type

Searched hist:"73 e441b99a7795a894ec06f367d9b09debb62c04" (Results 1 – 6 of 6) sorted by relevance

/dflybsd-src/sys/vfs/hammer2/
H A D	TODO	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.
H A D	hammer2_disk.h	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.
H A D	hammer2_vnops.c	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.
H A D	hammer2_chain.c	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.
H A D	hammer2_vfsops.c	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.
H A D	hammer2.h	73e441b99a7795a894ec06f367d9b09debb62c04 Wed Feb 29 08:53:55 GMT 2012 Matthew Dillon <dillon@apollo.backplane.com> hammer2 - Rework the flusher * Rework the flusher to remove numerous degenerate cases which caused excessive re-flushing of the same block(s). * No longer flushes the volume header on sync if the filesystem is not dirty. * General code cleanup. * Beginning of a work-up to implement variable logical block sizes for file data. Physical blocks will always be 64K but logical blocks and block allocations can be any multiple of 1K. Currently any file > 512 bytes allocates a 64K file block, which is horribly space inefficient. This will be fixed soon.