Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 03/21/2011 00:33, Jeff Roberson wrote: On Sun, 20 Mar 2011, Doug Barton wrote: On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. So you're saying the directory entry was missing? I'm saying that the file wasn't visible to 'ls /var/db/pkg/foo/'. I didn't debug it past determining that the files were missing. Can you tell me how big the directory was? Most of the damage was in /var/db/pkg/, so the individual directories that were missing files were small, no more than 10 files each. I imagine there was probably other damaged scattered throughout /var, but once I learned how many files were missing I just nuked it and restored from backup. Number of files? I stopped counting around 20 or so. Approximate directory size when you consider file names? When you fsck'd were inodes recovered and linked into lost and found? No. What was the actual path? To the lost files? The ones that I actually noticed missing were all /var/db/pkg/*/+CONTENTS. There were probably a lot of other files missing, but those were noticeable because the ports tree was throwing errors, and a missing +CONTENTS file can't be recovered from without re-installing the port. I'm trying to wrap my head around how this would be possible and where the error could be and whether it could be caused by SUJ. It never happened before enabling SUJ, happened shortly after I did, and has never happened since I disabled it. It's probably worth reiterating that the damage happened after an actual panic, as opposed to during regular operation. The number of interactions with disk writes are minimal. Corruption if it occurs would most likely be caused by a bad journal recovery. Unlikely in this case, since the damage was not confined to recently-written files. hth, Doug PS, my primary concern was that we not enable this by default until it can be demonstrated to be more robust. However Nathan has already enabled it in the new installer, so now perhaps it would be fitting to send a message to -current letting people know that the plan is to have it on by default in 9.0, and asking people to resume more rigorous testing. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Sun, 20 Mar 2011, Kirk McKusick wrote: Date: Sun, 20 Mar 2011 13:25:20 -0700 From: Doug Barton do...@freebsd.org To: Marius Strobl mar...@alchemy.franken.de CC: Kirk McKusick mckus...@mckusick.com, Nathan Whitehorn nwhiteh...@freebsd.org, svn-src-head@FreeBSD.org, Jeff Roberson j...@freebsd.org, Gavin Atkinson ga...@freebsd.org, svn-src-...@freebsd.org, src-committ...@freebsd.org, kved...@kvedulv.de Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. With all due respect to the hard work that went into the code, I would be very uncomfortable with enabling it by default at this point. Doug With all due respect, how can we fix things that nobody reports? If you have a problem, let us know about it. And of course, we need something more specific than the above. I have not been following current but I read any emails sent directly to me without a mailing list in the cc. I also was not aware of this. I had not heard of any filesystem corruption problems at all. If there are any, I also am not comfortable with enabling it by default. I want to fix that first. I have blocked off next week to work on this. I already sent an email out to current@ requesting bug reports. Please if you have anything else let me know immediately so I can prioritize it and start investigating. Thanks, Jeff Kirk McKusick ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Mar 20, 2011, at 10:34 PM, Jeff Roberson wrote: On Sun, 20 Mar 2011, Kirk McKusick wrote: Date: Sun, 20 Mar 2011 13:25:20 -0700 From: Doug Barton do...@freebsd.org To: Marius Strobl mar...@alchemy.franken.de CC: Kirk McKusick mckus...@mckusick.com, Nathan Whitehorn nwhiteh...@freebsd.org, svn-src-head@FreeBSD.org, Jeff Roberson j...@freebsd.org, Gavin Atkinson ga...@freebsd.org, svn-src-...@freebsd.org, src-committ...@freebsd.org, kved...@kvedulv.de Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. With all due respect to the hard work that went into the code, I would be very uncomfortable with enabling it by default at this point. Doug With all due respect, how can we fix things that nobody reports? If you have a problem, let us know about it. And of course, we need something more specific than the above. I have not been following current but I read any emails sent directly to me without a mailing list in the cc. I also was not aware of this. I had not heard of any filesystem corruption problems at all. If there are any, I also am not comfortable with enabling it by default. I want to fix that first. I have blocked off next week to work on this. I already sent an email out to current@ requesting bug reports. Please if you have anything else let me know immediately so I can prioritize it and start investigating. I haven't seen any data/metadata corruption issues with SUJ that weren't also present with SU (or just plain UFS). The vast majority of problems that I've witnessed have happened on systems with ATA/SATA disks, hinting (IMHO) that it's really the long-standing problem of running these disks with their write caches enabled. I don't think that I've encountered any appreciable problems on RAID controllers or SAS/SCSI disks with their write caches disabled. Maybe with CAMATA maturing and supporting NCQ, we can turn off the SATA write caches as the default policy. Scott ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Sun, 20 Mar 2011, Doug Barton wrote: On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. So you're saying the directory entry was missing? Can you tell me how big the directory was? Number of files? Approximate directory size when you consider file names? When you fsck'd were inodes recovered and linked into lost and found? What was the actual path? I'm trying to wrap my head around how this would be possible and where the error could be and whether it could be caused by SUJ. The number of interactions with disk writes are minimal. Corruption if it occurs would most likely be caused by a bad journal recovery. Thanks, Jeff With all due respect to the hard work that went into the code, I would be very uncomfortable with enabling it by default at this point. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
Hi All, On Sun, Mar 20, 2011 at 05:22:12PM +0100, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. Sorry, no details available, as I didn't record the panic and problems back then. However this was not the first panic which I attribute (maybe wrongly) to SUJ and as an consequence now all my UFS filesystems have SUJ turned off again. If SUJ really is going to be the default I would expact quite some fallout from this after my experiences. Kind Regards -- Michael Moll ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Mon, 21 Mar 2011, Michael Moll wrote: Hi All, On Sun, Mar 20, 2011 at 05:22:12PM +0100, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. Sorry, no details available, as I didn't record the panic and problems back then. However this was not the first panic which I attribute (maybe wrongly) to SUJ and as an consequence now all my UFS filesystems have SUJ turned off again. If SUJ really is going to be the default I would expact quite some fallout from this after my experiences. How long ago was this? We fixed quite a number of bugs a few months ago. Thanks, Jeff Kind Regards -- Michael Moll ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
Hi, On Mon, Mar 21, 2011 at 11:02:10AM -1000, Jeff Roberson wrote: Sorry, no details available, as I didn't record the panic and problems back then. However this was not the first panic which I attribute (maybe wrongly) to SUJ and as an consequence now all my UFS filesystems have SUJ turned off again. If SUJ really is going to be the default I would expact quite some fallout from this after my experiences. How long ago was this? Almost exactly two months ago. 19./20.01.2011 Regards -- Michael Moll ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Sat, Mar 19, 2011 at 05:00:51PM -0700, Kirk McKusick wrote: Date: Fri, 18 Mar 2011 20:50:08 -0500 From: Nathan Whitehorn nwhiteh...@freebsd.org Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit To: Gavin Atkinson ga...@freebsd.org Cc: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-head@FreeBSD.org On 03/15/11 12:50, Gavin Atkinson wrote: On Tue, 2011-03-15 at 12:26 -0500, Nathan Whitehorn wrote: Hrm, I hadn't realised this was the case. If this change is intentional and planned to remain, I guess the various bits of documentation that say several partitions good, one bad should be updated... It is intended. I think it makes things somewhat easier for the virtualization case, and I know a lot of people have been running their systems with one-big-/ for years. If it is harmful for some reason, however, it's easy to change. I wonder if it is time to start enabling SU+J on non-root filesystems now? That's certainly something to think about, although I'll defer whether that is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. As of r218726, you can now set this from newfs. (-j) Ah, wonderful. The decision of whether that is a good idea still rests with others, however :) -nathan I believe that we should enable SU+J by default. We should do it now so that we can get wider experience with it before 9.0 is released (thus letting us revert to SU if uncorrectable problems arise). I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. Marius ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. With all due respect to the hard work that went into the code, I would be very uncomfortable with enabling it by default at this point. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
Date: Sun, 20 Mar 2011 13:25:20 -0700 From: Doug Barton do...@freebsd.org To: Marius Strobl mar...@alchemy.franken.de CC: Kirk McKusick mckus...@mckusick.com, Nathan Whitehorn nwhiteh...@freebsd.org, svn-src-head@FreeBSD.org, Jeff Roberson j...@freebsd.org, Gavin Atkinson ga...@freebsd.org, svn-src-...@freebsd.org, src-committ...@freebsd.org, kved...@kvedulv.de Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit On 03/20/2011 09:22, Marius Strobl wrote: I fear it's still a bit premature for enable SU+J by default. Rather recently I was told about a SU+J filesystems lost after a panic that happend after snapshotting it (report CC'ed, maybe he can provide some more details) and I'm pretty sure I've seen the problem described in PR 149022 also after the potential fix mentioned in its feedback. +1 I tried enabling SU+J on my /var (after backing up of course) and after a panic random files were missing entirely. Not the last updates to those files, the whole file, and many of them had not been written to in days/weeks/months. With all due respect to the hard work that went into the code, I would be very uncomfortable with enabling it by default at this point. Doug With all due respect, how can we fix things that nobody reports? If you have a problem, let us know about it. And of course, we need something more specific than the above. Kirk McKusick ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
Date: Fri, 18 Mar 2011 20:50:08 -0500 From: Nathan Whitehorn nwhiteh...@freebsd.org Subject: Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit To: Gavin Atkinson ga...@freebsd.org Cc: src-committ...@freebsd.org, svn-src-...@freebsd.org, svn-src-head@FreeBSD.org On 03/15/11 12:50, Gavin Atkinson wrote: On Tue, 2011-03-15 at 12:26 -0500, Nathan Whitehorn wrote: Hrm, I hadn't realised this was the case. If this change is intentional and planned to remain, I guess the various bits of documentation that say several partitions good, one bad should be updated... It is intended. I think it makes things somewhat easier for the virtualization case, and I know a lot of people have been running their systems with one-big-/ for years. If it is harmful for some reason, however, it's easy to change. I wonder if it is time to start enabling SU+J on non-root filesystems now? That's certainly something to think about, although I'll defer whether that is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. As of r218726, you can now set this from newfs. (-j) Ah, wonderful. The decision of whether that is a good idea still rests with others, however :) -nathan I believe that we should enable SU+J by default. We should do it now so that we can get wider experience with it before 9.0 is released (thus letting us revert to SU if uncorrectable problems arise). The requirement that the root run without SU derived from the fact that you could get out of space errors if you tried to replace files too quickly (e.g., during installworld). That problem was fixed about 2004. So there is no reason that root cannot have SU enabled. In particular, if you are going to default to a single filesystem, then root should definitely have SU (or SU+J per above) enabled. Kirk McKusick ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 03/15/11 12:50, Gavin Atkinson wrote: On Tue, 2011-03-15 at 12:26 -0500, Nathan Whitehorn wrote: On 03/15/11 09:19, Gavin Atkinson wrote: On Tue, 2011-03-15 at 13:27 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Tue Mar 15 13:27:34 2011 New Revision: 219667 URL: http://svn.freebsd.org/changeset/base/219667 Log: Turn on softupdates by default. We need a UI to set filesystem parameters. Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c This would appear to still be a change from the previous behaviour, where softupdates were enabled by default for any filesystem except for the root filesystem. It is -- and this needs to become settable. Bear in mind, however, that the default partition layout is also different. If you select the auto option, only one file system is made, so there are no non-root file systems. Hrm, I hadn't realised this was the case. If this change is intentional and planned to remain, I guess the various bits of documentation that say several partitions good, one bad should be updated... It is intended. I think it makes things somewhat easier for the virtualization case, and I know a lot of people have been running their systems with one-big-/ for years. If it is harmful for some reason, however, it's easy to change. I wonder if it is time to start enabling SU+J on non-root filesystems now? That's certainly something to think about, although I'll defer whether that is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. As of r218726, you can now set this from newfs. (-j) Ah, wonderful. The decision of whether that is a good idea still rests with others, however :) -nathan ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 03/16/11 01:25, Daniel O'Connor wrote: On 16/03/2011, at 4:14, Ben Kaduk wrote: is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. I suspect the consensus of people like -arch and -fs will be that the burn-in time before it is considered sufficiently stable is be measured in years. Which is a good reason to have a UI to set it :) Or maybe when you say auto it asks if you want it on or not. Yes, there should be a UI for sure. Just ENOTIME so far. -Nathan ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 16/03/2011, at 4:14, Ben Kaduk wrote: is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. I suspect the consensus of people like -arch and -fs will be that the burn-in time before it is considered sufficiently stable is be measured in years. Which is a good reason to have a UI to set it :) Or maybe when you say auto it asks if you want it on or not. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
Author: nwhitehorn
Date: Tue Mar 15 13:27:34 2011
New Revision: 219667
URL: http://svn.freebsd.org/changeset/base/219667
Log:
Turn on softupdates by default. We need a UI to set filesystem parameters.
Modified:
head/usr.sbin/bsdinstall/partedit/gpart_ops.c
Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c
==
--- head/usr.sbin/bsdinstall/partedit/gpart_ops.c Tue Mar 15 13:19:26
2011(r219666)
+++ head/usr.sbin/bsdinstall/partedit/gpart_ops.c Tue Mar 15 13:27:34
2011(r219667)
@@ -496,7 +496,7 @@ set_default_part_metadata(const char *na
if (strcmp(type, freebsd-ufs) == 0) {
md-newfs = malloc(255);
- sprintf(md-newfs, newfs /dev/%s, name);
+ sprintf(md-newfs, newfs -U /dev/%s, name);
}
}
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Tue, 2011-03-15 at 13:27 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Tue Mar 15 13:27:34 2011 New Revision: 219667 URL: http://svn.freebsd.org/changeset/base/219667 Log: Turn on softupdates by default. We need a UI to set filesystem parameters. Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c This would appear to still be a change from the previous behaviour, where softupdates were enabled by default for any filesystem except for the root filesystem. I wonder if it is time to start enabling SU+J on non-root filesystems now? Gavin -- Gavin Atkinson FreeBSD committer and bugmeister GPG: A093262B (313A A79F 697D 3A5C 216A EDF5 935D EF44 A093 262B) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On 03/15/11 09:19, Gavin Atkinson wrote: On Tue, 2011-03-15 at 13:27 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Tue Mar 15 13:27:34 2011 New Revision: 219667 URL: http://svn.freebsd.org/changeset/base/219667 Log: Turn on softupdates by default. We need a UI to set filesystem parameters. Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c This would appear to still be a change from the previous behaviour, where softupdates were enabled by default for any filesystem except for the root filesystem. It is -- and this needs to become settable. Bear in mind, however, that the default partition layout is also different. If you select the auto option, only one file system is made, so there are no non-root file systems. I wonder if it is time to start enabling SU+J on non-root filesystems now? That's certainly something to think about, although I'll defer whether that is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. -Natha ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r219667 - head/usr.sbin/bsdinstall/partedit
On Tue, 2011-03-15 at 12:26 -0500, Nathan Whitehorn wrote: On 03/15/11 09:19, Gavin Atkinson wrote: On Tue, 2011-03-15 at 13:27 +, Nathan Whitehorn wrote: Author: nwhitehorn Date: Tue Mar 15 13:27:34 2011 New Revision: 219667 URL: http://svn.freebsd.org/changeset/base/219667 Log: Turn on softupdates by default. We need a UI to set filesystem parameters. Modified: head/usr.sbin/bsdinstall/partedit/gpart_ops.c This would appear to still be a change from the previous behaviour, where softupdates were enabled by default for any filesystem except for the root filesystem. It is -- and this needs to become settable. Bear in mind, however, that the default partition layout is also different. If you select the auto option, only one file system is made, so there are no non-root file systems. Hrm, I hadn't realised this was the case. If this change is intentional and planned to remain, I guess the various bits of documentation that say several partitions good, one bad should be updated... I wonder if it is time to start enabling SU+J on non-root filesystems now? That's certainly something to think about, although I'll defer whether that is wise to others. It's a little bit of a pain on the implementation side, since you can't turn it on from newfs, but that isn't a serious obstacle. As of r218726, you can now set this from newfs. (-j) Thanks, Gavin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
