| |||||||||||||
Why yet another filesystem?Why yet another filesystem?Posted Jun 25, 2009 11:37 UTC (Thu) by epa (subscriber, #39769)Parent article: Protected RAMFS
It's not clear why this is a whole new filesystem; surely the question of protecting a RAM device against kernel crashes is orthogonal to how the data is laid out on that device. If blocks need to be written, the device driver can lock and unlock the pages as needed. Similarly, checksumming each block could be done in a device driver layer below the filesystem (so the filesystem might see 4096 byte blocks, although they are stored in memory as 5000 bytes to allow checksums). Even if you do need the filesystem to do some special checking, why not start with an existing one such as minixfs?
These are all ignorant questions but the article doesn't have much rationale for why the new filesystem is needed.
(Log in to post comments)
Why yet another filesystem? Posted Jun 27, 2009 3:04 UTC (Sat) by giraffedata (subscriber, #1954) [Link] It's not clear why this is a whole new filesystem; surely the question of protecting a RAM device against kernel crashes is orthogonal to how the data is laid out on that device. I think what you're saying is that this could be done as a whole new block device type with an existing block-device-based filesystem type instead of as a whole new filesystem type. I believe pramfs recognizes that block devices are appropriate for disk drives and any other use is a stretch. Over the years, people have used block devices for things other than disk drives -- essentially emulating disk drives -- in order to leverage existing filesystem code intended for disk drives. But if you're willing to write the filesystem code, you can get a better result without the emulation. Indeed, we used to have traditional disk filesystems on a ramdisk; now we prefer ramfs.
|
|||||||||||||