| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
The 2006 Linux File Systems Workshop
The 2006 Linux File Systems Workshop
Posted Jul 6, 2006 0:11 UTC (Thu) by cventers (subscriber, #31465)In reply to: The 2006 Linux File Systems Workshop by jonabbey
Parent article: The 2006 Linux File Systems Workshop
Agreed! Now if we can just turn all the necessary gears to get reiser4
merged :)
(Log in to post comments)
File Systems Workshop Attendees
Posted Jul 6, 2006 5:43 UTC (Thu) by Felix.Braun (subscriber, #3032) [Link]
I was kind of wondering, why Mr Reiser didn't attend. I have the impression he is quite opinionated when it comes to File System development. Could anybody comment?
File Systems Workshop Attendees
Posted Jul 6, 2006 21:02 UTC (Thu) by khim (subscriber, #9252) [Link]
He is quite opinionated when it comes to File System development.
That's the reason. Mr Reiser is bright guy and he understands filesystems like noone else - but he is hard to budge. Quite often he's right and everyone else is wrong - but not always. And it takes herculean effort (typically month or so) to convince him when he's wrong. This means his attendance is mostly useless: better to read his papers - and agree or disagree.
The 2006 Linux File Systems Workshop
Posted Jul 6, 2006 9:57 UTC (Thu) by nix (subscriber, #2304) [Link]
Does reiser4 even try to solve any of the nasty problems Val mentions (the fsck crunch, the need for internal integrity checks, et al)?
As far as I can tell it doesn't. It used to have nice support for small files, but that got turned off because it impacted benchmarks and I don't know if it was ever turned on again.
reiser4
Posted Jul 7, 2006 1:48 UTC (Fri) by xoddam (subscriber, #2322) [Link]
One thing mentioned in the article which reiser4 does implement (thoughVal doesn't include it in her list of examples) is copy-on-write atomic
storage hierarchy updates -- depending on settings, changing an inode can
result in allocation of new copies of the block containing the inode and,
recursively, every parent block which references the change, right up to
the master block. The old versions are only freed once the root has been
'committed' to its canonical location.