[prev] [thread] [next] [lurker] [Date index for 2005/10/02]
> This isn't a network file system -- it's ReiserFS4, which brings its > own hatred but attempts to bring things around towards sanity. That's OK, it's hateful in non-network file systems as well. It's just that network file systems seem to have concentrated the hateful aspects much more effectively than even things like HFS+. > The attempt is to provide filesystem transactions using a new > interface. begin() read(), write(), ... commit()/rollback()? > Some of the kernel people seem to want an API to be developed which > could > be used across all filesystems, whether they implement transactions or > not, while the Reiser folks wants to wait before designing a > standardized > interface for something that isn't complete yet in their own codebase, > let alone usable with other filesystems. I vote for an API that can be implemented on all file systems, but not necessarily efficiently. > The problem is that it reserves a fixed percentage of filesystem size. > I > believe it's 5%. This means that with a 250 GB volume, 12.5 GB will be > reserved *just in case* a transaction which requires that much space > hits the pipe. So? Many existing file systems require a bigger reserve than that. Though it seems more logical, if the API supports transactions, to simply force a rollback() on the application. If the application is using transactions then it has to be able to handle that in any case.There's stuff above here
Generated at 16:00 on 04 Oct 2005 by mariachi 0.52