* [REVIEW] Don't make lazy counters default for mkfs @ 2008-02-28 1:09 Barry Naujok 2008-02-28 2:35 ` Nathan Scott 2008-03-02 10:26 ` Andi Kleen 0 siblings, 2 replies; 22+ messages in thread From: Barry Naujok @ 2008-02-28 1:09 UTC (permalink / raw) To: xfs@oss.sgi.com [-- Attachment #1: Type: text/plain, Size: 636 bytes --] Lazy superblock counters was released into mainline in 2.6.23-rc1. Some distros are still running an older kernel (2.6.22 for example) and with the latest xfsprogs, cannot mount a freshly made filesystem with default options. This patch make lazy counters default back to off now. Users who have a more recent kernel can easily enable them with mkfs or xfs_admin -c1 (in a patch posted out a few days ago which will be in the same xfsprogs release as this patch). Lazy counters will default to on again in xfsprogs 2.10.0 (when CI support is released). This should give enough time for distro kernels to catch up. Barry. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: default_lazycount_off.patch --] [-- Type: text/x-patch; name=default_lazycount_off.patch, Size: 440 bytes --] Index: ci/xfsprogs/mkfs/xfs_mkfs.c =================================================================== --- ci.orig/xfsprogs/mkfs/xfs_mkfs.c 2008-02-28 12:02:55.000000000 +1100 +++ ci/xfsprogs/mkfs/xfs_mkfs.c 2008-02-28 12:04:17.288809770 +1100 @@ -730,7 +730,7 @@ nodsflag = norsflag = 0; force_overwrite = 0; worst_freelist = 0; - lazy_sb_counters = 1; + lazy_sb_counters = 0; bzero(&fsx, sizeof(fsx)); bzero(&xi, sizeof(xi)); ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-28 1:09 [REVIEW] Don't make lazy counters default for mkfs Barry Naujok @ 2008-02-28 2:35 ` Nathan Scott 2008-02-29 21:21 ` Russell Cattelan 2008-03-02 10:26 ` Andi Kleen 1 sibling, 1 reply; 22+ messages in thread From: Nathan Scott @ 2008-02-28 2:35 UTC (permalink / raw) To: Barry Naujok; +Cc: xfs@oss.sgi.com On Thu, 2008-02-28 at 12:09 +1100, Barry Naujok wrote: > > > Lazy superblock counters was released into mainline in 2.6.23-rc1. > Some > distros are still running an older kernel (2.6.22 for example) and > with (many distros? RHEL5 and SLES10 wont have such recent kernels yet, right?) > the latest xfsprogs, cannot mount a freshly made filesystem with > default > options. > > This patch make lazy counters default back to off now. Looks good, thanks. > Users who have a more recent kernel can easily enable them with mkfs > or > xfs_admin -c1 (in a patch posted out a few days ago which will be in > the > same xfsprogs release as this patch). > > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI > support > is released). This should give enough time for distro kernels to catch > up. Hmm, that still seems pretty soon to me. I'd have thought you'd at least want to wait until most of the distributions (esp. SUSE for you guys) have released versions that have kernels sufficiently recent that the default mkfs will work. Otherwise this will be a recurring problem. cheers. -- Nathan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-28 2:35 ` Nathan Scott @ 2008-02-29 21:21 ` Russell Cattelan 2008-02-29 23:11 ` Eric Sandeen 0 siblings, 1 reply; 22+ messages in thread From: Russell Cattelan @ 2008-02-29 21:21 UTC (permalink / raw) To: nscott; +Cc: Barry Naujok, xfs@oss.sgi.com [-- Attachment #1: Type: text/plain, Size: 1330 bytes --] Nathan Scott wrote: > On Thu, 2008-02-28 at 12:09 +1100, Barry Naujok wrote: > >> Lazy superblock counters was released into mainline in 2.6.23-rc1. >> Some >> distros are still running an older kernel (2.6.22 for example) and >> with >> > > (many distros? RHEL5 and SLES10 wont have such recent kernels yet, > right?) > > >> the latest xfsprogs, cannot mount a freshly made filesystem with >> default >> options. >> >> This patch make lazy counters default back to off now. >> > > Looks good, thanks. > > >> Users who have a more recent kernel can easily enable them with mkfs >> or >> xfs_admin -c1 (in a patch posted out a few days ago which will be in >> the >> same xfsprogs release as this patch). >> >> Lazy counters will default to on again in xfsprogs 2.10.0 (when CI >> support >> is released). This should give enough time for distro kernels to catch >> up. >> > > Hmm, that still seems pretty soon to me. I'd have thought you'd at > least want to wait until most of the distributions (esp. SUSE for you > guys) have released versions that have kernels sufficiently recent > that the default mkfs will work. Otherwise this will be a recurring > problem. > I don't suppose there is an easy way to query xfs and find out if it can support the lazy SB option? > cheers. > > [-- Attachment #2: cattelan.vcf --] [-- Type: text/x-vcard, Size: 131 bytes --] begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 21:21 ` Russell Cattelan @ 2008-02-29 23:11 ` Eric Sandeen 2008-02-29 23:19 ` Russell Cattelan 0 siblings, 1 reply; 22+ messages in thread From: Eric Sandeen @ 2008-02-29 23:11 UTC (permalink / raw) To: Russell Cattelan; +Cc: nscott, Barry Naujok, xfs@oss.sgi.com Russell Cattelan wrote: >> Hmm, that still seems pretty soon to me. I'd have thought you'd at >> least want to wait until most of the distributions (esp. SUSE for you >> guys) have released versions that have kernels sufficiently recent >> that the default mkfs will work. Otherwise this will be a recurring >> problem. >> > I don't suppose there is an easy way to query xfs and find out if it can > support > the lazy SB option? I thought about that; xfs *could* stick someting in /proc/fs/xfs with supported features or somesuch. But, the kernel you mkfs under isn't necessarily the one you're going to need to fall back to tomorrow, though... -Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:11 ` Eric Sandeen @ 2008-02-29 23:19 ` Russell Cattelan 2008-02-29 23:47 ` Mark Goodwin 2008-03-02 23:34 ` Nathan Scott 0 siblings, 2 replies; 22+ messages in thread From: Russell Cattelan @ 2008-02-29 23:19 UTC (permalink / raw) To: Eric Sandeen; +Cc: nscott, Barry Naujok, xfs@oss.sgi.com [-- Attachment #1: Type: text/plain, Size: 882 bytes --] Eric Sandeen wrote: > Russell Cattelan wrote: > > > >>> Hmm, that still seems pretty soon to me. I'd have thought you'd at >>> least want to wait until most of the distributions (esp. SUSE for you >>> guys) have released versions that have kernels sufficiently recent >>> that the default mkfs will work. Otherwise this will be a recurring >>> problem. >>> >>> >> I don't suppose there is an easy way to query xfs and find out if it can >> support >> the lazy SB option? >> > > I thought about that; xfs *could* stick someting in /proc/fs/xfs with > supported features or somesuch. > > But, the kernel you mkfs under isn't necessarily the one you're going to > need to fall back to tomorrow, though... > > True but at least it could make a bit of a intelligent decision. and maybe a warning for a while about potentially incompatible flags. > -Eric > > [-- Attachment #2: cattelan.vcf --] [-- Type: text/x-vcard, Size: 131 bytes --] begin:vcard fn:Russell Cattelan n:Cattelan;Russell email;internet:cattelan@thebarn.com x-mozilla-html:FALSE version:2.1 end:vcard ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:19 ` Russell Cattelan @ 2008-02-29 23:47 ` Mark Goodwin 2008-02-29 23:56 ` Eric Sandeen 2008-03-01 0:02 ` Josef 'Jeff' Sipek 2008-03-02 23:34 ` Nathan Scott 1 sibling, 2 replies; 22+ messages in thread From: Mark Goodwin @ 2008-02-29 23:47 UTC (permalink / raw) To: Russell Cattelan; +Cc: Eric Sandeen, nscott, Barry Naujok, xfs@oss.sgi.com Russell Cattelan wrote: > Eric Sandeen wrote: >> Russell Cattelan wrote: >> >> >> >>>> Hmm, that still seems pretty soon to me. I'd have thought you'd at >>>> least want to wait until most of the distributions (esp. SUSE for you >>>> guys) have released versions that have kernels sufficiently recent >>>> that the default mkfs will work. Otherwise this will be a recurring >>>> problem. >>>> >>> I don't suppose there is an easy way to query xfs and find out if it >>> can support >>> the lazy SB option? >> >> I thought about that; xfs *could* stick someting in /proc/fs/xfs with >> supported features or somesuch. how about /proc/fs/xfs/features .. any format suggestions? >> But, the kernel you mkfs under isn't necessarily the one you're going to >> need to fall back to tomorrow, though... nor the one you just installed but haven't rebooted into yet > True but at least it could make a bit of a intelligent decision. > and maybe a warning for a while about potentially incompatible flags. yes agree Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:47 ` Mark Goodwin @ 2008-02-29 23:56 ` Eric Sandeen 2008-03-01 0:11 ` Eric Sandeen 2008-03-01 0:02 ` Josef 'Jeff' Sipek 1 sibling, 1 reply; 22+ messages in thread From: Eric Sandeen @ 2008-02-29 23:56 UTC (permalink / raw) To: markgw; +Cc: Russell Cattelan, nscott, Barry Naujok, xfs@oss.sgi.com Mark Goodwin wrote: > > Russell Cattelan wrote: >> Eric Sandeen wrote: >>> Russell Cattelan wrote: >>> >>> >>> >>>>> Hmm, that still seems pretty soon to me. I'd have thought you'd at >>>>> least want to wait until most of the distributions (esp. SUSE for you >>>>> guys) have released versions that have kernels sufficiently recent >>>>> that the default mkfs will work. Otherwise this will be a recurring >>>>> problem. >>>>> >>>> I don't suppose there is an easy way to query xfs and find out if it >>>> can support >>>> the lazy SB option? >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs with >>> supported features or somesuch. > > how about /proc/fs/xfs/features > .. any format suggestions? maybe just 2 values, with the actual supported features (& features2) values anded together? Easy enough to parse in the code. i.e. # cat /proc/fs/xfs/features 0xffffffff 0x00000001 ? -Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:56 ` Eric Sandeen @ 2008-03-01 0:11 ` Eric Sandeen 2008-03-02 23:59 ` Barry Naujok 0 siblings, 1 reply; 22+ messages in thread From: Eric Sandeen @ 2008-03-01 0:11 UTC (permalink / raw) To: markgw; +Cc: Russell Cattelan, nscott, Barry Naujok, xfs@oss.sgi.com Eric Sandeen wrote: > maybe just 2 values, with the actual supported features (& features2) > values anded together? Easy enough to parse in the code. > > i.e. > > # cat /proc/fs/xfs/features > 0xffffffff > 0x00000001 hm, but of course mkfs should never be checking for anything in the first features slot; yesterday's kernels support all those flags but don't export anything. wow, this is starting to feel as complex as ext4's flags ;) -Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-01 0:11 ` Eric Sandeen @ 2008-03-02 23:59 ` Barry Naujok 0 siblings, 0 replies; 22+ messages in thread From: Barry Naujok @ 2008-03-02 23:59 UTC (permalink / raw) To: Eric Sandeen, markgw; +Cc: Russell Cattelan, nscott, xfs@oss.sgi.com On Sat, 01 Mar 2008 11:11:03 +1100, Eric Sandeen <sandeen@sandeen.net> wrote: > Eric Sandeen wrote: > >> maybe just 2 values, with the actual supported features (& features2) >> values anded together? Easy enough to parse in the code. >> >> i.e. >> >> # cat /proc/fs/xfs/features >> 0xffffffff >> 0x00000001 > > hm, but of course mkfs should never be checking for anything in the > first features slot; yesterday's kernels support all those flags but > don't export anything. Bzzzzt! IRIX/ASCII case-insensitive mode (or OLDCI or "V1 CI" as I'm calling it :) ) is in the first features slot - 0x4000 > wow, this is starting to feel as complex as ext4's flags ;) > > -Eric > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:47 ` Mark Goodwin 2008-02-29 23:56 ` Eric Sandeen @ 2008-03-01 0:02 ` Josef 'Jeff' Sipek 1 sibling, 0 replies; 22+ messages in thread From: Josef 'Jeff' Sipek @ 2008-03-01 0:02 UTC (permalink / raw) To: Mark Goodwin Cc: Russell Cattelan, Eric Sandeen, nscott, Barry Naujok, xfs@oss.sgi.com On Sat, Mar 01, 2008 at 10:47:06AM +1100, Mark Goodwin wrote: > Russell Cattelan wrote: >> Eric Sandeen wrote: >>> Russell Cattelan wrote: >>>>> Hmm, that still seems pretty soon to me. I'd have thought you'd at >>>>> least want to wait until most of the distributions (esp. SUSE for you >>>>> guys) have released versions that have kernels sufficiently recent >>>>> that the default mkfs will work. Otherwise this will be a recurring >>>>> problem. >>>>> >>>> I don't suppose there is an easy way to query xfs and find out if it >>>> can support >>>> the lazy SB option? >>> >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs with >>> supported features or somesuch. > > how about /proc/fs/xfs/features > .. any format suggestions? I'd say strings like: lazy-count attr2 Something that'd match the mkfs option strings closely. This would make iterating over the features supported easy in a shell script... cat /proc/fs/xfs/features | while read feat ; do something $feat ; done I get the feeling that this might be useful even if mkfs doesn't check it. >>> But, the kernel you mkfs under isn't necessarily the one you're going to >>> need to fall back to tomorrow, though... > > nor the one you just installed but haven't rebooted into yet Right, if you know what you are doing, you can specify whatever options you want by hand...this is about the default values. Another issue is with portable media - I use XFS on external disks, and until recently I couldn't redo them with lazy-count if I wanted to use it on my laptop. Josef 'Jeff' Sipek. -- A CRAY is the only computer that runs an endless loop in just 4 hours... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-29 23:19 ` Russell Cattelan 2008-02-29 23:47 ` Mark Goodwin @ 2008-03-02 23:34 ` Nathan Scott 2008-03-03 0:16 ` Timothy Shimmin 2008-03-03 0:18 ` Donald Douwsma 1 sibling, 2 replies; 22+ messages in thread From: Nathan Scott @ 2008-03-02 23:34 UTC (permalink / raw) To: Russell Cattelan; +Cc: Eric Sandeen, Barry Naujok, xfs@oss.sgi.com On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: > > > I thought about that; xfs *could* stick someting in /proc/fs/xfs > with > > supported features or somesuch. > > > > But, the kernel you mkfs under isn't necessarily the one you're > going to > > need to fall back to tomorrow, though... > > > > > True but at least it could make a bit of a intelligent decision. > and maybe a warning for a while about potentially incompatible flags. Might also be a good idea to require -f to force a mkfs of a filesystem which the kernel doesn't support. Would be good to get blocksize > pagesize into this scheme too btw, and unfortunately that one isn't a superblock flag) - so this scheme might need to go beyond those flags, if anyone decides to implement it. cheers. -- Nathan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-02 23:34 ` Nathan Scott @ 2008-03-03 0:16 ` Timothy Shimmin 2008-03-03 0:30 ` Mark Goodwin 2008-03-03 0:18 ` Donald Douwsma 1 sibling, 1 reply; 22+ messages in thread From: Timothy Shimmin @ 2008-03-03 0:16 UTC (permalink / raw) To: Mark Goodwin Cc: nscott, Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com Nathan Scott wrote: > On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >> with >>> supported features or somesuch. >>> >>> But, the kernel you mkfs under isn't necessarily the one you're >> going to >>> need to fall back to tomorrow, though... >>> >>> >> True but at least it could make a bit of a intelligent decision. >> and maybe a warning for a while about potentially incompatible flags. > > Might also be a good idea to require -f to force a mkfs of a filesystem > which the kernel doesn't support. > 974981: mkfs.xfs should warn if it is about to create a fs that cannot be mounted Ivan was wanting this in December last year. Remember, Mark? He wanted to know what XFS features the running kernel supported? I don't think Dave (dgc) and others were not so keen on it IIRC. (Seems fine to me:) --Tim ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 0:16 ` Timothy Shimmin @ 2008-03-03 0:30 ` Mark Goodwin 2008-03-03 1:15 ` Josef 'Jeff' Sipek 2008-03-03 4:47 ` Niv Sardi 0 siblings, 2 replies; 22+ messages in thread From: Mark Goodwin @ 2008-03-03 0:30 UTC (permalink / raw) To: Timothy Shimmin Cc: nscott, Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com Timothy Shimmin wrote: > Nathan Scott wrote: >> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >>> with >>>> supported features or somesuch. >>>> >>>> But, the kernel you mkfs under isn't necessarily the one you're >>> going to >>>> need to fall back to tomorrow, though... >>>> >>>> >>> True but at least it could make a bit of a intelligent decision. >>> and maybe a warning for a while about potentially incompatible flags. >> >> Might also be a good idea to require -f to force a mkfs of a filesystem >> which the kernel doesn't support. >> > > 974981: mkfs.xfs should warn if it is about to create a fs that cannot > be mounted > > Ivan was wanting this in December last year. Remember, Mark? > He wanted to know what XFS features the running kernel supported? It was worse than that - IIRC, he wanted to know what features are supported by the XFS kernel module he just installed (this was part of an Appman upgrade scenario). I thought we rejected that bug ? > > I don't think Dave (dgc) and others were not so keen on it IIRC. anyone recall the reasons? Maybe I'm missing something, but if we export all the feature bits, both new and old, then (a) an old mkfs will continue to ignore them, and (b) future versions of mkfs will have all the information needed, but will need t be smart about how that information is used. Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 0:30 ` Mark Goodwin @ 2008-03-03 1:15 ` Josef 'Jeff' Sipek 2008-03-03 3:56 ` Eric Sandeen 2008-03-03 4:47 ` Niv Sardi 1 sibling, 1 reply; 22+ messages in thread From: Josef 'Jeff' Sipek @ 2008-03-03 1:15 UTC (permalink / raw) To: Mark Goodwin Cc: Timothy Shimmin, nscott, Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: ... > Maybe I'm missing something, but if we export all the feature bits, > both new and old, then (a) an old mkfs will continue to ignore them, > and (b) future versions of mkfs will have all the information needed, > but will need t be smart about how that information is used. IMHO: 1) mkfs should make a filesystem, the defaults should be conservative (say using features that have been around >1 year) 2) xfs should export supported features to userspace 3) if you want to make sure that the fs you create will be mountable with your current kernel, write a small shell script or something along those lines that reads the features from some kernel interface, and based on those passes the right options to mkfs 4) if you just use mkfs and it creates a fs that's incompatible with your current kernel, the mount will fail - as it does today, but perhaps a less cryptic error message would be in order Since installers are just gigantic wrappers around basic commands like mkfs, #3 gets nicely covered. Josef 'Jeff' Sipek. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 1:15 ` Josef 'Jeff' Sipek @ 2008-03-03 3:56 ` Eric Sandeen 2008-03-03 4:14 ` Josef 'Jeff' Sipek 0 siblings, 1 reply; 22+ messages in thread From: Eric Sandeen @ 2008-03-03 3:56 UTC (permalink / raw) To: Josef 'Jeff' Sipek Cc: Mark Goodwin, Timothy Shimmin, nscott, Russell Cattelan, Barry Naujok, xfs@oss.sgi.com Josef 'Jeff' Sipek wrote: > On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: > ... >> Maybe I'm missing something, but if we export all the feature bits, >> both new and old, then (a) an old mkfs will continue to ignore them, >> and (b) future versions of mkfs will have all the information needed, >> but will need t be smart about how that information is used. > > IMHO: > > 1) mkfs should make a filesystem, the defaults should be conservative (say > using features that have been around >1 year) I suppose I have to agree, unfortunately that means most competetive benchmarks will be using sub-optimal mkfs's, but... > 2) xfs should export supported features to userspace > > 3) if you want to make sure that the fs you create will be mountable with > your current kernel, write a small shell script or something along those > lines that reads the features from some kernel interface, and based on > those passes the right options to mkfs > 4) if you just use mkfs and it creates a fs that's incompatible with your > current kernel, the mount will fail - as it does today, but perhaps a > less cryptic error message would be in order Ya know, good point. We already have "running kernel compatibility checks" built in; it's called "see what happens when you mount it" It's not like we're running mkfs.ext3 here... ;) mkfs; mount will tell you quickly if there's a problem, won't it. Adding complexity to mkfs might not make a lot of sense. And I still am not a huge fan of checking the currently-running kernel; that's just a point in time, and not necessarily what you're gonna mount it with. (heck maybe you're mkfs'ing a san filesystem?) it's unix, after all. hand out the hangin' rope... just make the kernel explain exactly how & why you've just hung yourself at mount time, in that case.... -Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 3:56 ` Eric Sandeen @ 2008-03-03 4:14 ` Josef 'Jeff' Sipek 2008-03-03 4:19 ` Eric Sandeen 0 siblings, 1 reply; 22+ messages in thread From: Josef 'Jeff' Sipek @ 2008-03-03 4:14 UTC (permalink / raw) To: Eric Sandeen Cc: Mark Goodwin, Timothy Shimmin, nscott, Russell Cattelan, Barry Naujok, xfs@oss.sgi.com On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote: > Josef 'Jeff' Sipek wrote: > > On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: > > ... > >> Maybe I'm missing something, but if we export all the feature bits, > >> both new and old, then (a) an old mkfs will continue to ignore them, > >> and (b) future versions of mkfs will have all the information needed, > >> but will need t be smart about how that information is used. > > > > IMHO: > > > > 1) mkfs should make a filesystem, the defaults should be conservative (say > > using features that have been around >1 year) > > I suppose I have to agree, unfortunately that means most competetive > benchmarks will be using sub-optimal mkfs's, but... Benchmarks that use default mkfs options on xfs, but non-default on other fs? If you want, have a simple printf in mkfs that tells the user that he's not using the latest and greatest features (e.g., lazy-count); that should be enough to make it obvious that there're better options than the default. > It's not like we're running mkfs.ext3 here... ;) mkfs; mount will tell > you quickly if there's a problem, won't it. Adding complexity to mkfs > might not make a lot of sense. Exactly :) Josef 'Jeff' Sipek. -- I already backed up the [server] once, I can do it again. - a sysadmin threatening to do more frequent backups ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 4:14 ` Josef 'Jeff' Sipek @ 2008-03-03 4:19 ` Eric Sandeen 0 siblings, 0 replies; 22+ messages in thread From: Eric Sandeen @ 2008-03-03 4:19 UTC (permalink / raw) To: Josef 'Jeff' Sipek Cc: Mark Goodwin, Timothy Shimmin, nscott, Russell Cattelan, Barry Naujok, xfs@oss.sgi.com Josef 'Jeff' Sipek wrote: > On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote: >> Josef 'Jeff' Sipek wrote: >>> On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: >>> ... >>>> Maybe I'm missing something, but if we export all the feature bits, >>>> both new and old, then (a) an old mkfs will continue to ignore them, >>>> and (b) future versions of mkfs will have all the information needed, >>>> but will need t be smart about how that information is used. >>> IMHO: >>> >>> 1) mkfs should make a filesystem, the defaults should be conservative (say >>> using features that have been around >1 year) >> I suppose I have to agree, unfortunately that means most competetive >> benchmarks will be using sub-optimal mkfs's, but... > > Benchmarks that use default mkfs options on xfs, but non-default on other > fs? most benchmarks I see tune the heck out of "the home team" and leave the rest ;) > If you want, have a simple printf in mkfs that tells the user that he's not > using the latest and greatest features (e.g., lazy-count); that should be > enough to make it obvious that there're better options than the default. eh, nobody reads that stuff :) -Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 0:30 ` Mark Goodwin 2008-03-03 1:15 ` Josef 'Jeff' Sipek @ 2008-03-03 4:47 ` Niv Sardi 1 sibling, 0 replies; 22+ messages in thread From: Niv Sardi @ 2008-03-03 4:47 UTC (permalink / raw) To: markgw Cc: Timothy Shimmin, nscott, Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com Mark Goodwin <markgw@sgi.com> writes: > Timothy Shimmin wrote: >> Nathan Scott wrote: >>> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >>>> with >>>>> supported features or somesuch. >>>>> >>>>> But, the kernel you mkfs under isn't necessarily the one you're >>>> going to >>>>> need to fall back to tomorrow, though... >>>>> >>>>> >>>> True but at least it could make a bit of a intelligent decision. >>>> and maybe a warning for a while about potentially incompatible >>>> flags. >>> >>> Might also be a good idea to require -f to force a mkfs of a filesystem >>> which the kernel doesn't support. >>> >> 974981: mkfs.xfs should warn if it is about to create a fs that >> cannot be mounted >> >> Ivan was wanting this in December last year. Remember, Mark? >> He wanted to know what XFS features the running kernel supported? > > It was worse than that - IIRC, he wanted to know what features are > supported by the XFS kernel module he just installed (this was part > of an Appman upgrade scenario). I thought we rejected that bug ? > >> >> I don't think Dave (dgc) and others were not so keen on it IIRC. > > anyone recall the reasons? Yes, we got to the consensus that having mkfs check for kernel stuff is plain wrong, and there are a load of reasons to that, the most convincing is that you can have no XFS support in the kernel at mkfs time (i.e. module, that'll be loaded only on mount). Others reasons go along the line of: * You could be mkfsing for another box/kernel. * We want people to run latest kernels if they run latest xfsprogs =) Cheers, -- Niv Sardi ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-02 23:34 ` Nathan Scott 2008-03-03 0:16 ` Timothy Shimmin @ 2008-03-03 0:18 ` Donald Douwsma 2008-03-03 0:24 ` Nathan Scott 1 sibling, 1 reply; 22+ messages in thread From: Donald Douwsma @ 2008-03-03 0:18 UTC (permalink / raw) To: nscott; +Cc: Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com Nathan Scott wrote: > On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >> with >>> supported features or somesuch. >>> >>> But, the kernel you mkfs under isn't necessarily the one you're >> going to >>> need to fall back to tomorrow, though... >>> >>> >> True but at least it could make a bit of a intelligent decision. >> and maybe a warning for a while about potentially incompatible flags. > > Might also be a good idea to require -f to force a mkfs of a filesystem > which the kernel doesn't support. Could work but I dont like the idea of using -f for anything but mkfsing an existing filesystem. If that becomes habit for people it could lead to disasters. Don ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-03 0:18 ` Donald Douwsma @ 2008-03-03 0:24 ` Nathan Scott 0 siblings, 0 replies; 22+ messages in thread From: Nathan Scott @ 2008-03-03 0:24 UTC (permalink / raw) To: Donald Douwsma Cc: Russell Cattelan, Eric Sandeen, Barry Naujok, xfs@oss.sgi.com On Mon, 2008-03-03 at 11:18 +1100, Donald Douwsma wrote: > > > Could work but I dont like the idea of using -f for anything but > mkfsing an > existing filesystem. If that becomes habit for people it could lead to > disasters. Its already used for more than just overwriting existing filesystems. :) And it is already habit for some people. Which leads to disasters, yes. Its not a perfect system, but there's only so much you can do for people before they shoot themselves in the foot. -- Nathan ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-02-28 1:09 [REVIEW] Don't make lazy counters default for mkfs Barry Naujok 2008-02-28 2:35 ` Nathan Scott @ 2008-03-02 10:26 ` Andi Kleen 2008-03-02 10:41 ` Josef 'Jeff' Sipek 1 sibling, 1 reply; 22+ messages in thread From: Andi Kleen @ 2008-03-02 10:26 UTC (permalink / raw) To: Barry Naujok; +Cc: xfs@oss.sgi.com "Barry Naujok" <bnaujok@sgi.com> writes: > > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI > support is released). CI is what? -Andi ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [REVIEW] Don't make lazy counters default for mkfs 2008-03-02 10:26 ` Andi Kleen @ 2008-03-02 10:41 ` Josef 'Jeff' Sipek 0 siblings, 0 replies; 22+ messages in thread From: Josef 'Jeff' Sipek @ 2008-03-02 10:41 UTC (permalink / raw) To: Andi Kleen; +Cc: Barry Naujok, xfs@oss.sgi.com On Sun, Mar 02, 2008 at 11:26:07AM +0100, Andi Kleen wrote: > "Barry Naujok" <bnaujok@sgi.com> writes: > > > > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI > > support is released). > > CI is what? Case-insensitivity aka. case-folding. Josef 'Jeff' Sipek. -- Bad pun of the week: The formula 1 control computer suffered from a race condition ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-03-03 4:48 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-28 1:09 [REVIEW] Don't make lazy counters default for mkfs Barry Naujok 2008-02-28 2:35 ` Nathan Scott 2008-02-29 21:21 ` Russell Cattelan 2008-02-29 23:11 ` Eric Sandeen 2008-02-29 23:19 ` Russell Cattelan 2008-02-29 23:47 ` Mark Goodwin 2008-02-29 23:56 ` Eric Sandeen 2008-03-01 0:11 ` Eric Sandeen 2008-03-02 23:59 ` Barry Naujok 2008-03-01 0:02 ` Josef 'Jeff' Sipek 2008-03-02 23:34 ` Nathan Scott 2008-03-03 0:16 ` Timothy Shimmin 2008-03-03 0:30 ` Mark Goodwin 2008-03-03 1:15 ` Josef 'Jeff' Sipek 2008-03-03 3:56 ` Eric Sandeen 2008-03-03 4:14 ` Josef 'Jeff' Sipek 2008-03-03 4:19 ` Eric Sandeen 2008-03-03 4:47 ` Niv Sardi 2008-03-03 0:18 ` Donald Douwsma 2008-03-03 0:24 ` Nathan Scott 2008-03-02 10:26 ` Andi Kleen 2008-03-02 10:41 ` Josef 'Jeff' Sipek
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox