For reasons of auditability/accountability, I would like a filesystem such that I can write to it only ONCE, subsequently not modifiable/deletable, but always readable. Kind of a database journal logs - it is continuously being written, sequentiall appending, but not circular buffer based, so that upon running out of space, logging will be paused in memory, and after new storage devices added to it, it will continue to flush out whatever is outstanding in memory. Can ext3 / ext4 or current jbd2 be easily configured to serve this purpose? Thanks.
Thank you for your reply :-). On Sat, Mar 22, 2008 at 11:06 PM, J?rn Engel <joern at logfs.org> wrote:> On Sat, 22 March 2008 22:52:12 +0800, Peter Teoh wrote: > > > > what are the difference in terms of final features provided by these > > two different filesystem? what is this "garbage collection"? u > > still have features like creating different directories, and creating > > different files, and writing the files? How about setting the file > > attributes...it should be set before writing right (so that after > > writing and handle is closed it becomes permanently not > > modifiable)..but creating a subdirectory below the current dir should > > be possible right (even after closing the previous directory)? > > Your requirements aren't quite clear to me. Do you want the complete > filesystem to be read-only after being written once?YES....> Or do you want individual files/directories to be immutable - chattr?chattr is not good enough, as root can still modify it. So if current feature is not there, then some small development may be needed.> And in either case, what problem do you want to solve with a read-only filesystem?Simple: i want to record down everything that a user does, or a database does, or any applications running - just record down its state permanently securely into the filesystem, knowing that for sure, there is not way to modify the data, short of recreating the filesystem again. Sound logical? Or is there any loophole in this concept? In summary, are there any strong demand for such a concept/filesystem? I may take the plunge to implementing it, if justfiable and everybody is interested..:-)... -- Regards, Peter Teoh
J?rn Engel wrote:> On Sat, 22 March 2008 23:55:53 +0800, Peter Teoh wrote: >>> Or do you want individual files/directories to be immutable - chattr? >> chattr is not good enough, as root can still modify it. So if >> current feature is not there, then some small development may be >> needed. >> >>> And in either case, what problem do you want to solve with a read-only filesystem? >> Simple: i want to record down everything that a user does, or a >> database does, or any applications running - just record down its >> state permanently securely into the filesystem, knowing that for sure, >> there is not way to modify the data, short of recreating the >> filesystem again. Sound logical? Or is there any loophole in this >> concept? > > The loophole is called root. In a normal setup, root can do anything, > including writing directly to the device your filesystem resides in, > writing to kernel memory, etc. > > It may be rather inconvenient to change a filesystem by writing to the > block device, but far from impossible. If you want to make such changes > impossible, you are facing an uphill battle that I personally don't care > about. And if inconvenience is good enough, wouldn't chattr be > sufficiently inconvenient? > > J?rn >How about mounting an isofs via loopback? This has the added benefit of being ready to be exported to disc. You can make it with mkisofs on a directory structure and mount it to the tree with a normal mount(1). If it asks for fs type on mount, I think its 'iso9660'.