From: isw on
In article <300520102313075174%aeiou(a)mostly.invalid>,
Mark Conrad <aeiou(a)mostly.invalid> wrote:

> Thanks for the detailed decription of journaling.
>
> Personally, up to now I had always left journaling
> turned on, but since I decided to be an "early adopter"
> of Apple's 512 GB SSD, I decided to play it safe and
> eliminate the safety angle and recovery angle of the
> journal.
>
> Main reason is that I do not want to use up any more
> write cycles to the SSD than I absolutely had to,
> because present SSDs have a finite number of write
> cycles, then they are only good for doorstops.

I hear that a lot, but in Real-Life (tm) use, does it really matter?

If you translate write cycles into years (entirely possible, at least to
estimate), how many years of use do you expect?

Because if it's, say, one year, then SSD is a bad investment in almost
any scenario, but if it's, say, 100 years (only an exponential factor of
two different), then it really doesn't matter at all.

I have no idea what the answer is, but I think it should be known before
an informed decision whether to use or not use journaling (or even SSD)
could be made.

Isaac
From: Doug Anderson on
Mark Conrad <aeiou(a)mostly.invalid> writes:

> Thanks for the detailed decription of journaling.
>
> Personally, up to now I had always left journaling
> turned on, but since I decided to be an "early adopter"
> of Apple's 512 GB SSD, I decided to play it safe and
> eliminate the safety angle and recovery angle of the
> journal.
>
> Main reason is that I do not want to use up any more
> write cycles to the SSD than I absolutely had to,
> because present SSDs have a finite number of write
> cycles, then they are only good for doorstops.
>
> Hopefully, the SSD technology will improve in this respect,
> in the future, so fast SSD will last almost as long as regular
> hard drives.
>
> The "normal" Mac user can no doubt get a SSD to last long
> enough for it to be a good investment, even now.
>
> No waiting for a disk to spin around, bang, the data is there
> almost instantly, ready to grab.
>
> Apple would never have offered it as an option, if they figured
> that everyone would need the $1,300 SSD replaced after only
> a years use, they would go broke replacing SSD's.
>
> That said, it just does not make sense to me to deliberately
> rack up thousands and thousands of write cycles with something
> like journaling, just for the sake of a little added security on
> a few _recent_ files, every 3 years.

Note that file system corruption can lose files you haven't been
editing recently too.

And of course, hard crashes are rare, but by their nature they are
unpredictable. So the user has to decide how much it is worth doing
to protect him or her from rare events with unforseeable consequences.

> Dunno about others here, but I save my files to disk
> periodically as a habit, so in my case I just lose a few
> minutes work.

If you do this, and if you don't mind losing whatever work might have
been done since your last backup (in case of a bad crash), and you are
convinced that journaling has a cost that matters to you, then it
seems sensible to turn it off.

(snip)

> I have lost maybe 5 minutes of work, right?

Here is one place you are assuming more predictability than seems
justified.

You may have lost no work. Or your disk may be completely
unrecoverable, in which case you've lost up to your last backup.



From: Jamie Kahn Genet on
Mark Conrad <aeiou(a)mostly.invalid> wrote:

> In article <1jjaylp.ttqbyr1nfj9okN%mikePOST(a)TOGROUPmacconsult.com>,
> Mike Rosenberg <mikePOST(a)TOGROUPmacconsult.com> wrote:
>
> > Mark Conrad <aeiou(a)mostly.invalid> wrote:
> >
> > > I have been leaving journaling turned off for ages
> > > on my MacBook Pro, with nothing bad happening.
> > >
> > > Is journaling just a placebo?
> >
> > A quick Google search led me right to this:
> >
> > http://support.apple.com/kb/ht2355
>
>
> Yep, and that article stated:
>
> "If a volume contains read-only data that is not mission-critical,
> it may not be necessary to turn on journaling if performance
> is more important than safety."
>
> In my case, performance is the main bottleneck, not any
> file system "inconsistency" that may happen every 3 years.
>
>
>
> The article in that website further states:
>
> "If your server contains high-bandwidth usage data files,
> such as large video, graphics, or audio files, you may
> want to weigh the benefits of using journaling against
> the performance needed to access your data. In most
> cases, the impact of journaling upon data access
> performance are unnoticeable to users, but its
> implementation may not be practical for servers
> where data access demands outweigh its benefits."
>
>
>
> I consistently handle very large files, 100 GB and over,
> even though I do not run a server.
>
> I am not knocking journaling for servers, for them it is
> essential, to minimize down time.
>
> For the rest of us "hobby" users, I question whether the
> few percent "penalty" of running journaling is worth it,
> when most of us can use all the speed we can muster,
> instead of wasting our speed on journaling, which
> may or may not save a very few recent files
> once every 3 years.
>
>
> Mark-

Well you must have a lot less system freezes or badly made apps freezing
and not being able to be force quit, even if everything else is fine
(e.g. Quake 3 - using the ioQuake3 port, Eve Online, WoW in fullscreen
mode).

Either way 95% of the times I restart my Mac it is because of the above.
Of the remaining 5%, maybe 4% is system patches, and 1% - if that - is
intentional restarts/shutdowns.

