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. --Brett Glass
On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass <brett at lariat.net> 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)?Superstition -- Adam Vande More
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> > --Brett Glass > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org" >
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. > > JeffIt 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.) 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. 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. -- -- Karl Denninger /The Market Ticker ?/ <http://market-ticker.org> Cuda Systems LLC
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 > >
At 04:32 PM 11/3/2012, Karl Denninger wrote:>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 have not used "dump" in many, many years. So, I hope the installer will not make it difficult for me to turn on SU+J despite the problem you mention above. That being said, "dump" should obviously be fixed to work with SU+J. Perhaps there could be a workaround (e.g. synchronizing the file system and temporarily turning off journaling during a backup) that would eliminate the need to turn SU+J off all the time while a more graceful fix is being readied. --Brett
I personally let it be enabled during installation. I noticed that I was getting errors on fsck even after clean shutdown. After noticing it, I disabled it and the problems go away. Also, fsck works really fast so I don't see much advantage with SU+J. -- Sent from my phone. Please excuse my brevity. Brett Glass <brett at lariat.net> 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. > >--Brett Glass >_______________________________________________ >freebsd-stable at freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to >"freebsd-stable-unsubscribe at freebsd.org"
On 11/4/2012 5:32, Karl Denninger wrote:> 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.)Exactly. -- Adam Strohl http://www.ateamsystems.com/
Imho, at least wiki page (http://wiki.freebsd.org/) on setting up FreeBSD on SSDs is needed. Lots of confusion and different opinions (sector size!)... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Why-is-SU-J-undesirable-on-SSDs-tp5757733p5757907.html Sent from the freebsd-stable mailing list archive at Nabble.com.