| 1 |
Chris Bainbridge posted <623652d50510021043g6a4a9fd6n@××××××××××.com>, |
| 2 |
excerpted below, on Sun, 02 Oct 2005 17:43:04 +0000: |
| 3 |
|
| 4 |
> On 02/10/05, Dan Meltzer <parallelgrapefruit@×××××.com> wrote: |
| 5 |
>> On 10/2/05, Chris Bainbridge <chris.bainbridge@×××××.com> wrote: |
| 6 |
>> > On 02/10/05, Alec Warner <warnera6@×××××××.edu> wrote: |
| 7 |
>> > > Chris Bainbridge wrote: |
| 8 |
>> > > > On 02/10/05, R Hill <dirtyepic.sk@×××××.com> wrote: |
| 9 |
>> > > >>I still think it's retarded to have a reiser 4 boot partition, but |
| 10 |
>> > > >>whatever stirs your pot. ;P |
| 11 |
>> > > > |
| 12 |
>> > > > It makes sense if you're actually using reiser4 for everything |
| 13 |
>> > > > else. Why bloat your kernel with an extra FS just for /boot? |
| 14 |
>> In addition, why bloat your fs by having a journaled filesystem for |
| 15 |
>> essentially static files? |
| 16 |
> |
| 17 |
> Because it's easier to have a single fs for / than have multiple |
| 18 |
> partitions, and try to isolate all of the things that are "essentially |
| 19 |
> static" and move them over to unjournalled file systems. Journalling |
| 20 |
> operations on /boot are responsible for filling a very, very small |
| 21 |
> percentage of my hard disk. |
| 22 |
|
| 23 |
I'm doing this with reiserfs (3) ATM. 100% reiserfs system, fat and ext2 |
| 24 |
as kernel modules that I load only in the rare event I'm going to access a |
| 25 |
floppy. I have 20 partitions, including /boot and some others that are |
| 26 |
normally static, and /tmp and my portage tree and source partitions that |
| 27 |
are temporary or redownloadable so they really don't need journalled. |
| 28 |
However, the disk is some 250 GB, out of which well over 100 GB remains |
| 29 |
entirely unformatted at this point, so journal space isn't an issue, and |
| 30 |
it's simply less bother keeping everything on reiserfs, even on partitions |
| 31 |
where the default journal is a rather large portion of the entire |
| 32 |
partition, than otherwise. |
| 33 |
|
| 34 |
Note that reiser4 is "wandering journal". As I understand it, it doesn't |
| 35 |
set up a dedicated journal space, but rather, journals on the fly, by |
| 36 |
rewriting a file then cascading the metadata entries up the (duplicated) |
| 37 |
tree branch until it reaches the root entry, at which point the commit |
| 38 |
goes final as the old metadata tree branch is discarded and the new one |
| 39 |
takes effect. This isn't journalling, but rather, atomic metadata entry. |
| 40 |
Thus, there *IS* no journal per se, simply half finished commits that |
| 41 |
haven't gotten all the way up the tree to the root entry yet. The change |
| 42 |
is either fully committed or not committed at all, so unless the crash |
| 43 |
occurs at the exact moment the root entry itself is being updated (and I |
| 44 |
believe there's a special case for it, accounting for that very |
| 45 |
possibility), there's simply nothing to journal. Half-written commits |
| 46 |
that didn't fully cascade all the way to the top will simply be pruned in |
| 47 |
the event of recovery. The system is fully atomic, no journal necessary. |
| 48 |
|
| 49 |
Thus (unless I've misunderstood what I've read of reiser4), journal space |
| 50 |
isn't an issue with reiser4. It's an atomic transaction system, rather |
| 51 |
than a journal. |
| 52 |
|
| 53 |
That's also one of the reasons why copy method affects access time. Untar |
| 54 |
a tarball not created on reiser4 onto a reiser4 system, and those files |
| 55 |
won't be laid out for optimum access efficiency. That was one of the |
| 56 |
points Hans made in some of the benchmarking attempts. I don't quite |
| 57 |
understand the implications here, but apparently, taking the newly |
| 58 |
expanded files, copying (not moving) them elsewhere on the reiser4 system, |
| 59 |
deleting the old copy, then copying them back (if necessary), will |
| 60 |
reoptimize the layout into reiser4-access-optimized. Alternatively, |
| 61 |
running the repacker reoptimizes the entire fs, as well. |
| 62 |
|
| 63 |
Obviously, I've been following reiser4 with some interest, altho I've |
| 64 |
stuck with reiser3 to this point. (reiser4 has been unstable on amd64, |
| 65 |
I've been told.) That may change in the next few months, however, as I'll |
| 66 |
probably get a new disk (I've lots of space left, but this one has some |
| 67 |
badblocks due to overheating during an A/C malfunction) and am considering |
| 68 |
taking the opportunity to transfer to reiser4. |
| 69 |
|
| 70 |
-- |
| 71 |
Duncan - List replies preferred. No HTML msgs. |
| 72 |
"Every nonfree program has a lord, a master -- |
| 73 |
and if you use the program, he is your master." Richard Stallman in |
| 74 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
| 75 |
|
| 76 |
|
| 77 |
-- |
| 78 |
gentoo-dev@g.o mailing list |
Archives