Still, it is fairly rare, but at least once a month something will screw
up for me. Thus I am very glad I've journaling on, and was sad to see
ZFS for Mac die out. The more fault tolerant an OSes filesystem is the
happier I get, since software just keeps getting more larger and more
complicated, and usually buggier as a result.
--
If you're not part of the solution, you're part of the precipitate.
From: Mark Conrad on
In article <310520100943555145%nospam(a)nospam.invalid>, nospam
<nospam(a)nospam.invalid> wrote:

> > I will be glad when "real" 64 bit operation becomes
> > commonplace on Macs, so that developers will
> > actually write programs that can utilize 64 bit capability.
>
> that happened several years ago.

Yes, with portions of OS X "system files" and even their
associated buses, caches, buffers. That did little good
"years ago" because there were no app's around to take
advantage of the 64-bit system files.



> currently, there are plenty of 64 bit apps available, including
> adobe photoshop cs5, lightroom, and even apple's chess game.

Yes indeed, there must be all of 1% of 64-bit app's around. <g>

That hardly constitutes what most people think of when we
use the word "plenty".

That said, even the Windows guys are very lean on 64-bit app's,
despite their jumping up and down and raving about it.

They even have 64-bit usenet newsgroups for Windows guys,
to create the superficial impression they are somehow ahead of
the backward Mac people. ;-)

A few app's, such as the "64-bit compatible Dragon medical" app'
can actually be run on a 64-bit Windows OS, but like "Jolly Roger"
posted in a recent post to me here, that does not mean the
64-bit version of Dragon will run twice as fast on the 64-bit OS.

Actually, users found that running Dragon on a 64-bit OS yielded
only very minor increases in speed, hardly noticable.

In order to run twice as fast, Dragon code would have to be
completely re-written for 64-bit use, a job that could take years.

Not only that, but new CPUs would need to be created by Intel,
to take full advantage of 64-bit capabilities.

Even on my most recent 17" MacBook Pro with all the bells and
whistles, there is limited 64-bit capability. For example, it does
not even have a 64-bit Kernel or Extensions.

I have 8 GB of RAM, sure, but I can only access 4 GB of Ram
at a time. I need to access the CPU two separate times in order
to use the full 8 GB of RAM that I have, which takes added time.

A true 64-bit Kernel could access all 8 GB of RAM at once.

All in all, I do not look for true 64-bit operation for at least
another decade or two.

Mark-
From: nospam on
In article <310520101727292379%aeiou(a)mostly.invalid>, Mark Conrad
<aeiou(a)mostly.invalid> wrote:

> > > I will be glad when "real" 64 bit operation becomes
> > > commonplace on Macs, so that developers will
> > > actually write programs that can utilize 64 bit capability.
> >
> > that happened several years ago.
>
> Yes, with portions of OS X "system files" and even their
> associated buses, caches, buffers. That did little good
> "years ago" because there were no app's around to take
> advantage of the 64-bit system files.

yes there were.

> > currently, there are plenty of 64 bit apps available, including
> > adobe photoshop cs5, lightroom, and even apple's chess game.
>
> Yes indeed, there must be all of 1% of 64-bit app's around. <g>
>
> That hardly constitutes what most people think of when we
> use the word "plenty".

it's quite a bit more than that.

> That said, even the Windows guys are very lean on 64-bit app's,
> despite their jumping up and down and raving about it.

that's because it's more of a pain in the butt on windows.

> They even have 64-bit usenet newsgroups for Windows guys,
> to create the superficial impression they are somehow ahead of
> the backward Mac people. ;-)

that doesn't prove anything. there are newsgroups for pretty much
anything.

> A few app's, such as the "64-bit compatible Dragon medical" app'
> can actually be run on a 64-bit Windows OS, but like "Jolly Roger"
> posted in a recent post to me here, that does not mean the
> 64-bit version of Dragon will run twice as fast on the 64-bit OS.
>
> Actually, users found that running Dragon on a 64-bit OS yielded
> only very minor increases in speed, hardly noticable.

it depends on the app. in some cases it's quite a bit faster, and i
suspect dragon is one that would benefit a lot. in other cases it's
slower (and that's generally rare). most of the time, there's a
noticeable speed increase.

> In order to run twice as fast, Dragon code would have to be
> completely re-written for 64-bit use, a job that could take years.

it shouldn't take anywhere near that long.

> Not only that, but new CPUs would need to be created by Intel,
> to take full advantage of 64-bit capabilities.

that already happened, a while ago.

> Even on my most recent 17" MacBook Pro with all the bells and
> whistles, there is limited 64-bit capability. For example, it does
> not even have a 64-bit Kernel or Extensions.

it doesn't need a 64 bit kernel unless you have more than 32 gigs of
memory.

> I have 8 GB of RAM, sure, but I can only access 4 GB of Ram
> at a time. I need to access the CPU two separate times in order
> to use the full 8 GB of RAM that I have, which takes added time.

64 bit apps can access all 8 gig, today, and have been able to for a
few years.

> A true 64-bit Kernel could access all 8 GB of RAM at once.

as i said, it's not needed.

> All in all, I do not look for true 64-bit operation for at least
> another decade or two.

then you're living in a cave.