Date: Wed, 21 Oct 2015 13:08:43 -0500 From: Adam Vande More <amvandemore@gmail.com> To: "Brandon J. Wandersee" <brandon.wandersee@gmail.com> Cc: krad <kraduk@gmail.com>, FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: gjournal and TRIM: A safe combination? Message-ID: <CA%2BtpaK1W1Q_qwtoMNw5LbfncoFWZckTguGr4_OxymR8oUFk9-A@mail.gmail.com> In-Reply-To: <86oafs17ri.fsf@WorkBox.Home> References: <867fmh12nq.fsf@WorkBox.Home> <CALfReyfg-71nCg4K0dKmUK-YmZ8yi0ppeGGv4WOD-2Mt8NP9HQ@mail.gmail.com> <86pp081glq.fsf@WorkBox.Home> <CA%2BtpaK0ezoi7wBBD9VZwREq9Qp0YaJNfJY42=tZAYi5VSL8rCA@mail.gmail.com> <86oafs17ri.fsf@WorkBox.Home>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 21, 2015 at 11:55 AM, Brandon J. Wandersee < brandon.wandersee@gmail.com> wrote: > > Adam Vande More writes: > > > There is a fundamental difference between them. Don't you think you > should > > investigate the differences prior to deciding what to use? > > I did. Well not all that deeply apparently. > What I found was that apparently more people dislike SUJ than > like it, Anecdotal evidence isn't evidence all at. Many people used to say the same about SU etc. AFAICT that type of complaining falls into the same type as the hald whiners who will blame whatever they can on it and offer no real evidence why it is at fault. There were problems when it was introduced. Those have been fixed AFAIK other than snapshotting which is disabled. SU+J works great for many people and I leave it on for every new UFS based install. > SUJ is virtually undocumented, It's quite well documented. > and it is not intended to > protect data on a filesystem Of course not, that's what SU is for. Reading your responses lead me to question if you know what SU is. > but merely shorten boot times after a > crash. No, that's not what it's for although it's probably the final symptom many users wanted resolved. Faster boot times are simply an artifact of what SU+J does by skipping the need for a fsck background or otherwise. > The most recent information on gjournal outside the man page are > the Handbook and a years-old article that makes no mention of SSDs.[1] > gjournal came about during a time when HD drives were growing rapidly and fsck'ing a huge FS was becoming a problem. It was not designed for SSD's and its design makes it not a great choice for them. Actually an SSD as just a journal provider would make logical sense. > > Since I've seen nothing but complaints about SUJ, So you've said. Again, and again. And oh yes, don't forget to mention the lack of documentation as least twice more. and SUJ isn't > well-documented, > I don't know what that means, between the white papers, source code, presentations and man pages it seems documented quite well to me. > and SUJ apparently isn't intended to do what I'd like > journaling to do, and gjournal *is* reasonably well-documented and does > what I want, I went with gjournal. > > > It's not at clear what your goal is here. Do you want to minimize writes > > to the ssd or do you want to ensure the fs is always consistent from > both a > > meta-data and data perspective. These options are mutually exclusive in > > the parameters you've laid out. > > My goal is to format a disk partition and stick data on it. If possible, > I'd like to protect that data with something more than just > backups. Journaling is the way that's done. Journaling is one way it's done. <- FTFY SU is another, COW like ZFS is another. What do you mean by "protecting data"? That is only an artifact of what journaling does as well as preserving write ordering. I have no idea what you meant by the earlier reference "write holes". When referring to "write holes" one is generally talking about RAID and specifically RAID 5. So I still don't understand your goal here. You certainly haven't stated anything the standard UFS SU alone wouldn't cover. > (which has > absolutely nothing to do with minimizing writes--a practice that's > outdated at this point). Well I think we can all agree that's BS. It's the the fundamental point of TRIM and it's the main reason performance is maintained on a TRIM enabled as you reference below. > I've no idea whether TRIM and filesystem > journaling via gjournal are mutually exclusive; I think we're all clear on that point, but I'm not sure what that is a response to. If it was my earlier statement, I suggest you reread it. that's what I'm here to > find out. We're trying to find why you're asking bizarre questions. That's all. > There's no documentation on the matter. The four scenarios I > laid out are simply the four possible combinations of TRIM and > journaling (use either, use neither, use both). > > I simply got a warning message and want to know if that warning message > carries any weight. I want to know if using journaling with UFS on a > TRIM-enabled filesystem is potentially dangerous (as the warning > implies), or if the inability of the system to detect TRIM when > gjournal is enabled means that gjournal actually interferes with the > TRIM operation. If the combination of TRIM and gjournal--a combination > intended to preserve both data integrity and disk performance--can > actually cause more potential harm than good, then protecting data would > entail disabling TRIM while gjournal is enabled. On the other hand, if > TRIM is disabled then that means that performance on the disk will > gradually degrade, meaning that, journaling or no journaling, I'll need > to periodically wipe the filesystem and restore a backup in order to > restore > performance. In short, if gjournal interferes with TRIM in any way, or > if TRIM becomes potentially dangerous when used in conjunction with > gjournal, it's a no-win scenario. The ultimate result is effectively the > same: remake the filesystem and restore the data. > > I get the feeling that I'm the first person to ever bring this up. Maybe you're the first person to think gjournal on an SSD is something desirable. Could be, I know I don't. -- Adam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BtpaK1W1Q_qwtoMNw5LbfncoFWZckTguGr4_OxymR8oUFk9-A>