On Sat, 3 Nov 2012, Karl Denninger wrote:
On 11/3/2012 5:25 PM, Jeff Roberson wrote:
On Sat, 3 Nov 2012, Brett Glass wrote:
Have been following the thread related to SU+J, and
am wondering: why is it
considered to be undesirable on SSDs (assuming that
they have good wear
leveling)? I have been enabling it on systems with
SSDs, hoping that between
the lack of rotating media and the journaling I
would have very robust
systems.
I know of no reason to support this notion. Although SSDs are
so fast you might be happy to wait for the fsck time in exchange
for snapshots.
Jeff
It is utter insanity to enable, by default, filesystem options that break
the canonical backup solution in the handbook ("dump", when used with "-L",
which it must be to dump a live filesystem SAFELY.)
I did not enable it by default but it makes sense for desktop users who
are probably not often using dump/restore. I agree that the option should
be covered in more detail.
IMHO either snapshots with journaling needs to be fixed, some other
canonical and reasonably-implemented means of backups that actually works
and is as robust as dump must be made available, tested and documented at
the level that dump has been (good luck with that!) or +J has to be removed
as the default.
We are hopefully fixing snapshots in current and I would expect it to be
ready for backport in the 9.2 timeframe. It is next on the list after we
fix the drive write cache problem for mobile users who may lose power
frequently.
I love "progress" as much as the next guy but my first requirement for an
operating system is that it not irretrievably lose my data.
I hear your frustrations but please try to express it more productively in
the future.
Thanks,
Jeff
--
-- Karl Denninger
The Market Ticker (R)
Cuda Systems LLC
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
