| |||||||||||||
The 2006 Linux File Systems WorkshopThe 2006 Linux File Systems WorkshopPosted Jul 5, 2006 23:33 UTC (Wed) by jonabbey (subscriber, #2736)Parent article: The 2006 Linux File Systems Workshop
Wonderful article.
(Log in to post comments)
The 2006 Linux File Systems Workshop Posted Jul 6, 2006 0:00 UTC (Thu) by DYN_DaTa (guest, #34072) [Link] Yes, a nice one :).
The 2006 Linux File Systems Workshop Posted Jul 6, 2006 0:11 UTC (Thu) by cventers (subscriber, #31465) [Link] Agreed! Now if we can just turn all the necessary gears to get reiser4merged :)
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.
|
|||||||||||||