From owner-linux-xfs@oss.sgi.com Tue May  1 06:33:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41DXZt21051
	for linux-xfs-outgoing; Tue, 1 May 2001 06:33:35 -0700
Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41DXTM21048
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 06:33:30 -0700
Received: from ne.mediaone.net (IDENT:ms@steigman.ne.mediaone.net [24.147.237.193])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f41DX9809596
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 09:33:10 -0400 (EDT)
Message-ID: <3AEEBB28.8AAFCC75@ne.mediaone.net>
Date: Tue, 01 May 2001 09:33:28 -0400
From: Michael Steigman <steigman@ne.mediaone.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: RH 7.1 installer errors
Content-Type: multipart/mixed;
 boundary="------------771590663B010813CF1E5864"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------771590663B010813CF1E5864
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Both the test3 and test2 isos bomb out after using disk druid (when I
hit the "next" button) to partition 2 40GB drives. I haven't tried
test1. I am trying to configure and install onto RAID 1. The official
RH7.1 iso got past this point w/o a problem. The motherboard is an Asus
A7V with the VIA VT8363 and VT82C686A chipsets (the drives are hanging
off the ATA100 controllers). Also, the drives were previously configured
for RAID 1 under RH7. Since it's relatively small, I've attached the
anacdump.txt file from the aborted test3 install. Any other info I can
provide? 

Michael
--------------771590663B010813CF1E5864
Content-Type: text/plain; charset=us-ascii;
 name="anacdump-test3.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="anacdump-test3.txt"

Traceback (innermost last):
  File "/usr/bin/anaconda", line 520, in ?
    intf.run(todo, test = test)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 392, in run
    self.icw.run ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 880, in run
    mainloop ()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in mainloop
    _gtk.gtk_main()
  File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in __call__
    ret = apply(self.func, a)
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 482, in nextClicked
    next = self.currentScreen.getNext ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line 130, in getNext
    rc = self.lba32Check ()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line 76, in lba32Check
    maxcyl = self.todo.fstab.getBootPartitionMaxCylFromDesired()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 241, in getBootPartitionMaxCylFromDesired
    bootpart = self.getBootDevice()
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 267, in getBootDevice
    for (mntpoint, partition, fsystem, doFormat, size) in self.mountList():
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1040, in mountList
    self.fsCache[(device, mntpoint)] = (1, fsystem)
NameError: fsystem

Local variables in innermost frame:
size: 1028097
mntpoint: /
makeup: ['Raid001', 'Raid000']
device: md0
raidType: 1
start: 63
sortMounts: <function sortMounts at 8613168>
fsType: xfs
devices: [('hdc1', 'Raid001', 7, 63, 1028097, 64, 0), ('hda1', 'Raid000', 7, 63, 1028097, 64, 0), ('hda5', 'Raid002', 7, 1028223, 10249407, 702, 0), ('hdc5', 'Raid003', 7, 1028223, 10249407, 702, 0), ('hda6', 'Raid008', 7, 11277693, 8193087, 1212, 0), ('hdc6', 'Raid009', 7, 11277693, 8193087, 1212, 0), ('hda7', 'Raid004', 7, 19470843, 6152832, 1595, 0), ('hdc7', 'Raid005', 7, 19470843, 6152832, 1595, 0), ('hda8', 'Raid006', 7, 25623738, 2056257, 1723, 0), ('hdc8', 'Raid007', 7, 25623738, 2056257, 1723, 0), ('hda9', 'Raid010', 7, 27680058, 2056257, 1851, 0), ('hdc9', 'Raid011', 7, 27680058, 2056257, 1851, 0), ('hda10', 'Raid012', 7, 29736378, 48419847, 4865, 0), ('hdc10', 'Raid013', 7, 29736378, 48419847, 4865, 0)]
fstab: []
self: <fstab.GuiFstab instance at 85ff4a8>
raid: [('/', 'md0', 'xfs', 1, 63, 1028097, ['Raid001', 'Raid000']), ('/usr', 'md1', 'xfs', 1, 63, 1028097, ['Raid003', 'Raid002']), ('/home', 'md2', 'xfs', 1, 1028223, 10249407, ['Raid005', 'Raid004']), ('/var', 'md3', 'xfs', 1, 1028223, 10249407, ['Raid007', 'Raid006']), ('/ora', 'md4', 'xfs', 1, 11277693, 8193087, ['Raid009', 'Raid008']), ('<Swap Partition>', 'md5', 'swap', 1, 11277693, 8193087, ['Raid011', 'Raid010']), ('/av', 'md6', 'xfs', 1, 19470843, 6152832, ['Raid012', 'Raid013'])]
skipExtra: 0

ToDo object:
(itodo
ToDo
p1
(dp2
S'resState'
p3
S''
sS'progressWindow'
p4
NsS'setupFilesystems'
p5
I1
sS'monitorVsync'
p6
S''
sS'videoCardStateNode'
p7
S''
sS'serial'
p8
I0
sS'ddruidReadOnly'
p9
I0
sS'bootdisk'
p10
I0
sS'videoRamState'
p11
S''
sS'monitorOriginalName'
p12
S''
sS'language'
p13
(itodo
Language
(dp14
S'langInfoByName'
p15
(dp16
S'Arabic (Yemen)'
p17
(S'ar_YE'
S'iso06'
S'LatArCyrHeb-16'
tsS'Spanish (Argentina)'
p18
(S'es_AR'
S'iso01'
S'lat0-sun16'
tsS'Italian (Italy)'
p19
(S'it_IT@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Lebanon)'
p20
(S'ar_LB'
S'iso06'
S'LatArCyrHeb-16'
tsS'Spanish (Guatemala)'
p21
(S'es_GT'
S'iso01'
S'lat0-sun16'
tsS'Arabic (Libyan Arab Jamahiriya)'
p22
(S'ar_LY'
S'iso06'
S'LatArCyrHeb-16'
tsS'Arabic (Oman)'
p23
(S'ar_OM'
S'iso06'
S'LatArCyrHeb-16'
tsS'Arabic (Iraq)'
p24
(S'ar_IQ'
S'iso06'
S'LatArCyrHeb-16'
tsS'Spanish (Chile)'
p25
(S'es_CL'
S'iso01'
S'lat0-sun16'
tsS'English (South Africa)'
p26
(S'en_ZA'
S'iso01'
S'lat0-sun16'
tsS'French (Switzerland)'
p27
(S'fr_CH'
S'iso01'
S'lat0-sun16'
tsS'Arabic (Bahrein)'
p28
(S'ar_BH'
S'iso06'
S'LatArCyrHeb-16'
tsS'Croatian'
p29
(S'hr_HR'
S'iso02'
S'lat2-sun16'
tsS'French (France)'
p30
(S'fr_FR@euro'
S'iso15'
S'lat0-sun16'
tsS'Greenlandic (Greenland)'
p31
(S'kl_GL'
S'iso01'
S'lat0-sun16'
tsS'Korean (Republic of Korea)'
p32
(S'ko_KR.euckr'
S'iso01'
S'lat0-16'
tsS'Ukrainian'
p33
(S'uk_UA'
S'koi8-u'
S'cyr-sun16'
tsS'Spanish (Mexico)'
p34
(S'es_MX'
S'iso01'
S'lat0-sun16'
tsS'Greek'
p35
(S'el_GR'
S'iso07'
S'gr.f16'
tsS'Spanish (El Salvador)'
p36
(S'es_SV'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Honduras)'
p37
(S'es_HN'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Costa Rica)'
p38
(S'es_CR'
S'iso01'
S'lat0-sun16'
tsS'Dutch (Netherlands)'
p39
(S'nl_NL@euro'
S'iso15'
S'lat0-sun16'
tsS'Serbian (Yugoslavia)'
p40
(S'sr_YU@cyrillic'
S'iso05'
S'cyr-sun16'
tsS'Russian (Ukraine)'
p41
(S'ru_UA'
S'koi8-u'
S'cyr-sun16'
tsS'Afrikaans (South Africa)'
p42
(S'af_ZA'
S'iso01'
S'lat0-sun16'
tsS'Norwegian'
p43
(S'no_NO'
S'iso01'
S'lat0-sun16'
tsS'Arabic (Morocco)'
p44
(S'ar_MA'
S'iso06'
S'LatArCyrHeb-16'
tsS'Portuguese (Portugal)'
p45
(S'pt_PT@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Algeria)'
p46
(S'ar_DZ'
S'iso06'
S'LatArCyrHeb-16'
tsS'French (Belgium)'
p47
(S'fr_BE@euro'
S'iso15'
S'lat0-sun16'
tsS'Indonesian'
p48
(S'id_ID'
S'iso01'
S'lat0-sun16'
tsS'Danish'
p49
(S'da_DK'
S'iso01'
S'lat0-sun16'
tsS'English (Denmark)'
p50
(S'en_DK'
S'iso01'
S'lat0-sun16'
tsS'Faroese (Faroe Islands)'
p51
(S'fo_FO'
S'iso01'
S'lat0-sun16'
tsS'Galician (Spain)'
p52
(S'gl_ES@euro'
S'iso15'
S'lat0-sun16'
tsS'English (New Zealand)'
p53
(S'en_NZ'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Bolivia)'
p54
(S'es_BO'
S'iso01'
S'lat0-sun16'
tsS'Cornish (Britain)'
p55
(S'kw_GB'
S'iso01'
S'lat0-sun16'
tsS'Arabic (United Arab Emirates)'
p56
(S'ar_AE'
S'iso06'
S'LatArCyrHeb-16'
tsS'German (Austria)'
p57
(S'de_AT@euro'
S'iso15'
S'lat0-sun16'
tsS'Romanian'
p58
(S'ro_RO'
S'iso02'
S'lat2-sun16'
tsS'Spanish (Paraguay)'
p59
(S'es_PY'
S'iso01'
S'lat0-sun16'
tsS'Hebrew (Israel)'
p60
(S'he_IL'
S'iso08'
S'LatArCyrHeb-16'
tsS'German (Luxemburg)'
p61
(S'de_LU@euro'
S'iso15'
S'lat0-sun16'
tsS'Spanish (USA)'
p62
(S'es_US'
S'iso01'
S'lat0-sun16'
tsS'Portuguese (Brasil)'
p63
(S'pt_BR'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Equador)'
p64
(S'es_EC'
S'iso01'
S'lat0-sun16'
tsS'Polish'
p65
(S'pl_PL'
S'iso02'
S'lat2-sun16'
tsS'Slovak'
p66
(S'sk_SK'
S'iso02'
S'lat2-sun16'
tsS'Macedonian'
p67
(S'mk_MK'
S'iso05'
S'cyr-sun16'
tsS'Spanish (Spain)'
p68
(S'es_ES@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Syrian Arab Republic)'
p69
(S'ar_SY'
S'iso06'
S'LatArCyrHeb-16'
tsS'Czech'
p70
(S'cs_CZ'
S'iso02'
S'lat2-sun16'
tsS'Irish'
p71
(S'ga_IE@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Jordan)'
p72
(S'ar_JO'
S'iso06'
S'LatArCyrHeb-16'
tsS'Italian (Switzerland)'
p73
(S'it_CH'
S'iso01'
S'lat0-sun16'
tsS'German (Belgium)'
p74
(S'de_BE@euro'
S'iso15'
S'lat0-sun16'
tsS'Albanian'
p75
(S'sq_AL'
S'iso01'
S'lat0-sun16'
tsS'Finnish'
p76
(S'fi_FI@euro'
S'iso15'
S'lat0-sun16'
tsS'Swedish (Sweden)'
p77
(S'sv_SE'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Peru)'
p78
(S'es_PE'
S'iso01'
S'lat0-sun16'
tsS'Dutch (Belgium)'
p79
(S'nl_BE@euro'
S'iso15'
S'lat0-sun16'
tsS'Spanish (Panama)'
p80
(S'es_PA'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Venezuela)'
p81
(S'es_VE'
S'iso01'
S'lat0-sun16'
tsS'English (Great Britain)'
p82
(S'en_GB'
S'iso01'
S'lat0-sun16'
tsS'Russian'
p83
(S'ru_RU.koi8r'
S'koi8-u'
S'cyr-sun16'
tsS'Norwegian, Nynorsk (Norway)'
p84
(S'nn_NO'
S'iso01'
S'lat0-sun16'
tsS'English (Zimbabwe)'
p85
(S'en_ZW'
S'iso01'
S'lat0-sun16'
tsS'English (USA)'
p86
(S'en_US'
S'iso01'
S'lat0-sun16'
tsS'Spanish (Nicaragua)'
p87
(S'es_NI'
S'iso01'
S'lat0-sun16'
tsS'Arabic (Kuwait)'
p88
(S'ar_KW'
S'iso06'
S'LatArCyrHeb-16'
tsS'Spanish (Colombia)'
p89
(S'es_CO'
S'iso01'
S'lat0-sun16'
tsS'Basque (Spain)'
p90
(S'eu_ES@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Qatar)'
p91
(S'ar_QA'
S'iso06'
S'LatArCyrHeb-16'
tsS'Arabic (Egypt)'
p92
(S'ar_EG'
S'iso06'
S'LatArCyrHeb-16'
tsS'English (Ireland)'
p93
(S'en_IE@euro'
S'iso15'
S'lat0-sun16'
tsS'Hungarian'
p94
(S'hu_HU'
S'iso02'
S'lat2-sun16'
tsS'Arabic (Tunisia)'
p95
(S'ar_TN'
S'iso06'
S'LatArCyrHeb-16'
tsS'French (Luxemburg)'
p96
(S'fr_LU@euro'
S'iso15'
S'lat0-sun16'
tsS'Japanese'
p97
(S'ja_JP.eucJP'
S'iso01'
S'lat0-16'
tsS'Swedish (Finland)'
p98
(S'sv_FI@euro'
S'iso15'
S'lat0-sun16'
tsS'Arabic (Saudi Arabia)'
p99
(S'ar_SA'
S'iso06'
S'LatArCyrHeb-16'
tsS'Spanish (Dominican Republic)'
p100
(S'es_DO'
S'iso01'
S'lat0-sun16'
tsS'French (Canada)'
p101
(S'fr_CA'
S'iso01'
S'lat0-sun16'
tsS'English (Canada)'
p102
(S'en_CA'
S'iso01'
S'lat0-sun16'
tsS'German (Germany)'
p103
(S'de_DE@euro'
S'iso15'
S'lat0-sun16'
tsS'Slovenian (Slovenia)'
p104
(S'sl_SI'
S'iso02'
S'lat2-sun16'
tsS'Spanish (Uruguay)'
p105
(S'es_UY'
S'iso01'
S'lat0-sun16'
tsS'German (Switzerland)'
p106
(S'de_CH'
S'iso01'
S'lat0-sun16'
tsS'English (Australia)'
p107
(S'en_AU'
S'iso01'
S'lat0-sun16'
tsS'Catalan (Spain)'
p108
(S'ca_ES@euro'
S'iso15'
S'lat0-sun16'
tsS'Spanish (Puerto Rico)'
p109
(S'es_PR'
S'iso01'
S'lat0-sun16'
tsS'Turkish'
p110
(S'tr_TR'
S'iso09'
S'lat5-sun16'
tsS'Estonian'
p111
(S'et_EE'
S'iso01'
S'lat0-sun16'
tsS'Arabic (Sudan)'
p112
(S'ar_SD'
S'iso06'
S'LatArCyrHeb-16'
tsS'Icelandic'
p113
(S'is_IS'
S'iso01'
S'lat0-sun16'
tsS'English (Botswana)'
p114
(S'en_BW'
S'iso01'
S'lat0-sun16'
tsS'Manx Gaelic (Britain)'
p115
(S'gv_GB'
S'iso01'
S'lat0-sun16'
tssS'allSupportedLangs'
p116
(lp117
g42
ag75
ag46
ag28
ag92
ag24
ag72
ag88
ag20
ag22
ag44
ag23
ag91
ag99
ag112
ag69
ag95
ag56
ag17
ag90
ag108
ag55
ag29
ag70
ag49
ag79
ag39
ag107
ag114
ag102
ag50
ag82
ag93
ag53
ag26
ag86
ag85
ag111
ag51
ag76
ag47
ag101
ag30
ag96
ag27
ag52
ag57
ag74
ag103
ag61
ag106
ag35
ag31
ag60
ag94
ag113
ag48
ag71
ag19
ag73
ag97
ag32
ag67
ag115
ag43
ag84
ag65
ag63
ag45
ag58
ag83
ag41
ag40
ag66
ag104
ag18
ag54
ag25
ag89
ag38
ag100
ag36
ag64
ag21
ag37
ag34
ag87
ag80
ag59
ag78
ag109
ag68
ag62
ag105
ag81
ag98
ag77
ag110
ag33
asS'info'
p118
(dp119
S'SUPPORTED'
p120
NssS'supported'
p121
(lsS'default'
p122
NsbsS'instClass'
p123
(icustom
InstallClass
(dp124
S'rootPasswordCrypted'
p125
I0
sS'raidList'
p126
(lsS'nameserver'
p127
S''
sS'x'
NsS'rootPassword'
p128
NsS'makeBootdisk'
p129
I0
sS'installType'
p130
NsS'postScript'
p131
NsS'earlySwapOn'
p132
I0
sS'networkDevice'
p133
NsS'fstab'
p134
(lsS'clearText'
p135
NsS'lilo'
p136
(S'mbr'
p137
I1
S''
tsg13
NsS'name'
p138
S''
sS'postInChroot'
p139
I0
sS'pixmap'
p140
S''
sS'partitions'
p141
(lp142
(S'/boot'
p143
(I48
I-1
I0
t(S''
I-1
I0
t(I0
S'xfs'
p144
I0
tNta(S'/'
(I700
I-1
I1
t(S''
I-1
I0
t(I0
g144
I0
tNta(S'swap'
p145
(I256
I512
I1
t(S''
I-1
I0
t(I0
NI0
tNtasS'clearType'
p146
S'wkst'
p147
sS'gateway'
p148
S''
sS'mouse'
p149
NsS'packages'
p150
NsS'timezone'
p151
NsS'zeroMbr'
p152
I0
sS'keyboard'
p153
NsS'groups'
p154
NsS'bootProto'
p155
NsS'netmask'
p156
S''
sS'langdefault'
p157
NsS'skipSteps'
p158
(dsS'auth'
p159
(I1
I1
I0
S''
I0
S''
I0
I0
S''
S''
I0
S''
S''
S''
I0
S''
S''
tsS'hostname'
p160
NsS'langsupported'
p161
NsS'showgroups'
p162
NsS'ip'
p163
S''
sS'firewall'
p164
(I-1
I1
(lp165
S''
I0
I0
I0
I0
I0
I0
tsS'defaultRunlevel'
p166
NsS'desktop'
p167
S''
sS'clearPartText'
p168
S'Automatic partitioning will erase any preexisting Linux installations on your system.'
p169
sS'clearParts'
p170
I2
sbsS'bdstate'
p171
S''
sS'extraModules'
p172
(lp173
sS'rootpassword'
p174
NsS'fdDevice'
p175
S'fd0'
p176
sS'installSystem'
p177
I1
sS'comps'
p178
NsS'verifiedState'
p179
Nsg159
(itodo
Authentication
(dp180
S'useNIS'
p181
I0
sS'nisServer'
p182
S''
sS'useLdap'
p183
I0
sS'krb5Kdc'
p184
S''
sS'ldapTLS'
p185
S''
sS'useHesiod'
p186
I0
sS'ldapServer'
p187
S''
sS'nisDomain'
p188
S''
sS'krb5Realm'
p189
S''
sS'useLdapauth'
p190
I0
sS'hesiodRhs'
p191
S''
sS'useShadow'
p192
I1
sS'nisuseBroadcast'
p193
I0
sS'useKrb5'
p194
I0
sS'useMD5'
p195
I1
sS'ldapBasedn'
p196
S''
sS'krb5Admin'
p197
S''
sS'hesiodLhs'
p198
S''
sS'hesiodDlhs'
p199
S''
sbsS'users'
p200
NsS'hdList'
p201
NsS'dhcpState'
p202
S''
sS'method'
p203
(iimage
CdromInstallMethod
p204
(dp205
g4

<failed>

--------------771590663B010813CF1E5864--


From owner-linux-xfs@oss.sgi.com Tue May  1 08:05:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41F5vV25419
	for linux-xfs-outgoing; Tue, 1 May 2001 08:05:57 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41F5tM25416;
	Tue, 1 May 2001 08:05:56 -0700
Received: (from cattelan@localhost)
	by lupo.thebarn.com (8.11.3/8.11.0) id f41F5kU04281;
	Tue, 1 May 2001 10:05:46 -0500 (CDT)
	(envelope-from cattelan)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15086.53450.320884.346281@lupo.thebarn.com>
Date: Tue, 1 May 2001 10:05:46 -0500 (CDT)
BCC:
BCC:
BCC:
BCC:
From: xfs-masters@oss.sgi.com
Subject: Announce: XFS Release 1.0 for Linux
X-Mailer: VM 6.72 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tuesday May 1 2001:
SGI is pleased to announce the 1.0 release of XFS, high-performance
journaled file system for Linux. 

http://oss.sgi.com/projects/xfs/

XFS is widely recognized as the industry-leading high-performance file system,
providing rapid recovery from system crashes and the ability to support
extremely large disk farms. XFS is the first journaled file system for Linux
available today that has a proven track record in production environments
since December 1994. 

XFS Linux 1.0 is released for the Linux 2.4 kernel and offers the following
advanced features:

        * Fast recovery after a system crash or power failure, NO fsck!
        * Journaling for guaranteed file system integrity 
        * Direct I/O 
        * Space preallocation 
        * Transactionally recorded quotas 
        * Access control lists and Extended attributes 
        * Infrastructure for XDSM support (DMAPI) 
        * Excellent overall performance 
        * Excellent scalability (64 bit file system) 
        * On-disk compatibility with IRIX XFS file systems

A complete toolset including: 

        * dump/restore support including all XFS file system features such as ACLs and quotas 
        * Repair utility, file system editor, and growing the file system 
        * ACL editing utility 
        * Extended attribute editing utility

Excellent integration with other Linux subsystems: 
        * NFS version 2 and 3 server support 
        * Root file system and lilo support 
        * Software raid integration with md and lvm packages 
        * Mount by label and mount by uuid 


The SGI XFS team is also providing a modified Red Hat Linux anaconda based installer.
The installer handles all the details of setting up a Red Hat Linux 7.1 system running
entirely on XFS, or a combination of XFS and ext2 file systems.


Sincerely 
The SGI XFS Team.











From owner-linux-xfs@oss.sgi.com Tue May  1 08:10:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41FAe925583
	for linux-xfs-outgoing; Tue, 1 May 2001 08:10:40 -0700
Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41FAdM25580
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 08:10:39 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id 71746BC19; Tue,  1 May 2001 11:10:18 -0400 (EDT)
To: linux-xfs@oss.sgi.com
Subject: Updated devfsd?
Message-Id: <20010501151018.71746BC19@linux.compucomis.net>
Date: Tue,  1 May 2001 11:10:18 -0400 (EDT)
From: mburger@compucomis.net (Mike Burger)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I see that, since I installed RH7.1+XFS, that there's a new devfsd
package available from RedHat.  Is there any reason, known by the 
XFS dev folks, that should keep me from downloading and installing
this update package?

From owner-linux-xfs@oss.sgi.com Tue May  1 08:20:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41FKI626461
	for linux-xfs-outgoing; Tue, 1 May 2001 08:20:18 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41FKGM26447
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 08:20:16 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f41FJwwH016607;
	Tue, 1 May 2001 10:19:59 -0500 (CDT)
Message-ID: <3AEED419.35249164@thebarn.com>
Date: Tue, 01 May 2001 10:19:53 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Burger <mburger@compucomis.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Updated devfsd?
References: <20010501151018.71746BC19@linux.compucomis.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mike Burger wrote:

> I see that, since I installed RH7.1+XFS, that there's a new devfsd
> package available from RedHat.  Is there any reason, known by the
> XFS dev folks, that should keep me from downloading and installing
> this update package?

Haven't looked at it, but you might want to save the old config
file as the RH  version doesn't have the /dev/mouse and /dev/cdrom
"stuff".

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May  1 09:22:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41GMwQ30955
	for linux-xfs-outgoing; Tue, 1 May 2001 09:22:58 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41GMtM30947
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 09:22:55 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f41GMpB06969;
	Tue, 1 May 2001 11:22:51 -0500 (CDT)
Message-ID: <3AEEE251.306EF354@sgi.com>
Date: Tue, 01 May 2001 11:20:33 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_0.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Steigman <steigman@ne.mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Michael - 

Sorry about that, anaconda does a lot of mix-n-match on variable names -
"fsystem" should have been "fsType" in this case.  :)

Can you grab this floppy image:

http://lager.dyndns.org/raid-update.img

and write it to a floppy, then boot the original CD and type either
"linux update" or "text update" at the prompt, and then insert your
floppy when it asks?  This should solve it - let me know how it goes!

BTW, since XFS 1.0 is out today, you might want to grab those bits
instead, although this problem is still in the 1.0 installer,
unfortunately.  (the update disk should work with any recent iso)

Thanks,

-Eric

> Both the test3 and test2 isos bomb out after using disk druid (when I
> hit the "next" button) to partition 2 40GB drives. I haven't tried
> test1. I am trying to configure and install onto RAID 1. The official
> RH7.1 iso got past this point w/o a problem. The motherboard is an Asus
> A7V with the VIA VT8363 and VT82C686A chipsets (the drives are hanging
> off the ATA100 controllers). Also, the drives were previously configured
> for RAID 1 under RH7. Since it's relatively small, I've attached the
> anacdump.txt file from the aborted test3 install. Any other info I can
> provide?

From owner-linux-xfs@oss.sgi.com Tue May  1 09:52:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41GqAq01337
	for linux-xfs-outgoing; Tue, 1 May 2001 09:52:10 -0700
Received: from smtprelay1.abs.adelphia.net (smtprelay.abs.adelphia.net [64.8.20.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41Gq7M01331
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 09:52:07 -0700
Received: from ga.prestige.net ([63.94.220.73]) by
          smtprelay1.abs.adelphia.net (Netscape Messaging Server 4.15)
          with ESMTP id GCO1HA01.34X for <linux-xfs@oss.sgi.com>; Tue, 1
          May 2001 12:51:11 -0400 
Message-ID: <3AEEE97E.3060303@ga.prestige.net>
Date: Tue, 01 May 2001 12:51:10 -0400
From: Fred Reimer <fwr@ga.prestige.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; 0.8.1) Gecko/20010421
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Diffs for 2.4.4???
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

Where are the diffs for Linux-2.4.4?  I didn't see any patches available 
on the web site, only access to your cvs system.  What version of the 
kernel are you basing your cvs off of anyway?  Under cvs I saw comments 
about 2.4.2.  Can anyone make a proper diff, as I believe this will 
increase the number of people using the software dramatically?

Thanks,

Fred Reimer


From owner-linux-xfs@oss.sgi.com Tue May  1 13:40:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41KeYJ23932
	for linux-xfs-outgoing; Tue, 1 May 2001 13:40:34 -0700
Received: from hotmail.com (f167.law9.hotmail.com [64.4.9.167])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KeVM23920
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:40:31 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 1 May 2001 11:22:06 -0700
Received: from 62.59.16.251 by lw9fd.law9.hotmail.msn.com with HTTP;	Tue, 01 May 2001 18:22:05 GMT
X-Originating-IP: [62.59.16.251]
From: "Pietje Puk" <lbalbalba@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: Why release XFS as patches against a kernel ?
Date: Tue, 01 May 2001 18:22:05 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F16743TuylJc0xvlUQ90000e2bc@hotmail.com>
X-OriginalArrivalTime: 01 May 2001 18:22:06.0186 (UTC) FILETIME=[A076FCA0:01C0D26B]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Dear SGI,

As a linux user, I really appreciate your efforts to port your high quality 
filesystem XFS to linux as open source. However, I cannot understand your 
release scheme. You must understand that people will just want to download a 
tarball, `patch` the patches, and `./configure;make all;make install`. I 
sincerely feel that lots more people would give this fine fs a try if you 
would find the time to release XFS as a tarball, which people could just 
install by applying a patch to the kernel source, and compile by issuing a 
'make all' on the command prompt.
Just my 2$...

Anyways, keep up the good work.



Sincerely,

J.Smith

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


From owner-linux-xfs@oss.sgi.com Tue May  1 13:46:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41Gw3801856
	for linux-xfs-outgoing; Tue, 1 May 2001 09:58:03 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41GvwM01844
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 09:57:58 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f41GvV620879;
	Tue, 1 May 2001 11:57:36 -0500 (CDT)
Message-ID: <3AEEEB36.461D951F@sgi.com>
Date: Tue, 01 May 2001 11:58:30 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Fred Reimer <fwr@ga.prestige.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Diffs for 2.4.4???
References: <3AEEE97E.3060303@ga.prestige.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Fred Reimer wrote:
> 
> Hello,
> 
> Where are the diffs for Linux-2.4.4?  I didn't see any patches available
> on the web site, only access to your cvs system.  What version of the
> kernel are you basing your cvs off of anyway?  Under cvs I saw comments
> about 2.4.2.  Can anyone make a proper diff, as I believe this will
> increase the number of people using the software dramatically?

cvs for r1.0 is currently at 2.4.2, the devel cvs is 2.4.3.  As soon as
we work some kinks out of 2.4.4, the devel cvs tree will get bumped.

for r1.0, patches for both 2.4.2 and 2.4.3 are available in
ftp://linux-xfs.sgi.com/projects/xfs/download/Release-1.0/patches/ - see
the README file for how to apply them.

The vast majority of our testing for 1.0 was done on 2.4.2.  2.4.4 came
out about 3 days ago, so be patient until we can have similar confidence
in that version.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 13:47:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41Klu024612
	for linux-xfs-outgoing; Tue, 1 May 2001 13:47:56 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KlkF24596
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:47:46 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f41Kldw05816;
	Tue, 1 May 2001 15:47:39 -0500 (CDT)
Message-ID: <3AEF213D.F3BB48FB@sgi.com>
Date: Tue, 01 May 2001 15:49:01 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: GCS <gcs@agentsinside.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Congrats!; Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com> <20010501224011.A1604@sisinteli07.udg.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

GCS wrote:

> Russel: Sure, I would be interested about the 2.4.4 patch.

untested, unsupported, devel tree 2.4.4 patch:

ftp://linux-xfs.sgi.com/projects/xfs/download/testing/linux-2.4.4-xfs-TEST.patch
 

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 13:47:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41KlwL24634
	for linux-xfs-outgoing; Tue, 1 May 2001 13:47:58 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f41KlvF24627
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:47:57 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <JCFDCX2N>; Tue, 1 May 2001 16:47:51 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C8867@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "'Pietje Puk'" <lbalbalba@hotmail.com>, linux-xfs@oss.sgi.com
Subject: RE: Why release XFS as patches against a kernel ?
Date: Tue, 1 May 2001 16:47:41 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't understand the question.  They ship kernel patches and they ship pre-patched RedHat kernel-source rpms.  What more do you want?

-----Original Message-----
From: Pietje Puk [mailto:lbalbalba@hotmail.com]
Sent: Tuesday, May 01, 2001 14:22
To: linux-xfs@oss.sgi.com
Subject: Why release XFS as patches against a kernel ?



Dear SGI,

As a linux user, I really appreciate your efforts to port your high quality 
filesystem XFS to linux as open source. However, I cannot understand your 
release scheme. You must understand that people will just want to download a 
tarball, `patch` the patches, and `./configure;make all;make install`. I 
sincerely feel that lots more people would give this fine fs a try if you 
would find the time to release XFS as a tarball, which people could just 
install by applying a patch to the kernel source, and compile by issuing a 
'make all' on the command prompt.
Just my 2$...

Anyways, keep up the good work.



Sincerely,

J.Smith

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

From owner-linux-xfs@oss.sgi.com Tue May  1 13:48:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41KmVD24696
	for linux-xfs-outgoing; Tue, 1 May 2001 13:48:31 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KmUF24689
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:48:30 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f41K20x07859;
	Tue, 1 May 2001 15:02:00 -0500 (CDT)
Message-ID: <3AEF1689.5393EFD1@sgi.com>
Date: Tue, 01 May 2001 15:03:21 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Steigman <steigman@ne.mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com> <3AEF0B34.C0F12FCD@ne.mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Michael Steigman wrote:
 
> The installation went fine after loading the update disk. However, upon
> reboot, raidautorun reports "failed to open /dev/md0" which obviously
> leads to a kernel panic (my / is on md0). Suggestions?

You can also pass "devfs=nomount" to get around devfs for now, but
surely there's a way to make raid work with devfs.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 13:52:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41KqTh25232
	for linux-xfs-outgoing; Tue, 1 May 2001 13:52:29 -0700
Received: from dragon.vcu.edu (dragon.vcu.edu [128.172.65.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KqHF25208
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:52:21 -0700
Received: from comet.vcu.edu (comet.vcu.edu [128.172.1.33])
	by dragon.vcu.edu (8.9.3/8.9.3) with ESMTP id QAA4437702;
	Tue, 1 May 2001 16:52:20 -0400 (EDT)
Date: Tue, 1 May 2001 16:52:15 -0400 (EDT)
From: K Mitchell Russell <kmrussel@hsc.vcu.edu>
X-Sender: kmrussel@comet.vcu.edu
To: Pietje Puk <lbalbalba@hotmail.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Why release XFS as patches against a kernel ?
In-Reply-To: <F16743TuylJc0xvlUQ90000e2bc@hotmail.com>
Message-ID: <Pine.A41.4.10.10105011649410.12392-100000@comet.vcu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 1 May 2001, Pietje Puk wrote:

> 
> Dear SGI,
> 
> As a linux user, I really appreciate your efforts to port your high quality 
> filesystem XFS to linux as open source. However, I cannot understand your 
> release scheme. You must understand that people will just want to download a 
> tarball, `patch` the patches, and `./configure;make all;make install`. I 

Aren't these the patches here? :
ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/

RPMs are available, as well as the bleeding edge source tree via CVS
too.

Enjoy,
Mitchell


From owner-linux-xfs@oss.sgi.com Tue May  1 13:52:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41Kqq225291
	for linux-xfs-outgoing; Tue, 1 May 2001 13:52:52 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KqkF25280
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:52:46 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f41JK6x26460;
	Tue, 1 May 2001 14:20:06 -0500 (CDT)
Message-ID: <3AEF0CB9.A4D0F59C@sgi.com>
Date: Tue, 01 May 2001 14:21:29 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Steigman <steigman@ne.mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com> <3AEF0B34.C0F12FCD@ne.mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Michael Steigman wrote:
> 
> Eric,
> 
> Slight correction to your instructions - type "linux updates" ;-)

Ack, I knew that, typing too fast.  Sorry...
 
> The installation went fine after loading the update disk. However, upon
> reboot, raidautorun reports "failed to open /dev/md0" which obviously
> leads to a kernel panic (my / is on md0). Suggestions?

Hm... hopefully Martin or Russell can speak to this - I don't have any
raid machines here, and have not ever tested it...

Could this be a devfs thing?  Has /dev/md0 moved to /dev/md/0 perhaps? 
If devfsd hasn't started, the compatibility links won't be there if /
isn't even mounted.

-Eric

From owner-linux-xfs@oss.sgi.com Tue May  1 13:57:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41KvVk25551
	for linux-xfs-outgoing; Tue, 1 May 2001 13:57:31 -0700
Received: from justice.loyola.edu (root@justice.loyola.edu [144.126.178.227])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41KvPF25546
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 13:57:25 -0700
Received: (from mstone@localhost)
	by justice.loyola.edu (8.9.3/8.9.3/Debian 8.9.3-21) id QAA24967
	for linux-xfs@oss.sgi.com; Tue, 1 May 2001 16:57:24 -0400
Date: Tue, 1 May 2001 16:57:24 -0400
From: Michael Stone <mstone@cs.loyola.edu>
To: linux-xfs@oss.sgi.com
Subject: Re: Why release XFS as patches against a kernel ?
Message-ID: <20010501165724.F15731@justice.loyola.edu>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <23D04BDBA646D411BDDD00D0B774B539028C8867@SA-BWMAIL1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <23D04BDBA646D411BDDD00D0B774B539028C8867@SA-BWMAIL1>; from chip.christian@storageapps.com on Tue, May 01, 2001 at 04:47:41PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 01, 2001 at 04:47:41PM -0400, Christian, Chip wrote:
> I don't understand the question.  They ship kernel patches and they
> ship pre-patched RedHat kernel-source rpms.  What more do you want?

A reference to that on http://linux-xfs.sgi.com/projects/xfs/? 

>From that page: 
>Source Code:
>A complete linux 2.4.x-based tree including the XFS filesystem is
>available for CVS checkout. 
>Two distinct trees are available: 
>linux-2.4-xfs: fast moving development tree 
>linux-2.4-xfs-r1.0: XFS Linux Release 1.0 
>Please refer to the  CVS instructions  for  details. 
>CVSup  a much faster "File Distribution System" than cvs 
>CVSWEB  a web based source tree browser 

No reference to any patches there; it's often been non-intuitive to find
these, unless you already know that they're there. The "point & guess"
method's also been fairly hard today, because the ftp sites have been
overloaded (understandable, I think.) If you look at
ftp://linux-xfs.sgi.com/projects/xfs/download/ you'll see a patches/
directory, but that's not right. You will eventually find the right
stuff in
ftp://linux-xfs.sgi.com/projects/xfs/download/Release-1.0/patches/ but a
nice link from the front page would definately be more user-friendly.

-- 
Mike Stone

From owner-linux-xfs@oss.sgi.com Tue May  1 14:01:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41L1oQ25785
	for linux-xfs-outgoing; Tue, 1 May 2001 14:01:50 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41L1kF25780
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:01:46 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14uhGu-0000wP-00; Tue, 01 May 2001 23:01:25 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f41L0mP17435;
	Tue, 1 May 2001 17:00:48 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Eric Sandeen <sandeen@sgi.com>
Cc: Michael Steigman <steigman@ne.mediaone.net>, linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com>
	<3AEF0B34.C0F12FCD@ne.mediaone.net> <3AEF0CB9.A4D0F59C@sgi.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 01 May 2001 17:00:48 -0400
In-Reply-To: <3AEF0CB9.A4D0F59C@sgi.com>
Message-ID: <yq18zkgn5rz.fsf@jcb.mkp.net>
Lines: 19
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Eric" == Eric Sandeen <sandeen@sgi.com> writes:

>> The installation went fine after loading the update disk. However,
>> upon reboot, raidautorun reports "failed to open /dev/md0" which
>> obviously leads to a kernel panic (my / is on md0). Suggestions?

Eric> Hm... hopefully Martin or Russell can speak to this - I don't
Eric> have any raid machines here, and have not ever tested it...

Eric> Could this be a devfs thing?  Has /dev/md0 moved to /dev/md/0
Eric> perhaps?  If devfsd hasn't started, the compatibility links
Eric> won't be there if / isn't even mounted.

That's probably the case, yes.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May  1 14:02:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41L2FD25812
	for linux-xfs-outgoing; Tue, 1 May 2001 14:02:15 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.68.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f41L2FF25809
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:02:15 -0700
Received: (qmail 7497 invoked by uid 3995); 1 May 2001 20:02:14 -0000
From: "Dave Sill" <de5-dated-989179334.a80b8a@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Re: Announce: XFS Release 1.0 for Linux
References: <15086.53450.320884.346281@lupo.thebarn.com>
Date: 01 May 2001 16:02:14 -0400
In-Reply-To: xfs-masters@oss.sgi.com's message of "Tue, 1 May 2001 10:05:46 -0500 (CDT)"
Message-ID: <wx07l00x2gp.fsf@localhost.localdomain>
Lines: 13
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

xfs-masters@oss.sgi.com writes:

> Tuesday May 1 2001:
> SGI is pleased to announce the 1.0 release of XFS, high-performance
> journaled file system for Linux. 

Congratulations, and thanks to the Linux XFS Team!

I reinstalled my workstation this morning with the 0.10.4 installer,
and it went very smoothly compared to installing via building a
kernel.

-Dave

From owner-linux-xfs@oss.sgi.com Tue May  1 14:11:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LB0Z26393
	for linux-xfs-outgoing; Tue, 1 May 2001 14:11:00 -0700
Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LArF26385
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:10:53 -0700
Received: from ne.mediaone.net (IDENT:ms@steigman.ne.mediaone.net [24.147.237.193])
	by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f41JEg823401;
	Tue, 1 May 2001 15:14:42 -0400 (EDT)
Message-ID: <3AEF0B34.C0F12FCD@ne.mediaone.net>
Date: Tue, 01 May 2001 15:15:00 -0400
From: Michael Steigman <steigman@ne.mediaone.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric,

Slight correction to your instructions - type "linux updates" ;-)

The installation went fine after loading the update disk. However, upon
reboot, raidautorun reports "failed to open /dev/md0" which obviously
leads to a kernel panic (my / is on md0). Suggestions?

Michael

Eric Sandeen wrote:
> 
> Hi Michael -
> 
> Sorry about that, anaconda does a lot of mix-n-match on variable names -
> "fsystem" should have been "fsType" in this case.  :)
> 
> Can you grab this floppy image:
> 
> http://lager.dyndns.org/raid-update.img
> 
> and write it to a floppy, then boot the original CD and type either
> "linux update" or "text update" at the prompt, and then insert your
> floppy when it asks?  This should solve it - let me know how it goes!
> 
> BTW, since XFS 1.0 is out today, you might want to grab those bits
> instead, although this problem is still in the 1.0 installer,
> unfortunately.  (the update disk should work with any recent iso)
> 
> Thanks,
> 
> -Eric
> 
> > Both the test3 and test2 isos bomb out after using disk druid (when I
> > hit the "next" button) to partition 2 40GB drives. I haven't tried
> > test1. I am trying to configure and install onto RAID 1. The official
> > RH7.1 iso got past this point w/o a problem. The motherboard is an Asus
> > A7V with the VIA VT8363 and VT82C686A chipsets (the drives are hanging
> > off the ATA100 controllers). Also, the drives were previously configured
> > for RAID 1 under RH7. Since it's relatively small, I've attached the
> > anacdump.txt file from the aborted test3 install. Any other info I can
> > provide?

From owner-linux-xfs@oss.sgi.com Tue May  1 14:11:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LB9j26429
	for linux-xfs-outgoing; Tue, 1 May 2001 14:11:09 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LB8F26424
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:11:08 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f41LB5w14072;
	Tue, 1 May 2001 16:11:05 -0500 (CDT)
Message-ID: <3AEF26BC.C6DBCDE1@sgi.com>
Date: Tue, 01 May 2001 16:12:28 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Stone <mstone@cs.loyola.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: Why release XFS as patches against a kernel ?
References: <23D04BDBA646D411BDDD00D0B774B539028C8867@SA-BWMAIL1> <20010501165724.F15731@justice.loyola.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Michael Stone wrote:
 
> A reference to that on http://linux-xfs.sgi.com/projects/xfs/?

> No reference to any patches there; it's often been non-intuitive to find
> these, unless you already know that they're there. 

True enough.. there is an "FTP sites" link on the left, but we'll add
one to the front page as well.

There are also detailed links and instructions via
http://linux-xfs.sgi.com/projects/xfs/1.0_release.html, which is linked
off the front page.

Thanks,

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 14:14:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LEdB27147
	for linux-xfs-outgoing; Tue, 1 May 2001 14:14:39 -0700
Received: from mail.starkmedia.com (mail.starkmedia.com [63.237.54.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LEcF27137
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:14:38 -0700
Received: from starkmedia.com (gate.starkmedia.com [63.237.54.3])
	by mail.starkmedia.com (8.10.1/8.10.1) with ESMTP id f41LEfb26856
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:14:41 -0500
Message-ID: <3AEF26ED.F3E911B0@starkmedia.com>
Date: Tue, 01 May 2001 16:13:17 -0500
From: "Daniel J. Cody" <djc@starkmedia.com>
X-Mailer: Mozilla 4.77 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Announce: XFS Release 1.0 for Linux
References: <15086.53450.320884.346281@lupo.thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey guys - 

As a long time user(since beta 3) of XFS, and a long time lurker on the
linux-xfs list, I'd just like to say excellent job, kudos, and cheers..

Its been fun perusing the emails, not always understanding, but always
learning a thing or two in the process..

Again, nice job and thanks for all your hard work :)

--
.djc.
http://evolt.org
djc@members.evolt.org

xfs-masters@oss.sgi.com wrote:
> 
> Tuesday May 1 2001:
> SGI is pleased to announce the 1.0 release of XFS, high-performance
> journaled file system for Linux.
> 
> http://oss.sgi.com/projects/xfs/
> 
> XFS is widely recognized as the industry-leading high-performance file system,
> providing rapid recovery from system crashes and the ability to support
> extremely large disk farms. XFS is the first journaled file system for Linux
> available today that has a proven track record in production environments
> since December 1994.

From owner-linux-xfs@oss.sgi.com Tue May  1 14:21:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LLaj27848
	for linux-xfs-outgoing; Tue, 1 May 2001 14:21:36 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LLXF27840
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:21:33 -0700
Received: from crom.corp.sgi.com ([130.62.63.32]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA03333
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 10:18:53 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA65286 for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 10:22:26 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id A852ACED79
	for <linux-xfs@oss.sgi.com>; Tue,  1 May 2001 10:17:32 -0700 (PDT)
Subject: Re: Linux 2.4.4
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <4.3.2.7.2.20010428140403.04271ec0@pop.xs4all.nl>
References: <4.3.2.7.2.20010428140403.04271ec0@pop.xs4all.nl>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 01 May 2001 10:17:32 -0700
Message-Id: <988737452.4290.5.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 28 Apr 2001 14:06:10 +0200, Seth Mos wrote:
> Hi,
> 
> Kernel 2.4.4 was released this weekend. Any patches forthcoming or 
> experiences about it's "stability" ?
> Is this going to fix some more weirdness that some of the other 2.4 kernels 
> had?

I believe some people reported RAID issues.

-- 
Florin Andrei

"Bloat is not about being big. Bloat is about being slow and stupid and not
realizing that it's because of design mistakes." - Linus Torvalds


From owner-linux-xfs@oss.sgi.com Tue May  1 14:27:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LRks28241
	for linux-xfs-outgoing; Tue, 1 May 2001 14:27:46 -0700
Received: from wisdom.myplace.net (cc19815-a.zwoll1.ov.nl.home.com [212.204.138.247])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LRhF28236
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:27:43 -0700
Received: from ws1 (ws1.myplace.net [192.168.1.15])
	by wisdom.myplace.net (Postfix) with SMTP id 88A71147
	for <linux-xfs@oss.sgi.com>; Tue,  1 May 2001 23:27:39 +0200 (CEST)
Message-ID: <013c01c0d285$8cc41d40$0f01a8c0@ws1>
From: "Bas" <list@showme.wox.org>
To: <linux-xfs@oss.sgi.com>
References: <15086.53450.320884.346281@lupo.thebarn.com> <wx07l00x2gp.fsf@localhost.localdomain>
Subject: Re: Announce: XFS Release 1.0 for Linux
Date: Tue, 1 May 2001 23:27:39 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Congratulations, and thanks to the Linux XFS Team! Thanks for the support
and delivering a fine product.

But what's next ? Is it going to be in a standard kernel and in which ?

Thanks (again),
Bas.


----- Original Message -----
From: "Dave Sill" <de5-dated-989179334.a80b8a@sws5.ctd.ornl.gov>
To: <linux-xfs@oss.sgi.com>
Sent: Tuesday, May 01, 2001 10:02 PM
Subject: Re: Announce: XFS Release 1.0 for Linux


> xfs-masters@oss.sgi.com writes:
>
> > Tuesday May 1 2001:
> > SGI is pleased to announce the 1.0 release of XFS, high-performance
> > journaled file system for Linux.
>
> Congratulations, and thanks to the Linux XFS Team!
>
> I reinstalled my workstation this morning with the 0.10.4 installer,
> and it went very smoothly compared to installing via building a
> kernel.
>
> -Dave


From owner-linux-xfs@oss.sgi.com Tue May  1 14:28:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LSFW28276
	for linux-xfs-outgoing; Tue, 1 May 2001 14:28:15 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LSEF28270
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:28:14 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA09780
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:28:12 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA10586
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:28:11 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for linux-xfs@oss.sgi.com; Tue, 1 May 2001 14:28:06 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA36854
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:28:05 -0700
Message-Id: <3AEF2A65.AFD3FDFA@pipcws.ca.boeing.com>
Date: Tue, 01 May 2001 14:28:05 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Mandrake 8.0 +XFS update
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All;
Just a quick update. I now have XFS + LVM running on my Mandrake 8.0
installation using the kernel as supplied by SGI. 
While I have XFS + LVM running, it came at the cost of losing my Frame
Buffering. Actually, a worth-while trade.

I will be applying a custom kernel tonight to try to fix that problem as well.

Hats off the XFS team. And congratulations on getting release 1.0 out the door!

	Ric

From owner-linux-xfs@oss.sgi.com Tue May  1 14:32:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LWpo28914
	for linux-xfs-outgoing; Tue, 1 May 2001 14:32:51 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LWnF28910
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:32:49 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [144.253.131.5]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA08598
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 10:56:47 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA259327
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 19:54:04 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA01282; Tue, 1 May 2001 12:52:48 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f41HplB04290;
	Tue, 1 May 2001 13:51:47 -0400
Message-ID: <3AEEF7B3.4A2F5B14@thebarn.com>
Date: Tue, 01 May 2001 13:51:47 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Fred Reimer <fwr@ga.prestige.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Diffs for 2.4.4???
References: <3AEEE97E.3060303@ga.prestige.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Fred Reimer wrote:

> Hello,
>
> Where are the diffs for Linux-2.4.4?  I didn't see any patches available
> on the web site, only access to your cvs system.  What version of the
> kernel are you basing your cvs off of anyway?  Under cvs I saw comments
> about 2.4.2.  Can anyone make a proper diff, as I believe this will
> increase the number of people using the software dramatically?

I'm still working on cleanin up the merge; but this does run.

ftp://linux-xfs.sgi.com/projects/xfs/download/testing/linux-2.4.4-xfs-TEST.patch

>
>
> Thanks,
>
> Fred Reimer

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May  1 14:39:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41Ldne29633
	for linux-xfs-outgoing; Tue, 1 May 2001 14:39:49 -0700
Received: from bbking.techtrader.com ([63.105.9.67])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41LdjF29626
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:39:45 -0700
Received: by bbking.techtrader.com with Internet Mail Service (5.5.2650.21)
	id <2ZVNLJAN>; Tue, 1 May 2001 17:40:41 -0400
Message-ID: <D3DC1A12F511D511A83000B0D0AA447F0E9096@bbking.techtrader.com>
From: "Castellanos, Leon" <lcastellanos@techtrader.com>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: XFS question
Date: Tue, 1 May 2001 17:40:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

First I wanted to thank you for the effort you put in to contribute this
great part of your technology to the open source community and specially to
Linux.

I just converted all my file systems to xfs and have a few questions to
which I did not find answers to in the website. First, I would like to know
why it is that xfs doesn't like to be mounted "ro" read-only. I didn't find
anyone addressing this issue and had to figure out on my own to change the
/etc/lilo.conf entry "read-only" to "read-write".
Second, how can I get by the problem of xfs doing its job too well :) and
leaving pid files and caches? I pulled the power cord out of my box to test
the xfs journaling and several things didn't work out well when the system
came back up: sysklogd didn't start up because it found its old pid file and
thought it was still running and also my enlightenment window-manager
configuration was totally purged. I had to rearrange my entire start-up
setup (location of apps that run on startup, etc). Are there any flags to
pass to mount in order to fix these problems?

Thank you again for the great work, I hope to see more OSS from sgi.
Maybe an open-source version of Maya Unlimited :) or free... don't have 15k
to dish out unfortunately :(

Leon F. Castellanos

From owner-linux-xfs@oss.sgi.com Tue May  1 14:57:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41LvBV30650
	for linux-xfs-outgoing; Tue, 1 May 2001 14:57:11 -0700
Received: from moe.rice.edu (moe.rice.edu [128.42.5.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41Lv7F30645
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 14:57:08 -0700
Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116])
	by moe.rice.edu (8.9.0/8.9.0) with ESMTP id QAA11348
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:57:07 -0500 (CDT)
Received: from photino.sid.rice.edu (rjain@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f41Lv6HP021098
        for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:57:06 -0500
Received: (from rjain@localhost)
        by photino.sid.rice.edu (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f41Lv6l7021096
        for linux-xfs@oss.sgi.com; Tue, 1 May 2001 16:57:06 -0500
Date: Tue, 1 May 2001 16:57:06 -0500
From: Rahul Jain <rahul@rice.edu>
To: linux-xfs@oss.sgi.com
Subject: Re: XFS question
Message-ID: <20010501165706.B20890@photino.sid.rice.edu>
Reply-To: Rahul Jain <rahul@rice.edu>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <D3DC1A12F511D511A83000B0D0AA447F0E9096@bbking.techtrader.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <D3DC1A12F511D511A83000B0D0AA447F0E9096@bbking.techtrader.com>; from lcastellanos@techtrader.com on Tue, May 01, 2001 at 05:40:40PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 01, 2001 at 05:40:40PM -0400, Castellanos, Leon wrote:
> I just converted all my file systems to xfs and have a few questions to
> which I did not find answers to in the website. First, I would like to know
> why it is that xfs doesn't like to be mounted "ro" read-only. I didn't find
> anyone addressing this issue and had to figure out on my own to change the
> /etc/lilo.conf entry "read-only" to "read-write".
> Second, how can I get by the problem of xfs doing its job too well :) and
> leaving pid files and caches? I pulled the power cord out of my box to test
> the xfs journaling and several things didn't work out well when the system
> came back up: sysklogd didn't start up because it found its old pid file and
> thought it was still running and also my enlightenment window-manager
> configuration was totally purged. I had to rearrange my entire start-up
> setup (location of apps that run on startup, etc). Are there any flags to
> pass to mount in order to fix these problems?

I don't think this issue has anything to do with mount. It has to do with your
init scripts not cleaning up /var/run on boot, as they should. e.g. on Debian:

----- excerpt from /etc/init.d/bootmisc.sh -----

#
# Clean up /var/run and create /var/run/utmp so that we can login.
#
[ "$VERBOSE" != no ] && echo -n "/var/run"
( cd /var/run && \
        find . ! -type d ! -name utmp ! -name innd.pid ! -name random-seed \
        ! -newer /etc/mtab -exec rm -f -- {} \; )
: > /var/run/utmp
if grep -q ^utmp: /etc/group
then
        chmod 664 /var/run/utmp
        chgrp utmp /var/run/utmp
fi
[ "$VERBOSE" != no ] && echo "."

-------------------------------------------------


-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

From owner-linux-xfs@oss.sgi.com Tue May  1 16:02:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41N2O901409
	for linux-xfs-outgoing; Tue, 1 May 2001 16:02:24 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41N2LF01404
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:02:21 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA07030
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:00:53 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA71247; Tue, 1 May 2001 18:00:00 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f41Mx0B06393;
	Tue, 1 May 2001 18:59:00 -0400
Message-ID: <3AEF3FB4.73AC80FB@thebarn.com>
Date: Tue, 01 May 2001 18:59:00 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Rahul Jain <rahul@rice.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS question
References: <D3DC1A12F511D511A83000B0D0AA447F0E9096@bbking.techtrader.com> <20010501165706.B20890@photino.sid.rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Rahul Jain wrote:

> On Tue, May 01, 2001 at 05:40:40PM -0400, Castellanos, Leon wrote:
> > I just converted all my file systems to xfs and have a few questions to
> > which I did not find answers to in the website. First, I would like to know
> > why it is that xfs doesn't like to be mounted "ro" read-only. I didn't find
> > anyone addressing this issue and had to figure out on my own to change the
> > /etc/lilo.conf entry "read-only" to "read-write".

Hmm never tried that... guess we'll have to look at that.

>
> > Second, how can I get by the problem of xfs doing its job too well :) and
> > leaving pid files and caches? I pulled the power cord out of my box to test
> > the xfs journaling and several things didn't work out well when the system
> > came back up: sysklogd didn't start up because it found its old pid file and
> > thought it was still running and also my enlightenment window-manager
> > configuration was totally purged. I had to rearrange my entire start-up
> > setup (location of apps that run on startup, etc). Are there any flags to
> > pass to mount in order to fix these problems?

Note no file system can guarantee no data is ever lost. Pulling the plug on a
system
means any data still on the cache that has not been written out to disk is lost.
The only way to reduce the amount of data loss is to run the  file system with
"sync"
enabled, but you will be negating the performance advantages of XFSs delay
allocation.


>

>
>
> I don't think this issue has anything to do with mount. It has to do with your
> init scripts not cleaning up /var/run on boot, as they should. e.g. on Debian:

Yes exactly.

>
>
> ----- excerpt from /etc/init.d/bootmisc.sh -----
>
> #
> # Clean up /var/run and create /var/run/utmp so that we can login.
> #
> [ "$VERBOSE" != no ] && echo -n "/var/run"
> ( cd /var/run && \
>         find . ! -type d ! -name utmp ! -name innd.pid ! -name random-seed \
>         ! -newer /etc/mtab -exec rm -f -- {} \; )
> : > /var/run/utmp
> if grep -q ^utmp: /etc/group
> then
>         chmod 664 /var/run/utmp
>         chgrp utmp /var/run/utmp
> fi
> [ "$VERBOSE" != no ] && echo "."
>
> -------------------------------------------------
>
> --
> -> -/-                       - Rahul Jain -                       -\- <-
> -> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <-
> -> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
> |--|--------|--------------|----|-------------|------|---------|-----|-|
>    Version 11.423.999.220020101.23.50110101.042
>    (c)1996-2000, All rights reserved. Disclaimer available upon request.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May  1 16:05:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41N5pi01581
	for linux-xfs-outgoing; Tue, 1 May 2001 16:05:51 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41N5lF01576
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:05:47 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA07601
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:04:26 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA48418; Tue, 1 May 2001 18:04:31 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f41N3UB06439;
	Tue, 1 May 2001 19:03:30 -0400
Message-ID: <3AEF40C2.1D418EA9@thebarn.com>
Date: Tue, 01 May 2001 19:03:30 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Martin K. Petersen" <mkp@linuxcare.com>
CC: Eric Sandeen <sandeen@sgi.com>,
   Michael Steigman <steigman@ne.mediaone.net>, linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com>
		<3AEF0B34.C0F12FCD@ne.mediaone.net> <3AEF0CB9.A4D0F59C@sgi.com> <yq18zkgn5rz.fsf@jcb.mkp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Martin K. Petersen" wrote:

> >>>>> "Eric" == Eric Sandeen <sandeen@sgi.com> writes:
>
> >> The installation went fine after loading the update disk. However,
> >> upon reboot, raidautorun reports "failed to open /dev/md0" which
> >> obviously leads to a kernel panic (my / is on md0). Suggestions?
>
> Eric> Hm... hopefully Martin or Russell can speak to this - I don't
> Eric> have any raid machines here, and have not ever tested it...
>
> Eric> Could this be a devfs thing?  Has /dev/md0 moved to /dev/md/0
> Eric> perhaps?  If devfsd hasn't started, the compatibility links
> Eric> won't be there if / isn't even mounted.
>
> That's probably the case, yes.

Wouldn't this be before / is mounted? so  it probably doesn't matter  if

/dev/ is real or devfs.

How does the kernel find and mount / if it is an md device?  the dev_id
is usually
part of the lilo boot process but in the md case?


>
>
> --
> Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
> mkp@linuxcare.com, http://www.linuxcare.com/
> SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May  1 16:28:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41NSHc02852
	for linux-xfs-outgoing; Tue, 1 May 2001 16:28:17 -0700
Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41NSEF02848
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:28:15 -0700
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id BAA20175;
	Wed, 2 May 2001 01:28:13 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id BAA17685;
	Wed, 2 May 2001 01:28:12 +0200 (CEST)
Date: Wed, 2 May 2001 01:28:12 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: Fred Reimer <fwr@ga.prestige.net>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Diffs for 2.4.4???
In-Reply-To: <3AEEE97E.3060303@ga.prestige.net>
Message-ID: <Pine.BSI.4.33L2.0105020123560.16941-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 1 May 2001, Fred Reimer wrote:

> Hello,
>
> Where are the diffs for Linux-2.4.4?  I didn't see any patches available
> on the web site, only access to your cvs system.  What version of the
> kernel are you basing your cvs off of anyway?  Under cvs I saw comments
> about 2.4.2.  Can anyone make a proper diff, as I believe this will
> increase the number of people using the software dramatically?

The 2.4.2 release is tested a lot and is fairly stable. It includes a lot
of patches depending on th used kernel.

The linux-2.4-xfs tree is based on 2.4.3 and the beta tree on 2.4.2.
There is a patch for 2.4.4 available on
ftp://linux-xfs.sgi.com/projects/xfs/download/testing/
This one is not available in CVS before it is tested at SGI internally.

In a few days the linux-2.4-xfs cvs tree will probably updated to 2.4.4

Bye
Seth
>
> Thanks,
>
> Fred Reimer
>
>


From owner-linux-xfs@oss.sgi.com Tue May  1 16:44:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41NiG203751
	for linux-xfs-outgoing; Tue, 1 May 2001 16:44:16 -0700
Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41NiEF03746
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:44:15 -0700
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id BAA23212;
	Wed, 2 May 2001 01:44:12 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id BAA18044;
	Wed, 2 May 2001 01:44:12 +0200 (CEST)
Date: Wed, 2 May 2001 01:44:11 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: Russell Cattelan <cattelan@thebarn.com>
cc: Rahul Jain <rahul@rice.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: XFS question
In-Reply-To: <3AEF3FB4.73AC80FB@thebarn.com>
Message-ID: <Pine.BSI.4.33L2.0105020142050.16941-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 1 May 2001, Russell Cattelan wrote:

> Rahul Jain wrote:
>
> > On Tue, May 01, 2001 at 05:40:40PM -0400, Castellanos, Leon wrote:
> > > I just converted all my file systems to xfs and have a few questions to
> > > which I did not find answers to in the website. First, I would like to know
> > > why it is that xfs doesn't like to be mounted "ro" read-only. I didn't find
> > > anyone addressing this issue and had to figure out on my own to change the
> > > /etc/lilo.conf entry "read-only" to "read-write".
>
> Hmm never tried that... guess we'll have to look at that.

I see this on RedHat too. It spits out a warning if it has to replay it's
log to mount the fs. After that it _is_ mounted ro.
You can't really mount a journaling fs without logreplay. Maybe you could
but would you really want that?

Bye
Seth


From owner-linux-xfs@oss.sgi.com Tue May  1 16:47:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f41NlJS03821
	for linux-xfs-outgoing; Tue, 1 May 2001 16:47:19 -0700
Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f41NlIF03818
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:47:18 -0700
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id BAA23794;
	Wed, 2 May 2001 01:47:13 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id BAA18120;
	Wed, 2 May 2001 01:47:12 +0200 (CEST)
Date: Wed, 2 May 2001 01:47:12 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: Russell Cattelan <cattelan@thebarn.com>
cc: "Martin K. Petersen" <mkp@linuxcare.com>, Eric Sandeen <sandeen@sgi.com>,
   Michael Steigman <steigman@ne.mediaone.net>, <linux-xfs@oss.sgi.com>
Subject: Re: RH 7.1 installer errors
In-Reply-To: <3AEF40C2.1D418EA9@thebarn.com>
Message-ID: <Pine.BSI.4.33L2.0105020144400.16941-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 1 May 2001, Russell Cattelan wrote:

> "Martin K. Petersen" wrote:
>
> > >>>>> "Eric" == Eric Sandeen <sandeen@sgi.com> writes:
> >
> > >> The installation went fine after loading the update disk. However,
> > >> upon reboot, raidautorun reports "failed to open /dev/md0" which
> > >> obviously leads to a kernel panic (my / is on md0). Suggestions?
> >
> > Eric> Hm... hopefully Martin or Russell can speak to this - I don't
> > Eric> have any raid machines here, and have not ever tested it...
> >
> > Eric> Could this be a devfs thing?  Has /dev/md0 moved to /dev/md/0
> > Eric> perhaps?  If devfsd hasn't started, the compatibility links
> > Eric> won't be there if / isn't even mounted.
> >
> > That's probably the case, yes.
>
> Wouldn't this be before / is mounted? so  it probably doesn't matter  if
>
> /dev/ is real or devfs.
>
> How does the kernel find and mount / if it is an md device?  the dev_id
> is usually
> part of the lilo boot process but in the md case?

Do you have a initrdimage for inserting the md modules?
AFAIk they were also modular on redhat kernels.
I managed to make the server I admin 100Km away unbootable after
forgetting to compile raid 1 support in :-/

Bye
Seth


From owner-linux-xfs@oss.sgi.com Tue May  1 17:00:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4200o104174
	for linux-xfs-outgoing; Tue, 1 May 2001 17:00:50 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4200mF04171
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:00:48 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f41Nvkg05291;
	Tue, 1 May 2001 18:57:46 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 1 May 2001 18:57:45 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Seth Mos <knuffie@xs4all.nl>
cc: Russell Cattelan <cattelan@thebarn.com>,
   "Martin K. Petersen" <mkp@linuxcare.com>, Eric Sandeen <sandeen@sgi.com>,
   Michael Steigman <steigman@ne.mediaone.net>, <linux-xfs@oss.sgi.com>
Subject: Re: RH 7.1 installer errors
In-Reply-To: <Pine.BSI.4.33L2.0105020144400.16941-100000@xs4.xs4all.nl>
Message-ID: <Pine.LNX.4.33.0105011857140.1723-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hmm...as far as I know you MUST compile in the md support if you want to
have / or /boot useable if they are md/lvm devices.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 2 May 2001, Seth Mos wrote:

> On Tue, 1 May 2001, Russell Cattelan wrote:
>
> > "Martin K. Petersen" wrote:
> >
> > > >>>>> "Eric" == Eric Sandeen <sandeen@sgi.com> writes:
> > >
> > > >> The installation went fine after loading the update disk. However,
> > > >> upon reboot, raidautorun reports "failed to open /dev/md0" which
> > > >> obviously leads to a kernel panic (my / is on md0). Suggestions?
> > >
> > > Eric> Hm... hopefully Martin or Russell can speak to this - I don't
> > > Eric> have any raid machines here, and have not ever tested it...
> > >
> > > Eric> Could this be a devfs thing?  Has /dev/md0 moved to /dev/md/0
> > > Eric> perhaps?  If devfsd hasn't started, the compatibility links
> > > Eric> won't be there if / isn't even mounted.
> > >
> > > That's probably the case, yes.
> >
> > Wouldn't this be before / is mounted? so  it probably doesn't matter  if
> >
> > /dev/ is real or devfs.
> >
> > How does the kernel find and mount / if it is an md device?  the dev_id
> > is usually
> > part of the lilo boot process but in the md case?
>
> Do you have a initrdimage for inserting the md modules?
> AFAIk they were also modular on redhat kernels.
> I managed to make the server I admin 100Km away unbootable after
> forgetting to compile raid 1 support in :-/
>
> Bye
> Seth
>


From owner-linux-xfs@oss.sgi.com Tue May  1 17:16:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420Gdj04924
	for linux-xfs-outgoing; Tue, 1 May 2001 17:16:39 -0700
Received: from pervalidus.dyndns.org (exim@200191143098-dial-user-UOL.acessonet.com.br [200.191.143.98])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420GNF04900
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:16:35 -0700
Received: from pervalidus by pervalidus.dyndns.org with local (Exim 3.22 #1)
	id 14ukJS-0002Rl-00
	for linux-xfs@oss.sgi.com; Tue, 01 May 2001 21:16:14 -0300
Date: Tue, 1 May 2001 21:16:14 -0300
From: =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <0@pervalidus.net>
To: linux-xfs@oss.sgi.com
Subject: Question about XFS as a module
Message-ID: <20010501211614.J123@pervalidus>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.16i
X-Mailer: Mutt/1.3.16i - Linux 2.4.4
X-URL: http://www.pervalidus.net/
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi. From http://linux-xfs.sgi.com/projects/xfs/faq.html :

Q: Mounting the XFS filesystem does not work - what is wrong?

   If you get something like:
    mount: /dev/hda5 has wrong major or minor number

you either don't have XFS compiled into the kernel (or you
forgot to load the modules) or you did not use the "-t xfs"
option on mount or the "xfs" option in /etc/fstab.

My question is if I can use XFS without rebooting, only building
the module, or I also need to make bzImage ?

-- 
0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)

From owner-linux-xfs@oss.sgi.com Tue May  1 17:20:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420KqJ05151
	for linux-xfs-outgoing; Tue, 1 May 2001 17:20:52 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420KoF05143
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:20:51 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f420KnN19219
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 19:20:49 -0500 (CDT)
Message-ID: <3AEF5335.BDFE5C4F@sgi.com>
Date: Tue, 01 May 2001 19:22:13 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: Question about XFS as a module
References: <20010501211614.J123@pervalidus>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Frédéric L. W. Meunier wrote:
 
> My question is if I can use XFS without rebooting, only building
> the module, or I also need to make bzImage ?

XFS requires more than just the module - there are also some changes to
the kernel itself, so you will need to make bzImage as well.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 17:22:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420Mab05242
	for linux-xfs-outgoing; Tue, 1 May 2001 17:22:36 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420MaF05239
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:22:36 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA09236
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:33:17 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (localhost [127.0.0.1])
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA76170;
	Wed, 2 May 2001 10:21:16 +1000 (EST)
Message-Id: <200105020021.KAA76170@snort.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <0@pervalidus.net>
cc: linux-xfs@oss.sgi.com
Subject: Re: Question about XFS as a module 
In-reply-to: Your message of "Tue, 01 May 2001 21:16:14 -0300."
             <20010501211614.J123@pervalidus> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 02 May 2001 10:21:16 +1000
From: Daniel Moore <dxm@snort.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier writes:
 => Hi. From http://linux-xfs.sgi.com/projects/xfs/faq.html :
 => 
 => Q: Mounting the XFS filesystem does not work - what is wrong?
 => 
 =>    If you get something like:
 =>     mount: /dev/hda5 has wrong major or minor number
 => 
 => you either don't have XFS compiled into the kernel (or you
 => forgot to load the modules) or you did not use the "-t xfs"
 => option on mount or the "xfs" option in /etc/fstab.
 => 
 => My question is if I can use XFS without rebooting, only building
 => the module, or I also need to make bzImage ?

Kernel changes are required to support XFS. You need to rebuild the
kernel even if you are using XFS as a module.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue May  1 17:24:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420OrT05410
	for linux-xfs-outgoing; Tue, 1 May 2001 17:24:53 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420OpF05406
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:24:51 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f420Og511919;
	Tue, 1 May 2001 19:24:42 -0500 (CDT)
Message-ID: <3AEF541E.438CBDA5@sgi.com>
Date: Tue, 01 May 2001 19:26:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Rahul Jain <rahul@rice.edu>, linux-xfs@oss.sgi.com
Subject: Re: XFS question
References: <D3DC1A12F511D511A83000B0D0AA447F0E9096@bbking.techtrader.com> <20010501165706.B20890@photino.sid.rice.edu> <3AEF3FB4.73AC80FB@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Rahul Jain wrote:
> 
> > On Tue, May 01, 2001 at 05:40:40PM -0400, Castellanos, Leon wrote:
> > > First, I would like to know
> > > why it is that xfs doesn't like to be mounted "ro" read-only. I didn't find
> > > anyone addressing this issue and had to figure out on my own to change the
> > > /etc/lilo.conf entry "read-only" to "read-write".
> 
> Hmm never tried that... guess we'll have to look at that.

I don't think there's really a problem here - a warning is generated,
but I think it's just saying "hey, you wanted read only, but I'm going
to be read-write for a minute so I can play the log"

I have read-only specified in lilo on my xfs-only box, and while I see
this warning, everything works fine.  Mounting a filesystem read-only on
the running system also behaves as expected.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 17:30:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420UO305548
	for linux-xfs-outgoing; Tue, 1 May 2001 17:30:24 -0700
Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420UNF05545
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:30:23 -0700
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id CAA01563;
	Wed, 2 May 2001 02:30:21 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id CAA19065;
	Wed, 2 May 2001 02:30:21 +0200 (CEST)
Date: Wed, 2 May 2001 02:30:21 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: =?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier <0@pervalidus.net>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Question about XFS as a module
In-Reply-To: <20010501211614.J123@pervalidus>
Message-ID: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f420UOF05546
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 1 May 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:

> Hi. From http://linux-xfs.sgi.com/projects/xfs/faq.html :
>
> Q: Mounting the XFS filesystem does not work - what is wrong?
>
>    If you get something like:
>     mount: /dev/hda5 has wrong major or minor number
>
> you either don't have XFS compiled into the kernel (or you
> forgot to load the modules) or you did not use the "-t xfs"
> option on mount or the "xfs" option in /etc/fstab.
>
> My question is if I can use XFS without rebooting, only building
> the module, or I also need to make bzImage ?

No, you always need to have the kernel booted of the same version and with
all the neccesary symbols to be able insert the module.
bzImage is the actual kernel and you will need to boot that one before you
can try to load the module.
A modprobe xfs would probably return a error if you don't run a xfs
capable kernel with xfs compiled as a module.

Bye
Seth

>
> --
> 0@pervalidus.{net, {dyndns.}org} Tel: 55-21-717-2399 (Niterói-RJ BR)
>


From owner-linux-xfs@oss.sgi.com Tue May  1 17:42:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420gfx05841
	for linux-xfs-outgoing; Tue, 1 May 2001 17:42:41 -0700
Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420gaF05836
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:42:36 -0700
Received: from david ([65.2.16.49]) by femail13.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010502004230.WSRL15258.femail13.sdc1.sfba.home.com@david>
          for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:42:30 -0700
Message-ID: <00b001c0d2a0$c16f6fc0$0a00a8c0@david>
From: "David Benigni" <benigni@cse.psu.edu>
Cc: <linux-xfs@oss.sgi.com>
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl>
Subject: swapon error
Date: Tue, 1 May 2001 20:42:20 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, I downloaded an installed the XFS Redhat 7.1 install iso.  During boot I
get this error when the swapon part of sysinit runs.
swapon /dev/hda6: Device or resource busy.

This didn't happen with vanilla 7.1.  here's what I have.
/boot as xfs
/ as xfs
and the swap partition.

Anyone else experience this?

David P. Benigni II


From owner-linux-xfs@oss.sgi.com Tue May  1 17:48:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f420mxu06024
	for linux-xfs-outgoing; Tue, 1 May 2001 17:48:59 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f420mvF06021
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:48:57 -0700
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA19379
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 17:47:35 -0700 (PDT)
	mail_from (kaos@ocs.com.au)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id KAA04412; Wed, 2 May 2001 10:47:33 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@ocs.com.au>
To: Seth Mos <knuffie@xs4all.nl>
cc: "Fr d ric L. W. Meunier" <0@pervalidus.net>, linux-xfs@oss.sgi.com
Subject: Re: Question about XFS as a module 
In-reply-to: Your message of "Wed, 02 May 2001 02:30:21 +0200."
             <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Date: Wed, 02 May 2001 10:47:32 +1000
Message-ID: <8445.988764452@kao2.melbourne.sgi.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f420mvF06022
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 2 May 2001 02:30:21 +0200 (CEST), 
Seth Mos <knuffie@xs4all.nl> wrote:
>On Tue, 1 May 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:
>> My question is if I can use XFS without rebooting, only building
>> the module, or I also need to make bzImage ?
>
>No, you always need to have the kernel booted of the same version and with
>all the neccesary symbols to be able insert the module.

Nit picking.  It is quite possible to add code to the kernel, compile
it as a module and load into the existing kernel without rebuilding
bzImage or rebooting.  This only works if the add on code has *NO*
changes to the main kernel, several drivers are shipped this way
because they are completely standalone.  However XFS requires changes
to the base kernel code as well as the XFs code itself so in this case
you do need to compile bzImage and reboot.

Keith Owens, modutils and kernel build maintainer.


From owner-linux-xfs@oss.sgi.com Tue May  1 18:04:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4214l606538
	for linux-xfs-outgoing; Tue, 1 May 2001 18:04:47 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4214jF06535
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 18:04:45 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4214iN27087;
	Tue, 1 May 2001 20:04:44 -0500 (CDT)
Message-ID: <3AEF5D7E.31544F90@sgi.com>
Date: Tue, 01 May 2001 20:06:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Benigni <benigni@cse.psu.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: swapon error
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> <00b001c0d2a0$c16f6fc0$0a00a8c0@david>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yes, I have seen this as well.  Swap _does_ get enabled, and everything
is fine, but there is this warning.

I think it's YADT (Yet Another Devfs Thing).

For the gory details, read on...

Looking at rc.sysinit, it actually executes swapon twice.  Not sure why
Red hat does this.

If I do

$ swapoff -a
$ swapon -a -e
$ swapon -a

(essentially the same as rc.sysinit) I get the same "device busy" error
message.  However, the man page says that for "swapon -a," "devices that
are already running as swap are silently skipped" - but we're not seing
this behavior.

So my guess is that since the "device" (/dev/hda5 in my case) is
actually just a symlink under devfs, it's confusing swapon somehow. 
Booting with "devfs = nomount" gets rid of the error, so that must be
it.

I'll put it on the devfs list and see what people think... 

-Eric


David Benigni wrote:
> 
> Ok, I downloaded an installed the XFS Redhat 7.1 install iso.  During boot I
> get this error when the swapon part of sysinit runs.
> swapon /dev/hda6: Device or resource busy.
> 
> This didn't happen with vanilla 7.1.  here's what I have.
> /boot as xfs
> / as xfs
> and the swap partition.
> 
> Anyone else experience this?
> 
> David P. Benigni II

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 18:05:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4215fI06566
	for linux-xfs-outgoing; Tue, 1 May 2001 18:05:41 -0700
Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4215eF06560
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 18:05:41 -0700
Received: from ne.mediaone.net (IDENT:ms@steigman.ne.mediaone.net [24.147.237.193])
	by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f4215K602193;
	Tue, 1 May 2001 21:05:20 -0400 (EDT)
Message-ID: <3AEF5D61.11393EDE@ne.mediaone.net>
Date: Tue, 01 May 2001 21:05:37 -0400
From: Michael Steigman <steigman@ne.mediaone.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 installer errors
References: <3AEEBB28.8AAFCC75@ne.mediaone.net> <3AEEE251.306EF354@sgi.com> <3AEF0B34.C0F12FCD@ne.mediaone.net> <3AEF1689.5393EFD1@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I was able to boot the system by passing "devfs=nomount" to the kernel
so the panic was devfs related. Otherwise, things are going swimmingly -
the RAID devices synced up fine and performance seems good to the naked
eye. Since I know next to nothing about devfs, I should probably start
by reading the devfs FAQ (as you mention on the XFS page :-0)

In the meantime, any other pointers are welcome. Thanks.

Michael

Eric Sandeen wrote:
> 
> Michael Steigman wrote:
> 
> > The installation went fine after loading the update disk. However, upon
> > reboot, raidautorun reports "failed to open /dev/md0" which obviously
> > leads to a kernel panic (my / is on md0). Suggestions?
> 
> You can also pass "devfs=nomount" to get around devfs for now, but
> surely there's a way to make raid work with devfs.
> 
> -Eric
> 
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 18:06:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42163X06580
	for linux-xfs-outgoing; Tue, 1 May 2001 18:06:03 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42162F06577
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 18:06:02 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA352646
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:06:00 +0200 (CEST)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id SAA59809; Tue, 1 May 2001 18:00:13 -0700 (PDT)
Message-ID: <3AEF5CAE.DBFBB3E4@sgi.com>
Date: Tue, 01 May 2001 18:02:38 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Benigni <benigni@cse.psu.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: swapon error
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> <00b001c0d2a0$c16f6fc0$0a00a8c0@david>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

David Benigni wrote:
> 
> Ok, I downloaded an installed the XFS Redhat 7.1 install iso.  During boot I
> get this error when the swapon part of sysinit runs.
> swapon /dev/hda6: Device or resource busy.
> 
> This didn't happen with vanilla 7.1.  here's what I have.
> /boot as xfs
> / as xfs
> and the swap partition.
> 
> Anyone else experience this?
> 

I've seen this on some systems here, but the effect seems
to be benign:  "swapon -s" shows the swap being there.

Can you confirm that swap still works in spite of the warning message?

ananth.


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May  1 19:13:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f422D6K08694
	for linux-xfs-outgoing; Tue, 1 May 2001 19:13:06 -0700
Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f422D5F08690
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 19:13:05 -0700
Received: from david ([65.2.16.49]) by femail13.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010502021259.YGV15258.femail13.sdc1.sfba.home.com@david>;
          Tue, 1 May 2001 19:12:59 -0700
Message-ID: <010801c0d2ad$65688e20$0a00a8c0@david>
From: "David Benigni" <benigni@cse.psu.edu>
To: "Rajagopal Ananthanarayanan" <ananth@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> <00b001c0d2a0$c16f6fc0$0a00a8c0@david> <3AEF5CAE.DBFBB3E4@sgi.com>
Subject: Re: swapon error
Date: Tue, 1 May 2001 22:12:53 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't know if it is on not.  I'm assuming so, because after on the second
boot, I still get the error but says it started "ok."  I haven't
investigated further because its finals week for college, and I should be
studying :)

David P. Benigni II


----- Original Message -----
From: "Rajagopal Ananthanarayanan" <ananth@sgi.com>
To: "David Benigni" <benigni@cse.psu.edu>
Cc: <linux-xfs@oss.sgi.com>
Sent: Tuesday, May 01, 2001 9:02 PM
Subject: Re: swapon error


> David Benigni wrote:
> >
> > Ok, I downloaded an installed the XFS Redhat 7.1 install iso.  During
boot I
> > get this error when the swapon part of sysinit runs.
> > swapon /dev/hda6: Device or resource busy.
> >
> > This didn't happen with vanilla 7.1.  here's what I have.
> > /boot as xfs
> > / as xfs
> > and the swap partition.
> >
> > Anyone else experience this?
> >
>
> I've seen this on some systems here, but the effect seems
> to be benign:  "swapon -s" shows the swap being there.
>
> Can you confirm that swap still works in spite of the warning message?
>
> ananth.
>
>
> --------------------------------------------------------------------------
> Rajagopal Ananthanarayanan ("ananth")
> Member Technical Staff, SGI.
> --------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Tue May  1 19:15:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f422FVf08752
	for linux-xfs-outgoing; Tue, 1 May 2001 19:15:31 -0700
Received: from femail13.sdc1.sfba.home.com (femail13.sdc1.sfba.home.com [24.0.95.140])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f422FRF08748
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 19:15:27 -0700
Received: from david ([65.2.16.49]) by femail13.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010502021521.BBAU15258.femail13.sdc1.sfba.home.com@david>;
          Tue, 1 May 2001 19:15:21 -0700
Message-ID: <011401c0d2ad$b9b891f0$0a00a8c0@david>
From: "David Benigni" <benigni@cse.psu.edu>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> <00b001c0d2a0$c16f6fc0$0a00a8c0@david> <3AEF5D7E.31544F90@sgi.com>
Subject: Re: swapon error
Date: Tue, 1 May 2001 22:15:14 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Good, atleast I'm not the only one :)

I didn't get very far with XFS, installed it, did a df, and hit reset and
booted back up.  In about a week, I'll have more free time to see what's
going on.

David P. Benigni II


----- Original Message -----
From: "Eric Sandeen" <sandeen@sgi.com>
To: "David Benigni" <benigni@cse.psu.edu>
Cc: <linux-xfs@oss.sgi.com>
Sent: Tuesday, May 01, 2001 9:06 PM
Subject: Re: swapon error


> Yes, I have seen this as well.  Swap _does_ get enabled, and everything
> is fine, but there is this warning.
>
> I think it's YADT (Yet Another Devfs Thing).
>
> For the gory details, read on...
>
> Looking at rc.sysinit, it actually executes swapon twice.  Not sure why
> Red hat does this.
>
> If I do
>
> $ swapoff -a
> $ swapon -a -e
> $ swapon -a
>
> (essentially the same as rc.sysinit) I get the same "device busy" error
> message.  However, the man page says that for "swapon -a," "devices that
> are already running as swap are silently skipped" - but we're not seing
> this behavior.
>
> So my guess is that since the "device" (/dev/hda5 in my case) is
> actually just a symlink under devfs, it's confusing swapon somehow.
> Booting with "devfs = nomount" gets rid of the error, so that must be
> it.
>
> I'll put it on the devfs list and see what people think...
>
> -Eric
>
>
> David Benigni wrote:
> >
> > Ok, I downloaded an installed the XFS Redhat 7.1 install iso.  During
boot I
> > get this error when the swapon part of sysinit runs.
> > swapon /dev/hda6: Device or resource busy.
> >
> > This didn't happen with vanilla 7.1.  here's what I have.
> > /boot as xfs
> > / as xfs
> > and the swap partition.
> >
> > Anyone else experience this?
> >
> > David P. Benigni II
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Tue May  1 19:19:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f422JVh08839
	for linux-xfs-outgoing; Tue, 1 May 2001 19:19:31 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f422JVF08836
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 19:19:31 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f422JO506006;
	Tue, 1 May 2001 21:19:24 -0500 (CDT)
Message-ID: <3AEF6F01.1EF38AE4@sgi.com>
Date: Tue, 01 May 2001 21:20:49 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: David Benigni <benigni@cse.psu.edu>
CC: Rajagopal Ananthanarayanan <ananth@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: swapon error
References: <Pine.BSI.4.33L2.0105020227080.18968-100000@xs4.xs4all.nl> <00b001c0d2a0$c16f6fc0$0a00a8c0@david> <3AEF5CAE.DBFBB3E4@sgi.com> <010801c0d2ad$65688e20$0a00a8c0@david>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

David Benigni wrote:
> 
> I don't know if it is on not.  I'm assuming so, because after on the second
> boot, I still get the error but says it started "ok."  

That's because they call "swapon -a" and then pass /bin/true to the part
of the script that generates "ok"

Your system could be melting, and that particular line of the boot
scripts would still generate a cheery green

[OK]

:)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 20:09:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42394510215
	for linux-xfs-outgoing; Tue, 1 May 2001 20:09:04 -0700
Received: from smtp10ve.mailsrvcs.net ([206.46.170.142])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42393F10212
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 20:09:03 -0700
Received: from neuronet.pitt.edu (adsl-151-201-240-40.pittpa.adsl.bellatlantic.net [151.201.240.40])
	by smtp10ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id QAA18543
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 16:03:49 -0500 (CDT)
Message-ID: <3AEF79FC.2FA0F191@neuronet.pitt.edu>
Date: Tue, 01 May 2001 23:07:40 -0400
From: "Rafael E. Herrera" <raffo@neuronet.pitt.edu>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Problem loading modules under Suse 7.1 and kernel 2.4.3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

I used  linux-2.4-xfs-1.0.patch.gz and linux-2.4.3-core-xfs-1.0.patch.gz 
to patch a vanilla 2.4.3 kernel, made xfs and page buffer support as 
modules and rebuilt my kernel.

Fisrt of all, the compiler was hardcoded as kgcc, this is a redhad-ism, 
there should be a test for the distribution in order to use kgcc. In
suse 
the compiler is gcc-2.95.2

I use a a ram disk image to load my scsi and usb modules. At boot I got
a number 
of unresolved symbols and the modules didn't get loaded and the system 
didn't boot. Re-built with the scsi modules built in, but had the same 
problem. I have modutils 2.4.2.

A sample of the log looks like this:

May  1 22:32:55 inca syslogd 1.3-3: restart.
May  1 22:32:57 inca usbmgr[9298]: start 0.4.1
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
schedule_timeout
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
__wake_up
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
__generic_copy_from_user
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
schedule
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
kmalloc
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
unregister_chrdev
May  1 22:32:57 inca insmod:
/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
register_chrdev

I followed the usual make menuconfig, dep, bzImage, modules,
modules-install, lilo.

So, it's a no go for my system. I'd appreciate any suggestion.

-- 
     Rafael

From owner-linux-xfs@oss.sgi.com Tue May  1 20:18:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f423IO010498
	for linux-xfs-outgoing; Tue, 1 May 2001 20:18:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f423IMF10463
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 20:18:22 -0700
Received: from sydney.sydney.sgi.com ([134.14.48.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id UAA09047
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 20:18:17 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id NAA13914; Wed, 2 May 2001 13:16:57 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Rafael E. Herrera" <raffo@neuronet.pitt.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: Problem loading modules under Suse 7.1 and kernel 2.4.3 
In-reply-to: Your message of "Tue, 01 May 2001 23:07:40 -0400."
             <3AEF79FC.2FA0F191@neuronet.pitt.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 02 May 2001 13:16:56 +1000
Message-ID: <10633.988773416@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 01 May 2001 23:07:40 -0400, 
"Rafael E. Herrera" <raffo@neuronet.pitt.edu> wrote:
>May  1 22:32:57 inca insmod:
>/lib/modules/2.4.3-XFS/kernel/drivers/usb/usbcore.o: unresolved symbol
>schedule_timeout

schedule_timeout is always exported so either you have the wrong kernel
booted or you have a symbol version problem.  If 
  grep schedule_timeout /proc/ksyms
shows schedule_timeout with a _R suffix then you have been bitten by
the broken kernel Makefiles, see http://www.tux.org/lkml/#s8-8


From owner-linux-xfs@oss.sgi.com Tue May  1 21:08:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4248X211717
	for linux-xfs-outgoing; Tue, 1 May 2001 21:08:33 -0700
Received: from wwweasel.geeksrus.net (wwweasel.geeksrus.net [64.67.200.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4248QF11711
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 21:08:28 -0700
Received: (from alane@localhost)
	by wwweasel.geeksrus.net (8.11.2/8.11.2) id f4248Ff16968;
	Wed, 2 May 2001 00:08:15 -0400
Date: Wed, 2 May 2001 00:08:14 -0400
From: Alan Eldridge <alane@geeksrus.net>
To: tvignaud@mandrakesoft.com
Cc: linux-xfs@oss.sgi.com
Subject: devfsd-1.3.11-1
Message-ID: <20010502000814.A16705@wwweasel.geeksrus.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm running SGI's XFS-based version of RH 7.1, which in turn uses your
patched version of devfsd. Since this version of devfsd has a home with the
Mandrake distribution, I figured this would be the most appropriate way to
report a bug.

The code for saving and restoring the permissions has got it *half* right.
Yup, the event is triggered and the copy happens. But it happens *before*
the underlying device node has been altered. The semantics thus become,
"save the previous state to restore, and then modify the device node". This
leaves something to be desired.

The work around, of course, is if you need to change the perms on anything
under /dev, do it *twice*. Then the first changed device node will get
copied before the second (identical, hence no-op) change is applied.

I'll try to work up a patch in a day or two; OTOH if you know where the
culprit lies already, please advise me and send me (and SGI) the patch you
come up with.

Oh, and another thing.... :)

I'm not sure if this is a bug or a feature, but if you have cases where
a device name would match more than one event regexp, it seems that only the
(first? last? I can't remember which) one happens.

So, order notwithstanding, if you've got, e.g.,

REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath $mntpath
REGISTER ^cdroms/cdrom0$ EXECUTE /bin/ln -s $devname cdrom

only one of those two things is going to happen (I think the latter). This
kinda sucks, especially for the exact case I used. There's fsck-all
different names for cdrom devices (cdrom, cdrom0, scd0, sr0, cdroms/cdrom0,
your/mommas/cdrom/0, scsi/host0/bus0/target3/lun0/{cd,generic}), and
wouldn't you know there's gotta be some piece of software that is going to
want *each* possible variation... (think: RedHat's kudzu and "updfstab").

It would be ever so nice if the multiple matching case thing performed all
matching actions, instead of the one most recent. It would also be *really*
nice to have a way to get at the regex match parts:

REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath scd$1

or something like that. (I know, I know, matching the bits of the RE can be
a royal PITA, and this isn't really meant to be "sed", but some way to pick
out the matching numeric portion of the name would really help.)

Okay. I'm done. :)

-- 
Alan Eldridge
import std_disclaimer

From owner-linux-xfs@oss.sgi.com Tue May  1 21:21:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f424LZl12013
	for linux-xfs-outgoing; Tue, 1 May 2001 21:21:35 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f424LWF12007
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 21:21:32 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f424LB502548;
	Tue, 1 May 2001 23:21:11 -0500 (CDT)
Message-ID: <3AEF8B8E.E6E3ED9E@sgi.com>
Date: Tue, 01 May 2001 23:22:38 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Eldridge <alane@geeksrus.net>
CC: tvignaud@mandrakesoft.com, linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
References: <20010502000814.A16705@wwweasel.geeksrus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Alan Eldridge wrote:
 
> So, order notwithstanding, if you've got, e.g.,
> 
> REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath $mntpath
> REGISTER ^cdroms/cdrom0$ EXECUTE /bin/ln -s $devname cdrom
>
> only one of those two things is going to happen (I think the latter). This
> kinda sucks, especially for the exact case I used. 

Interesting, I'll have to look at this.  The fact that there is a
keyword:

       IGNORE This  action  causes  all subsequent processing for
              the device to be ignored.

for devfsd.conf made me think that the default was to continue on,
processing each match...?

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  1 21:44:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f424iac13190
	for linux-xfs-outgoing; Tue, 1 May 2001 21:44:36 -0700
Received: from smtp4ve.mailsrvcs.net (smtp4vepub.gte.net [206.46.170.25])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f424iZF13187
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 21:44:35 -0700
Received: from neuronet.pitt.edu (adsl-151-201-240-40.pittpa.adsl.bellatlantic.net [151.201.240.40])
	by smtp4ve.mailsrvcs.net (8.9.1/8.9.1) with ESMTP id FAA26223223
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 05:02:07 GMT
Message-ID: <3AEF90AC.14203975@neuronet.pitt.edu>
Date: Wed, 02 May 2001 00:44:28 -0400
From: "Rafael E. Herrera" <raffo@neuronet.pitt.edu>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: Problem loading modules under Suse 7.1 and kernel 2.4.3
References: <10633.988773416@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I re-built after the previous suggestion and this time it worked. I'll
compile a kernel on it as a test. Looks good. Thanks everybody for this
work.

-- 
     Rafael

From owner-linux-xfs@oss.sgi.com Tue May  1 23:41:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f426fX016546
	for linux-xfs-outgoing; Tue, 1 May 2001 23:41:33 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f426fJF16508
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 23:41:19 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA01120
	for <linux-xfs@oss.sgi.com>; Tue, 1 May 2001 23:52:01 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id BAA71804 for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 01:40:02 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f426d2M09386
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 02:39:02 -0400
Date: Wed, 2 May 2001 02:39:02 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105020639.f426d2M09386@gibble.americas.sgi.com>
Subject: TAKE - Bring the development tree to 2.4.4
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This passes basic dbench, bonnie, and doio tests.

alloc_kiovec have been reverted to allocating
slab memory, this appears to working but
more changes may be forth comming as the
kiovec's now have "wasted" buffer_heads attached
to them.

As always approach with caution as
it may or may not be stable.

2.4.4 Merge

Date:  Tue May  1 23:22:13 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4.4-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93822a
linux/arch/mips/math-emu/sp_tint.c - 1.1
linux/drivers/net/wan/sdla_ft1.c - 1.1
linux/drivers/net/wan/wanpipe_multppp.c - 1.1
linux/drivers/s390/block/dasd_9343_erp.h - 1.1
linux/drivers/s390/char/ctrlchar.c - 1.1
linux/Documentation/DocBook/deviceiobook.tmpl - 1.1
linux/drivers/s390/char/ctrlchar.h - 1.1
linux/drivers/s390/char/tuball.c - 1.1
linux/drivers/s390/char/tubfs.c - 1.1
linux/drivers/s390/char/tubio.h - 1.1
linux/Documentation/DocBook/tulip-user.tmpl - 1.1
linux/drivers/s390/char/tubtty.c - 1.1
linux/drivers/s390/char/tubttyaid.c - 1.1
linux/net/wanrouter/af_wanpipe.c - 1.1
linux/drivers/s390/char/tubttybld.c - 1.1
linux/drivers/s390/char/tubttyrcl.c - 1.1
linux/drivers/s390/char/tubttyscl.c - 1.1
linux/drivers/s390/char/tubttysiz.c - 1.1
linux/drivers/net/saa9730.h - 1.1
linux/drivers/net/saa9730.c - 1.1
linux/drivers/s390/net/ctctty.c - 1.1
linux/drivers/s390/net/ctctty.h - 1.1
linux/drivers/sbus/char/bbc_envctrl.c - 1.1
linux/drivers/sbus/char/bbc_i2c.c - 1.1
linux/drivers/sbus/char/bbc_i2c.h - 1.1
linux/Documentation/mips/GT64120.README - 1.1
linux/Documentation/mips/time.README - 1.1
linux/drivers/sbus/char/max1617.h - 1.1
linux/drivers/net/gt96100eth.h - 1.1
linux/Documentation/networking/TODO - 1.1
linux/drivers/net/gt96100eth.c - 1.1
linux/drivers/sound/aci.h - 1.1
linux/drivers/sound/cs46xx_wrapper-24.h - 1.1
linux/drivers/sound/cs46xxpm-24.h - 1.1
linux/drivers/sound/cs46xxpm.h - 1.1
linux/drivers/media/radio/rds-miropcm20.c - 1.1
linux/drivers/isdn/hisax/elsa_cs.c - 1.1
linux/Documentation/s390/3270.ChangeLog - 1.1
linux/Documentation/s390/3270.txt - 1.1
linux/Documentation/s390/Debugging390.txt - 1.1
linux/drivers/video/dcfb.c - 1.1
linux/Documentation/s390/config3270.sh - 1.1
linux/Documentation/s390/s390dbf.txt - 1.1
linux/drivers/video/epson1355fb.c - 1.1
linux/drivers/video/maxinefb.c - 1.1
linux/drivers/video/maxinefb.h - 1.1
linux/drivers/video/pmag-ba-fb.c - 1.1
linux/drivers/video/pmag-ba-fb.h - 1.1
linux/drivers/video/pmagb-b-fb.c - 1.1
linux/drivers/video/pmagb-b-fb.h - 1.1
linux/drivers/char/qtronixmap.map - 1.1
linux/drivers/char/qtronix.c - 1.1
linux/drivers/char/joystick/stinger.c - 1.1
linux/drivers/char/joystick/cs461x.c - 1.1
linux/drivers/char/ec3104_keyb.c - 1.1
linux/drivers/block/paride/ppc6lnx.c - 1.1
linux/drivers/block/paride/bpck6.c - 1.1
linux/arch/sparc64/kernel/chmc.c - 1.1
linux/arch/sh/kernel/setup_hd64465.c - 1.1
linux/arch/sh/kernel/setup_ec3104.c - 1.1
linux/arch/sh/kernel/setup_dc.c - 1.1
linux/arch/arm/boot/compressed/head-clps7500.S - 1.1
linux/arch/sh/kernel/pci_st40.h - 1.1
linux/arch/sh/kernel/pci_st40.c - 1.1
linux/fs/nls/nls_cp1251.c - 1.1
linux/fs/nls/nls_cp1255.c - 1.1
linux/fs/nls/nls_iso8859-13.c - 1.1
linux/arch/sh/kernel/mach_ec3104.c - 1.1
linux/arch/sh/kernel/mach_dmida.c - 1.1
linux/arch/sh/kernel/mach_dc.c - 1.1
linux/arch/sh/kernel/mach_cat68701.c - 1.1
linux/arch/sh/kernel/irq_intc2.c - 1.1
linux/fs/nls/nls_koi8-u.c - 1.1
linux/fs/nls/nls_tis-620.c - 1.1
linux/arch/sh/kernel/io_hd64465.c - 1.1
linux/arch/sh/kernel/io_ec3104.c - 1.1
linux/arch/sh/kernel/io_dc.c - 1.1
linux/arch/sh/kernel/io_cat68701.c - 1.1
linux/arch/sh/kernel/hd64465_gpio.c - 1.1
linux/arch/s390x/lib/misaligned.c - 1.1
linux/arch/arm/kernel/io.c - 1.1
linux/arch/arm/kernel/irq-arch.c - 1.1
linux/arch/s390/math-emu/sfp-util.h - 1.1
linux/arch/s390/math-emu/qrnnd.S - 1.1
linux/arch/s390/math-emu/math.c - 1.1
linux/arch/s390/math-emu/Makefile - 1.1
linux/arch/s390/lib/misaligned.c - 1.1
linux/include/asm-arm/arch-l7200/aux_reg.h - 1.1
linux/include/asm-arm/arch-l7200/gp_timers.h - 1.1
linux/include/asm-arm/arch-l7200/gpio.h - 1.1
linux/include/asm-arm/arch-l7200/keyboard.h - 1.1
linux/include/asm-arm/arch-l7200/pmpcon.h - 1.1
linux/include/asm-arm/arch-l7200/pmu.h - 1.1
linux/include/asm-arm/arch-l7200/serial.h - 1.1
linux/arch/arm/mach-ebsa110/Makefile - 1.1
linux/arch/arm/mach-ebsa110/arch.c - 1.1
linux/arch/arm/mach-ebsa110/io.c - 1.1
linux/arch/arm/mach-ebsa110/irq.c - 1.1
linux/arch/arm/mach-ebsa110/leds.c - 1.1
linux/arch/arm/mach-ebsa110/mm.c - 1.1
linux/arch/arm/mach-ebsa110/time.c - 1.1
linux/include/asm-arm/arch-l7200/sib.h - 1.1
linux/include/asm-arm/arch-l7200/sys-clock.h - 1.1
linux/arch/arm/mach-footbridge/irq.c - 1.1
linux/arch/arm/mach-footbridge/mm.c - 1.1
linux/include/asm-arm/arch-sa1100/pcmcia.h - 1.1
linux/include/asm-arm/hardware/clps7111.h - 1.1
linux/arch/arm/mach-sa1100/dma-sa1100.c - 1.1
linux/arch/arm/mach-sa1100/dma-sa1111.c - 1.1
linux/arch/arm/mach-sa1100/dma.h - 1.1
linux/include/asm-arm/hardware/ep7212.h - 1.1
linux/include/asm-arm/proc-armo/pgalloc.h - 1.1
linux/include/asm-arm/proc-armv/pgalloc.h - 1.1
linux/arch/arm/mach-shark/leds.c - 1.1
linux/include/asm-cris/etraxgpio.h - 1.1
linux/include/asm-cris/etraxi2c.h - 1.1
linux/include/asm-cris/sync_serial.h - 1.1
linux/include/asm-i386/rwsem.h - 1.1
linux/include/asm-ia64/kregs.h - 1.1
linux/include/asm-ia64/perfmon.h - 1.1
linux/include/asm-ia64/sn/pci/pciba.h - 1.1
linux/include/asm-ia64/sn/sn_sal.h - 1.1
linux/include/asm-ia64/sn/sv.h - 1.1
linux/include/asm-ia64/ucontext.h - 1.1
linux/arch/mips/mips-boards/malta/malta_setup.c - 1.1
linux/arch/mips/mips-boards/malta/malta_rtc.c - 1.1
linux/arch/mips/mips-boards/malta/malta_int.c - 1.1
linux/arch/mips/mips-boards/malta/Makefile - 1.1
linux/arch/mips/mips-boards/generic/time.c - 1.1
linux/arch/mips/mips-boards/generic/reset.c - 1.1
linux/arch/mips/mips-boards/generic/printf.c - 1.1
linux/arch/mips/mips-boards/generic/pci.c - 1.1
linux/arch/mips/mips-boards/generic/mipsIRQ.S - 1.1
linux/arch/mips/mips-boards/generic/memory.c - 1.1
linux/arch/mips/mips-boards/generic/init.c - 1.1
linux/net/ipv4/netfilter/ip_nat_helper.c - 1.1
linux/arch/mips/mips-boards/generic/gdb_hook.c - 1.1
linux/arch/mips/mips-boards/generic/display.c - 1.1
linux/arch/mips/mips-boards/generic/cmdline.c - 1.1
linux/arch/mips/mips-boards/generic/Makefile - 1.1
linux/arch/mips/mips-boards/atlas/atlas_setup.c - 1.1
linux/arch/mips/mips-boards/atlas/atlas_rtc.c - 1.1
linux/arch/mips/mips-boards/atlas/atlas_int.c - 1.1
linux/arch/mips/mips-boards/atlas/Makefile - 1.1
linux/arch/mips/math-emu/sp_tlong.c - 1.1
linux/arch/mips/math-emu/sp_sub.c - 1.1
linux/arch/mips/math-emu/sp_sqrt.c - 1.1
linux/arch/mips/math-emu/sp_simple.c - 1.1
linux/arch/mips/math-emu/sp_scalb.c - 1.1
linux/arch/mips/math-emu/sp_mul.c - 1.1
linux/arch/mips/math-emu/sp_modf.c - 1.1
linux/arch/mips/math-emu/sp_logb.c - 1.1
linux/arch/cris/boot/rescue/Makefile - 1.1
linux/arch/cris/boot/rescue/head.S - 1.1
linux/arch/cris/boot/rescue/kimagerescue.S - 1.1
linux/arch/cris/boot/rescue/rescue.ld - 1.1
linux/arch/cris/boot/rescue/testrescue.S - 1.1
linux/arch/cris/boot/tools/build.c - 1.1
linux/arch/mips/math-emu/sp_frexp.c - 1.1
linux/arch/mips/math-emu/sp_flong.c - 1.1
linux/arch/mips/math-emu/sp_fint.c - 1.1
linux/arch/mips/math-emu/sp_fdp.c - 1.1
linux/arch/mips/math-emu/sp_div.c - 1.1
linux/arch/mips/math-emu/sp_cmp.c - 1.1
linux/arch/mips/math-emu/sp_add.c - 1.1
linux/arch/cris/drivers/examples/kiobuftest.c - 1.1
linux/arch/cris/drivers/gpio.c - 1.1
linux/arch/cris/drivers/i2c.c - 1.1
linux/arch/cris/drivers/i2c.h - 1.1
linux/arch/mips/math-emu/kernel_linkage.c - 1.1
linux/arch/mips/math-emu/ieee754xcpt.c - 1.1
linux/arch/mips/math-emu/ieee754sp.h - 1.1
linux/arch/cris/drivers/sync_serial.c - 1.1
linux/arch/cris/drivers/usb-host.c - 1.1
linux/arch/cris/drivers/usb-host.h - 1.1
linux/arch/mips/math-emu/ieee754sp.c - 1.1
linux/arch/mips/math-emu/ieee754m.c - 1.1
linux/arch/mips/math-emu/ieee754int.h - 1.1
linux/arch/mips/math-emu/ieee754dp.h - 1.1
linux/arch/mips/math-emu/ieee754dp.c - 1.1
linux/arch/mips/math-emu/ieee754d.c - 1.1
linux/arch/mips/math-emu/ieee754.h - 1.1
linux/arch/mips/math-emu/ieee754.c - 1.1
linux/arch/mips/math-emu/dp_tlong.c - 1.1
linux/arch/mips/math-emu/dp_tint.c - 1.1
linux/arch/mips/math-emu/dp_sub.c - 1.1
linux/arch/mips/math-emu/dp_sqrt.c - 1.1
linux/arch/cris/lib/dram_init.S - 1.1
linux/arch/mips/math-emu/dp_simple.c - 1.1
linux/lib/rwsem.c - 1.1
linux/lib/rwsem-spinlock.c - 1.1
linux/arch/cris/mm/ioremap.c - 1.1
linux/arch/mips/math-emu/dp_scalb.c - 1.1
linux/arch/mips/math-emu/dp_mul.c - 1.1
linux/arch/mips/math-emu/dp_modf.c - 1.1
linux/arch/mips/math-emu/dp_logb.c - 1.1
linux/arch/mips/math-emu/dp_fsp.c - 1.1
linux/arch/mips/math-emu/dp_frexp.c - 1.1
linux/arch/mips/math-emu/dp_flong.c - 1.1
linux/arch/mips/math-emu/dp_fint.c - 1.1
linux/arch/mips/math-emu/dp_div.c - 1.1
linux/arch/mips/math-emu/dp_cmp.c - 1.1
linux/arch/mips/math-emu/dp_add.c - 1.1
linux/arch/mips/math-emu/cp1emu.c - 1.1
linux/arch/mips/math-emu/Makefile - 1.1
linux/arch/mips/ite-boards/qed-4n-s01b/pci_fixup.c - 1.1
linux/arch/mips/ite-boards/qed-4n-s01b/init.c - 1.1
linux/arch/mips/ite-boards/qed-4n-s01b/README - 1.1
linux/arch/i386/lib/strstr.c - 1.1
linux/arch/mips/ite-boards/qed-4n-s01b/Makefile - 1.1
linux/arch/mips/ite-boards/generic/time.c - 1.1
linux/arch/mips/ite-boards/generic/reset.c - 1.1
linux/arch/mips/ite-boards/generic/puts.c - 1.1
linux/arch/mips/ite-boards/generic/pmon_prom.c - 1.1
linux/arch/mips/ite-boards/generic/lpc.c - 1.1
linux/arch/mips/ite-boards/generic/it8172_setup.c - 1.1
linux/arch/mips/ite-boards/generic/it8172_rtc.c - 1.1
linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.1
linux/arch/mips/ite-boards/generic/it8172_cir.c - 1.1
linux/arch/mips/ite-boards/generic/irq.c - 1.1
linux/arch/mips/ite-boards/generic/int-handler.S - 1.1
linux/arch/mips/ite-boards/generic/dbg_io.c - 1.1
linux/arch/mips/ite-boards/generic/Makefile - 1.1
linux/arch/mips/defconfig-it8172 - 1.1
linux/include/asm-mips/it8172/it8172.h - 1.1
linux/include/asm-mips/it8172/it8172_cir.h - 1.1
linux/arch/mips/defconfig-ddb5476 - 1.1
linux/include/asm-mips/it8172/it8172_dbg.h - 1.1
linux/include/asm-mips/it8172/it8172_int.h - 1.1
linux/include/asm-mips/it8172/it8172_lpc.h - 1.1
linux/arch/mips/ddb5476/time.c - 1.1
linux/arch/mips/ddb5476/setup.c - 1.1
linux/arch/mips/ddb5476/prom.c - 1.1
linux/arch/mips/ddb5476/pci.c - 1.1
linux/arch/mips/ddb5476/nile4.c - 1.1
linux/arch/mips/ddb5476/irq.c - 1.1
linux/arch/mips/ddb5476/int-handler.S - 1.1
linux/arch/mips/ddb5476/dbg_io.c - 1.1
linux/arch/mips/ddb5476/Makefile - 1.1
linux/include/asm-mips/it8172/it8172_pci.h - 1.1
linux/include/asm-mips/it8712.h - 1.1
linux/include/asm-s390/cpcmd.h - 1.1
linux/include/asm-s390/sfp-machine.h - 1.1
linux/include/asm-s390/vtoc.h - 1.1
linux/include/asm-s390x/cpcmd.h - 1.1
linux/include/asm-s390x/vtoc.h - 1.1
linux/include/asm-sh/ec3104.h - 1.1
linux/include/asm-sh/hd64465.h - 1.1
linux/include/asm-sh/hd64465_gpio.h - 1.1
linux/include/asm-sh/io_cat68701.h - 1.1
linux/arch/mips/arc/arc_con.c - 1.1
linux/include/asm-sh/io_dc.h - 1.1
linux/include/asm-sh/io_ec3104.h - 1.1
linux/include/asm-sh/io_hd64465.h - 1.1
linux/arch/ia64/kernel/efivars.c - 1.1
linux/include/asm-sh/keyboard-ec3104.h - 1.1
linux/include/asm-sh/serial-ec3104.h - 1.1
linux/arch/ia64/sn/sn1/sv.c - 1.1
linux/arch/ia64/sn/sn1/sn1_ksyms.c - 1.1
linux/include/asm-sparc64/chafsr.h - 1.1
linux/arch/ia64/sn/sn1/probe.c - 1.1
linux/include/asm-sparc64/chmctrl.h - 1.1
linux/include/asm-sparc64/estate.h - 1.1
linux/arch/ia64/sn/sn1/error.c - 1.1
linux/include/asm-sparc64/rwsem.h - 1.1
linux/arch/ia64/sn/io/pciba.c - 1.1
linux/include/linux/compiler.h - 1.1
linux/arch/ia64/sn/io/huberror.c - 1.1
linux/include/linux/if_wanpipe.h - 1.1
linux/include/linux/if_wanpipe_common.h - 1.1
linux/include/linux/netfilter_ipv4/ip_conntrack_icmp.h - 1.1
linux/include/linux/rwsem-spinlock.h - 1.1
linux/include/linux/rwsem.h - 1.1
linux/include/linux/sdla_asy.h - 1.1
linux/scripts/ver_linux - 1.8
linux/scripts/tkgen.c - 1.7
linux/scripts/lxdialog/checklist.c - 1.4
linux/net/x25/x25_out.c - 1.6
linux/net/x25/af_x25.c - 1.20
linux/net/wanrouter/wanproc.c - 1.13
linux/net/wanrouter/wanmain.c - 1.10
linux/net/wanrouter/patchlevel - 1.3
linux/net/wanrouter/Makefile - 1.4
linux/net/unix/af_unix.c - 1.28
linux/net/sysctl_net.c - 1.7
linux/net/sunrpc/xprt.c - 1.16
linux/net/sunrpc/sysctl.c - 1.8
linux/net/sunrpc/svcsock.c - 1.14
linux/net/sunrpc/sched.c - 1.17
linux/net/sunrpc/clnt.c - 1.12
linux/net/socket.c - 1.21
linux/net/rose/rose_dev.c - 1.7
linux/net/rose/af_rose.c - 1.18
linux/net/packet/af_packet.c - 1.22
linux/net/netsyms.c - 1.31
linux/net/netrom/nr_out.c - 1.4
linux/net/netrom/nr_dev.c - 1.7
linux/net/netrom/af_netrom.c - 1.17
linux/net/netlink/af_netlink.c - 1.13
linux/net/lapb/lapb_iface.c - 1.8
linux/net/irda/irda_device.c - 1.18
linux/net/irda/af_irda.c - 1.19
linux/net/ipx/sysctl_net_ipx.c - 1.4
linux/net/ipx/af_spx.c - 1.11
linux/net/ipx/af_ipx.c - 1.19
linux/net/ipv6/udp.c - 1.20
linux/net/ipv6/tcp_ipv6.c - 1.23
linux/net/ipv6/sit.c - 1.14
linux/net/ipv6/route.c - 1.16
linux/net/ipv6/reassembly.c - 1.10
linux/net/ipv6/raw.c - 1.17
linux/net/ipv6/ndisc.c - 1.12
linux/net/ipv6/mcast.c - 1.14
linux/net/ipv6/ip6_output.c - 1.9
linux/net/ipv6/ip6_input.c - 1.9
linux/net/ipv6/icmp.c - 1.10
linux/net/ipv6/exthdrs.c - 1.4
linux/net/ipv6/datagram.c - 1.7
linux/net/ipv6/af_inet6.c - 1.16
linux/net/ipv6/addrconf.c - 1.15
linux/net/ipv4/udp.c - 1.23
linux/net/ipv4/tcp_timer.c - 1.18
linux/net/ipv4/tcp_output.c - 1.17
linux/net/ipv4/tcp_ipv4.c - 1.32
linux/net/ipv4/tcp_input.c - 1.24
linux/net/ipv4/tcp.c - 1.26
linux/net/ipv4/syncookies.c - 1.9
linux/net/ipv4/route.c - 1.21
linux/net/ipv4/raw.c - 1.17
linux/net/ipv4/ipmr.c - 1.15
linux/net/ipv4/ipip.c - 1.15
linux/net/ipv4/ip_sockglue.c - 1.13
linux/net/ipv4/ip_output.c - 1.20
linux/net/ipv4/ip_nat_dumb.c - 1.5
linux/net/ipv4/ip_input.c - 1.12
linux/net/ipv4/ip_gre.c - 1.15
linux/net/ipv4/ip_fragment.c - 1.13
linux/net/ipv4/ip_forward.c - 1.7
linux/net/ipv4/igmp.c - 1.13
linux/net/ipv4/icmp.c - 1.16
linux/net/ipv4/arp.c - 1.17
linux/net/ipv4/af_inet.c - 1.24
linux/net/econet/Makefile - 1.6
linux/net/core/sock.c - 1.19
linux/net/core/skbuff.c - 1.19
linux/net/core/iovec.c - 1.7
linux/net/core/filter.c - 1.7
linux/net/core/dev.c - 1.32
linux/net/core/datagram.c - 1.10
linux/net/ax25/af_ax25.c - 1.19
linux/net/appletalk/ddp.c - 1.16
linux/net/802/transit/pdutr.pre - 1.3
linux/net/802/pseudo/pseudocode - 1.3
linux/net/802/llc_sendpdu.c - 1.4
linux/net/802/cl2llc.pre - 1.3
linux/net/802/cl2llc.c - 1.4
linux/net/802/TODO - 1.3
linux/mm/vmscan.c - 1.53
linux/mm/swapfile.c - 1.30
linux/mm/swap_state.c - 1.23
linux/mm/page_io.c - 1.15
linux/mm/page_alloc.c - 1.40
linux/mm/mremap.c - 1.22
linux/mm/mmap.c - 1.35
linux/mm/memory.c - 1.47
linux/mm/filemap.c - 1.73
linux/lib/vsprintf.c - 1.10
linux/lib/string.c - 1.13
linux/lib/Makefile - 1.6
linux/kernel/sysctl.c - 1.37
linux/kernel/sys.c - 1.20
linux/kernel/sched.c - 1.34
linux/kernel/ksyms.c - 1.87
linux/kernel/info.c - 1.6
linux/kernel/fork.c - 1.31
linux/init/main.c - 1.52
linux/include/scsi/scsi.h - 1.5
linux/include/net/udp.h - 1.6
linux/include/net/tcp.h - 1.22
linux/include/net/sock.h - 1.22
linux/include/net/rawv6.h - 1.4
linux/include/net/raw.h - 1.4
linux/include/net/protocol.h - 1.5
linux/include/net/ndisc.h - 1.6
linux/include/net/ipv6.h - 1.9
linux/include/net/ipip.h - 1.5
linux/include/net/ip.h - 1.15
linux/include/net/icmp.h - 1.6
linux/include/net/addrconf.h - 1.6
linux/include/linux/wireless.h - 1.6
linux/include/linux/wavefront.h - 1.3
linux/include/linux/wanrouter.h - 1.9
linux/include/linux/wanpipe.h - 1.6
linux/include/linux/videodev.h - 1.14
linux/include/linux/tty_ldisc.h - 1.3
linux/include/linux/tpqic02.h - 1.4
linux/include/linux/tcp.h - 1.7
linux/include/linux/sysctl.h - 1.32
linux/include/linux/swap.h - 1.25
linux/include/linux/sunrpc/sched.h - 1.8
linux/include/linux/string.h - 1.9
linux/include/linux/socket.h - 1.8
linux/include/linux/skbuff.h - 1.18
linux/include/linux/serialP.h - 1.13
linux/include/linux/sdladrv.h - 1.4
linux/include/linux/sdla_x25.h - 1.3
linux/include/linux/sdla_ppp.h - 1.4
linux/include/linux/sdla_fr.h - 1.4
linux/include/linux/sched.h - 1.39
linux/include/linux/scc.h - 1.5
linux/include/linux/proc_fs.h - 1.28
linux/include/linux/pipe_fs_i.h - 1.7
linux/include/linux/pci.h - 1.41
linux/include/linux/pagemap.h - 1.25
linux/include/linux/ntfs_fs_sb.h - 1.6
linux/include/linux/ntfs_fs_i.h - 1.5
linux/include/linux/nfs_fs.h - 1.14
linux/include/linux/netdevice.h - 1.22
linux/include/linux/net.h - 1.8
linux/include/linux/nbd.h - 1.7
linux/include/linux/mroute.h - 1.5
linux/include/linux/mm.h - 1.52
linux/include/linux/miscdevice.h - 1.10
linux/include/linux/major.h - 1.26
linux/include/linux/kernel.h - 1.16
linux/include/linux/joystick.h - 1.8
linux/include/linux/isdnif.h - 1.9
linux/include/linux/isdn_ppp.h - 1.8
linux/include/linux/isdn.h - 1.15
linux/include/linux/igmp.h - 1.5
linux/include/linux/if_ppp.h - 1.6
linux/include/linux/if_packet.h - 1.5
linux/include/linux/if_ether.h - 1.8
linux/include/linux/if_ec.h - 1.4
linux/include/linux/if_arp.h - 1.9
linux/include/linux/icmpv6.h - 1.4
linux/include/linux/icmp.h - 1.5
linux/include/linux/fs.h - 1.91
linux/include/linux/filter.h - 1.4
linux/include/linux/etherdevice.h - 1.7
linux/include/linux/elf.h - 1.13
linux/include/linux/dcache.h - 1.17
linux/include/linux/coff.h - 1.3
linux/include/linux/coda_psdev.h - 1.7
linux/include/linux/coda_proc.h - 1.6
linux/include/linux/coda_linux.h - 1.11
linux/include/linux/coda_fs_i.h - 1.6
linux/include/linux/coda.h - 1.8
linux/include/linux/cdrom.h - 1.18
linux/include/linux/blkdev.h - 1.31
linux/include/linux/blk.h - 1.20
linux/include/linux/apm_bios.h - 1.9
linux/include/linux/amigaffs.h - 1.3
linux/include/linux/affs_fs_sb.h - 1.3
linux/include/linux/affs_fs_i.h - 1.4
linux/include/linux/affs_fs.h - 1.8
linux/include/asm-sparc64/visasm.h - 1.3
linux/include/asm-sparc64/ttable.h - 1.7
linux/include/asm-sparc64/system.h - 1.12
linux/include/asm-sparc64/spitfire.h - 1.5
linux/include/asm-sparc64/spinlock.h - 1.9
linux/include/asm-sparc64/smp.h - 1.11
linux/include/asm-sparc64/semaphore.h - 1.7
linux/include/asm-sparc64/processor.h - 1.17
linux/include/asm-sparc64/pgtable.h - 1.19
linux/include/asm-sparc64/perfctr.h - 1.3
linux/include/asm-sparc64/elf.h - 1.8
linux/include/asm-sparc64/delay.h - 1.7
linux/include/asm-sparc64/checksum.h - 1.7
linux/include/asm-sparc64/bitops.h - 1.8
linux/include/asm-sparc64/asi.h - 1.4
linux/include/asm-sparc64/a.out.h - 1.4
linux/include/asm-sparc/semaphore.h - 1.7
linux/include/asm-sparc/processor.h - 1.13
linux/include/asm-sparc/perfctr.h - 1.3
linux/include/asm-ppc/semaphore.h - 1.7
linux/include/asm-mips/shmiq.h - 1.3
linux/include/asm-mips/semaphore.h - 1.7
linux/include/asm-mips/processor.h - 1.14
linux/include/asm-mips/pci.h - 1.8
linux/include/asm-mips/mipsregs.h - 1.7
linux/include/asm-mips/keyboard.h - 1.7
linux/include/asm-mips/bootinfo.h - 1.8
linux/include/asm-m68k/serial.h - 1.4
linux/include/asm-m68k/semaphore.h - 1.7
linux/include/asm-m68k/bootinfo.h - 1.4
linux/include/asm-i386/uaccess.h - 1.9
linux/include/asm-i386/string.h - 1.10
linux/include/asm-i386/semaphore.h - 1.14
linux/include/asm-i386/io.h - 1.14
linux/include/asm-i386/bitops.h - 1.7
linux/include/asm-i386/atomic.h - 1.11
linux/include/asm-arm/unistd.h - 1.16
linux/include/asm-arm/setup.h - 1.9
linux/include/asm-arm/semaphore.h - 1.7
linux/include/asm-arm/procinfo.h - 1.7
linux/include/asm-arm/processor.h - 1.16
linux/include/asm-arm/proc-armv/uaccess.h - 1.8
linux/include/asm-arm/proc-armv/pgtable.h - 1.12
linux/include/asm-arm/proc-armo/ptrace.h - 1.5
linux/include/asm-arm/proc-armo/pgtable.h - 1.8
linux/include/asm-arm/pgtable.h - 1.18
linux/include/asm-arm/io.h - 1.14
linux/include/asm-arm/elf.h - 1.5
linux/include/asm-arm/byteorder.h - 1.4
linux/include/asm-arm/arch-rpc/system.h - 1.11
linux/include/asm-arm/arch-rpc/irq.h - 1.6
linux/include/asm-arm/arch-rpc/hardware.h - 1.9
linux/include/asm-arm/arch-ebsa285/irq.h - 1.14
linux/include/asm-arm/arch-ebsa110/uncompress.h - 1.4
linux/include/asm-arm/arch-ebsa110/time.h - 1.7
linux/include/asm-arm/arch-ebsa110/memory.h - 1.7
linux/include/asm-arm/arch-ebsa110/irq.h - 1.4
linux/include/asm-arm/arch-ebsa110/io.h - 1.7
linux/include/asm-arm/arch-ebsa110/hardware.h - 1.9
linux/include/asm-arm/arch-arc/system.h - 1.10
linux/include/asm-arm/arch-arc/irq.h - 1.6
linux/include/asm-arm/arch-arc/hardware.h - 1.8
linux/include/asm-alpha/semaphore.h - 1.7
linux/include/asm-alpha/pgtable.h - 1.25
linux/include/asm-alpha/ioctls.h - 1.4
linux/include/asm-alpha/io.h - 1.14
linux/include/asm-alpha/compiler.h - 1.7
linux/fs/vfat/namei.c - 1.19
linux/fs/umsdos/ioctl.c - 1.7
linux/fs/ufs/super.c - 1.17
linux/fs/sysv/inode.c - 1.19
linux/fs/super.c - 1.45
linux/fs/stat.c - 1.20
linux/fs/smbfs/proc.c - 1.9
linux/fs/smbfs/ioctl.c - 1.6
linux/fs/smbfs/inode.c - 1.20
linux/fs/romfs/inode.c - 1.22
linux/fs/qnx4/inode.c - 1.23
linux/fs/proc/inode.c - 1.14
linux/fs/proc/array.c - 1.27
linux/fs/ntfs/util.h - 1.3
linux/fs/ntfs/util.c - 1.4
linux/fs/ntfs/sysctl.h - 1.3
linux/fs/ntfs/support.h - 1.3
linux/fs/ntfs/support.c - 1.5
linux/fs/ntfs/super.h - 1.4
linux/fs/ntfs/super.c - 1.8
linux/fs/ntfs/struct.h - 1.4
linux/fs/ntfs/ntfstypes.h - 1.4
linux/fs/ntfs/ntfsendian.h - 1.3
linux/fs/ntfs/macros.h - 1.3
linux/fs/ntfs/inode.h - 1.3
linux/fs/ntfs/inode.c - 1.7
linux/fs/ntfs/fs.c - 1.25
linux/fs/ntfs/dir.h - 1.3
linux/fs/ntfs/dir.c - 1.3
linux/fs/ntfs/attr.h - 1.3
linux/fs/ntfs/attr.c - 1.3
linux/fs/ntfs/Makefile - 1.7
linux/fs/nls/nls_iso8859-8.c - 1.6
linux/fs/nls/Makefile - 1.7
linux/fs/nls/Config.in - 1.7
linux/fs/nfsd/nfs3proc.c - 1.8
linux/fs/nfs/write.c - 1.25
linux/fs/nfs/read.c - 1.22
linux/fs/nfs/inode.c - 1.24
linux/fs/ncpfs/inode.c - 1.20
linux/fs/namei.c - 1.28
linux/fs/msdos/namei.c - 1.17
linux/fs/minix/inode.c - 1.21
linux/fs/isofs/inode.c - 1.23
linux/fs/inode.c - 1.39
linux/fs/hfs/super.c - 1.9
linux/fs/filesystems.c - 1.18
linux/fs/file_table.c - 1.14
linux/fs/fat/inode.c - 1.21
linux/fs/fat/fatfs_syms.c - 1.9
linux/fs/fat/dir.c - 1.11
linux/fs/fat/Makefile - 1.5
linux/fs/ext2/super.c - 1.16
linux/fs/ext2/inode.c - 1.26
linux/fs/exec.c - 1.41
linux/fs/devpts/inode.c - 1.10
linux/fs/dcache.c - 1.23
linux/fs/coda/upcall.c - 1.11
linux/fs/coda/sysctl.c - 1.12
linux/fs/coda/symlink.c - 1.12
linux/fs/coda/psdev.c - 1.15
linux/fs/coda/inode.c - 1.13
linux/fs/coda/file.c - 1.13
linux/fs/coda/dir.c - 1.19
linux/fs/coda/coda_linux.c - 1.6
linux/fs/coda/cnode.c - 1.11
linux/fs/coda/cache.c - 1.8
linux/fs/buffer.c - 1.61
linux/fs/binfmt_elf.c - 1.26
linux/fs/affs/symlink.c - 1.12
linux/fs/affs/super.c - 1.10
linux/fs/affs/namei.c - 1.11
linux/fs/affs/inode.c - 1.12
linux/fs/affs/file.c - 1.15
linux/fs/affs/dir.c - 1.9
linux/fs/affs/bitmap.c - 1.5
linux/fs/affs/amigaffs.c - 1.4
linux/fs/affs/Makefile - 1.4
linux/fs/affs/Changes - 1.4
linux/fs/adfs/super.c - 1.11
linux/fs/Config.in - 1.56
linux/drivers/video/vesafb.c - 1.14
linux/drivers/video/sbusfb.c - 1.17
linux/drivers/video/imsttfb.c - 1.12
linux/drivers/video/fbmem.c - 1.36
linux/drivers/video/atyfb.c - 1.28
linux/drivers/video/atafb.c - 1.11
linux/drivers/video/amifb.c - 1.16
linux/drivers/video/acornfb.c - 1.16
linux/drivers/video/Makefile - 1.30
linux/drivers/video/Config.in - 1.25
linux/drivers/usb/usb.c - 1.47
linux/drivers/usb/uhci.h - 1.23
linux/drivers/usb/uhci.c - 1.42
linux/drivers/usb/hub.h - 1.14
linux/drivers/usb/hub.c - 1.35
linux/drivers/sound/waveartist.c - 1.13
linux/drivers/sound/vidc.c - 1.10
linux/drivers/sound/sound_core.c - 1.17
linux/drivers/sound/sonicvibes.c - 1.31
linux/drivers/sound/sb_common.c - 1.17
linux/drivers/sound/mad16.c - 1.13
linux/drivers/sound/es1371.c - 1.31
linux/drivers/sound/es1370.c - 1.30
linux/drivers/sound/Makefile - 1.28
linux/drivers/sound/Config.in - 1.23
linux/drivers/sgi/char/Makefile - 1.4
linux/drivers/sgi/Makefile - 1.5
linux/drivers/scsi/wd7000.c - 1.11
linux/drivers/scsi/tmscsim.h - 1.6
linux/drivers/scsi/tmscsim.c - 1.12
linux/drivers/scsi/sym53c8xx.c - 1.23
linux/drivers/scsi/scsi_ioctl.c - 1.17
linux/drivers/scsi/scsi.c - 1.34
linux/drivers/scsi/qlogicisp.c - 1.20
linux/drivers/scsi/qlogicfc.c - 1.17
linux/drivers/scsi/qlogicfas.h - 1.3
linux/drivers/scsi/qlogicfas.c - 1.7
linux/drivers/scsi/pci2220i.c - 1.17
linux/drivers/scsi/pci2000.c - 1.15
linux/drivers/scsi/ncr53c8xx.c - 1.20
linux/drivers/scsi/megaraid.h - 1.9
linux/drivers/scsi/megaraid.c - 1.22
linux/drivers/scsi/ini9100u.h - 1.8
linux/drivers/scsi/hosts.h - 1.16
linux/drivers/scsi/gdth.c - 1.11
linux/drivers/scsi/fdomain.c - 1.13
linux/drivers/scsi/fastlane.c - 1.8
linux/drivers/scsi/atp870u.c - 1.12
linux/drivers/scsi/advansys.h - 1.5
linux/drivers/scsi/advansys.c - 1.17
linux/drivers/scsi/AM53C974.c - 1.11
linux/drivers/scsi/53c7xx.scr - 1.3
linux/drivers/scsi/53c7xx.c - 1.12
linux/drivers/scsi/53c7,8xx.h - 1.5
linux/drivers/scsi/53c7,8xx.c - 1.13
linux/drivers/sbus/char/zs.c - 1.15
linux/drivers/sbus/char/sunserial.c - 1.8
linux/drivers/sbus/char/su.c - 1.15
linux/drivers/sbus/char/sab82532.c - 1.17
linux/drivers/sbus/char/Makefile - 1.10
linux/drivers/pci/quirks.c - 1.19
linux/drivers/pci/pci.c - 1.35
linux/drivers/pci/Makefile - 1.14
linux/drivers/net/znet.c - 1.8
linux/drivers/net/zlib.c - 1.5
linux/drivers/net/yellowfin.c - 1.20
linux/drivers/net/wd.c - 1.12
linux/drivers/net/wavelan.c - 1.20
linux/drivers/net/via-rhine.c - 1.23
linux/drivers/net/tlan.c - 1.19
linux/drivers/net/sunqe.c - 1.17
linux/drivers/net/sunlance.c - 1.22
linux/drivers/net/sunhme.h - 1.9
linux/drivers/net/sunhme.c - 1.24
linux/drivers/net/sunbmac.c - 1.18
linux/drivers/net/smc9194.c - 1.13
linux/drivers/net/smc-ultra.c - 1.15
linux/drivers/net/slip.c - 1.15
linux/drivers/net/sk_g16.c - 1.11
linux/drivers/net/shaper.c - 1.16
linux/drivers/net/sgiseeq.c - 1.11
linux/drivers/net/seeq8005.c - 1.12
linux/drivers/net/rrunner.c - 1.15
linux/drivers/net/rcpci45.c - 1.18
linux/drivers/net/ptifddi.c - 1.8
linux/drivers/net/plip.c - 1.18
linux/drivers/net/pcnet32.c - 1.23
linux/drivers/net/ni65.c - 1.9
linux/drivers/net/ni52.c - 1.12
linux/drivers/net/ni5010.c - 1.12
linux/drivers/net/net_init.c - 1.18
linux/drivers/net/ne2k-pci.c - 1.20
linux/drivers/net/ne.c - 1.16
linux/drivers/net/myri_sbus.c - 1.12
linux/drivers/net/mace.c - 1.12
linux/drivers/net/loopback.c - 1.8
linux/drivers/net/lance.c - 1.18
linux/drivers/net/hydra.c - 1.13
linux/drivers/net/hplance.c - 1.9
linux/drivers/net/hp.c - 1.11
linux/drivers/net/hp-plus.c - 1.12
linux/drivers/net/hamradio/soundmodem/sm.c - 1.13
linux/drivers/net/hamradio/scc.c - 1.17
linux/drivers/net/hamradio/mkiss.c - 1.11
linux/drivers/net/hamradio/hdlcdrv.c - 1.13
linux/drivers/net/hamradio/dmascc.c - 1.9
linux/drivers/net/hamradio/bpqether.c - 1.15
linux/drivers/net/hamradio/baycom_ser_hdx.c - 1.13
linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.13
linux/drivers/net/hamradio/baycom_par.c - 1.13
linux/drivers/net/hamradio/baycom_epp.c - 1.15
linux/drivers/net/hamradio/6pack.c - 1.11
linux/drivers/net/fmv18x.c - 1.13
linux/drivers/net/ewrk3.c - 1.15
linux/drivers/net/ethertap.c - 1.9
linux/drivers/net/eth16i.c - 1.16
linux/drivers/net/es3210.c - 1.13
linux/drivers/net/eql.c - 1.11
linux/drivers/net/epic100.c - 1.19
linux/drivers/net/eepro.c - 1.18
linux/drivers/net/e2100.c - 1.12
linux/drivers/net/dgrs.c - 1.15
linux/drivers/net/depca.c - 1.14
linux/drivers/net/defxx.c - 1.15
linux/drivers/net/de620.c - 1.10
linux/drivers/net/de600.c - 1.11
linux/drivers/net/de4x5.c - 1.20
linux/drivers/net/daynaport.c - 1.10
linux/drivers/net/cs89x0.c - 1.17
linux/drivers/net/atp.c - 1.14
linux/drivers/net/atarilance.c - 1.8
linux/drivers/net/atari_pamsnet.c - 1.9
linux/drivers/net/atari_bionet.c - 1.9
linux/drivers/net/ariadne2.c - 1.11
linux/drivers/net/ariadne.c - 1.12
linux/drivers/net/apne.c - 1.9
linux/drivers/net/am79c961a.c - 1.11
linux/drivers/net/acenic.h - 1.12
linux/drivers/net/acenic.c - 1.25
linux/drivers/net/ac3200.c - 1.13
linux/drivers/net/a2065.c - 1.13
linux/drivers/net/Space.c - 1.30
linux/drivers/net/Makefile - 1.41
linux/drivers/net/Config.in - 1.37
linux/drivers/net/8390.h - 1.9
linux/drivers/net/8390.c - 1.20
linux/drivers/net/82596.c - 1.16
linux/drivers/net/3c59x.c - 1.25
linux/drivers/net/3c527.c - 1.17
linux/drivers/net/3c523.c - 1.14
linux/drivers/net/3c515.c - 1.17
linux/drivers/net/3c509.c - 1.20
linux/drivers/net/3c507.c - 1.17
linux/drivers/net/3c505.c - 1.18
linux/drivers/net/3c503.c - 1.16
linux/drivers/net/3c501.c - 1.12
linux/drivers/isdn/sc/message.c - 1.4
linux/drivers/isdn/sc/interrupt.c - 1.4
linux/drivers/isdn/pcbit/drv.c - 1.12
linux/drivers/isdn/isdn_ppp.c - 1.13
linux/drivers/isdn/isdn_net.h - 1.7
linux/drivers/isdn/isdn_net.c - 1.18
linux/drivers/isdn/isdn_common.c - 1.23
linux/drivers/isdn/icn/icn.h - 1.7
linux/drivers/isdn/icn/icn.c - 1.11
linux/drivers/isdn/hisax/hisax.h - 1.16
linux/drivers/isdn/hisax/config.c - 1.17
linux/drivers/isdn/hisax/Makefile - 1.11
linux/drivers/isdn/avmb1/capidrv.c - 1.16
linux/drivers/isdn/avmb1/capi.c - 1.20
linux/drivers/isdn/avmb1/b1pci.c - 1.12
linux/drivers/isdn/Config.in - 1.16
linux/drivers/char/tty_io.c - 1.29
linux/drivers/char/synclink.c - 1.14
linux/drivers/char/serial.c - 1.38
linux/drivers/char/qpmouse.c - 1.10
linux/drivers/char/pcwd.c - 1.13
linux/drivers/char/pc_keyb.c - 1.22
linux/drivers/char/n_tty.c - 1.12
linux/drivers/char/misc.c - 1.24
linux/drivers/char/mem.c - 1.34
linux/drivers/char/joystick/Makefile - 1.7
linux/drivers/char/joystick/Config.in - 1.7
linux/drivers/char/isicom.c - 1.13
linux/drivers/char/ftape/zftape/zftape-vtbl.c - 1.5
linux/drivers/char/esp.c - 1.9
linux/drivers/char/epca.c - 1.14
linux/drivers/char/cyclades.c - 1.16
linux/drivers/char/Makefile - 1.42
linux/drivers/cdrom/sbpcd.c - 1.11
linux/drivers/block/ps2esdi.c - 1.12
linux/drivers/block/paride/paride.c - 1.8
linux/drivers/block/paride/Makefile - 1.6
linux/drivers/block/paride/Config.in - 1.4
linux/drivers/block/nbd.c - 1.18
linux/drivers/block/loop.c - 1.31
linux/drivers/block/ll_rw_blk.c - 1.67
linux/arch/sparc64/solaris/timod.c - 1.12
linux/arch/sparc64/prom/p1275.c - 1.6
linux/arch/sparc64/mm/modutil.c - 1.8
linux/arch/sparc64/mm/init.c - 1.24
linux/arch/sparc64/mm/generic.c - 1.8
linux/arch/sparc64/lib/debuglocks.c - 1.7
linux/arch/sparc64/lib/blockops.S - 1.11
linux/arch/sparc64/kernel/unaligned.c - 1.7
linux/arch/sparc64/kernel/ttable.S - 1.8
linux/arch/sparc64/kernel/traps.c - 1.13
linux/arch/sparc64/kernel/trampoline.S - 1.7
linux/arch/sparc64/kernel/time.c - 1.13
linux/arch/sparc64/kernel/sys_sunos32.c - 1.29
linux/arch/sparc64/kernel/sys_sparc32.c - 1.35
linux/arch/sparc64/kernel/sys_sparc.c - 1.20
linux/arch/sparc64/kernel/starfire.c - 1.9
linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.27
linux/arch/sparc64/kernel/smp.c - 1.23
linux/arch/sparc64/kernel/signal32.c - 1.17
linux/arch/sparc64/kernel/setup.c - 1.18
linux/arch/sparc64/kernel/process.c - 1.19
linux/arch/sparc64/kernel/irq.c - 1.18
linux/arch/sparc64/kernel/ioctl32.c - 1.33
linux/arch/sparc64/kernel/init_task.c - 1.4
linux/arch/sparc64/kernel/head.S - 1.8
linux/arch/sparc64/kernel/entry.S - 1.13
linux/arch/sparc64/kernel/ebus.c - 1.12
linux/arch/sparc64/kernel/dtlb_prot.S - 1.6
linux/arch/sparc64/kernel/devices.c - 1.8
linux/arch/sparc64/kernel/check_asm.sh - 1.5
linux/arch/sparc64/kernel/auxio.c - 1.7
linux/arch/sparc64/kernel/Makefile - 1.18
linux/arch/sparc64/defconfig - 1.34
linux/arch/sparc64/config.in - 1.37
linux/arch/sparc/prom/console.c - 1.6
linux/arch/sparc/mm/sun4c.c - 1.26
linux/arch/sparc/mm/srmmu.c - 1.24
linux/arch/sparc/mm/init.c - 1.24
linux/arch/sparc/mm/generic.c - 1.7
linux/arch/sparc/lib/memset.S - 1.4
linux/arch/sparc/kernel/sys_sunos.c - 1.28
linux/arch/sparc/kernel/sys_sparc.c - 1.14
linux/arch/sparc/kernel/sun4m_irq.c - 1.8
linux/arch/sparc/kernel/sun4c_irq.c - 1.7
linux/arch/sparc/kernel/setup.c - 1.18
linux/arch/sparc/kernel/irq.c - 1.15
linux/arch/sparc/kernel/head.S - 1.8
linux/arch/sparc/config.in - 1.28
linux/arch/ppc/kernel/prep_setup.c - 1.18
linux/arch/ppc/kernel/chrp_setup.c - 1.20
linux/arch/ppc/config.in - 1.34
linux/arch/mips/sni/Makefile - 1.6
linux/arch/mips/sgi/kernel/Makefile - 1.8
linux/arch/mips/mm/Makefile - 1.5
linux/arch/mips/lib/Makefile - 1.8
linux/arch/mips/kernel/traps.c - 1.9
linux/arch/mips/kernel/signal.c - 1.12
linux/arch/mips/kernel/setup.c - 1.10
linux/arch/mips/kernel/r6000_fpu.S - 1.6
linux/arch/mips/kernel/r4k_switch.S - 1.6
linux/arch/mips/kernel/r4k_misc.S - 1.7
linux/arch/mips/kernel/r4k_fpu.S - 1.6
linux/arch/mips/kernel/r2300_switch.S - 1.6
linux/arch/mips/kernel/r2300_fpu.S - 1.6
linux/arch/mips/kernel/ptrace.c - 1.8
linux/arch/mips/kernel/process.c - 1.10
linux/arch/mips/kernel/branch.c - 1.3
linux/arch/mips/jazz/Makefile - 1.5
linux/arch/mips/defconfig - 1.17
linux/arch/mips/config.in - 1.21
linux/arch/mips/Makefile - 1.8
linux/arch/m68k/q40/config.c - 1.9
linux/arch/m68k/kernel/setup.c - 1.12
linux/arch/m68k/config.in - 1.21
linux/arch/m68k/amiga/config.c - 1.8
linux/arch/i386/mm/init.c - 1.29
linux/arch/i386/math-emu/wm_sqrt.S - 1.3
linux/arch/i386/math-emu/status_w.h - 1.3
linux/arch/i386/math-emu/reg_u_sub.S - 1.3
linux/arch/i386/math-emu/reg_u_mul.S - 1.3
linux/arch/i386/math-emu/reg_u_div.S - 1.4
linux/arch/i386/math-emu/reg_u_add.S - 1.3
linux/arch/i386/math-emu/reg_round.S - 1.5
linux/arch/i386/math-emu/reg_mul.c - 1.3
linux/arch/i386/math-emu/reg_ld_str.c - 1.3
linux/arch/i386/math-emu/reg_divide.c - 1.3
linux/arch/i386/math-emu/reg_constant.h - 1.3
linux/arch/i386/math-emu/reg_compare.c - 1.3
linux/arch/i386/math-emu/poly_tan.c - 1.5
linux/arch/i386/math-emu/poly_sin.c - 1.4
linux/arch/i386/math-emu/poly_l2.c - 1.3
linux/arch/i386/math-emu/poly_atan.c - 1.3
linux/arch/i386/math-emu/poly_2xm1.c - 1.3
linux/arch/i386/math-emu/poly.h - 1.4
linux/arch/i386/math-emu/load_store.c - 1.3
linux/arch/i386/math-emu/get_address.c - 1.4
linux/arch/i386/math-emu/fpu_trig.c - 1.4
linux/arch/i386/math-emu/fpu_etc.c - 1.3
linux/arch/i386/math-emu/fpu_entry.c - 1.5
linux/arch/i386/math-emu/fpu_emu.h - 1.4
linux/arch/i386/math-emu/fpu_asm.h - 1.3
linux/arch/i386/math-emu/exception.h - 1.3
linux/arch/i386/math-emu/errors.c - 1.3
linux/arch/i386/math-emu/div_Xsig.S - 1.4
linux/arch/i386/math-emu/control_w.h - 1.3
linux/arch/i386/lib/usercopy.c - 1.5
linux/arch/i386/lib/Makefile - 1.14
linux/arch/i386/kernel/smp.c - 1.32
linux/arch/i386/kernel/setup.c - 1.45
linux/arch/i386/kernel/mtrr.c - 1.25
linux/arch/i386/kernel/ldt.c - 1.8
linux/arch/i386/kernel/i386_ksyms.c - 1.36
linux/arch/i386/kernel/head.S - 1.18
linux/arch/i386/kernel/apm.c - 1.31
linux/arch/i386/defconfig - 1.54
linux/arch/i386/config.in - 1.55
linux/arch/i386/boot/setup.S - 1.19
linux/arch/i386/Makefile - 1.22
linux/arch/arm/mm/small_page.c - 1.9
linux/arch/arm/mm/proc-sa110.S - 1.20
linux/arch/arm/mm/mm-footbridge.c - 1.8
linux/arch/arm/mm/mm-ebsa110.c - 1.7
linux/arch/arm/mm/mm-armv.c - 1.21
linux/arch/arm/mm/ioremap.c - 1.8
linux/arch/arm/mm/init.c - 1.22
linux/arch/arm/mm/fault-common.c - 1.15
linux/arch/arm/mm/fault-armv.c - 1.13
linux/arch/arm/mm/Makefile - 1.11
linux/arch/arm/lib/io.c - 1.5
linux/arch/arm/lib/delay.S - 1.5
linux/arch/arm/lib/backtrace.S - 1.6
linux/arch/arm/lib/Makefile - 1.16
linux/arch/arm/kernel/setup.c - 1.19
linux/arch/arm/kernel/oldlatches.c - 1.7
linux/arch/arm/kernel/leds-ebsa110.c - 1.5
linux/arch/arm/kernel/irq.c - 1.12
linux/arch/arm/kernel/head-armv.S - 1.14
linux/arch/arm/kernel/head-armo.S - 1.7
linux/arch/arm/kernel/fiq.c - 1.9
linux/arch/arm/kernel/entry-common.S - 1.14
linux/arch/arm/kernel/entry-armv.S - 1.18
linux/arch/arm/kernel/ecard.c - 1.12
linux/arch/arm/kernel/armksyms.c - 1.18
linux/arch/arm/kernel/Makefile - 1.16
linux/arch/arm/config.in - 1.24
linux/arch/arm/boot/compressed/head.S - 1.12
linux/arch/arm/boot/compressed/Makefile - 1.17
linux/arch/arm/boot/Makefile - 1.7
linux/arch/arm/Makefile - 1.20
linux/arch/alpha/mm/init.c - 1.17
linux/arch/alpha/kernel/alpha_ksyms.c - 1.20
linux/arch/alpha/config.in - 1.29
linux/REPORTING-BUGS - 1.5
linux/Makefile - 1.86
linux/MAINTAINERS - 1.57
linux/Documentation/sound/sonicvibes - 1.3
linux/Documentation/sound/es1371 - 1.3
linux/Documentation/sound/es1370 - 1.3
linux/Documentation/sound/README.OSS - 1.5
linux/Documentation/sound/PCM1-pro - 1.3
linux/Documentation/scsi-generic.txt - 1.7
linux/Documentation/parport.txt - 1.12
linux/Documentation/networking/wanpipe.txt - 1.5
linux/Documentation/networking/wan-router.txt - 1.5
linux/Documentation/mtrr.txt - 1.5
linux/Documentation/kernel-docs.txt - 1.7
linux/Documentation/joystick-api.txt - 1.7
linux/Documentation/filesystems/vfat.txt - 1.5
linux/Documentation/arm/README - 1.6
linux/Documentation/Configure.help - 1.78
linux/Documentation/Changes - 1.37
linux/CREDITS - 1.51
linux/net/decnet/af_decnet.c - 1.23
linux/fs/hpfs/super.c - 1.8
linux/fs/efs/super.c - 1.8
linux/drivers/video/vga16fb.c - 1.9
linux/drivers/isdn/hisax/md5sums.asc - 1.11
linux/drivers/isdn/hisax/isar.c - 1.11
linux/drivers/isdn/eicon/eicon_idi.c - 1.11
linux/arch/arm/nwfpe/single_cpdo.c - 1.4
linux/arch/arm/nwfpe/fpopcode.h - 1.3
linux/arch/arm/nwfpe/fpopcode.c - 1.4
linux/arch/arm/nwfpe/fpmodule.inl - 1.3
linux/arch/arm/nwfpe/fpmodule.c - 1.8
linux/arch/arm/nwfpe/fpa11_cprt.c - 1.5
linux/arch/arm/nwfpe/fpa11_cpdo.c - 1.5
linux/arch/arm/nwfpe/fpa11.inl - 1.3
linux/arch/arm/nwfpe/fpa11.c - 1.4
linux/arch/arm/nwfpe/extended_cpdo.c - 1.5
linux/arch/arm/nwfpe/entry26.S - 1.4
linux/arch/arm/nwfpe/entry.S - 1.3
linux/arch/arm/nwfpe/double_cpdo.c - 1.5
linux/arch/arm/nwfpe/config.h - 1.3
linux/arch/arm/nwfpe/Makefile - 1.5
linux/arch/arm/kernel/arthur.c - 1.6
linux/arch/arm/boot/compressed/ll_char_wr.S - 1.3
linux/Documentation/kernel-parameters.txt - 1.12
linux/drivers/tc/Makefile - 1.2
linux/drivers/net/jazzsonic.c - 1.7
linux/drivers/net/declance.c - 1.10
linux/drivers/net/bagetlance.c - 1.9
linux/arch/mips/lib/kbd-std.c - 1.4
linux/arch/mips/dec/boot/Makefile - 1.2
linux/arch/mips/dec/Makefile - 1.3
linux/arch/mips/baget/prom/Makefile - 1.4
linux/arch/mips/baget/Makefile - 1.4
linux/arch/mips/arc/printf.c - 1.5
linux/arch/mips/arc/misc.c - 1.5
linux/arch/mips/arc/memory.c - 1.8
linux/arch/mips/arc/init.c - 1.6
linux/arch/mips/arc/identify.c - 1.4
linux/arch/mips/arc/console.c - 1.5
linux/arch/mips/arc/cmdline.c - 1.5
linux/arch/mips/arc/Makefile - 1.5
linux/drivers/net/arlan-proc.c - 1.7
linux/Documentation/networking/olympic.txt - 1.3
linux/include/linux/raw.h - 1.2
linux/fs/iobuf.c - 1.19
linux/drivers/parport/parport_pc.c - 1.32
linux/drivers/char/raw.c - 1.15
linux/include/linux/iobuf.h - 1.13
linux/drivers/net/ppp_generic.c - 1.20
linux/drivers/net/ppp_async.c - 1.11
linux/drivers/net/mvme147.c - 1.7
linux/drivers/net/hamradio/yam.c - 1.14
linux/drivers/char/sx.c - 1.17
linux/include/linux/ppp_channel.h - 1.8
linux/drivers/sound/esssolo1.c - 1.27
linux/fs/partitions/Makefile - 1.5
linux/drivers/pnp/isapnp.c - 1.20
linux/drivers/isdn/hisax/hfc_pci.h - 1.5
linux/drivers/isdn/hisax/hfc_pci.c - 1.15
linux/drivers/isdn/hisax/bkm_a8.c - 1.9
linux/drivers/isdn/avmb1/b1.c - 1.11
linux/drivers/isdn/avmb1/avmcard.h - 1.5
linux/Documentation/isapnp.txt - 1.5
linux/drivers/net/sis900.c - 1.21
linux/drivers/net/sb1000.c - 1.12
linux/drivers/net/fc/iph5526.c - 1.13
linux/drivers/char/ip2.c - 1.5
linux/drivers/atm/zatm.c - 1.9
linux/arch/i386/kernel/semaphore.c - 1.15
linux/arch/alpha/kernel/semaphore.c - 1.5
linux/Documentation/sound/solo1 - 1.2
linux/net/core/netfilter.c - 1.13
linux/net/atm/svc.c - 1.10
linux/net/atm/pvc.c - 1.9
linux/net/atm/common.c - 1.10
linux/net/atm/clip.c - 1.10
linux/net/atm/addr.h - 1.3
linux/net/atm/addr.c - 1.5
linux/include/linux/netfilter.h - 1.8
linux/arch/ppc/kernel/semaphore.c - 1.4
linux/arch/arm/kernel/semaphore.c - 1.9
linux/arch/arm/kernel/bios32.c - 1.21
linux/arch/sparc64/kernel/semaphore.c - 1.6
linux/arch/sparc64/kernel/pci_sabre.c - 1.18
linux/arch/sparc64/kernel/pci_psycho.c - 1.16
linux/arch/sparc64/kernel/pci_impl.h - 1.6
linux/arch/sparc64/kernel/pci.c - 1.18
linux/arch/sparc/kernel/semaphore.c - 1.7
linux/arch/sh/mm/ioremap.c - 1.6
linux/arch/sh/mm/init.c - 1.13
linux/arch/sh/mm/extable.c - 1.3
linux/arch/sh/kernel/time.c - 1.14
linux/arch/sh/kernel/sh_ksyms.c - 1.8
linux/arch/sh/kernel/setup.c - 1.14
linux/arch/sh/kernel/semaphore.c - 1.6
linux/arch/sh/kernel/ptrace.c - 1.7
linux/arch/sh/kernel/process.c - 1.13
linux/arch/sh/kernel/entry.S - 1.17
linux/arch/sh/kernel/Makefile - 1.11
linux/arch/sh/config.in - 1.16
linux/drivers/scsi/ips.c - 1.15
linux/drivers/char/n_r3964.c - 1.8
linux/include/asm-sh/sigcontext.h - 1.5
linux/include/asm-sh/semaphore.h - 1.4
linux/include/asm-sh/processor.h - 1.12
linux/include/asm-sh/pgtable.h - 1.17
linux/include/asm-sh/irq.h - 1.9
linux/include/asm-sh/io.h - 1.9
linux/include/asm-sh/bugs.h - 1.7
linux/include/asm-i386/kmap_types.h - 1.3
linux/drivers/net/sun3lance.c - 1.7
linux/arch/m68k/mm/motorola.c - 1.5
linux/arch/m68k/kernel/semaphore.c - 1.6
linux/include/asm-m68k/mac_iop.h - 1.2
linux/fs/udf/partition.c - 1.5
linux/fs/udf/super.c - 1.18
linux/drivers/net/starfire.c - 1.13
linux/drivers/net/pcmcia/ray_cs.c - 1.20
linux/drivers/net/pcmcia/pcnet_cs.c - 1.14
linux/drivers/net/pcmcia/3c589_cs.c - 1.15
linux/drivers/net/dmfe.c - 1.13
linux/Documentation/filesystems/proc.txt - 1.7
linux/drivers/net/wan/Makefile - 1.11
linux/drivers/net/wan/Config.in - 1.10
linux/drivers/net/tokenring/olympic.h - 1.7
linux/drivers/net/tokenring/olympic.c - 1.12
linux/arch/ppc/kernel/m8xx_setup.c - 1.11
linux/arch/i386/lib/mmx.c - 1.6
linux/arch/i386/kernel/pci-pc.c - 1.22
linux/include/linux/pci_ids.h - 1.34
linux/drivers/net/wan/x25_asy.c - 1.7
linux/drivers/net/wan/syncppp.c - 1.9
linux/drivers/net/wan/sealevel.c - 1.8
linux/drivers/net/wan/sdlamain.c - 1.8
linux/drivers/net/wan/sdladrv.c - 1.6
linux/drivers/net/wan/sdla_x25.c - 1.6
linux/drivers/net/wan/sdla_ppp.c - 1.9
linux/drivers/net/wan/sdla_fr.c - 1.10
linux/drivers/net/wan/sdla.c - 1.11
linux/drivers/net/wan/lapbether.c - 1.7
linux/drivers/net/wan/hostess_sv11.c - 1.8
linux/drivers/net/wan/dlci.c - 1.7
linux/drivers/net/wan/cycx_x25.c - 1.12
linux/drivers/video/tdfxfb.c - 1.9
linux/drivers/net/tokenring/tms380tr.c - 1.15
linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.13
linux/drivers/net/pcmcia/3c574_cs.c - 1.13
linux/drivers/net/pcmcia/nmclan_cs.c - 1.11
linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.10
linux/drivers/net/pcmcia/netwave_cs.c - 1.14
linux/arch/sh/mm/cache.c - 1.10
linux/arch/arm/mm/mm-sa1100.c - 1.10
linux/drivers/net/pcmcia/wavelan_cs.h - 1.8
linux/arch/arm/mm/mm-armo.c - 1.8
linux/drivers/net/pcmcia/wavelan_cs.c - 1.9
linux/arch/arm/kernel/debug-armv.S - 1.8
linux/drivers/net/pcmcia/smc91c92_cs.c - 1.11
linux/mm/highmem.c - 1.19
linux/mm/bootmem.c - 1.13
linux/include/asm-sh/ide.h - 1.8
linux/include/asm-arm/proc-armv/cache.h - 1.7
linux/include/asm-arm/proc-armo/cache.h - 1.6
linux/include/asm-arm/arch-sa1100/system.h - 1.11
linux/include/asm-arm/arch-sa1100/serial.h - 1.4
linux/include/asm-arm/arch-sa1100/keyboard.h - 1.4
linux/include/asm-arm/arch-sa1100/dma.h - 1.3
linux/include/asm-sh/pgtable-2level.h - 1.5
linux/drivers/net/ppp_synctty.c - 1.8
linux/fs/proc/proc_misc.c - 1.18
linux/fs/bfs/inode.c - 1.14
linux/drivers/usb/dc2xx.c - 1.17
linux/drivers/net/sis900.h - 1.8
linux/drivers/isdn/avmb1/t1pci.c - 1.11
linux/drivers/net/sk98lin/skge.c - 1.10
linux/include/asm-ppc/pgalloc.h - 1.6
linux/include/asm-i386/pgalloc.h - 1.9
linux/include/asm-arm/pgalloc.h - 1.6
linux/include/asm-arm/arch-cl7500/uncompress.h - 1.3
linux/include/asm-arm/arch-cl7500/time.h - 1.5
linux/include/asm-arm/arch-cl7500/system.h - 1.10
linux/include/asm-arm/arch-cl7500/shmparam.h - 1.2
linux/include/asm-arm/arch-cl7500/irqs.h - 1.3
linux/include/asm-arm/arch-cl7500/irq.h - 1.3
linux/include/asm-arm/arch-cl7500/hardware.h - 1.6
linux/include/asm-alpha/pgalloc.h - 1.9
linux/drivers/sound/trident.c - 1.21
linux/drivers/net/pcmcia/aironet4500_cs.c - 1.11
linux/drivers/net/aironet4500_card.c - 1.11
linux/drivers/char/agp/agpgart_fe.c - 1.9
linux/drivers/usb/uhci-debug.h - 1.6
linux/drivers/pcmcia/yenta.c - 1.22
linux/drivers/pcmcia/pci_socket.c - 1.7
linux/include/asm-sparc64/pgalloc.h - 1.11
linux/fs/cramfs/inode.c - 1.15
linux/drivers/usb/scanner.c - 1.20
linux/include/linux/com20020.h - 1.3
linux/include/asm-sparc/pgalloc.h - 1.9
linux/drivers/usb/hid.h - 1.11
linux/drivers/usb/hid.c - 1.23
linux/drivers/net/pcmcia/com20020_cs.c - 1.7
linux/drivers/net/arcnet/com90xx.c - 1.7
linux/drivers/net/arcnet/com90io.c - 1.7
linux/drivers/net/arcnet/com20020-pci.c - 1.8
linux/drivers/net/arcnet/arcnet.c - 1.10
linux/drivers/net/tokenring/smctr.c - 1.10
linux/drivers/usb/devio.c - 1.14
linux/drivers/pci/setup-res.c - 1.6
linux/drivers/scsi/scsi_scan.c - 1.14
linux/drivers/scsi/3w-xxxx.c - 1.9
linux/drivers/net/wan/sdla_chdlc.c - 1.9
linux/drivers/net/tokenring/madgemc.c - 1.3
linux/Documentation/DMA-mapping.txt - 1.8
linux/include/linux/sdlapci.h - 1.2
linux/include/linux/sdla_chdlc.h - 1.2
linux/fs/autofs4/expire.c - 1.8
linux/drivers/usb/usb-uhci.c - 1.19
linux/drivers/usb/usb-ohci.h - 1.9
linux/drivers/usb/usb-ohci.c - 1.19
linux/drivers/sound/ac97_codec.c - 1.16
linux/drivers/net/macmace.c - 1.4
linux/arch/ia64/kernel/head.S - 1.7
linux/arch/ia64/kernel/semaphore.c - 1.7
linux/arch/ia64/kernel/gate.S - 1.6
linux/arch/ia64/kernel/fw-emu.c - 1.6
linux/arch/ia64/kernel/entry.h - 1.3
linux/arch/ia64/kernel/entry.S - 1.12
linux/arch/ia64/kernel/efi_stub.S - 1.3
linux/arch/ia64/kernel/efi.c - 1.10
linux/arch/ia64/kernel/acpi.c - 1.8
linux/arch/ia64/kernel/Makefile - 1.9
linux/arch/ia64/ia32/sys_ia32.c - 1.15
linux/arch/ia64/ia32/ia32_support.c - 1.4
linux/arch/ia64/ia32/ia32_entry.S - 1.11
linux/arch/ia64/ia32/binfmt_elf32.c - 1.10
linux/arch/ia64/hp/hpsim_irq.c - 1.4
linux/arch/ia64/dig/setup.c - 1.6
linux/arch/ia64/vmlinux.lds.S - 1.5
linux/arch/ia64/tools/print_offsets.c - 1.6
linux/arch/ia64/config.in - 1.17
linux/arch/ia64/boot/bootloader.c - 1.4
linux/arch/ia64/Makefile - 1.8
linux/arch/arm/kernel/time-acorn.c - 1.3
linux/arch/ia64/tools/print_offsets.awk - 1.3
linux/Documentation/pm.txt - 1.4
linux/arch/ia64/kernel/irq.c - 1.12
linux/arch/ia64/sn/Makefile - 1.4
linux/arch/ia64/sn/sn1/Makefile - 1.4
linux/arch/ia64/lib/strncpy_from_user.S - 1.4
linux/arch/ia64/kernel/setup.c - 1.8
linux/arch/ia64/kernel/signal.c - 1.8
linux/arch/ia64/kernel/smp.c - 1.8
linux/arch/ia64/kernel/sys_ia64.c - 1.7
linux/arch/ia64/kernel/time.c - 1.9
linux/arch/ia64/kernel/traps.c - 1.9
linux/arch/ia64/kernel/unaligned.c - 1.7
linux/arch/ia64/kernel/unwind.c - 1.7
linux/arch/ia64/lib/Makefile - 1.7
linux/arch/ia64/kernel/ivt.S - 1.10
linux/arch/ia64/lib/clear_page.S - 1.3
linux/arch/ia64/lib/clear_user.S - 1.4
linux/arch/ia64/lib/copy_page.S - 1.4
linux/arch/ia64/sn/sn1/setup.c - 1.5
linux/arch/ia64/lib/copy_user.S - 1.8
linux/arch/ia64/sn/sn1/machvec.c - 1.3
linux/arch/ia64/sn/sn1/irq.c - 1.4
linux/arch/ia64/lib/csum_partial_copy.c - 1.2
linux/arch/ia64/lib/do_csum.S - 1.3
linux/arch/ia64/kernel/ptrace.c - 1.8
linux/arch/ia64/kernel/process.c - 1.8
linux/arch/ia64/kernel/perfmon.c - 1.6
linux/arch/ia64/mm/tlb.c - 1.7
linux/arch/ia64/kernel/mca.c - 1.6
linux/arch/ia64/mm/init.c - 1.9
linux/arch/ia64/lib/flush.S - 1.4
linux/arch/ia64/mm/fault.c - 1.6
linux/arch/ia64/lib/memset.S - 1.3
linux/arch/ia64/lib/strlen.S - 1.5
linux/arch/ia64/lib/strlen_user.S - 1.4
linux/arch/ia64/mm/extable.c - 1.2
linux/arch/ia64/kernel/mca_asm.S - 1.6
linux/arch/ia64/kernel/pal.S - 1.6
linux/arch/ia64/lib/strnlen_user.S - 1.3
linux/drivers/scsi/qla1280.c - 1.9
linux/kernel/pm.c - 1.8
linux/include/asm-ia64/sigcontext.h - 1.2
linux/include/asm-ia64/io.h - 1.6
linux/include/asm-ia64/ia32.h - 1.8
linux/include/asm-ia64/hardirq.h - 1.9
linux/include/asm-ia64/efi.h - 1.6
linux/include/asm-ia64/dma.h - 1.4
linux/include/asm-ia64/delay.h - 1.4
linux/include/asm-ia64/cache.h - 1.4
linux/include/asm-ia64/byteorder.h - 1.2
linux/include/asm-ia64/bitops.h - 1.5
linux/include/asm-ia64/a.out.h - 1.3
linux/include/asm-ia64/siginfo.h - 1.8
linux/include/asm-ia64/segment.h - 1.2
linux/include/asm-ia64/mca_asm.h - 1.3
linux/include/asm-ia64/smp.h - 1.7
linux/include/asm-ia64/sal.h - 1.6
linux/include/asm-ia64/processor.h - 1.10
linux/include/asm-ia64/smplock.h - 1.3
linux/include/asm-ia64/pgtable.h - 1.11
linux/include/asm-ia64/pgalloc.h - 1.6
linux/include/asm-ia64/machvec.h - 1.5
linux/include/asm-ia64/param.h - 1.4
linux/include/asm-ia64/pal.h - 1.7
linux/include/asm-ia64/page.h - 1.9
linux/include/asm-ia64/softirq.h - 1.4
linux/include/asm-ia64/offsets.h - 1.9
linux/include/asm-ia64/ptrace.h - 1.7
linux/include/asm-ia64/machvec_sn1.h - 1.3
linux/include/asm-ia64/mca.h - 1.4
linux/include/asm-ia64/mmu_context.h - 1.6
linux/include/asm-ia64/semaphore.h - 1.5
linux/include/asm-ia64/uaccess.h - 1.6
linux/include/asm-ia64/timex.h - 1.2
linux/include/asm-ia64/unwind.h - 1.4
linux/include/asm-ia64/system.h - 1.8
linux/drivers/video/sun3fb.c - 1.5
linux/drivers/net/8139too.c - 1.18
linux/arch/arm/mm/consistent.c - 1.8
linux/drivers/isdn/avmb1/c4.c - 1.11
linux/drivers/isdn/avmb1/b1dma.c - 1.12
linux/Documentation/filesystems/devfs/ChangeLog - 1.7
linux/drivers/usb/plusb.c - 1.10
linux/include/linux/devfs_fs_kernel.h - 1.4
linux/drivers/isdn/hysdn/hysdn_defs.h - 1.5
linux/drivers/isdn/hysdn/hysdn_net.c - 1.6
linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.9
linux/fs/devfs/base.c - 1.14
linux/drivers/isdn/hysdn/hysdn_sched.c - 1.6
linux/drivers/isdn/hysdn/boardergo.c - 1.8
linux/drivers/net/skfp/skfddi.c - 1.10
linux/net/bridge/br_stp_if.c - 1.4
linux/arch/mips/ddb5074/time.c - 1.3
linux/Documentation/networking/8139too.txt - 1.9
linux/arch/mips/ddb5074/setup.c - 1.4
linux/arch/mips/ddb5074/nile4.c - 1.3
linux/arch/mips/ddb5074/prom.c - 1.3
linux/arch/mips/ddb5074/pci.c - 1.6
linux/arch/mips/kernel/semaphore.c - 1.3
linux/arch/mips/ddb5074/irq.c - 1.4
linux/arch/mips/defconfig-decstation - 1.6
linux/arch/mips/ddb5074/int-handler.S - 1.3
linux/arch/mips/defconfig-ip22 - 1.7
linux/arch/mips/ddb5074/Makefile - 1.3
linux/drivers/video/matrox/matroxfb_DAC1064.c - 1.6
linux/drivers/net/tulip/tulip_core.c - 1.20
linux/drivers/net/tulip/tulip.h - 1.11
linux/drivers/net/tulip/timer.c - 1.8
linux/drivers/net/tulip/pnic.c - 1.6
linux/drivers/net/tulip/media.c - 1.8
linux/drivers/net/tulip/interrupt.c - 1.9
linux/drivers/net/tulip/eeprom.c - 1.9
linux/drivers/net/tulip/Makefile - 1.3
linux/drivers/net/tulip/21142.c - 1.7
linux/include/asm-mips64/errno.h - 1.4
linux/include/asm-mips/sgi/sgimc.h - 1.3
linux/include/asm-mips/pgalloc.h - 1.4
linux/include/video/newport.h - 1.2
linux/include/linux/ac97_codec.h - 1.8
linux/include/asm-mips64/shmiq.h - 1.3
linux/include/asm-mips64/semaphore.h - 1.4
linux/include/asm-mips64/pgalloc.h - 1.6
linux/include/asm-mips64/pci/bridge.h - 1.3
linux/include/asm-mips64/mmzone.h - 1.6
linux/include/asm-mips64/keyboard.h - 1.3
linux/include/asm-mips64/mipsregs.h - 1.5
linux/arch/mips64/defconfig - 1.12
linux/arch/mips64/mm/Makefile - 1.4
linux/arch/mips64/tools/Makefile - 1.4
linux/arch/mips64/config.in - 1.13
linux/arch/mips64/defconfig-ip22 - 1.8
linux/arch/mips64/kernel/semaphore.c - 1.3
linux/arch/mips64/defconfig-ip27 - 1.7
linux/arch/arm/mm/mm-clps7500.c - 1.3
linux/include/asm-sh/pgalloc.h - 1.3
linux/include/asm-sh/pgalloc-2level.h - 1.3
linux/include/asm-sh/pci.h - 1.6
linux/drivers/net/appletalk/ltpc.c - 1.9
linux/drivers/net/appletalk/ipddp.c - 1.5
linux/drivers/net/appletalk/cops.c - 1.10
linux/drivers/char/sh-sci.h - 1.7
linux/drivers/char/sh-sci.c - 1.11
linux/arch/sh/kernel/cf-enabler.c - 1.4
linux/net/econet/sysctl_net_ec.c - 1.2
linux/net/econet/af_econet.c - 1.7
linux/include/linux/usb.h - 1.15
linux/include/asm-ia64/hw_irq.h - 1.5
linux/drivers/usb/serial/usb-serial.h - 1.12
linux/drivers/sound/miroaci.h - 1.3
linux/drivers/sound/aedsp16.c - 1.5
linux/drivers/sound/aci.c - 1.5
linux/drivers/parport/ChangeLog - 1.13
linux/arch/ia64/kernel/irq_ia64.c - 1.8
linux/drivers/ide/pdc202xx.c - 1.7
linux/drivers/ide/ide.c - 1.21
linux/drivers/ide/ide-pci.c - 1.11
linux/drivers/ide/alim15x3.c - 1.8
linux/arch/arm/lib/io-shark.c - 1.3
linux/arch/arm/kernel/arch.c - 1.8
linux/Documentation/networking/comx.txt - 1.3
linux/Documentation/DocBook/Makefile - 1.13
linux/scripts/kernel-doc - 1.8
linux/drivers/net/tokenring/lanstreamer.c - 1.6
linux/Documentation/DocBook/kernel-api.tmpl - 1.9
linux/net/ipv4/netfilter/ipt_REJECT.c - 1.9
linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.7
linux/net/ipv4/netfilter/ipchains_core.c - 1.4
linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.10
linux/net/ipv4/netfilter/ip_nat_rule.c - 1.4
linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.6
linux/net/ipv4/netfilter/ip_nat_core.c - 1.5
linux/net/ipv4/netfilter/ip_fw_compat.c - 1.8
linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.8
linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.6
linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.7
linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c - 1.4
linux/net/ipv4/netfilter/ip_conntrack_proto_generic.c - 1.4
linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.6
linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.8
linux/net/ipv4/netfilter/Makefile - 1.8
linux/include/linux/netfilter_ipv4/ip_nat_helper.h - 1.3
linux/include/linux/netfilter_ipv4/ip_nat_ftp.h - 1.2
linux/include/linux/netfilter_ipv4/ip_nat.h - 1.2
linux/include/linux/netfilter_ipv4/ip_conntrack_protocol.h - 1.3
linux/include/linux/netfilter_ipv4/ip_conntrack_ftp.h - 1.3
linux/include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.4
linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.7
linux/fs/nfs/flushd.c - 1.8
linux/drivers/scsi/dmx3191d.c - 1.6
linux/drivers/net/pcmcia/ibmtr_cs.c - 1.4
linux/arch/sparc64/lib/bitops.S - 1.2
linux/Documentation/sound/PAS16 - 1.2
linux/Documentation/DocBook/parportbook.tmpl - 1.4
linux/include/asm-arm/arch-shark/uncompress.h - 1.2
linux/include/asm-arm/arch-shark/timex.h - 1.2
linux/include/asm-arm/arch-shark/time.h - 1.4
linux/include/asm-arm/arch-shark/system.h - 1.4
linux/include/asm-arm/arch-shark/param.h - 1.2
linux/include/asm-arm/arch-shark/memory.h - 1.3
linux/include/asm-arm/arch-shark/keyboard.h - 1.4
linux/include/asm-arm/arch-shark/irqs.h - 1.2
linux/include/asm-arm/arch-shark/irq.h - 1.2
linux/include/asm-arm/arch-shark/io.h - 1.4
linux/drivers/video/sa1100fb.c - 1.6
linux/drivers/usb/serial/keyspan_pda.c - 1.12
linux/drivers/usb/serial/ftdi_sio.c - 1.14
linux/drivers/usb/serial/usbserial.c - 1.14
linux/drivers/usb/serial/whiteheat.c - 1.12
linux/drivers/usb/serial/visor.h - 1.3
linux/include/asm-arm/arch-shark/dma.h - 1.2
linux/drivers/usb/serial/visor.c - 1.14
linux/include/asm-arm/arch-shark/ide.h - 1.3
linux/include/asm-arm/arch-shark/hardware.h - 1.4
linux/arch/ia64/kernel/smpboot.c - 1.3
linux/arch/ia64/kernel/minstate.h - 1.5
linux/drivers/usb/serial/omninet.c - 1.11
linux/drivers/sound/i810_audio.c - 1.10
linux/drivers/sound/emu10k1/timer.h - 1.3
linux/drivers/sound/emu10k1/cardmi.h - 1.3
linux/drivers/sound/emu10k1/audio.c - 1.7
linux/fs/partitions/ibm.c - 1.3
linux/drivers/usb/serial/digi_acceleport.c - 1.11
linux/arch/ppc/kernel/m8260_setup.c - 1.7
linux/drivers/char/rio/rioctrl.c - 1.5
linux/drivers/char/rio/rio_linux.c - 1.8
linux/arch/s390/kernel/mathemu.c - 1.3
linux/arch/s390/kernel/process.c - 1.5
linux/include/asm-s390/page.h - 1.4
linux/arch/s390/boot/Makefile - 1.3
linux/arch/s390/Makefile - 1.3
linux/include/asm-s390/uaccess.h - 1.4
linux/include/asm-s390/types.h - 1.2
linux/arch/s390/config.in - 1.7
linux/arch/s390/defconfig - 1.4
linux/include/asm-s390/major.h - 1.2
linux/include/asm-s390/irq.h - 1.4
linux/include/asm-s390/irqextras390.h - 1.3
linux/include/asm-s390/system.h - 1.4
linux/arch/s390/kernel/Makefile - 1.3
linux/include/asm-s390/elf.h - 1.4
linux/include/asm-s390/ebcdic.h - 1.3
linux/include/asm-s390/delay.h - 1.3
linux/include/asm-s390/checksum.h - 1.3
linux/include/asm-s390/chandev.h - 1.3
linux/include/asm-s390/spinlock.h - 1.3
linux/include/asm-s390/smp.h - 1.3
linux/include/asm-s390/sigp.h - 1.3
linux/include/asm-s390/signal.h - 1.2
linux/include/asm-s390/setup.h - 1.3
linux/include/asm-s390/semaphore.h - 1.3
linux/arch/s390/kernel/entry.S - 1.8
linux/arch/s390/kernel/head.S - 1.3
linux/include/asm-s390/atomic.h - 1.3
linux/drivers/s390/net/iucv.c - 1.3
linux/drivers/s390/net/ctc.c - 1.5
linux/include/asm-s390/semaphore-helper.h - 1.2
linux/drivers/s390/net/Makefile - 1.3
linux/drivers/s390/misc/chandev.c - 1.4
linux/drivers/s390/misc/Makefile - 1.3
linux/drivers/s390/char/hwc_rw.c - 1.3
linux/drivers/s390/char/hwc_tty.c - 1.3
linux/drivers/s390/char/hwc_con.c - 1.4
linux/drivers/s390/char/Makefile - 1.3
linux/drivers/s390/char/hwc.h - 1.3
linux/drivers/s390/char/con3215.c - 1.6
linux/include/asm-s390/s390io.h - 1.3
linux/arch/s390/kernel/irq.c - 1.5
linux/drivers/s390/block/dasd_eckd.c - 1.3
linux/include/asm-s390/s390dyn.h - 1.3
linux/drivers/s390/block/dasd.c - 1.5
linux/include/asm-s390/s390-regs-common.h - 1.3
linux/arch/s390/kernel/irqextras390.c - 1.2
linux/drivers/s390/Makefile - 1.3
linux/drivers/s390/Config.in - 1.5
linux/include/asm-s390/queue.h - 1.3
linux/include/asm-s390/ptrace.h - 1.4
linux/include/asm-s390/misc390.h - 1.3
linux/include/asm-s390/mathemu.h - 1.3
linux/include/asm-s390/div64.h - 1.2
linux/include/asm-s390/bitops.h - 1.4
linux/arch/s390/kernel/cpcmd.c - 1.3
linux/arch/s390/kernel/cpcmd.h - 1.2
linux/arch/s390/kernel/ebcdic.c - 1.3
linux/arch/s390/kernel/floatlib.c - 1.2
linux/drivers/s390/block/Makefile - 1.3
linux/arch/s390/tools/silo/silo.c - 1.3
linux/include/asm-s390/pgalloc.h - 1.3
linux/arch/s390/kernel/traps.c - 1.5
linux/arch/s390/kernel/ptrace.c - 1.3
linux/arch/s390/kernel/s390_ksyms.c - 1.3
linux/arch/s390/kernel/s390fpu.c - 1.3
linux/arch/s390/kernel/semaphore.c - 1.5
linux/arch/s390/kernel/setup.c - 1.3
linux/arch/s390/kernel/signal.c - 1.5
linux/arch/s390/kernel/smp.c - 1.5
linux/arch/s390/lib/checksum.c - 1.2
linux/arch/s390/lib/Makefile - 1.3
linux/arch/s390/tools/dasdfmt/dasdfmt.c - 1.4
linux/arch/s390/mm/fault.c - 1.5
linux/arch/s390/mm/init.c - 1.6
linux/arch/s390/mm/ioremap.c - 1.3
linux/arch/sh/kernel/irq_ipr.c - 1.4
linux/arch/sh/kernel/io_se.c - 1.4
linux/net/ipv6/netfilter/Makefile - 1.5
linux/arch/sh/kernel/io_generic.c - 1.4
linux/Documentation/DocBook/kernel-hacking.tmpl - 1.4
linux/Documentation/DocBook/kernel-locking.tmpl - 1.5
linux/arch/mips/ddb5074/pci-dma.c - 1.2
linux/drivers/net/stnic.c - 1.6
linux/include/asm-arm/arch-l7200/dma.h - 1.3
linux/include/asm-arm/arch-l7200/hardware.h - 1.4
linux/include/asm-arm/arch-l7200/time.h - 1.3
linux/include/asm-arm/arch-l7200/system.h - 1.4
linux/include/asm-arm/arch-l7200/irqs.h - 1.2
linux/include/asm-arm/arch-l7200/irq.h - 1.2
linux/include/asm-arm/arch-l7200/io.h - 1.3
linux/drivers/char/joystick/tmdc.c - 1.3
linux/drivers/char/joystick/spaceball.c - 1.4
linux/drivers/char/joystick/sidewinder.c - 1.5
linux/drivers/char/joystick/ns558.c - 1.6
linux/drivers/char/joystick/gamecon.c - 1.3
linux/drivers/char/joystick/cobra.c - 1.3
linux/drivers/char/joystick/adi.c - 1.4
linux/Documentation/i386/boot.txt - 1.2
linux/drivers/char/i810_rng.c - 1.6
linux/drivers/char/hp600_keyb.c - 1.4
linux/drivers/video/hitfb.c - 1.4
linux/drivers/char/drm/ffb_drv.c - 1.5
linux/drivers/usb/storage/transport.h - 1.5
linux/drivers/usb/storage/transport.c - 1.8
linux/drivers/char/scan_keyb.c - 1.5
linux/drivers/char/scan_keyb.h - 1.2
linux/include/asm-sh/hd64461.h - 1.3
linux/include/asm-sh/keyboard.h - 1.3
linux/drivers/usb/serial/keyspan.c - 1.8
linux/include/asm-ia64/asmmacro.h - 1.3
linux/include/asm-sh/serial.h - 1.2
linux/include/asm-arm/mmzone.h - 1.3
linux/arch/arm/boot/compressed/setup-sa1100.S - 1.5
linux/drivers/acpi/namespace/nsxfobj.c - 1.7
linux/arch/arm/mm/mm-l7200.c - 1.4
linux/lib/cmdline.c - 1.3
linux/arch/ia64/kernel/brl_emu.c - 1.2
linux/arch/ia64/kernel/ia64_ksyms.c - 1.5
linux/arch/ia64/kernel/palinfo.c - 1.5
linux/include/asm-arm/arch-sa1100/mmzone.h - 1.5
linux/include/asm-arm/arch-sa1100/bitsy.h - 1.3
linux/include/asm-arm/arch-sa1100/assabet.h - 1.3
linux/include/asm-arm/arch-sa1100/SA-1100.h - 1.3
linux/arch/ia64/lib/memcpy.S - 1.4
linux/drivers/mtd/pmc551.c - 1.4
linux/include/asm-sparc64/mc146818rtc.h - 1.3
linux/arch/sh/kernel/setup_hd64461.c - 1.3
linux/arch/sh/kernel/io_hd64461.c - 1.3
linux/arch/mips/defconfig-cobalt - 1.3
linux/include/linux/serio.h - 1.2
linux/arch/mips/defconfig-orion - 1.3
linux/arch/mips/defconfig-rm200 - 1.3
linux/fs/nls/nls_cp932.c - 1.2
linux/fs/nls/nls_euc-jp.c - 1.3
linux/arch/mips/orion/Makefile - 1.2
linux/arch/mips/orion/int-handler.S - 1.2
linux/arch/mips/orion/irq.c - 1.4
linux/arch/mips/orion/ld.script.orion - 1.2
linux/arch/mips/orion/misc.c - 1.3
linux/arch/mips/orion/no_initrd.c - 1.2
linux/arch/mips/orion/piggyback.c - 1.2
linux/arch/mips/orion/promcon.c - 1.3
linux/arch/mips/orion/setup.c - 1.3
linux/drivers/net/tun.c - 1.6
linux/net/ipv4/tcp_minisocks.c - 1.4
linux/include/asm-sparc/kmap_types.h - 1.2
linux/include/asm-sh/machvec.h - 1.2
linux/include/asm-sh/io_unknown.h - 1.2
linux/include/asm-sh/io_se.h - 1.2
linux/include/asm-sh/io_od.h - 1.2
linux/include/asm-sh/io_hd64461.h - 1.3
linux/include/asm-sh/io_generic.h - 1.2
linux/fs/smbfs/getopt.c - 1.2
linux/drivers/usb/storage/sddr09.c - 1.5
linux/drivers/sound/cs46xx.c - 1.8
linux/drivers/sound/cs461x_image.h - 1.4
linux/drivers/sound/cs461x.h - 1.2
linux/drivers/net/natsemi.c - 1.6
linux/drivers/media/video/stradis.c - 1.5
linux/drivers/media/video/cpia.c - 1.4
linux/Documentation/networking/tuntap.txt - 1.3
linux/drivers/media/video/bttv.h - 1.7
linux/drivers/media/video/bttv-cards.c - 1.6
linux/drivers/media/radio/radio-miropcm20.c - 1.4
linux/drivers/media/radio/Makefile - 1.5
linux/drivers/media/radio/Config.in - 1.4
linux/drivers/isdn/hysdn/hycapi.c - 1.5
linux/drivers/input/keybdev.c - 1.4
linux/drivers/input/joydev.c - 1.4
linux/drivers/char/joystick/iforce.c - 1.5
linux/arch/sh/kernel/setup_cqreek.c - 1.3
linux/arch/sh/kernel/mach_unknown.c - 1.2
linux/arch/sh/kernel/mach_se.c - 1.2
linux/arch/sh/kernel/mach_hp600.c - 1.2
linux/arch/sh/kernel/io_unknown.c - 1.2
linux/arch/sh/kernel/io.c - 1.3
linux/arch/arm/tools/mach-types - 1.4
linux/arch/arm/mach-footbridge/arch.c - 1.3
linux/arch/arm/mach-footbridge/Makefile - 1.3
linux/Documentation/SubmittingDrivers - 1.4
linux/Documentation/filesystems/ext2.txt - 1.2
linux/arch/arm/kernel/via82c505.c - 1.3
linux/arch/arm/mach-sa1100/Makefile - 1.3
linux/arch/arm/mach-sa1100/arch.c - 1.3
linux/arch/arm/mach-shark/Makefile - 1.3
linux/arch/arm/mach-shark/arch.c - 1.2
linux/arch/arm/mach-shark/dma.c - 1.2
linux/arch/arm/mach-shark/mm.c - 1.2
linux/arch/i386/kernel/bluesmoke.c - 1.6
linux/drivers/block/cciss.c - 1.6
linux/drivers/block/cciss.h - 1.3
linux/drivers/block/cciss_cmd.h - 1.2
linux/drivers/char/toshiba.c - 1.2
linux/drivers/md/md.c - 1.12
linux/drivers/net/hamachi.c - 1.5
linux/drivers/net/sundance.c - 1.5
linux/drivers/net/winbond-840.c - 1.6
linux/drivers/scsi/cpqfcTSinit.c - 1.5
linux/fs/minix/itree_common.c - 1.2
linux/include/asm-arm/arch-tbox/time.h - 1.2
linux/include/asm-arm/hardware/ioc.h - 1.2
linux/include/asm-arm/hardware/iomd.h - 1.2
linux/include/asm-ppc/kmap_types.h - 1.3
linux/drivers/net/isa-skeleton.c - 1.4
linux/include/asm-ia64/acpikcfg.h - 1.3
linux/include/asm-ia64/module.h - 1.3
linux/arch/ia64/lib/idiv64.S - 1.2
linux/drivers/net/tulip/ChangeLog - 1.5
linux/drivers/usb/serial/belkin_sa.c - 1.5
linux/drivers/usb/serial/belkin_sa.h - 1.3
linux/Documentation/dnotify.txt - 1.3
linux/net/irda/irnet/irnet_ppp.c - 1.2
linux/include/asm-arm/xor.h - 1.3
linux/include/linux/ethtool.h - 1.3
linux/include/asm-m68k/motorola_pgalloc.h - 1.2
linux/drivers/usb/serial/mct_u232.c - 1.4
linux/include/asm-parisc/pgalloc.h - 1.2
linux/drivers/usb/serial/empeg.c - 1.4
linux/drivers/usb/serial/Config.in - 1.4
linux/arch/parisc/kernel/semaphore.c - 1.2
linux/include/asm-m68k/sun3_pgalloc.h - 1.2
linux/drivers/sound/ymfpci_image.h - 1.2
linux/drivers/sound/ymfpci.c - 1.5
linux/include/asm-parisc/semaphore.h - 1.2
linux/arch/parisc/config.in - 1.2
linux/include/linux/shmem_fs.h - 1.2
linux/mm/shmem.c - 1.5
linux/drivers/atm/firestream.c - 1.3
linux/arch/m68k/ifpsp060/src/pfpsp.S - 1.4
linux/drivers/atm/firestream.h - 1.2
linux/arch/m68k/ifpsp060/src/fpsp.S - 1.4
linux/arch/ia64/sn/io/stubs.c - 1.2
linux/include/asm-ia64/sn/addrs.h - 1.2
linux/include/asm-ia64/sn/agent.h - 1.2
linux/include/asm-ia64/sn/arc/hinv.h - 1.2
linux/include/asm-ia64/sn/arch.h - 1.2
linux/include/asm-ia64/sn/cdl.h - 1.2
linux/include/asm-ia64/sn/cmn_err.h - 1.2
linux/include/asm-ia64/sn/dmamap.h - 1.2
linux/include/asm-ia64/sn/eeprom.h - 1.2
linux/include/asm-ia64/sn/gda.h - 1.2
linux/include/asm-ia64/sn/hack.h - 1.2
linux/include/asm-ia64/sn/hcl.h - 1.2
linux/include/asm-ia64/sn/hwcntrs.h - 1.2
linux/include/asm-ia64/sn/intr.h - 1.2
linux/include/asm-ia64/sn/intr_public.h - 1.2
linux/include/asm-ia64/sn/invent.h - 1.2
linux/include/asm-ia64/sn/io.h - 1.2
linux/include/asm-ia64/sn/ioerror.h - 1.2
linux/include/asm-ia64/sn/ioerror_handling.h - 1.2
linux/include/asm-ia64/sn/iograph.h - 1.2
linux/include/asm-ia64/sn/klconfig.h - 1.2
linux/include/asm-ia64/sn/kldir.h - 1.2
linux/include/asm-ia64/sn/ksys/elsc.h - 1.2
linux/include/asm-ia64/sn/ksys/l1.h - 1.2
linux/arch/ia64/kernel/iosapic.c - 1.2
linux/include/asm-ia64/sn/mmzone.h - 1.2
linux/include/asm-ia64/sn/mmzone_sn1.h - 1.2
linux/include/asm-ia64/sn/module.h - 1.2
linux/include/asm-ia64/sn/nodemask.h - 1.2
linux/include/asm-ia64/sn/xtalk/xtalkaddrs.h - 1.2
linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.2
linux/include/asm-ia64/sn/xtalk/xtalk.h - 1.2
linux/include/asm-ia64/sn/war.h - 1.2
linux/include/asm-ia64/sn/types.h - 1.2
linux/include/asm-ia64/sn/synergy.h - 1.2
linux/include/asm-ia64/sn/sn_private.h - 1.2
linux/include/asm-ia64/sn/sn_fru.h - 1.2
linux/include/asm-ia64/sn/sn_cpuid.h - 1.2
linux/include/asm-ia64/sn/sn1/war.h - 1.2
linux/include/asm-ia64/sn/sn1/uart16550.h - 1.2
linux/include/asm-ia64/sn/sn1/slotnum.h - 1.2
linux/arch/ia64/lib/swiotlb.c - 1.2
linux/include/asm-ia64/sn/sn1/router.h - 1.2
linux/include/asm-ia64/sn/sn1/leds.h - 1.2
linux/include/asm-ia64/sn/sn1/ip27config.h - 1.2
linux/arch/ia64/sn/fprom/Makefile - 1.2
linux/arch/ia64/sn/fprom/fw-emu.c - 1.2
linux/arch/ia64/sn/io/Makefile - 1.2
linux/arch/ia64/sn/io/alenlist.c - 1.2
linux/arch/ia64/sn/io/cdl.c - 1.2
linux/arch/ia64/sn/io/devsupport.c - 1.2
linux/arch/ia64/sn/io/eeprom.c - 1.2
linux/arch/ia64/sn/io/hcl.c - 1.2
linux/arch/ia64/sn/io/hcl_util.c - 1.2
linux/arch/ia64/sn/io/hubdev.c - 1.2
linux/arch/ia64/sn/io/hubspc.c - 1.2
linux/arch/ia64/sn/io/invent.c - 1.2
linux/arch/ia64/sn/io/io.c - 1.2
linux/arch/ia64/sn/io/ip37.c - 1.2
linux/arch/ia64/sn/io/klconflib.c - 1.3
linux/arch/ia64/sn/io/klgraph.c - 1.2
linux/arch/ia64/sn/io/klgraph_hack.c - 1.3
linux/arch/ia64/sn/io/l1.c - 1.4
linux/arch/ia64/sn/io/l1_command.c - 1.2
linux/arch/ia64/sn/io/labelcl.c - 1.2
linux/arch/ia64/sn/io/mem_refcnt.c - 1.2
linux/arch/ia64/sn/io/ml_SN_init.c - 1.2
linux/arch/ia64/sn/io/ml_SN_intr.c - 1.2
linux/arch/ia64/sn/io/ml_iograph.c - 1.2
linux/arch/ia64/sn/io/module.c - 1.2
linux/arch/ia64/sn/io/pci.c - 1.2
linux/arch/ia64/sn/io/pci_bus_cvlink.c - 1.2
linux/arch/ia64/sn/io/pci_dma.c - 1.2
linux/arch/ia64/sn/io/pcibr.c - 1.4
linux/arch/ia64/sn/io/pciio.c - 1.2
linux/arch/ia64/sn/io/sgi_if.c - 1.2
linux/arch/ia64/sn/io/sgi_io_init.c - 1.2
linux/arch/ia64/sn/io/sgi_io_sim.c - 1.2
linux/include/asm-ia64/sn/nodepda.h - 1.2
linux/arch/ia64/sn/io/xbow.c - 1.3
linux/arch/ia64/sn/io/xswitch.c - 1.2
linux/arch/ia64/sn/io/xtalk.c - 1.3
linux/include/asm-ia64/sn/sn1/hubxb_next.h - 1.2
linux/arch/ia64/sn/sn1/discontig.c - 1.2
linux/arch/ia64/sn/sn1/iomv.c - 1.2
linux/arch/ia64/sn/sn1/llsc4.c - 1.2
linux/arch/ia64/sn/sn1/mm.c - 1.2
linux/include/asm-ia64/sn/sn1/hubpi_next.h - 1.2
linux/arch/ia64/sn/sn1/smp.c - 1.2
linux/arch/ia64/sn/sn1/sn1_asm.S - 1.2
linux/arch/ia64/sn/sn1/synergy.c - 1.2
linux/include/asm-ia64/sn/sn1/hubio_next.h - 1.2
linux/include/asm-ia64/sn/sn1/bedrock.h - 1.2
linux/include/asm-ia64/sn/sn1/addrs.h - 1.2
linux/include/asm-ia64/sn/slotnum.h - 1.2
linux/include/asm-ia64/sn/sgi.h - 1.2
linux/arch/sh/kernel/rtc.c - 1.2
linux/include/asm-ia64/sn/router.h - 1.2
linux/include/asm-ia64/sn/pio.h - 1.2
linux/include/asm-ia64/sn/pci/pciio_private.h - 1.2
linux/include/asm-ia64/sn/pci/pciio.h - 1.2
linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.3
linux/include/asm-ia64/sn/pci/pcibr.h - 1.2
linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.2
linux/fs/reiserfs/stree.c - 1.3
linux/fs/reiserfs/super.c - 1.3
linux/fs/reiserfs/tail_conversion.c - 1.4
linux/fs/reiserfs/prints.c - 1.2
linux/fs/reiserfs/objectid.c - 1.2
linux/fs/reiserfs/namei.c - 1.3
linux/arch/sparc64/kernel/pci_schizo.c - 1.4
linux/fs/reiserfs/journal.c - 1.2
linux/fs/reiserfs/inode.c - 1.3
linux/fs/reiserfs/fix_node.c - 1.3
linux/fs/reiserfs/file.c - 1.2
linux/include/linux/reiserfs_fs.h - 1.3
linux/include/linux/reiserfs_fs_i.h - 1.2
linux/include/linux/reiserfs_fs_sb.h - 1.2
linux/fs/reiserfs/bitmap.c - 1.2
linux/drivers/sbus/char/cpwatchdog.c - 1.3
linux/include/asm-s390/dasd.h - 1.2
linux/include/asm-s390x/queue.h - 1.2
linux/arch/s390x/kernel/sys_s390.c - 1.3
linux/Documentation/cris/README - 1.2
linux/include/asm-s390x/ptrace.h - 1.2
linux/arch/s390x/kernel/smp.c - 1.2
linux/arch/s390x/kernel/signal32.c - 1.2
linux/include/asm-s390x/pgtable.h - 1.2
linux/include/asm-s390x/pgalloc.h - 1.2
linux/drivers/video/riva/rivafb.h - 1.2
linux/arch/s390x/kernel/signal.c - 1.2
linux/arch/s390x/kernel/setup.c - 1.2
linux/include/asm-s390x/page.h - 1.2
linux/arch/s390x/kernel/semaphore.c - 1.2
linux/Documentation/s390/chandev.8 - 1.2
linux/include/asm-s390x/misc390.h - 1.2
linux/include/asm-s390x/major.h - 1.2
linux/include/asm-s390x/irqextras390.h - 1.2
linux/include/asm-s390x/irq.h - 1.2
linux/include/asm-s390x/elf.h - 1.2
linux/include/asm-s390x/ebcdic.h - 1.2
linux/include/asm-s390x/delay.h - 1.2
linux/include/asm-s390x/debug.h - 1.2
linux/arch/s390x/kernel/s390_ksyms.c - 1.2
linux/arch/s390x/kernel/s390_ext.c - 1.2
linux/include/asm-s390x/dasd.h - 1.3
linux/arch/arm/boot/compressed/head-shark.S - 1.2
linux/arch/arm/boot/compressed/ofw-shark.c - 1.2
linux/include/asm-s390x/chandev.h - 1.2
linux/include/asm-s390x/ccwcache.h - 1.3
linux/drivers/sound/maestro3.c - 1.3
linux/include/asm-s390x/s390dyn.h - 1.2
linux/include/asm-s390x/s390io.h - 1.2
linux/drivers/sound/cs4281/cs4281m.c - 1.2
linux/drivers/sound/cs4281/cs4281_wrapper-24.c - 1.2
linux/arch/s390x/kernel/ptrace.c - 1.2
linux/arch/s390x/kernel/process.c - 1.2
linux/arch/s390x/kernel/linux32.c - 1.3
linux/arch/s390x/kernel/irqextras390.c - 1.2
linux/arch/s390x/kernel/irq.c - 1.2
linux/arch/s390x/kernel/head.S - 1.2
linux/include/asm-s390x/semaphore-helper.h - 1.2
linux/include/asm-s390x/semaphore.h - 1.2
linux/include/asm-s390x/setup.h - 1.2
linux/include/asm-s390x/signal.h - 1.2
linux/include/asm-s390x/sigp.h - 1.2
linux/arch/cris/Makefile - 1.2
linux/arch/cris/boot/compressed/Makefile - 1.2
linux/arch/cris/boot/compressed/decompress.ld - 1.2
linux/arch/cris/boot/compressed/head.S - 1.2
linux/arch/cris/boot/compressed/misc.c - 1.2
linux/arch/cris/config.in - 1.2
linux/arch/cris/cris.ld - 1.2
linux/arch/cris/defconfig - 1.2
linux/arch/cris/drivers/Config.in - 1.2
linux/arch/cris/drivers/Makefile - 1.2
linux/arch/cris/drivers/axisflashmap.c - 1.2
linux/arch/cris/drivers/ethernet.c - 1.2
linux/arch/cris/drivers/ide.c - 1.2
linux/arch/cris/drivers/serial.c - 1.3
linux/arch/cris/drivers/serial.h - 1.2
linux/arch/cris/kernel/entry.S - 1.3
linux/arch/cris/kernel/head.S - 1.2
linux/arch/cris/kernel/irq.c - 1.2
linux/arch/cris/kernel/kgdb.c - 1.2
linux/arch/cris/kernel/process.c - 1.2
linux/arch/cris/kernel/semaphore.c - 1.2
linux/arch/cris/kernel/setup.c - 1.2
linux/arch/cris/kernel/signal.c - 1.2
linux/arch/cris/kernel/sys_cris.c - 1.3
linux/arch/cris/kernel/traps.c - 1.2
linux/arch/cris/lib/checksum.S - 1.2
linux/arch/cris/lib/checksumcopy.S - 1.2
linux/arch/cris/mm/Makefile - 1.2
linux/arch/cris/mm/fault.c - 1.3
linux/arch/cris/mm/init.c - 1.2
linux/drivers/s390/s390io.c - 1.2
linux/drivers/s390/s390dyn.c - 1.2
linux/drivers/s390/net/netiucv.c - 1.3
linux/include/asm-s390x/smp.h - 1.2
linux/drivers/s390/net/ctcmain.c - 1.2
linux/drivers/s390/idals.c - 1.2
linux/drivers/s390/char/tapedefs.h - 1.2
linux/drivers/s390/char/tapechar.h - 1.2
linux/arch/s390x/kernel/exec32.c - 1.3
linux/drivers/s390/char/tapechar.c - 1.2
linux/arch/s390x/kernel/entry.S - 1.3
linux/drivers/s390/char/tapeblock.h - 1.2
linux/drivers/s390/char/tapeblock.c - 1.2
linux/drivers/s390/char/tape34xx.h - 1.2
linux/drivers/s390/char/tape34xx.c - 1.3
linux/drivers/s390/char/tape3490.h - 1.2
linux/drivers/s390/char/tape3490.c - 1.2
linux/drivers/s390/char/tape3480.h - 1.2
linux/drivers/s390/char/tape3480.c - 1.2
linux/drivers/s390/char/tape.h - 1.2
linux/drivers/s390/char/tape.c - 1.2
linux/arch/s390x/kernel/ebcdic.c - 1.2
linux/arch/s390x/kernel/debug.c - 1.2
linux/arch/s390x/kernel/cpprintk.c - 1.2
linux/arch/s390x/kernel/cpcmd.h - 1.2
linux/arch/s390x/kernel/cpcmd.c - 1.2
linux/arch/s390x/kernel/binfmt_elf32.c - 1.3
linux/arch/s390x/kernel/Makefile - 1.3
linux/arch/s390x/defconfig - 1.2
linux/arch/s390x/config.in - 1.2
linux/arch/s390x/mm/ioremap.c - 1.2
linux/arch/s390x/mm/init.c - 1.2
linux/include/asm-s390x/spinlock.h - 1.2
linux/drivers/s390/ccwcache.c - 1.2
linux/drivers/s390/block/xpram.c - 1.2
linux/include/asm-s390x/system.h - 1.2
linux/include/asm-s390x/termios.h - 1.2
linux/include/asm-s390x/todclk.h - 1.2
linux/drivers/s390/block/dasd_fba.c - 1.2
linux/include/asm-s390x/types.h - 1.2
linux/drivers/s390/block/dasd_eckd.h - 1.2
linux/drivers/s390/block/dasd_diag.c - 1.2
linux/arch/s390x/lib/delay.c - 1.2
linux/arch/s390x/lib/Makefile - 1.3
linux/include/asm-s390x/uaccess.h - 1.2
linux/include/asm-s390/ccwcache.h - 1.3
linux/drivers/s390/block/dasd_3990_erp.h - 1.2
linux/drivers/s390/block/dasd_3990_erp.c - 1.2
linux/include/asm-cris/unistd.h - 1.2
linux/include/asm-cris/termios.h - 1.2
linux/include/asm-cris/sv_addr.agh - 1.2
linux/include/asm-cris/socket.h - 1.2
linux/drivers/pcmcia/hd64465_ss.c - 1.2
linux/include/asm-s390x/atomic.h - 1.2
linux/include/asm-cris/semaphore.h - 1.2
linux/drivers/net/tokenring/tmsisa.c - 1.3
linux/include/asm-s390/todclk.h - 1.2
linux/include/asm-s390/debug.h - 1.2
linux/drivers/net/pci-skeleton.c - 1.3
linux/include/asm-cris/bitops.h - 1.2
linux/include/asm-cris/delay.h - 1.2
linux/include/asm-cris/eshlibld.h - 1.2
linux/arch/s390/kernel/debug.c - 1.2
linux/include/asm-cris/ptrace.h - 1.2
linux/include/asm-cris/processor.h - 1.2
linux/arch/s390/kernel/s390_ext.c - 1.2
linux/include/asm-cris/pgalloc.h - 1.2
linux/include/asm-cris/irq.h - 1.2
linux/include/asm-cris/io.h - 1.2
linux/arch/s390x/vmlinux.lds - 1.2
linux/arch/s390x/tools/silo/silo.c - 1.2
linux/arch/s390x/tools/dasdfmt/dasdfmt.c - 1.3
linux/arch/s390x/boot/Makefile - 1.3
linux/drivers/net/pcmcia/hermes.h - 1.2
linux/Documentation/i810_rng.txt - 1.2
linux/include/asm-sparc64/bbc.h - 1.2
linux/include/asm-ppc/tqm8xx.h - 1.2
linux/drivers/usb/serial/io_edgeport.c - 1.2
linux/drivers/scsi/aic7xxx_old/sequencer.h - 1.2
linux/drivers/scsi/aic7xxx_old/aic7xxx.seq - 1.2
linux/drivers/scsi/aic7xxx_old/aic7xxx.reg - 1.2
linux/drivers/scsi/aic7xxx_old.c - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.2
linux/drivers/sbus/char/riowatchdog.c - 1.2
linux/drivers/net/wan/hdlc.c - 1.2
linux/arch/arm/tools/getconstants.c - 1.2
linux/drivers/net/wan/dscc4.c - 1.2
linux/drivers/net/sungem.h - 1.2
linux/drivers/net/sungem.c - 1.2
linux/drivers/net/pcmcia/orinoco_cs.c - 1.2
linux/drivers/net/pcmcia/hermes.c - 1.2
linux/drivers/char/machzwd.c - 1.2


From owner-linux-xfs@oss.sgi.com Wed May  2 00:30:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f427UHp18182
	for linux-xfs-outgoing; Wed, 2 May 2001 00:30:17 -0700
Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.3.13])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f427UFF18175
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 00:30:15 -0700
Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15])
	by mx03.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id JAA10411
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:30:14 +0200
Received: from chimaera (pool4019.studentenheim.uni-tuebingen.de [134.2.214.19])
	by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id JAA20969
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:30:13 +0200
Message-ID: <005c01c0d2da$06bd8100$0a42a8c0@chimaera>
From: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>
To: <linux-xfs@oss.sgi.com>
Subject: XFS 1.0 RH7.1 won't boot
Date: Wed, 2 May 2001 09:31:52 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,
I downloaded and installed the 1.0-XFS-Redhat ISOs, but the
system does not boot - instead it locks up after
> RAMDISK - compressed image found at block 0
I used the boot.img bootdisk because I have a non-bootable
cdrom drive, I hope this isn't a problem?
The partition I used is hdc2, beyond the 1024 cylinder, what
might be a problem, but a stock-EXT2-Redhat 7.1 can run
without any trouble from hdc2.
Did I miss something important or is this an installer related
bug?

- Simon


From owner-linux-xfs@oss.sgi.com Wed May  2 00:39:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f427dbn18523
	for linux-xfs-outgoing; Wed, 2 May 2001 00:39:37 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f427dYF18520
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 00:39:34 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f427cuB11986;
	Wed, 2 May 2001 02:38:56 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AEFC6DE.53A727B4@thebarn.com>
Date: Wed, 02 May 2001 03:35:43 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Pabst <simon.pabst@student.uni-tuebingen.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0 RH7.1 won't boot
References: <005c01c0d2da$06bd8100$0a42a8c0@chimaera>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Simon Pabst wrote:

Ok I hate to ask this; but what kind of mother board do you have?
please don't say bamboo.
The boot images has APIC enabled to solve a problem with the SGI 1200's
apparently enabling this does break on some motherboards.
One option is to download the Release-1.0-test3 iso image.... err
scratch that download the bootnet.img from the test3 dir.
If it works simple go ahead and install your system and then
upgrade the kernel rpm after the system is up.


> Hi,
> I downloaded and installed the 1.0-XFS-Redhat ISOs, but the
> system does not boot - instead it locks up after
> > RAMDISK - compressed image found at block 0
> I used the boot.img bootdisk because I have a non-bootable
> cdrom drive, I hope this isn't a problem?
> The partition I used is hdc2, beyond the 1024 cylinder, what
> might be a problem, but a stock-EXT2-Redhat 7.1 can run
> without any trouble from hdc2.
> Did I miss something important or is this an installer related
> bug?
>
> - Simon


From owner-linux-xfs@oss.sgi.com Wed May  2 00:52:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f427qTh19021
	for linux-xfs-outgoing; Wed, 2 May 2001 00:52:29 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f427qOF19016
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 00:52:25 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id JAA454993
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:52:15 +0200 (CEST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id CAA88948 for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 02:50:59 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f427nxG15920
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 03:49:59 -0400
Date: Wed, 2 May 2001 03:49:59 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105020749.f427nxG15920@gibble.americas.sgi.com>
Subject: TAKE - LVM function fix.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Wed May  2 00:48:52 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-clean

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93825a
linux/drivers/md/lvm.c - 1.12
	- Change get_hardblocksize to get_hardsect_size
	  Thanks to Chris Pascoe for sending in the patch.



From owner-linux-xfs@oss.sgi.com Wed May  2 01:05:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4285E019903
	for linux-xfs-outgoing; Wed, 2 May 2001 01:05:14 -0700
Received: from oboe.it.uc3m.es (oboe.it.uc3m.es [163.117.139.101])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4285AF19898
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 01:05:10 -0700
Received: (from ptb@localhost)
	by oboe.it.uc3m.es (8.11.0/8.11.0) id f4284qX23956;
	Wed, 2 May 2001 10:04:52 +0200
From: "Peter T. Breuer" <ptb@it.uc3m.es>
Message-Id: <200105020804.f4284qX23956@oboe.it.uc3m.es>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <3AEFC6DE.53A727B4@thebarn.com> from "Russell Cattelan" at "May
 2, 2001 03:35:43 am"
To: "Russell Cattelan" <cattelan@thebarn.com>
Date: Wed, 2 May 2001 10:04:52 +0200 (MET DST)
CC: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>,
   linux-xfs@oss.sgi.com
X-Anonymously-To:                                 
Reply-To: ptb@it.uc3m.es
X-Mailer: ELM [version 2.4ME+ PL66 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Russell Cattelan wrote:"
> The boot images has APIC enabled to solve a problem with the SGI 1200's
> apparently enabling this does break on some motherboards.

boot with "noapic" as one of the boot parameters.

> One option is to download the Release-1.0-test3 iso image.... err
> scratch that download the bootnet.img from the test3 dir.

Peter

From owner-linux-xfs@oss.sgi.com Wed May  2 01:16:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f428Gj520488
	for linux-xfs-outgoing; Wed, 2 May 2001 01:16:45 -0700
Received: from mx01.uni-tuebingen.de (mx01.uni-tuebingen.de [134.2.3.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f428GfF20461
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 01:16:41 -0700
Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15])
	by mx01.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id KAA15619
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 10:16:40 +0200
Received: from chimaera (pool4019.studentenheim.uni-tuebingen.de [134.2.214.19])
	by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id KAA24546
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 10:16:40 +0200
Message-ID: <000f01c0d2e0$83ef76f0$0a42a8c0@chimaera>
From: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>
To: <linux-xfs@oss.sgi.com>
References: <200105020804.f4284qX23956@oboe.it.uc3m.es>
Subject: Re: XFS 1.0 RH7.1 won't boot
Date: Wed, 2 May 2001 10:18:19 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks, but this doesn't solve anything - 
I don't think this is APIC-related.
It's NOT the boot.img bootdisk to start the installation 
that locks up, it's after using the installer-created bootdisk 
(instead of LILO) to boot the installed system.

- Simon

> "Russell Cattelan wrote:"
> > The boot images has APIC enabled to solve a problem with the SGI 1200's
> > apparently enabling this does break on some motherboards.
> 
> boot with "noapic" as one of the boot parameters.
> 
> > One option is to download the Release-1.0-test3 iso image.... err
> > scratch that download the bootnet.img from the test3 dir.
> 
> Peter
> 


From owner-linux-xfs@oss.sgi.com Wed May  2 02:57:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f429vuJ25190
	for linux-xfs-outgoing; Wed, 2 May 2001 02:57:56 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f429vrF25187
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 02:57:54 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 06697C231; Wed,  2 May 2001 11:56:02 +0100 (BST)
To: Ric Tibbetts <ric@chadera.net>
Cc: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: Mandrake 8.0 + XFS (patch)
References: <3AECCD58.28A6FCD8@chadera.net>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 02 May 2001 11:56:02 +0100
In-Reply-To: <3AECCD58.28A6FCD8@chadera.net> (Ric Tibbetts's message of "Sun, 29 Apr 2001 19:26:32 -0700")
Message-ID: <m3lmogm33x.fsf@giants.mandrakesoft.com>
Lines: 8
User-Agent: Gnus/5.090002 (Oort Gnus v0.02) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts <ric@chadera.net> writes:

> What I'd like to try this time, is to put the XFS patch against the
> Mandrake kernel. Rhe frame buffer on the mandarke kernel works (on this
> box), but the one in the cvs tree from SGI doesn't, and I'd like to keep
> using it.

I don't understand what it doen't work, do you have CONFIG_VESA set ?

From owner-linux-xfs@oss.sgi.com Wed May  2 03:18:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42AIuN25793
	for linux-xfs-outgoing; Wed, 2 May 2001 03:18:56 -0700
Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AIrF25787
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:18:54 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id ACBCCBC19; Wed,  2 May 2001 06:18:52 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by linux.compucomis.net (Postfix) with ESMTP
	id 933DA3FE5; Wed,  2 May 2001 06:18:52 -0400 (EDT)
Date: Wed, 2 May 2001 06:18:52 -0400 (EDT)
From: Mike Burger <mburger@compucomis.net>
To: Simon Pabst <simon.pabst@student.uni-tuebingen.de>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <000f01c0d2e0$83ef76f0$0a42a8c0@chimaera>
Message-ID: <Pine.LNX.4.33.0105020618220.929-100000@linux.compucomis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Does the system boot without the boot disk, ie, via the HD?

If so, recreate your boot disk by running "mkbootdisk" as root.

On Wed, 2 May 2001, Simon Pabst wrote:

> Thanks, but this doesn't solve anything -
> I don't think this is APIC-related.
> It's NOT the boot.img bootdisk to start the installation
> that locks up, it's after using the installer-created bootdisk
> (instead of LILO) to boot the installed system.
>
> - Simon
>
> > "Russell Cattelan wrote:"
> > > The boot images has APIC enabled to solve a problem with the SGI 1200's
> > > apparently enabling this does break on some motherboards.
> >
> > boot with "noapic" as one of the boot parameters.
> >
> > > One option is to download the Release-1.0-test3 iso image.... err
> > > scratch that download the bootnet.img from the test3 dir.
> >
> > Peter
> >
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 03:26:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42AQrO26137
	for linux-xfs-outgoing; Wed, 2 May 2001 03:26:53 -0700
Received: from mx02.uni-tuebingen.de (mx02.uni-tuebingen.de [134.2.3.12])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AQnF26126
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:26:49 -0700
Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15])
	by mx02.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id MAA19863;
	Wed, 2 May 2001 12:26:45 +0200
Received: from chimaera (pool4019.studentenheim.uni-tuebingen.de [134.2.214.19])
	by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id MAA02756;
	Wed, 2 May 2001 12:26:45 +0200
Message-ID: <006901c0d2f2$b00fd4c0$0a42a8c0@chimaera>
From: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>
To: <linux-xfs@oss.sgi.com>
Cc: "Mike Burger" <mburger@compucomis.net>
References: <Pine.LNX.4.33.0105020618220.929-100000@linux.compucomis.net>
Subject: Re: XFS 1.0 RH7.1 won't boot
Date: Wed, 2 May 2001 12:28:24 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

No, I skipped LILO installation because the RH-installer
suggested it - I suppose Redhat still uses a LILO that
has problems with partitions beyond 1024 cylinder?
I am new to Redhat - I use SuSE on my other pc's, so
I am not sure.
But I have created several bootdisks, and none of them
can boot my partition, so I don't think it's a floppy problem
Looks like I got to do it the hard way - install RH7.1 with ext2,
which works without problems, and change to
a XFS root later on.

thanks
- Simon

> Does the system boot without the boot disk, ie, via the HD?
>
> If so, recreate your boot disk by running "mkbootdisk" as root.
>
> On Wed, 2 May 2001, Simon Pabst wrote:
>
> > Thanks, but this doesn't solve anything -
> > I don't think this is APIC-related.
> > It's NOT the boot.img bootdisk to start the installation
> > that locks up, it's after using the installer-created bootdisk
> > (instead of LILO) to boot the installed system.
> >
> > - Simon
> >
> > > "Russell Cattelan wrote:"
> > > > The boot images has APIC enabled to solve a problem with the SGI
1200's
> > > > apparently enabling this does break on some motherboards.
> > >
> > > boot with "noapic" as one of the boot parameters.
> > >
> > > > One option is to download the Release-1.0-test3 iso image.... err
> > > > scratch that download the bootnet.img from the test3 dir.
> > >
> > > Peter
> > >
> >
> >
>


From owner-linux-xfs@oss.sgi.com Wed May  2 03:35:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42AZaf26398
	for linux-xfs-outgoing; Wed, 2 May 2001 03:35:36 -0700
Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AZWF26386
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:35:32 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id 9DDA2BC19; Wed,  2 May 2001 06:35:29 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by linux.compucomis.net (Postfix) with ESMTP
	id CD1373FBD; Wed,  2 May 2001 06:35:29 -0400 (EDT)
Date: Wed, 2 May 2001 06:35:28 -0400 (EDT)
From: Mike Burger <mburger@compucomis.net>
To: Simon Pabst <simon.pabst@student.uni-tuebingen.de>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <006901c0d2f2$b00fd4c0$0a42a8c0@chimaera>
Message-ID: <Pine.LNX.4.33.0105020634170.929-100000@linux.compucomis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That could be a problem. <G>

FWIW, just to be safe, when I install, I create a small partition for
/boot (10-15MB should be more than enough) at the beginning of my HD, to
keep LILO and all the boot info inside the 1024 cylinder mark.

On Wed, 2 May 2001, Simon Pabst wrote:

> No, I skipped LILO installation because the RH-installer
> suggested it - I suppose Redhat still uses a LILO that
> has problems with partitions beyond 1024 cylinder?
> I am new to Redhat - I use SuSE on my other pc's, so
> I am not sure.
> But I have created several bootdisks, and none of them
> can boot my partition, so I don't think it's a floppy problem
> Looks like I got to do it the hard way - install RH7.1 with ext2,
> which works without problems, and change to
> a XFS root later on.
>
> thanks
> - Simon
>
> > Does the system boot without the boot disk, ie, via the HD?
> >
> > If so, recreate your boot disk by running "mkbootdisk" as root.
> >
> > On Wed, 2 May 2001, Simon Pabst wrote:
> >
> > > Thanks, but this doesn't solve anything -
> > > I don't think this is APIC-related.
> > > It's NOT the boot.img bootdisk to start the installation
> > > that locks up, it's after using the installer-created bootdisk
> > > (instead of LILO) to boot the installed system.
> > >
> > > - Simon
> > >
> > > > "Russell Cattelan wrote:"
> > > > > The boot images has APIC enabled to solve a problem with the SGI
> 1200's
> > > > > apparently enabling this does break on some motherboards.
> > > >
> > > > boot with "noapic" as one of the boot parameters.
> > > >
> > > > > One option is to download the Release-1.0-test3 iso image.... err
> > > > > scratch that download the bootnet.img from the test3 dir.
> > > >
> > > > Peter
> > > >
> > >
> > >
> >
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 03:39:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42AdR326512
	for linux-xfs-outgoing; Wed, 2 May 2001 03:39:27 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AdOF26509
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:39:24 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f42AdLK05188;
	Wed, 2 May 2001 12:39:21 +0200
Message-Id: <4.3.2.7.2.20010502121155.034d5dd0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 May 2001 12:39:28 +0200
To: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>,
   <linux-xfs@oss.sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <005c01c0d2da$06bd8100$0a42a8c0@chimaera>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 09:31 2-5-2001 +0200, Simon Pabst wrote:
>Hi,
>I downloaded and installed the 1.0-XFS-Redhat ISOs, but the
>system does not boot - instead it locks up after
> > RAMDISK - compressed image found at block 0
>I used the boot.img bootdisk because I have a non-bootable
>cdrom drive, I hope this isn't a problem?

Can't comment on that one. Should work.

>The partition I used is hdc2, beyond the 1024 cylinder, what
>might be a problem, but a stock-EXT2-Redhat 7.1 can run
>without any trouble from hdc2.
>Did I miss something important or is this an installer related
>bug?

The installer I used (test4 iso image) gave an error that /boot was above 
1024 cylinders on my notebook. Which is nonsense since it actually should 
try to use lba32 instead. Because I know it works.
Or print a warning that it might not bootable after installation and 
suggest making the floppy.


>- Simon

Bye
Seth
--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Wed May  2 03:46:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Akhb26671
	for linux-xfs-outgoing; Wed, 2 May 2001 03:46:43 -0700
Received: from mx02.uni-tuebingen.de (mx02.uni-tuebingen.de [134.2.3.12])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AkeF26666
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:46:40 -0700
Received: from mailserv05.uni-tuebingen.de (mailserv05.uni-tuebingen.de [192.168.3.15])
	by mx02.uni-tuebingen.de (8.9.3/8.9.3) with ESMTP id MAA21365;
	Wed, 2 May 2001 12:46:33 +0200
Received: from chimaera (pool4019.studentenheim.uni-tuebingen.de [134.2.214.19])
	by mailserv05.uni-tuebingen.de (8.9.3/8.9.3) with SMTP id MAA04519;
	Wed, 2 May 2001 12:46:33 +0200
Message-ID: <008e01c0d2f5$74702160$0a42a8c0@chimaera>
From: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>
To: <linux-xfs@oss.sgi.com>
Cc: "Seth Mos" <knuffie@xs4all.nl>
References: <4.3.2.7.2.20010502121155.034d5dd0@pop.xs4all.nl>
Subject: Re: XFS 1.0 RH7.1 won't boot
Date: Wed, 2 May 2001 12:48:12 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> At 09:31 2-5-2001 +0200, Simon Pabst wrote:
> >Hi,
> >I downloaded and installed the 1.0-XFS-Redhat ISOs, but the
> >system does not boot - instead it locks up after
> > > RAMDISK - compressed image found at block 0
> >I used the boot.img bootdisk because I have a non-bootable
> >cdrom drive, I hope this isn't a problem?
>
> Can't comment on that one. Should work.
>
> >The partition I used is hdc2, beyond the 1024 cylinder, what
> >might be a problem, but a stock-EXT2-Redhat 7.1 can run
> >without any trouble from hdc2.
> >Did I miss something important or is this an installer related
> >bug?
>
> The installer I used (test4 iso image) gave an error that /boot was above
> 1024 cylinders on my notebook. Which is nonsense since it actually should
> try to use lba32 instead. Because I know it works.
> Or print a warning that it might not bootable after installation and
> suggest making the floppy.

that's exactly what it did suggest - and so I did, but this
disk isn't capable of booting my system, it stops after the RAMDISK...
line.
Do you think it might work if I move /boot to the beginning of hda?
I have a boot partition there, but it is used otherwise right now,
so this would mean some work.

thanks
- Simon



From owner-linux-xfs@oss.sgi.com Wed May  2 03:57:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42AvtK27059
	for linux-xfs-outgoing; Wed, 2 May 2001 03:57:55 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42AvnF27055
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 03:57:50 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f42AvkK05280;
	Wed, 2 May 2001 12:57:46 +0200
Message-Id: <4.3.2.7.2.20010502125705.0377cdd8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 02 May 2001 12:57:53 +0200
To: "Simon Pabst" <simon.pabst@student.uni-tuebingen.de>,
   <linux-xfs@oss.sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <008e01c0d2f5$74702160$0a42a8c0@chimaera>
References: <4.3.2.7.2.20010502121155.034d5dd0@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 12:48 2-5-2001 +0200, Simon Pabst wrote:
> > At 09:31 2-5-2001 +0200, Simon Pabst wrote:
> > >Hi,
> > >I downloaded and installed the 1.0-XFS-Redhat ISOs, but the
> > >system does not boot - instead it locks up after
> > > > RAMDISK - compressed image found at block 0
> > >I used the boot.img bootdisk because I have a non-bootable
> > >cdrom drive, I hope this isn't a problem?
> >
> > Can't comment on that one. Should work.
> >
> > >The partition I used is hdc2, beyond the 1024 cylinder, what
> > >might be a problem, but a stock-EXT2-Redhat 7.1 can run
> > >without any trouble from hdc2.
> > >Did I miss something important or is this an installer related
> > >bug?
> >
> > The installer I used (test4 iso image) gave an error that /boot was above
> > 1024 cylinders on my notebook. Which is nonsense since it actually should
> > try to use lba32 instead. Because I know it works.
> > Or print a warning that it might not bootable after installation and
> > suggest making the floppy.
>
>that's exactly what it did suggest - and so I did, but this
>disk isn't capable of booting my system, it stops after the RAMDISK...
>line.
>Do you think it might work if I move /boot to the beginning of hda?
>I have a boot partition there, but it is used otherwise right now,
>so this would mean some work.

Yes this does work. I just made a /boot of 50M and the install went fine 
after that.


>thanks
>- Simon

Bye



--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Wed May  2 07:35:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42EZDM06949
	for linux-xfs-outgoing; Wed, 2 May 2001 07:35:13 -0700
Received: from gate.front.se ([193.15.243.114])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42EZAF06946
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 07:35:11 -0700
Received: from [(hidden)] by gate.front.se
	for linux-xfs@oss.sgi.com
	id QAA01009; Wed May  2 16:33:45 2001
Message-ID: <E374F34816D3BE49AA6A2C375231909604F2E2@mailsto01.front.se>
Subject: Unable to create XFS tree via patchfile
Date: Wed, 2 May 2001 16:35:59 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
From: Jan Jonasson <jan.jonasson@front.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,
I was not able to install XFS from the patch-files!

This is my setup/result:

//
[root@lin02 src]# pwd
/usr/src
[root@lin02 src]# cat /etc/issue

Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.4-pre6 on an i586

[root@lin02 src]# ls -l
total 196k
lrwxrwxrwx    1 root     root           11 May  2 15:01 linux ->
linux-2.4.4/
-rw-r--r--    1 root     root         179k May  2 15:53
linux-2.4.3-core-xfs-1.0.patch
drwxr-xr-x   14 1046     101          4.0k May  2 15:35 linux-2.4.4/
drwxr-xr-x   14 1046     101          4.0k Apr 24 11:56
old-linux-2.4.4-pre6/
drwxr-xr-x    7 root     root         4.0k Apr 20 16:07 redhat/
[root@lin02 src]# patch -p1 < linux-2.4.3-core-xfs-1.0.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- /export/extra/lxfs-cvs/linux-2.4.3/linux/Documentation/Changes     Tue
Mar  6 21:44:34 2001
|+++ linux/Documentation/Changes        Mon Apr 23 20:45:41 2001
--------------------------
File to patch: 
[root@lin02 src]# 

//

Any suggestions ??

/Janne Jonasson


From owner-linux-xfs@oss.sgi.com Wed May  2 07:50:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Eonf07587
	for linux-xfs-outgoing; Wed, 2 May 2001 07:50:49 -0700
Received: from foehn100.plesnik.bonsai.de (mail.plesnik.de [212.117.70.78])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42EoiF07584
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 07:50:44 -0700
Received: from quickstep.plesnik.bonsai.de (root@quickstep.plesnik.bonsai.de [192.168.103.212])
	by foehn100.plesnik.bonsai.de (8.9.1/8.9.1) with ESMTP id QAA25383
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 16:48:01 +0200
Received: (from mas@localhost)
	by quickstep.plesnik.bonsai.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f42EmAj21188
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 16:48:10 +0200
Date: Wed, 2 May 2001 16:48:10 +0200
From: Martin Spott <mas@plesnik.de>
To: linux-xfs@oss.sgi.com
Subject: Re: Unable to create XFS tree via patchfile
Message-ID: <20010502164810.A16064@quickstep.plesnik.bonsai.de>
References: <E374F34816D3BE49AA6A2C375231909604F2E2@mailsto01.front.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <E374F34816D3BE49AA6A2C375231909604F2E2@mailsto01.front.se>; from jan.jonasson@front.com on Wed, May 02, 2001 at 04:35:59PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 02, 2001 at 04:35:59PM +0200, Jan Jonasson wrote:

> [root@lin02 src]# patch -p1 < linux-2.4.3-core-xfs-1.0.patch

Is this the first time you're patching a kernel source tree ?  ;-)
Please change to /usr/src/linux/ and apply the patch in this directory,
using '-p1'.
BTW, you will not get linux-2.4.3-core-xfs-1.0.patch applied to the 2.4.4
source tree without manually correcting several rejects. I did this myself
and it was pretty time consuming,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed May  2 08:13:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FDAs08988
	for linux-xfs-outgoing; Wed, 2 May 2001 08:13:10 -0700
Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FD7F08984
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:13:08 -0700
Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [65.100.85.34])
	by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id JAA18427
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:09:44 -0600
Date: Wed, 2 May 2001 09:09:44 -0600 (MDT)
From: Russel Ingram <ringram@gargoylecc.com>
To: <linux-xfs@oss.sgi.com>
Subject: Re: XFS 1.0 RH7.1 won't boot
In-Reply-To: <006901c0d2f2$b00fd4c0$0a42a8c0@chimaera>
Message-ID: <Pine.LNX.4.33.0105020903320.18368-100000@roujin.gargoylecc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 2 May 2001, Simon Pabst wrote:

> No, I skipped LILO installation because the RH-installer
> suggested it - I suppose Redhat still uses a LILO that
> has problems with partitions beyond 1024 cylinder?

Just my $0.02 worth here ....

Seems to me that not installing LILO would more than likely be your
problem.  I have a couple of systems with drives that run past the 1024
cylinder mark with no /boot partition that boot just fine after the 7.1
installation.  lba32 is installed by default (whether you keep it under
the 1024 mark or not) and it works fine.  You might just try booting from
the installation disks again and using the rescue option to install a
lilo.


-- 
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com


From owner-linux-xfs@oss.sgi.com Wed May  2 08:13:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FDlZ09016
	for linux-xfs-outgoing; Wed, 2 May 2001 08:13:47 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FDkF09013
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:13:46 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f42FDhN28155;
	Wed, 2 May 2001 10:13:43 -0500 (CDT)
Message-ID: <3AF02478.371F24FF@sgi.com>
Date: Wed, 02 May 2001 10:15:04 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Pabst <simon.pabst@student.uni-tuebingen.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0 RH7.1 won't boot
References: <200105020804.f4284qX23956@oboe.it.uc3m.es> <000f01c0d2e0$83ef76f0$0a42a8c0@chimaera>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Simon Pabst wrote:
> 
> Thanks, but this doesn't solve anything -
> I don't think this is APIC-related.
> It's NOT the boot.img bootdisk to start the installation
> that locks up, it's after using the installer-created bootdisk
> (instead of LILO) to boot the installed system.

Ah, that's the problem.  If you're booting off the installer-created
boot floppy, odds are the kernel was too big to fit on the floppy, and
that's why it's failing.  We really need to add a warning and/or check
to the "make boot floppy" option - or just disable it.  It's tough to
fit XFS + scsi drivers on a boot floppy...

If you want to get in and muck around w/ your system to make it boot
from the hard drive, try booting into installer rescue mode with "linux
rescue" at the installer lilo prompt.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 08:17:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FHGB09123
	for linux-xfs-outgoing; Wed, 2 May 2001 08:17:16 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FHEF09120
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:17:14 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f42FGLN28985;
	Wed, 2 May 2001 10:16:21 -0500 (CDT)
Message-ID: <3AF02515.4C0838E6@sgi.com>
Date: Wed, 02 May 2001 10:17:41 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
CC: David Benigni <benigni@cse.psu.edu>, linux-xfs@oss.sgi.com
Subject: Re: swapon error
References: <Pine.A41.4.10.10105020812001.57450-100000@comet.vcu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

K Mitchell Russell wrote:

> One more annoyance probably related to devfs is the failed umount of
> /dev on shutdown of my system.  I get a message something to the effect
> of:
> 
> unmounting file system:  umount2 failed device busy
>         resource or device /dev busy                    [failed]
> (this is paraphrased from memory, as syslogd is shutdown by this point)

Yep, I get this too.

Again, it should be harmless (rebooting with a _virtual_ filesystem
still mounted should cause no problems) but I'd like to get rid of it as
well...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 08:19:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FJS509187
	for linux-xfs-outgoing; Wed, 2 May 2001 08:19:28 -0700
Received: from apeiba.wanadoo.fr (smtp-rt-2.wanadoo.fr [193.252.19.154])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FJMF09179
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:19:24 -0700
Received: from amyris.wanadoo.fr (193.252.19.150) by apeiba.wanadoo.fr; 2 May 2001 17:19:14 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by amyris.wanadoo.fr; 2 May 2001 17:19:02 +0200
Subject: SGI CD installer and RedHat disc1: two in one
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: linux-xfs <linux-xfs@oss.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 17:20:30 +0200
Message-Id: <988816831.4045.0.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

I have mixed SGI CD and RedHat disc1 in one CD.
It works but I would like to modify the installer to not ask for SGI CD
(whereas it is the same) thus avoiding one CD swap.
I just create .disc3-i386 on CD 1 to avoid anaconda to crash and it's
worked.

I looked at anaconda-7.1-xfs.patch from src.rpm but i do not have finds
my happiness.

Finally, can somebody explain me the use of --fileorder argument to
genhdlist binary ?

Thanks in advance and cheer for you remarkable work @ SGI around Linux

-David


From owner-linux-xfs@oss.sgi.com Wed May  2 08:25:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FPGT09506
	for linux-xfs-outgoing; Wed, 2 May 2001 08:25:16 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FPEF09500
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:25:14 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f42FP9502837;
	Wed, 2 May 2001 10:25:09 -0500 (CDT)
Message-ID: <3AF02727.CC69EC6A@sgi.com>
Date: Wed, 02 May 2001 10:26:31 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Martin Spott <mas@plesnik.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: Unable to create XFS tree via patchfile
References: <E374F34816D3BE49AA6A2C375231909604F2E2@mailsto01.front.se> <20010502164810.A16064@quickstep.plesnik.bonsai.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Martin Spott wrote:
> 
> On Wed, May 02, 2001 at 04:35:59PM +0200, Jan Jonasson wrote:
> 
> > [root@lin02 src]# patch -p1 < linux-2.4.3-core-xfs-1.0.patch
> 
> Is this the first time you're patching a kernel source tree ?  ;-)
> Please change to /usr/src/linux/ and apply the patch in this directory,
> using '-p1'.

That's partly our fault - the patch used to apply 1 level higher (since
it patched linux/ and created cmds/) and the instructions on the web
page are wrong.  I'll fix that, sorry!

Martin's right, though, apply it in the linux/ directory rather than
it's parent directory.

He's also right that you REALLY only want to apply the 2.4.3 patch to a
2.4.3 kernel.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 08:26:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FQbV09590
	for linux-xfs-outgoing; Wed, 2 May 2001 08:26:37 -0700
Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FQaF09587
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:26:36 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id 78DE8BC19; Wed,  2 May 2001 11:26:36 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by linux.compucomis.net (Postfix) with ESMTP
	id 72A513FA1; Wed,  2 May 2001 11:26:36 -0400 (EDT)
Date: Wed, 2 May 2001 11:26:36 -0400 (EDT)
From: Mike Burger <mburger@compucomis.net>
To: "redhat.angus" <redhat.angus@wanadoo.fr>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: SGI CD installer and RedHat disc1: two in one
In-Reply-To: <988816831.4045.0.camel@adslgw>
Message-ID: <Pine.LNX.4.33.0105021125540.3437-100000@linux.compucomis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The SGI and RH Disc1 CDs aren't the same...the SGI CD has much less on it
than the RH1 CD, and installation requires at least the SGI and RH CD1, if
not RH CD2.

On 2 May 2001, redhat.angus wrote:

> Hello,
>
> I have mixed SGI CD and RedHat disc1 in one CD.
> It works but I would like to modify the installer to not ask for SGI CD
> (whereas it is the same) thus avoiding one CD swap.
> I just create .disc3-i386 on CD 1 to avoid anaconda to crash and it's
> worked.
>
> I looked at anaconda-7.1-xfs.patch from src.rpm but i do not have finds
> my happiness.
>
> Finally, can somebody explain me the use of --fileorder argument to
> genhdlist binary ?
>
> Thanks in advance and cheer for you remarkable work @ SGI around Linux
>
> -David
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 08:31:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FV8x09732
	for linux-xfs-outgoing; Wed, 2 May 2001 08:31:08 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FV7F09729
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:31:07 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f42FV0504733;
	Wed, 2 May 2001 10:31:00 -0500 (CDT)
Message-ID: <3AF02886.1FDA8E02@sgi.com>
Date: Wed, 02 May 2001 10:32:22 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "redhat.angus" <redhat.angus@wanadoo.fr>
CC: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: SGI CD installer and RedHat disc1: two in one
References: <988816831.4045.0.camel@adslgw>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"redhat.angus" wrote:
> 
> Hello,
> 
> I have mixed SGI CD and RedHat disc1 in one CD.
> It works but I would like to modify the installer to not ask for SGI CD
> (whereas it is the same) thus avoiding one CD swap.
> I just create .disc3-i386 on CD 1 to avoid anaconda to crash and it's
> worked.
> 
> I looked at anaconda-7.1-xfs.patch from src.rpm but i do not have finds
> my happiness.

Look at line 173 in the patched image.py - change

self.currentDisc = 3

to

self.currentDisc = 1

and put .disc1-i386 on your combination CD - that should do it.
 
> Finally, can somebody explain me the use of --fileorder argument to
> genhdlist binary ?

You may not need to use it if you only have 2 discs... basically, you
can pass a modified installation order (just a list of RPMs) into
genhdlist, and that will put the install order in the generated hdlist. 
Otherwise, it will use a default order based on dependencies, and you
may wind up with extra disc swaps.

HTH,

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 08:51:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42FpNF10464
	for linux-xfs-outgoing; Wed, 2 May 2001 08:51:23 -0700
Received: from femail11.sdc1.sfba.home.com (femail11.sdc1.sfba.home.com [24.0.95.107])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42FpLF10458
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 08:51:21 -0700
Received: from david ([65.2.16.49]) by femail11.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010502155119.TWUK22926.femail11.sdc1.sfba.home.com@david>;
          Wed, 2 May 2001 08:51:19 -0700
Message-ID: <008b01c0d31f$b6acaab0$0a00a8c0@david>
From: "David Benigni" <benigni@cse.psu.edu>
To: "Eric Sandeen" <sandeen@sgi.com>,
   "K Mitchell Russell" <kmrussel@hsc.vcu.edu>
Cc: <linux-xfs@oss.sgi.com>
References: <Pine.A41.4.10.10105020812001.57450-100000@comet.vcu.edu> <3AF02515.4C0838E6@sgi.com>
Subject: Re: swapon error
Date: Wed, 2 May 2001 11:51:12 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Count me in too on that error as well.

So, basically, these errors are devfs problems correct?

David P. Benigni II


----- Original Message ----- 

> K Mitchell Russell wrote:
> 
> > One more annoyance probably related to devfs is the failed umount of
> > /dev on shutdown of my system.  I get a message something to the effect
> > of:
> > 
> > unmounting file system:  umount2 failed device busy
> >         resource or device /dev busy                    [failed]
> > (this is paraphrased from memory, as syslogd is shutdown by this point)
> 
> Yep, I get this too.
> 
> Again, it should be harmless (rebooting with a _virtual_ filesystem
> still mounted should cause no problems) but I'd like to get rid of it as
> well...
> 
> -Eric
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  2 09:03:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42G3gZ11702
	for linux-xfs-outgoing; Wed, 2 May 2001 09:03:42 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G3eF11699
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:03:41 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f42G1fU10799;
	Wed, 2 May 2001 11:01:41 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 2 May 2001 11:01:40 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: David Benigni <benigni@cse.psu.edu>,
   Rajagopal Ananthanarayanan <ananth@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: Re: swapon error
In-Reply-To: <3AEF6F01.1EF38AE4@sgi.com>
Message-ID: <Pine.LNX.4.33.0105021100580.10052-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

There are 2 sections in rc.sysinit which call swapon -a. The last one,
line 628 or something like that, maybe it was 648, anyway, just comment
that out, Swap has already been enabled.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 1 May 2001, Eric Sandeen wrote:

> David Benigni wrote:
> >
> > I don't know if it is on not.  I'm assuming so, because after on the second
> > boot, I still get the error but says it started "ok."
>
> That's because they call "swapon -a" and then pass /bin/true to the part
> of the script that generates "ok"
>
> Your system could be melting, and that particular line of the boot
> scripts would still generate a cheery green
>
> [OK]
>
> :)
>
> -Eric
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 09:04:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42G4RE11765
	for linux-xfs-outgoing; Wed, 2 May 2001 09:04:27 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G4QF11758
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:04:26 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f42G2ac10813;
	Wed, 2 May 2001 11:02:36 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 2 May 2001 11:02:36 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Alan Eldridge <alane@geeksrus.net>
cc: <tvignaud@mandrakesoft.com>, <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
In-Reply-To: <20010502000814.A16705@wwweasel.geeksrus.net>
Message-ID: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 2 May 2001, Alan Eldridge wrote:

> I'm running SGI's XFS-based version of RH 7.1, which in turn uses your
> patched version of devfsd. Since this version of devfsd has a home with the
> Mandrake distribution, I figured this would be the most appropriate way to
> report a bug.
>
> The code for saving and restoring the permissions has got it *half* right.
> Yup, the event is triggered and the copy happens. But it happens *before*
> the underlying device node has been altered. The semantics thus become,
> "save the previous state to restore, and then modify the device node". This
> leaves something to be desired.
>
> The work around, of course, is if you need to change the perms on anything
> under /dev, do it *twice*. Then the first changed device node will get
> copied before the second (identical, hence no-op) change is applied.
>
> I'll try to work up a patch in a day or two; OTOH if you know where the
> culprit lies already, please advise me and send me (and SGI) the patch you
> come up with.
>
> Oh, and another thing.... :)
>
> I'm not sure if this is a bug or a feature, but if you have cases where
> a device name would match more than one event regexp, it seems that only the
> (first? last? I can't remember which) one happens.
>
> So, order notwithstanding, if you've got, e.g.,
>
> REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath $mntpath
> REGISTER ^cdroms/cdrom0$ EXECUTE /bin/ln -s $devname cdrom
>
> only one of those two things is going to happen (I think the latter). This
> kinda sucks, especially for the exact case I used. There's fsck-all
> different names for cdrom devices (cdrom, cdrom0, scd0, sr0, cdroms/cdrom0,
> your/mommas/cdrom/0, scsi/host0/bus0/target3/lun0/{cd,generic}), and
> wouldn't you know there's gotta be some piece of software that is going to
> want *each* possible variation... (think: RedHat's kudzu and "updfstab").
>
> It would be ever so nice if the multiple matching case thing performed all
> matching actions, instead of the one most recent. It would also be *really*
> nice to have a way to get at the regex match parts:
>
> REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath scd$1
>
> or something like that. (I know, I know, matching the bits of the RE can be
> a royal PITA, and this isn't really meant to be "sed", but some way to pick
> out the matching numeric portion of the name would really help.)
>
> Okay. I'm done. :)
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 09:06:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42G6vl11922
	for linux-xfs-outgoing; Wed, 2 May 2001 09:06:57 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G6uF11919
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:06:56 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f42G4bO10829;
	Wed, 2 May 2001 11:04:37 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 2 May 2001 11:04:37 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: David Benigni <benigni@cse.psu.edu>
cc: Eric Sandeen <sandeen@sgi.com>, K Mitchell Russell <kmrussel@hsc.vcu.edu>,
   <linux-xfs@oss.sgi.com>
Subject: Re: swapon error
In-Reply-To: <008b01c0d31f$b6acaab0$0a00a8c0@david>
Message-ID: <Pine.LNX.4.33.0105021104160.10052-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Naah..it just tries to turn swap on 2 times in rc.sysinit

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 2 May 2001, David Benigni wrote:

> Count me in too on that error as well.
>
> So, basically, these errors are devfs problems correct?
>
> David P. Benigni II
>
>
> ----- Original Message -----
>
> > K Mitchell Russell wrote:
> >
> > > One more annoyance probably related to devfs is the failed umount of
> > > /dev on shutdown of my system.  I get a message something to the effect
> > > of:
> > >
> > > unmounting file system:  umount2 failed device busy
> > >         resource or device /dev busy                    [failed]
> > > (this is paraphrased from memory, as syslogd is shutdown by this point)
> >
> > Yep, I get this too.
> >
> > Again, it should be harmless (rebooting with a _virtual_ filesystem
> > still mounted should cause no problems) but I'd like to get rid of it as
> > well...
> >
> > -Eric
> >
> > --
> > Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> > sandeen@sgi.com   SGI, Inc.
>


From owner-linux-xfs@oss.sgi.com Wed May  2 09:07:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42G73a11937
	for linux-xfs-outgoing; Wed, 2 May 2001 09:07:03 -0700
Received: from hotmail.com (f31.law14.hotmail.com [64.4.21.31])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G73F11934
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:07:03 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 2 May 2001 09:06:58 -0700
Received: from 216.47.248.113 by lw14fd.law14.hotmail.msn.com with HTTP;	Wed, 02 May 2001 16:06:57 GMT
X-Originating-IP: [216.47.248.113]
From: "Peter Pauly" <paulypeter@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: Anyone have any luck with the RPMs?
Date: Wed, 02 May 2001 09:06:57 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F31r9oD6XMLDthODt9C00012b83@hotmail.com>
X-OriginalArrivalTime: 02 May 2001 16:06:58.0055 (UTC) FILETIME=[EA0E2170:01C0D321]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I tried installing the kernel RPM at:
http://www.smithconcepts.com/files/xfs/kernel-2.4.2-xfscvs_feb24/i386/
on a relatively fresh and virgin retail Redhat 7.1 system. It got part way 
through the installation and complained about a MD5 mismatch on a "arlan.o" 
module. I couldn't see any way to turn off MD5 checking during the install 
(you can do it for a verify), so I'm stuck. I prefer not to do the full 
blown install from the XFS ISO. I can always build a new kernel from scratch 
if I have to, but the RPM's would have been nice.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-linux-xfs@oss.sgi.com Wed May  2 09:08:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42G84C11971
	for linux-xfs-outgoing; Wed, 2 May 2001 09:08:04 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42G84F11968
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:08:04 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f42G80M16696;
	Wed, 2 May 2001 11:08:00 -0500 (CDT)
Message-ID: <3AF03131.319A28C7@sgi.com>
Date: Wed, 02 May 2001 11:09:21 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: David Benigni <benigni@cse.psu.edu>,
   Rajagopal Ananthanarayanan <ananth@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: swapon error
References: <Pine.LNX.4.33.0105021100580.10052-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> There are 2 sections in rc.sysinit which call swapon -a. The last one,
> line 628 or something like that, maybe it was 648, anyway, just comment
> that out, Swap has already been enabled.

FWIW, apparently the second one is to enable swap _files_ as opposed to
swap _partitions_.

Enabling swap _files_ can't happen until after all the filesystems are
mounted, that's the reason for the "late" second swapon.  If you don't
use swap files, then you're right, just comment it out.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 09:11:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GBNu12148
	for linux-xfs-outgoing; Wed, 2 May 2001 09:11:23 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GBNF12143
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:11:23 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f42GBLM18334;
	Wed, 2 May 2001 11:11:21 -0500 (CDT)
Message-ID: <3AF031FB.445D4F7D@sgi.com>
Date: Wed, 02 May 2001 11:12:43 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>, linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?

The devfsd "version" that comes with Red Hat Linux is deceptive - they
generate it out of the kernel SRPM, and it gets the same version as the
kernel.

The actual devfsd version is still 1.3.x, it's just that the rpm is
versioned differently for some reason.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 09:13:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GDUh12267
	for linux-xfs-outgoing; Wed, 2 May 2001 09:13:30 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GDTF12264
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:13:29 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f42GDSU19169;
	Wed, 2 May 2001 11:13:28 -0500 (CDT)
Message-ID: <3AF03279.3C13C242@sgi.com>
Date: Wed, 02 May 2001 11:14:49 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Pauly <paulypeter@hotmail.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Anyone have any luck with the RPMs?
References: <F31r9oD6XMLDthODt9C00012b83@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Peter Pauly wrote:
> 
> I tried installing the kernel RPM at:
> http://www.smithconcepts.com/files/xfs/kernel-2.4.2-xfscvs_feb24/i386/
> on a relatively fresh and virgin retail Redhat 7.1 system. It got part way
> through the installation and complained about a MD5 mismatch on a "arlan.o"
> module. I couldn't see any way to turn off MD5 checking during the install
> (you can do it for a verify), so I'm stuck. I prefer not to do the full
> blown install from the XFS ISO. I can always build a new kernel from scratch
> if I have to, but the RPM's would have been nice.

For starters, those are ANCIENT, unsupported, cvs snapshot rpms.  Go to
oss.sgi.com/projects/xfs and get some fresh ones - see how that goes.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 09:24:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GOJK13096
	for linux-xfs-outgoing; Wed, 2 May 2001 09:24:19 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GOIF13092
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:24:18 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f42GO4h10965;
	Wed, 2 May 2001 11:24:04 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 2 May 2001 11:24:03 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
In-Reply-To: <3AF031FB.445D4F7D@sgi.com>
Message-ID: <Pine.LNX.4.33.0105021123560.10052-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

So is it ok to use it then?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 2 May 2001, Eric Sandeen wrote:

> Austin Gonyou wrote:
> >
> > Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?
>
> The devfsd "version" that comes with Red Hat Linux is deceptive - they
> generate it out of the kernel SRPM, and it gets the same version as the
> kernel.
>
> The actual devfsd version is still 1.3.x, it's just that the rpm is
> versioned differently for some reason.
>
> -Eric
>
>


From owner-linux-xfs@oss.sgi.com Wed May  2 09:24:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GOtV13135
	for linux-xfs-outgoing; Wed, 2 May 2001 09:24:55 -0700
Received: from hotmail.com (f37.law14.hotmail.com [64.4.21.37])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GOsF13128
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:24:54 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 2 May 2001 09:24:48 -0700
Received: from 216.47.248.113 by lw14fd.law14.hotmail.msn.com with HTTP;	Wed, 02 May 2001 16:24:48 GMT
X-Originating-IP: [216.47.248.113]
From: "Peter Pauly" <paulypeter@hotmail.com>
To: sandeen@sgi.com
Cc: linux-xfs@oss.sgi.com
Subject: Re: Anyone have any luck with the RPMs?
Date: Wed, 02 May 2001 09:24:48 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F37B1FxQFM83UV8wAdd00001f14@hotmail.com>
X-OriginalArrivalTime: 02 May 2001 16:24:48.0377 (UTC) FILETIME=[68044E90:01C0D324]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks for the tip. The ones I was using are referenced in the FAQ at
http://linux-xfs.sgi.com/projects/xfs/faq.html. Does the FAQ need to be 
updated?


>From: Eric Sandeen <sandeen@sgi.com>
>To: Peter Pauly <paulypeter@hotmail.com>
>CC: linux-xfs@oss.sgi.com
>Subject: Re: Anyone have any luck with the RPMs?
>Date: Wed, 02 May 2001 11:14:49 -0500
>
>Peter Pauly wrote:
> >
> > I tried installing the kernel RPM at:
> > http://www.smithconcepts.com/files/xfs/kernel-2.4.2-xfscvs_feb24/i386/
> > on a relatively fresh and virgin retail Redhat 7.1 system. It got part 
>way
> > through the installation and complained about a MD5 mismatch on a 
>"arlan.o"
> > module. I couldn't see any way to turn off MD5 checking during the 
>install
> > (you can do it for a verify), so I'm stuck. I prefer not to do the full
> > blown install from the XFS ISO. I can always build a new kernel from 
>scratch
> > if I have to, but the RPM's would have been nice.
>
>For starters, those are ANCIENT, unsupported, cvs snapshot rpms.  Go to
>oss.sgi.com/projects/xfs and get some fresh ones - see how that goes.
>
>-Eric
>
>--
>Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
>sandeen@sgi.com   SGI, Inc.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-linux-xfs@oss.sgi.com Wed May  2 09:28:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GS0U13389
	for linux-xfs-outgoing; Wed, 2 May 2001 09:28:00 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GRxF13385
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:27:59 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f42GRvU25658;
	Wed, 2 May 2001 11:27:57 -0500 (CDT)
Message-ID: <3AF034FD.A274998F@sgi.com>
Date: Wed, 02 May 2001 11:25:33 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_0.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Pauly <paulypeter@hotmail.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Anyone have any luck with the RPMs?
References: <F37B1FxQFM83UV8wAdd00001f14@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Peter Pauly wrote:
> 
> Thanks for the tip. The ones I was using are referenced in the FAQ at
> http://linux-xfs.sgi.com/projects/xfs/faq.html. Does the FAQ need to be
> updated?

Yep.  :)

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 09:28:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GSZ013446
	for linux-xfs-outgoing; Wed, 2 May 2001 09:28:35 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GSYF13443
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:28:34 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f42GSYU25952;
	Wed, 2 May 2001 11:28:34 -0500 (CDT)
Message-ID: <3AF03522.8ABA8B27@sgi.com>
Date: Wed, 02 May 2001 11:26:10 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_0.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105021123560.10052-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> So is it ok to use it then?

Sure, but I don't think you'll gain anything - experimentation should be
no problem though.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 09:35:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GZRj13796
	for linux-xfs-outgoing; Wed, 2 May 2001 09:35:27 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GZPF13789
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:35:26 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id MAA04254
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:35:23 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Wed, 2 May 2001 12:35:23 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: Linux xfs mailing list <linux-xfs@oss.sgi.com>
Subject: Module loading on log{in|out}
Message-ID: <Pine.LNX.4.30.0105021144400.4135-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

First off, let me congratulate everyone on a job well done getting 1.0
polished up and out the door.  Absolutely excellent.

I have a RH 7.1 system upgraded with the 1.0-Release RPMs.  Whenever I log
in or out on the console, the following occurs, as logged in
/var/log/messages (and `dmesg`, of course):

i2c-core.o: i2c core module
i2c-algo-bit.o: i2c bit algorithm module
Linux video capture interface: v1.00
bttv: driver version 0.7.57 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
bttv: Host bridge needs ETBF enabled.

An lsmod right after logging in does *not* show these modules loaded.  I'm
just curious as to what's going on and if I can stop it.  It's not fatal
or anything, but it does make the logs bigger (and may scare the users).
Thanks.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University



From owner-linux-xfs@oss.sgi.com Wed May  2 09:41:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GfSC14040
	for linux-xfs-outgoing; Wed, 2 May 2001 09:41:28 -0700
Received: from infa.abo.fi (IDENT:root@infa.abo.fi [130.232.208.126])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GfPF14036
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:41:25 -0700
Received: (from jweeriks@localhost)
	by infa.abo.fi (8.9.3/8.9.3) id TAA05882
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 19:41:21 +0300
Date: Wed, 2 May 2001 19:41:21 +0300
From: Johannes Eriksson <jweeriks@infa.abo.fi>
To: Linux xfs mailing list <linux-xfs@oss.sgi.com>
Subject: Re: Module loading on log{in|out}
Message-ID: <20010502194121.A4751@infa.abo.fi>
Mail-Followup-To: Linux xfs mailing list <linux-xfs@oss.sgi.com>
References: <Pine.LNX.4.30.0105021144400.4135-100000@chaos.egr.duke.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.10i
In-Reply-To: <Pine.LNX.4.30.0105021144400.4135-100000@chaos.egr.duke.edu>; from jlb17@duke.edu on Wed, May 02, 2001 at 12:35:23PM -0400
X-Operating-System: Linux 2.2.19
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Joshua Baker-LePain [Wed, May 02, 2001 at 12:35:23PM -0400]:
> First off, let me congratulate everyone on a job well done getting 1.0
> polished up and out the door.  Absolutely excellent.
> 
> I have a RH 7.1 system upgraded with the 1.0-Release RPMs.  Whenever I log
> in or out on the console, the following occurs, as logged in
> /var/log/messages (and `dmesg`, of course):
> 
> i2c-core.o: i2c core module
> i2c-algo-bit.o: i2c bit algorithm module
> Linux video capture interface: v1.00
> bttv: driver version 0.7.57 loaded
> bttv: using 2 buffers with 2080k (4160k total) for capture
> bttv: Host bridge needs ETBF enabled.
> 
> An lsmod right after logging in does *not* show these modules loaded.  I'm
> just curious as to what's going on and if I can stop it.  It's not fatal
> or anything, but it does make the logs bigger (and may scare the users).
> Thanks.
> 

I got rid of it by commenting out the lines 

alias           /dev/v4l                bttv
post-install bttv ln -sf /dev/video0 /dev/video
post-install bttv ln -sf /dev/vbi0 /dev/vbi

in /etc/modules.devfs

-- 
Johannes Eriksson
<joheriks@abo.fi>


From owner-linux-xfs@oss.sgi.com Wed May  2 09:44:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GixN14183
	for linux-xfs-outgoing; Wed, 2 May 2001 09:44:59 -0700
Received: from apicra.wanadoo.fr (smtp-rt-3.wanadoo.fr [193.252.19.155])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GivF14178
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:44:57 -0700
Received: from villosa.wanadoo.fr (193.252.19.122) by apicra.wanadoo.fr; 2 May 2001 18:44:50 +0200
Received: from ARennes-301-1-2-86.abo.wanadoo.fr (193.251.184.86) by villosa.wanadoo.fr; 2 May 2001 18:44:47 +0200
Subject: Re: SGI CD installer and RedHat disc1: two in one
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <3AF02886.1FDA8E02@sgi.com>
References: <988816831.4045.0.camel@adslgw>  <3AF02886.1FDA8E02@sgi.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 18:45:54 +0200
Message-Id: <988821955.808.0.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 02 May 2001 10:32:22 -0500, Eric Sandeen a écrit :
> Look at line 173 in the patched image.py - change
> 
> self.currentDisc = 3
> 
> to
> 
> self.currentDisc = 1
> 
> and put .disc1-i386 on your combination CD - that should do it.

Thank you very much I will test

> > Finally, can somebody explain me the use of --fileorder argument to
> > genhdlist binary ?
> 
> You may not need to use it if you only have 2 discs... basically, you
> can pass a modified installation order (just a list of RPMs) into
> genhdlist, and that will put the install order in the generated hdlist. 
> Otherwise, it will use a default order based on dependencies, and you
> may wind up with extra disc swaps.

OK

-David


From owner-linux-xfs@oss.sgi.com Wed May  2 09:46:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42GkTn14275
	for linux-xfs-outgoing; Wed, 2 May 2001 09:46:29 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GkSF14272
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:46:28 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f42Gk8B13535;
	Wed, 2 May 2001 11:46:08 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0471D.B17EDECF@thebarn.com>
Date: Wed, 02 May 2001 12:42:54 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: "redhat.angus" <redhat.angus@wanadoo.fr>,
   linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: SGI CD installer and RedHat disc1: two in one
References: <988816831.4045.0.camel@adslgw> <3AF02886.1FDA8E02@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:

> "redhat.angus" wrote:
> >
> > Hello,
> >
> > I have mixed SGI CD and RedHat disc1 in one CD.
> > It works but I would like to modify the installer to not ask for SGI CD
> > (whereas it is the same) thus avoiding one CD swap.
> > I just create .disc3-i386 on CD 1 to avoid anaconda to crash and it's
> > worked.
> >
> > I looked at anaconda-7.1-xfs.patch from src.rpm but i do not have finds
> > my happiness.
>
> Look at line 173 in the patched image.py - change
>
> self.currentDisc = 3
>
> to
>
> self.currentDisc = 1

BTW you will need to hack this change in to the stage2 image.
mount it up as ext2 via the loop device, and make the change.
or  completely rebuild anaconda and the installer images.


>

>
>
> and put .disc1-i386 on your combination CD - that should do it.
>
> > Finally, can somebody explain me the use of --fileorder argument to
> > genhdlist binary ?
>
> You may not need to use it if you only have 2 discs...

Order on the Red Hat dics have been modified.. you will need to pull the
list
and replace the kernel and devfs versions with the XFS versions.

> basically, you
> can pass a modified installation order (just a list of RPMs) into
> genhdlist, and that will put the install order in the generated hdlist.
> Otherwise, it will use a default order based on dependencies, and you
> may wind up with extra disc swaps.
>
> HTH,
>
> -Eric
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  2 09:56:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Guok14754
	for linux-xfs-outgoing; Wed, 2 May 2001 09:56:50 -0700
Received: from areca.wanadoo.fr (smtp-rt-4.wanadoo.fr [193.252.19.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42GukF14749
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 09:56:47 -0700
Received: from antholoma.wanadoo.fr (193.252.19.153) by areca.wanadoo.fr; 2 May 2001 18:56:40 +0200
Received: from ARennes-301-1-2-86.abo.wanadoo.fr (193.251.184.86) by antholoma.wanadoo.fr; 2 May 2001 18:56:19 +0200
Subject: Re: SGI CD installer and RedHat disc1: two in one
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <3AF0471D.B17EDECF@thebarn.com>
References: <988816831.4045.0.camel@adslgw> <3AF02886.1FDA8E02@sgi.com> 
	<3AF0471D.B17EDECF@thebarn.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 18:57:26 +0200
Message-Id: <988822647.809.1.camel@localhost.localdomain>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 02 May 2001 12:42:54 -0500, Russell Cattelan a écrit :
> BTW you will need to hack this change in to the stage2 image.
> mount it up as ext2 via the loop device, and make the change.
> or  completely rebuild anaconda and the installer images.

Thank you, modification of the image via the loop device is certainly more simple :)
I will test.

> Order on the Red Hat dics have been modified.. you will need to pull the
> list
> and replace the kernel and devfs versions with the XFS versions.

It is already done, thank you still.

-David


From owner-linux-xfs@oss.sgi.com Wed May  2 10:40:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Heu718139
	for linux-xfs-outgoing; Wed, 2 May 2001 10:40:56 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f42HesF18126
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 10:40:55 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 2 May 2001 17:40:54 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001050211371001:139781 ;
          Wed, 2 May 2001 11:37:10 -0600 
Received: from amis.com ([172.16.17.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001050211404839:13227 ;
          Wed, 2 May 2001 11:40:48 -0600 
Message-ID: <3AF0468B.70E8B919@amis.com>
Date: Wed, 02 May 2001 11:40:27 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: 2.4.4-xfs NFS testing
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 11:40:48 AM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 11:40:49 AM,
	Serialize complete at 05/02/2001 11:40:49 AM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 11:37:10 AM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 11:37:12 AM,
	Serialize complete at 05/02/2001 11:37:12 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

2.4.4 works great -- most of the time.

I started with a 2.4.4 clean tree and applied the
linux-2.4.4-xfs-TEST.patch.

(I have a hard time using cvs to get the tree -- our firewall is
default deny)

My hardware is Tyan 1854, PIII 866, 3com 905b, 3ware 6200 ide
controller, ibm 75G ide disk.
My base OS is SUSE 7.1
Linux linux 2.4.4-xfs #1 SMP
NFS v2 turned on. NFS v3 turned off.


Stress Testing:
---------------

Linux box acting as NFS server for solaris 2.8 boxes.

3 Solaris 2.8 boxes running 'while(true);do bonnie -s $size;done' on a
nfs v2 mount of a 68G xfs filesystem. I run the $size value
differently on all boxes so the read/writes are fairly randomized.
100M, 500M, 50M... 

The xfs box will run for almost 1 hr before it hangs. Will not respond
to ping. X-windows are hung. No virutal consoles available. Something
is not right. I have repeated this about 4 times in the last 12 hours.

Right now it appears to handle heavy nfs loads better than my
reiserfs/knfsd patched kernel while it is running, but the reiser
testing hasn't hung the box this bad.


Questions
---------
1. what debug can I do?
2. Is this a via chipset issue?
3. I'm using default args in mkfs.xfs and mount. Any suggestions for
changes there?


Thanks -- xfs looks pretty good right now.
eric








-- 
__________________________________________________________________
Eric T. Whiting					AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Wed May  2 10:54:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Hsu720767
	for linux-xfs-outgoing; Wed, 2 May 2001 10:54:56 -0700
Received: from pluto.runbox.com (pluto.runbox.com [193.71.199.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42HstF20764
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 10:54:55 -0700
Received: from dialin-port11144.access.nacamar.de ([62.27.212.135] helo=runbox.com)
	by pluto.runbox.com with esmtp (Exim 3.16 #2)
	id 14v0pR-00073T-00
	for linux-xfs@oss.sgi.com; Wed, 02 May 2001 19:54:21 +0200
Message-ID: <3AF049D9.4090201@runbox.com>
Date: Wed, 02 May 2001 19:54:33 +0200
From: Sven Herzberg <herzi@runbox.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; de-AT; 0.8.1) Gecko/20010323
X-Accept-Language: de, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Mandrake RPM's
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

First thanks to SGI and all the developers for the Release 1.0.
Now I've got a question: *Is there anyone providing RPMs for Mandrake 
8.0?* 'Cos the RedHat RPMs are conflicting with Mandrake's initscripts 
(I think it was the file "install-kernel").

Thanks
Sven


From owner-linux-xfs@oss.sgi.com Wed May  2 10:55:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42HtWv20793
	for linux-xfs-outgoing; Wed, 2 May 2001 10:55:32 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42HtUF20790
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 10:55:30 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 5FCB91E241; Wed,  2 May 2001 19:55:11 +0200 (MEST)
Date: Wed, 2 May 2001 19:55:01 +0200
From: Andi Kleen <ak@suse.de>
To: Eric Whiting <ewhiting@amis.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
Message-ID: <20010502195501.A13116@gruyere.muc.suse.de>
References: <3AF0468B.70E8B919@amis.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF0468B.70E8B919@amis.com>; from ewhiting@amis.com on Wed, May 02, 2001 at 11:40:27AM -0600
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 02, 2001 at 11:40:27AM -0600, Eric Whiting wrote:
> My hardware is Tyan 1854, PIII 866, 3com 905b, 3ware 6200 ide
> controller, ibm 75G ide disk.
> My base OS is SUSE 7.1

SuSE 7.1 comes with gcc 2.95; it is a bit safer to compile with an
egcs 1.1 compiler because there have been problems with that compiler
version and XFS in the past.

> Questions
> ---------
> 1. what debug can I do?

You could compile KDB in if you didn't do it already (it's part of the XFS
tree); then either don't run X or put a serial console onto the box.
When it hangs you have good chances that you see an KDB prompt (it could
be happening already and often looks like a hang in X; if yes your keyboard 
lights should be blinking). Then enter bt and send the results to the list.
It's easier with an serial console to do that of course.

If you get a hard hang it's much harder to debug. In this case it's also
likely that you're running into a generic 2.4 kernel problem; contact
linux-kernel@vger.kernel.org with your  hardware configuration and setup.


-Andi 


From owner-linux-xfs@oss.sgi.com Wed May  2 11:06:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42I6Xk21403
	for linux-xfs-outgoing; Wed, 2 May 2001 11:06:33 -0700
Received: from ns.tecosim.de (ns.tecosim.de [194.24.222.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42I6NF21389
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 11:06:31 -0700
Received: from donner.tecosim.de (root@donner.tecosim.de [194.24.222.109])
	by ns.tecosim.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id UAA22912;
	Wed, 2 May 2001 20:06:21 +0200
Received: (from leh@localhost)
	by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f42I6KD01889;
	Wed, 2 May 2001 20:06:20 +0200
Date: Wed, 2 May 2001 20:06:20 +0200
From: Utz Lehmann <leh@tecosim.de>
To: Eric Sandeen <sandeen@sgi.com>
Cc: Austin Gonyou <austin@coremetrics.com>,
   David Benigni <benigni@cse.psu.edu>,
   Rajagopal Ananthanarayanan <ananth@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: swapon error
Message-ID: <20010502200620.A1248@tecosim.de>
References: <Pine.LNX.4.33.0105021100580.10052-100000@UberGeek.coremetrics.com> <3AF03131.319A28C7@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF03131.319A28C7@sgi.com>; from sandeen@sgi.com on Wed, May 02, 2001 at 11:09:21AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen [sandeen@sgi.com] wrote:
> Austin Gonyou wrote:
> > 
> > There are 2 sections in rc.sysinit which call swapon -a. The last one,
> > line 628 or something like that, maybe it was 648, anyway, just comment
> > that out, Swap has already been enabled.
> 
> FWIW, apparently the second one is to enable swap _files_ as opposed to
> swap _partitions_.
> 
> Enabling swap _files_ can't happen until after all the filesystems are
> mounted, that's the reason for the "late" second swapon.  If you don't
> use swap files, then you're right, just comment it out.


or for swap on lvm volumes. the first swapon is before lvm is activated (if
i remember correctly).


btw: congratulations for the 1.0 release and thanks for all the support!


utz

From owner-linux-xfs@oss.sgi.com Wed May  2 11:11:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42IB4M21532
	for linux-xfs-outgoing; Wed, 2 May 2001 11:11:04 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42IB3F21529
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 11:11:03 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 6BA3BC231; Wed,  2 May 2001 20:09:12 +0100 (BST)
To: Sven Herzberg <herzi@runbox.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 02 May 2001 20:09:12 +0100
In-Reply-To: <3AF049D9.4090201@runbox.com> (Sven Herzberg's message of "Wed, 02 May 2001 19:54:33 +0200")
Message-ID: <m3bspbwotj.fsf@giants.mandrakesoft.com>
Lines: 8
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sven Herzberg <herzi@runbox.com> writes:

> First thanks to SGI and all the developers for the Release 1.0.
> Now I've got a question: *Is there anyone providing RPMs for Mandrake
> 8.0?* 'Cos the RedHat RPMs are conflicting with Mandrake's initscripts
> (I think it was the file "install-kernel").

We may provide some additional set...

From owner-linux-xfs@oss.sgi.com Wed May  2 11:20:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42IKlV22372
	for linux-xfs-outgoing; Wed, 2 May 2001 11:20:47 -0700
Received: from mail24.bigmailbox.com (mail24.bigmailbox.com [209.132.220.207])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42IKkF22369
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 11:20:46 -0700
Received: 
	by mail24.bigmailbox.com (8.8.7/8.8.7) id LAA05754;
	Wed, 2 May 2001 11:20:21 -0700
Date: Wed, 2 May 2001 11:20:21 -0700
Message-Id: <200105021820.LAA05754@mail24.bigmailbox.com>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-Mailer: MIME-tools 4.104 (Entity 4.116)
Mime-Version: 1.0
X-Originating-Ip: [198.253.22.114]
From: "Jonathan Day" <jd9812@my-deja.com>
To: linux-xfs@oss.sgi.com
Subject: XFS for Linux 2.4.4 query
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

   I'm running Red Hat 7.1, with the kernel upgraded to 2.4.4. The newest kernel patch I can find with XFS is for 2.4.3. Normally, the difference between one stable kernel and the next is not significant, and patches'll go in cleanly. Unfortunately, Alan Cox has been at the Mountain Dew again, and the differences are too great.

   Any idea if you'll be making a 2.4.4 patch? XFS looks like an excellent filing system, but I want to avoid having too many base kernel releases on my computer. Since XFS shouldn't touch -too- many core components, could you produce an "XFS module kit", to handle situations like this? (It would probably save on hair-restorer, too.)

Thanks in advance,

Jonathan Day




------------------------------------------------------------
--== Sent via Deja.com ==--
http://www.deja.com/

From owner-linux-xfs@oss.sgi.com Wed May  2 11:53:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Ir0C24198
	for linux-xfs-outgoing; Wed, 2 May 2001 11:53:00 -0700
Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42IqwF24194
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 11:52:58 -0700
Received: from vador.mandrakesoft.com (anakin.mandrakesoft.com [192.168.1.4])
	by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id UAA12384;
	Wed, 2 May 2001 20:52:49 +0200
To: Austin Gonyou <austin@coremetrics.com>
Cc: Alan Eldridge <alane@geeksrus.net>, <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
X-URL: <http://www.linux-mandrake.com/
Organization: MandrakeSoft
From: Thierry Vignaud <tvignaud@mandrakesoft.com>
Date: 02 May 2001 21:01:44 +0200
In-Reply-To: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
Message-ID: <m1ae4vr2w7.fsf@vador.mandrakesoft.com>
Lines: 5
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.95
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou <austin@coremetrics.com> writes:

> Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?

as far as i'm concerned, latest devfsd is 1.3.11


From owner-linux-xfs@oss.sgi.com Wed May  2 11:54:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42IsG924242
	for linux-xfs-outgoing; Wed, 2 May 2001 11:54:16 -0700
Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42IsEF24239
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 11:54:15 -0700
Received: from vador.mandrakesoft.com (anakin.mandrakesoft.com [192.168.1.4])
	by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id UAA12394;
	Wed, 2 May 2001 20:54:13 +0200
To: Eric Sandeen <sandeen@sgi.com>
Cc: Alan Eldridge <alane@geeksrus.net>, linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
References: <20010502000814.A16705@wwweasel.geeksrus.net>
	<3AEF8B8E.E6E3ED9E@sgi.com>
X-URL: <http://www.linux-mandrake.com/
Organization: MandrakeSoft
From: Thierry Vignaud <tvignaud@mandrakesoft.com>
Date: 02 May 2001 21:03:08 +0200
In-Reply-To: <3AEF8B8E.E6E3ED9E@sgi.com>
Message-ID: <m166fjr2tv.fsf@vador.mandrakesoft.com>
Lines: 20
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.95
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen <sandeen@sgi.com> writes:

> > So, order notwithstanding, if you've got, e.g.,
> > 
> > REGISTER ^cdroms/cdrom.$ EXECUTE /bin/ln -s $devpath $mntpath
> > REGISTER ^cdroms/cdrom0$ EXECUTE /bin/ln -s $devname cdrom
> >
> > only one of those two things is going to happen (I think the latter). This
> > kinda sucks, especially for the exact case I used. 
> 
> Interesting, I'll have to look at this.  The fact that there is a
> keyword:
> 
>        IGNORE This  action  causes  all subsequent processing for
>               the device to be ignored.
> 
> for devfsd.conf made me think that the default was to continue on,
> processing each match...?

i'll look at it


From owner-linux-xfs@oss.sgi.com Wed May  2 12:07:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42J7ea26567
	for linux-xfs-outgoing; Wed, 2 May 2001 12:07:40 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42J7cF26547
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:07:38 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09289
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:18:20 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA26366; Wed, 2 May 2001 14:06:21 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f42J5LB17820;
	Wed, 2 May 2001 15:05:21 -0400
Message-ID: <3AF05A70.4A11C072@thebarn.com>
Date: Wed, 02 May 2001 15:05:20 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Day <jd9812@my-deja.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS for Linux 2.4.4 query
References: <200105021820.LAA05754@mail24.bigmailbox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jonathan Day wrote:

>     Hi,
>
>    I'm running Red Hat 7.1, with the kernel upgraded to 2.4.4. The newest kernel patch I can find with XFS is for 2.4.3. Normally, the difference between one stable kernel and the next is not significant, and patches'll go in cleanly. Unfortunately, Alan Cox has been at the Mountain Dew again, and the differences are too great.
>
>    Any idea if you'll be making a 2.4.4 patch? XFS looks like an excellent filing system, but I want to avoid having too many base kernel releases on my computer. Since XFS shouldn't touch -too- many core components, could you produce an "XFS module kit", to handle situations like this? (It would probably save on hair-restorer, too.)

At this point anybody insisting on running 2.4.4 should grab the development tree.
http://linux-xfs.sgi.com/projects/xfs/cvsup.html

I moved the devel/current  tree up to 2.4.4 last night; any testing and debugging will be happening in
this tree not the 1.0 tree.

Functionally the development tree and the 1.0 are virtually identical, (for the moment).

I may finish generating a 1.0 core patch for 2.4.4 but I getting a bit source tree dizzy at this point
and may put it off for a while.


>
> ------------------------------------------------------------
> --== Sent via Deja.com ==--
> http://www.deja.com/

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  2 12:15:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42JFMN28785
	for linux-xfs-outgoing; Wed, 2 May 2001 12:15:22 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JFGF28751
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:15:17 -0700
Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14v25j-00071b-00; Wed, 2 May 2001 21:15:15 +0200
Received: from pd901e312.dip.t-dialin.net ([217.1.227.18] helo=kernelpanix.aura.of.mankind)
	by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14v25f-0003Eg-00; Wed, 2 May 2001 21:15:11 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f42IYsH09584;
	Wed, 2 May 2001 20:34:54 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 2 May 2001 20:34:54 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Andi Kleen <ak@suse.de>
Cc: Eric Whiting <ewhiting@amis.com>, linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
Message-ID: <20010502203454.A9561@s2y4n2c.de>
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010502195501.A13116@gruyere.muc.suse.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Andi Kleen [ak@suse.de] wrote:
> On Wed, May 02, 2001 at 11:40:27AM -0600, Eric Whiting wrote:
> > My hardware is Tyan 1854, PIII 866, 3com 905b, 3ware 6200 ide
> > controller, ibm 75G ide disk.
> > My base OS is SUSE 7.1
> 
> SuSE 7.1 comes with gcc 2.95; it is a bit safer to compile with an
> egcs 1.1 compiler because there have been problems with that compiler
> version and XFS in the past.

btw: you can install the redhat 7.0 kgcc rpm on suse 7.1. it works.
dont forget to change the linux makefile to use kgcc and all makefiles for
other kernel modules (nvidia driver).


utz

From owner-linux-xfs@oss.sgi.com Wed May  2 12:34:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42JYV403633
	for linux-xfs-outgoing; Wed, 2 May 2001 12:34:31 -0700
Received: from mail11.svr.pol.co.uk (mail11.svr.pol.co.uk [195.92.193.23])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JYQF03611
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:34:26 -0700
Received: from modem-13.kleins-butterfly.dialup.pol.co.uk ([62.136.216.13] helo=win)
	by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0)
	id 14v2O8-0005fE-00
	for linux-xfs@oss.sgi.com; Wed, 02 May 2001 20:34:16 +0100
From: Hahaha <hahaha@sexyfun.net>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEVG5M7OXE7C1I38HEJ8XUVW127WT"
Message-Id: <E14v2O8-0005fE-00.2001-05-02-20-34-16@mail11.svr.pol.co.uk>
Bcc:
Date: Wed, 02 May 2001 20:34:16 +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

----VEVG5M7OXE7C1I38HEJ8XUVW127WT
Content-Type: text/plain; charset="us-ascii"

Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a 
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...


----VEVG5M7OXE7C1I38HEJ8XUVW127WT
Content-Type: application/octet-stream; name="sexy virgin.scr"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sexy virgin.scr"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAALRMzSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAABQRQAATAECAAAAAAAAAAAAAAAAAOAADwELAQAAAFYAAAAAAAAAAAAAABAA
AAAQAAAAAAAAAABAAAAQAAAAAgAABAAAAAAAAAAEAAAAAAAAAACAAAAAAgAAAAAAAAIAAAAAABAA
ABAAAAAAEAAAEAAAAAAAABAAAAAAAAAAAAAAAAhwAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAAAGAAAAAQAACoVAAAAAIA
AAAAAAAAAAAAAAAAACAAAOAucmRhdGEAAAAQAAAAcAAAWgAAAABYAAAAAAAAAAAAAAAAAABAAADA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADr
FqhUAABPQk1HR0dISwARBkhZQlJJUwD8aExwQAD/FQBwQACjCiNAAIPEhIvMUOh8AAAAXqE1Cifa
HPo3yJDnSLXJ7t3FOxTtOKRv+GfTc+pR9O6i/AuJNOIiPrxC4Cq53H5sNXfMXjVguFwJrFAYrHHj
SiXLG3Lv+wdKT1hwcrOTfD7rduGAY5LvseJ7FEQYpBTblO28PiFdANOtfu+nOGbHGCUuPV1gfpLV
ICaXTlFqH+jWCAAAagPHRCR8IIO47V0xLSsXQAAxLVEXQACLLQIQQABqQGgAMAAAVWoA/1QkSIXA
D4TKBAAAUFVQ/1QkSAEsJF+FwI21ABBAAA+FsQQAAGhMTAAAaDMyLkRoV1MyX1T/VCQwhcBYWFgP
hJIEAABQ/1QkKP2H6fOkxgfrgcc4AQAA/+f86L8HAADGhZwFAADrxoX0AQAAPImNmAUAAIHsBAEA
AIv0gcTA/v//aAQBAABW/5QkkAIAAIXAD4QiBAAAjTwGuFxXU0+rNR8cYH2rNW0Pf36rK8CrVFb/
lCSMAgAAi9hDD4T4AwAAK+1Q/5QknAIAADlsJBwPheQDAABqEotEJCQr0ln38YP6EA+ExQMAAGiA
AAAAVv+UJHwCAACFwHQcVWiAAAAAagNVVWgAAADAVv+UJHgCAACL2EB1butnaAQBAABqQP+UJLQC
AACFwHRV6PAGAADGhfQBAADriYWYBQAAxoWcBQAAPDP/l+iUCAAAV1bzpIPvC411BqWlq19eagFW
V/+UJMACAACFwA+FQv///8eEJLwCAAAAAAAAxoWcBQAA6+kWAwAAU4t0JCSBxgAAAQBVVlVqBFVT
/5QkdAIAAIXAD4TWAgAAUFZVVWoCUP+UJHACAACFwA+EnAIAAFD/dCQsUP+UJJQCAACFwIsEJA+F
fQIAAGAPtxgDQDxQaPgAAABQ/5QkuAIAAIXAWA+FXgIAADMY6CcGAACB8x0fAACLTQIPhUgCAABm
90AWACExQAgPt1gGD4Q1AgAAa9sojZQY+AAAAIt67Itq5Ita6AFK6AFK4MdC/EAAAMCLcDhOAXLg
99YhcuCLcug5cuBzBYly4OvnUYtK4ANK5IlIUFkD+41UHQCNqtASAAADfCQcUlXoqgUAAIv1UfOk
XSv9iZf3EgAAK/Vdh2goib7hAwAAia/jEgAAlYtEJFBqEgNNPEkDwffRVeh1BQAAA0UCI8Er0l1Z
9/GZQED34UhIiUQkUP90JCSNtQQBAAAPt00Gi314i9+tUCvYrSvYcgZYg+7g4u+tUOguBAAAMX8E
i38c6CMEAABeXofN6CIFAABbXlNqA7sgg7jtXY2GbgsAAIvQhwSvg+30K8KD6F2Jg8cLAACNhjYe
AACL0IcEr0Urwi3eAAAAiYMQHwAAjYbvEQAARYvQRYcEryvCLYEAAACJg2wSAACNhucSAACLk+MS
AAApg+MSAACF0nUGiZPjEgAAaAABAADocwcAAP7Egetw7P//iYN0////llKJk2////9fhf91Covy
ibN0////6x0DuQwBAAAruQQBAAADPCSLB4lDzGr/6DMHAACJA4fx4wgAB67ByAji+IfxW4lxWIm0
JOgCAACLbCRMh/NVh83R6WatZgPQZoPSAOL1WAPCiUVY6CkEAACAvfQBAAA8dFCNtCRsAQAAagRW
/7WYBQAA/5Qk2AIAAIXAdS5obWUAAGhSZW5hi8xoSU5JAGhOSVQuaFdJTklU/7WYBQAAVlH/lCTs
AgAAg8QUxoWcBQAA62H/lCS8AgAA/5QkaAIAACvtVVX/dCQs/3QkDP+UJIQCAAD/NCT/lCSUAgAA
jUQkGFCD6AhQg+gIUP90JAz/lCSMAgAA/5QkZAIAAI2cJEABAAD/NCRT/5QkfAIAAOsLx4QkvAIA
AAAAAABo+AdRADwK/zQk/5QkwAIAAP+UJHACAACBxEQCAAC/BAEAACvni9wr54vsV1VqAP+UJHgC
AABXU/+UJFQCAACLyIvRi/uL9aw6B3QGNCA4B3UDR+LyjTwTsFyquE9GS02ruEdETUyruNG6p7r3
0KsrwKuDvCSAAgAAAA+EaAEAAIXJD4S5AAAAagNoAAAAgFXoqAEAAIvwQA+EkAEAAGgAAAIAakD/
lCR4AgAAi/hqAOixAgAAge16+f//VWgAAAIAV1b/lCRoAgAAVv+UJCgCAABqAmgAAABAU+heAQAA
i+hAdFWNtCQAAQAAagBWaCCDuO1XVf+UJGwCAABQUGr/av/oLQUAAA+30OglBQAAD7fAgOQPgMQe
VFJQ/5QkfAIAAIvEUFBQVf+UJFQCAABYWFX/lCQoAgAAV/+UJDQCAABqAGhQSTMyaEFEVkFU/5Qk
OAIAAFlZWWhRPE7OaF7Stp5o2bCuwovMg+wMi9RQUVJqA+h/AgAAXltfg8QMVFRoBgACAGoA6NoB
AACB7f73//9VaAIAAIBWi/VqEFmBNiCDuO2t4vde/9ZahcB0FlBUaAYAAgBqAFVoAQAAgP/WhcBa
dWlSjbQkCAEAAFboUwMAAIcMJFFqAWoAagBS/9P/14HxIIO47YXJdUKL7GoEagBV/5QkcAIAAIXA
dTBoTlVMAIvMaG1lAABoUmVuYYvUaElOSQBoTklULmhXSU5JVFVRUv+UJIgCAACDxBiBxAgCAAD/
NCT/NCTCdAArwFBogAAAAP90JBRQagP/dCQc/3QkHP+UJEwCAADCDAADfCQEK3wkCAN8JAzDc+ze
mVfiyoh8ztGOUuzLgkb35LpJ7dyCV/DkrlXxyohO9+6IUvDRgk7f6phOzNaORYO47Qjgkc125tuD
QYO47WCH/ovui10Ai3UEM8mLxsHgBIvWweoFM8KL1jPRA8KL0YPiAwMElwPYgcG5eTeei9PB4gSL
w8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcD8oH5IDfvxnW3iV0AiXUEYcNgh/6L7otdAIt1BLkgN+/G
i9PB4gSLw8HoBTPQi8MzwQPQi8HB6AuD4AMDFIcr8oHBR4bIYYvGweAEi9bB6gUzwovWM9EDwovR
g+IDAwSXK9iFyXW7iV0AiXUEYcPoAAAAAF2Bxf72///DQetW89CFLt9rmvNIEg6q973wG3KAvaix
UJTSRed0Rce/4CEZ5ZsiSo/xDNA2CYvMLHIzMkfPsppRi4ToHGuYCPg9hG/7sX0zDw56vkBpng2X
JvfX7qX5do2hPCAR+S1lusPlQWOkYLA4bev3UoepJgqI5W08F0qVd3tDEzOPh2wAAAAAi1QkEIty
PI10MniLNo10FhitUK1QrZNdWa2Wh/P32ivyK+or2iv/R61gK8KWagBZrITAdBQyyLAI0elzBoHx
IIO47f7IdfLr54t0JCyLVCQkh9GtK8J0CeL5YUl1ycIQAE8PtwR7i0SFAANEJDCLdCQoSYkEjuvi
TThakDgDZgIECXH/gbjCkQFAwhXGgAkOtEzNIRUB6xhQRQhMAVMCFM7gAw8BC5VsKRCmBKWeKAzI
bwTvFCziApwH3FPpCMpHWz4DCOfSKAoB9UAudGV456sOkck8B+AgkgsHLnJkYXQqJFFaSkzSTg7A
FQH/qu/gzP8l4BBwQXQ4VAEPMNUQG8pMDDUgLzdWMDsRgEdldE1vZHV3bB1IYW72DJbgSxxFUk7D
TDMyLnEemwd3UwAAVlAryayEwHQDQev4WF7DYIt0JCSLfCQo/LKApOhoAAAAc/gzyehfAAAAcxoz
wOhWAAAAcyBBsBDoTAAAABLAc/d1PKrr1uhKAAAASeIQ6EAAAADrKKzR6HRLE8nrHJFIweAIrOgq
AAAAPQB9AABzCoD8BXMGg/h/dwJBQZWLxVaL9yvw86Re65MC0nUFihZGEtLDM8lB6O7///8Tyejn
////cvLDK3wkKIl8JBxhwggAYOgjAAAAi2QkCGRnjwYAAMcEJEwnAADoc/3///+VzBIAAGH5G8DC
DAAr22T/M2SJI4tEJDBmi1gCU4tABFBqAuh0EAAAWFtyB6kIAAAAdbpkZ48GAABYYemXaP//VVFS
uEkbXQW5bU7GQffhBTkwAAAl////B+gU/f//iYXPCwAAi0wkECvS9/GSWlldwgQAyAgBAGD8i30Q
i9czwLkgAAAA86v/Aot1FI29+P7//7kgAAAA86WLRQzorAIAAIld/MdF+AAAAACH24tFDItV+A+j
EHMIi1UQ6BkAAACNlfj+///oDgAAAP9F+P9N/HnaYcnCEACQjb14////M8CJB4lHBIlHCIlHDIlH
EIlHFIlHGIlHHIlHIIlHJIlHKIlHLIlHMIlHNIlHOIlHPIlHQIlHRIlHSIlHTIlHUIlHVIlHWIlH
XIlHYIlHZIlHaIlHbIlHcIlHdIlHeIlHfI2F+P7//+gCAgAAh9vRJ9FXBNFXCNFXDNFXENFXFNFX
GNFXHNFXINFXJNFXKNFXLNFXMNFXNNFXONFXPNFXQNFXRNFXSNFXTNFXUNFXVNFXWNFXXNFXYNFX
ZNFXaNFXbNFXcNFXdNFXeNFXfOisAQAAjYX4/v//D6MYD4PFAAAAiwKLSgQBBxFPBItCCItKDBFH
CBFPDItCEItKFBFHEBFPFItCGItKHBFHGBFPHItCIItKJBFHIBFPJItCKItKLBFHKBFPLItCMItK
NBFHMBFPNItCOItKPBFHOBFPPItCQItKRBFHQBFPRItCSItKTBFHSBFPTItCUItKVBFHUBFPVItC
WItKXBFHWBFPXItCYItKZBFHYBFPZItCaItKbBFHaBFPbItCcItKdBFHcBFPdItCeItKfBFHeBFP
fOjaAAAAh9tLD4nB/v//iweLXwSLTwiLdwyJAolaBIlKCIlyDItHEItfFItPGIt3HIlCEIlaFIlK
GIlyHItHIItfJItPKIt3LIlCIIlaJIlKKIlyLItHMItfNItPOIt3PIlCMIlaNIlKOIlyPItHQItf
RItPSIt3TIlCQIlaRIlKSIlyTItHUItfVItPWIt3XIlCUIlaVIlKWIlyXItHYItfZItPaIt3bIlC
YIlaZIlKaIlybItHcItfdItPeIt3fIlCcIladIlKeIlyfMOH27v/AwAAD6MYcgNLdfjDh9uLdQiL
R3yLTnw7wXLwD4c1AgAAi0d4i054O8Fy4A+HJQIAAItHdItOdDvBctAPhxUCAACLR3CLTnA7wXLA
D4cFAgAAi0dsi05sO8FysA+H9QEAAItHaItOaDvBcqAPh+UBAACLR2SLTmQ7wXKQD4fVAQAAi0dg
i05gO8EPgnz///8Ph8EBAACLR1yLTlw7wQ+CaP///w+HrQEAAItHWItOWDvBD4JU////D4eZAQAA
i0dUi05UO8EPgkD///8Ph4UBAACLR1CLTlA7wQ+CLP///w+HcQEAAItHTItOTDvBD4IY////D4dd
AQAAi0dIi05IO8EPggT///8Ph0kBAACLR0SLTkQ7wQ+C8P7//w+HNQEAAItHQItOQDvBD4Lc/v//
D4chAQAAi0c8i048O8EPgsj+//8Phw0BAACLRziLTjg7wQ+CtP7//w+H+QAAAItHNItONDvBD4Kg
/v//D4flAAAAi0cwi04wO8EPgoz+//8Ph9EAAACLRyyLTiw7wQ+CeP7//w+HvQAAAItHKItOKDvB
D4Jk/v//D4epAAAAi0cki04kO8EPglD+//8Ph5UAAACLRyCLTiA7wQ+CPP7//w+HgQAAAItHHItO
HDvBD4Io/v//d3GLRxiLThg7wQ+CGP7//3dhi0cUi04UO8EPggj+//93UYtHEItOEDvBD4L4/f//
d0GLRwyLTgw7wQ+C6P3//3cxi0cIi04IO8EPgtj9//93IYtHBItOBDvBD4LI/f//dxGLB4sOO8EP
grr9//93A4fbkIsGi04EKQcZTwSLRgiLTgwZRwgZTwyLRhCLThQZRxAZTxSLRhiLThwZRxgZTxyL
RiCLTiQZRyAZTySLRiiLTiwZRygZTyyLRjCLTjQZRzAZTzSLRjiLTjwZRzgZTzyLRkCLTkQZR0AZ
T0SLRkiLTkwZR0gZT0yLRlCLTlQZR1AZT1SLRliLTlwZR1gZT1yLRmCLTmQZR2AZT2SLRmiLTmwZ
R2gZT2yLRnCLTnQZR3AZT3SLRniLTnwZR3gZT3zD6AcAAAC8IIO47etoZGf/NgAAZGeJJgAAYOjw
9v//iaX1EQAAahBfK+eLxFdUUP90JEj/lcQSAABYD7dEJAID54DsGXUvi3QkMIvui0QkNCvHdiGt
Jd/f3981UkNQVK11EyX/39//NSBUTzp1B6xW6AoWAABhZGePBgAAWOnIZP//G2vHiJi92YfYoPwy
IAMBOJtmQc4YySe0yvC5beWUf0NhJqPpsY2ceNHlN4YuwR1jW0iGeIyJhnhqc4Z4KIyGeK+fhniR
oYZ4fZKGeH2WhniFR4Z40IyGeCRnhngqZ4Z4g3wkCAF0FoN8JAgAD4QnBQAA6RZg//9qAVjCDABg
6Ar2//+L/YHvAKAAAIvfgcf9EgAAuaQBAABgaAAA97+Nhe8hAABQg8BwUGoc6G72//9oTEwAAGgz
Mi5EaFdTMl9U6Mj1////lXsiAACDxAyJhTsYAABQjYVwEgAAUIPAMFBqDOg39v//YeNMgT9Vi+yB
dESL8cHhAmoAVGoAVGoEUVf/lcsiAACJhYsTAACHrWMiAABQi9n/1VNXaP///3+4DfD7B4fOKAfB
yAiu4vj/1V3oV/X//2gAAQAAakD/lbciAACJhYgfAAD/lZciAACJhc8LAAAryWog6P33//+R043H
GAAAuIABAADooQ0AAImNRhgAAFCJhUgcAAAFgAEAAOjZDgAAi10CA92D6wyL04t6CCvfRw+EsQAA
AGogT1mLtUgcAACLAjlGBHUpi0IEOUYIc9ZggcQc////VIiNxRgAAOhxBAAAVP+VvyIAAIHsHP//
/2GDxgziy2ogWYHsOQEAAFToTwQAAFT/lWsiAABAdAr+hcUYAADi6OtEYFCLxGoAUFcr/1ONdCQ0
V2iAAAAAagJXV2gAAADAVv+VqyIAAIvYU/+VfyIAAFP/laciAACLhUgcAACHBCToHg4AAGGB7Mf+
///pPv///411Biv/VldqAv+VgyIAAIXAdRKLzrgQAAAA6GsMAACH+YkI6xaXahBQUGoCV/+VjyIA
AIXAD4QLAwAAib0nGAAAiYUsGAAAjUUKK/9QV2oC/5WDIgAAhcAPhYgCAAD/dQKNTQq4BAABAOgc
DAAAiY0YGAAABASJhSYfAABQUI2FBgoAAFDohfX//4v1X1bogRMAAA+CEQEAAItFAgPwi0b8QHQH
g8AK99Dr8YvGKwQkiUUCaADAAABqQP+VtyIAAIXAD4TiAAAAVw+67R+Xi/eHdCQEi40CAACA86Rq
IGj/AAAAWg+2hRAAAIDR4CvQi7VIHACAWYvZOH4ED4SWAAAAav/oBvb//zrCD4OHAAAAYCvZi8uB
7AQBAABU6LQOAACL1CvbU2iAAAAAagNTagFoAAAAgFL/lasiAICL2EB0TGoAU/+VbyIAgIvI4ziL
lCQoAQAAA0ICPQCAAAB3J4PADIlCAomFAgAAgFCLxGoAUFFXA/lT/5WjIgCAi0YEq4tGCKtYq1P/
laciAICBxAQBAACJPCRhg+70SQ+FV////1+LhQIAAIC5IItFAovIXovfgccAAgAAV/Okx4PLCQAA
/zQk/8eDzwkAADQkwnQPuvUfYHMJK/BW/5WzIgAAYYHH/wEAAIHnAP7//4sUJI2yAPwAAIPHBFcr
+ofXiZOcAAAAiYOIAQAAgcIAAgAAiZO0AQAAjYIAAgAAiUP8iYXyHAAAgcL/DQAAgeIA8P//jYII
EAAAiYMAAQAAiZOAAQAAgcIAEAAAiZOsAQAAgcIAEAAAiZPQAAAAgcIA4P7/ARYBVggBVhQBVhgB
VjBo/wEAAFlf86ReBUQAQACJRhqDwLSJRiCB7g36///+hhz6///oOQAAAIPu+ugxAAAAgcYN+v//
6CYAAACt6CAAAABq/+hX9P//iYa9GAAAj0UC/7UmHwAAagHonQQAAFjrP2r/6Df0//8BBoEmDw8P
D4EGQUFBQcOJhRgYAABoAAABAFdXagJQ/5WPIgAAhcB0RovwrYm1Jh8AAImF8hwAAOgAEQAAcgyN
hcQhAABQ6HAJAACNhWcfAABQ6GQJAACNhesYAABQ6FgJAACB7ezg//9V6EwJAABh6dn6//9g6O7w
//+H9YHGJh8AAGiEAAAAgwb8/zboqgkAAGiAAAAAaACgW4LomwkAAOjD8P//aAAAhnj/lXciAABo
ZAAAAP+1SBwAAOh7CQAAi7WIHwAAVmogWa2L0K2F0nQHUFLoYgkAAOLv/5WzIgAA64tg6H/w//9o
8EkCAP+VuyIAAI2FkiQAAFD/tUgcAAD/dCQs6IgDAABYWGHCBAD5YGY9YPiLfCQkchNoBAEAAFfo
QfD///+VhyIAAAP4sSC6Wp9vANPKagxZsFyqi8GKwiQPBEGqwcIE4vSID8ZH/C5hwgQAYGgAAAEA
akDoBfD///+VtyIAAIXAD4THAgAAUCvJiYgAeAAAi1UIiZAA+AAAi1UGiZAE+AAAx4AI+AAALkVY
RYmIDPgAAFBqCOjuAgAAWBvJUYt8JASBxwD8AABqHuh98v//uS0tVkWRq2aDwQVqJOhr8v//PBpy
BAQWZj0EQari7IvBq4t0JASBxgB4AACLBCSFwHUGrITAdftOi/7oPQAAAE1JTUUtVmVyc2lvbjog
MS4wDQpDb250ZW50LVR5cGU6IG11bHRpcGFydC9taXhlZDsgYm91bmRhcnk9IgBe6NMBAADo3QEA
AE9PuCINCgCrT+jJAQAAiwQkhcB1UOgxAAAAQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy
c2V0PSJ1cy1hc2NpaSINCg0KAF7ofQEAAIt0JATodAEAAGa4DQpmq+hyAQAA6C8AAABDb250ZW50
LVR5cGU6IGFwcGxpY2F0aW9uL29jdGV0LXN0cmVhbTsgbmFtZT0iAF7oLwEAAIt0JASBxgD4AADo
IAEAAOhSAAAAIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogYmFzZTY0DQpDb250ZW50LURp
c3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFtZT0iAF7owwAAAIt0JASBxgD4AADotAAAALAi
qrgNCg0Kq+j/7f//i4XyHAAAi7UmHwAA6JYIAAAD+eiXAAAAx0f+LS0NCsdHAgAAAABYgSwkAIj/
/2Doy+3//2gBAQAAK8Be6KsLAAByVSvmVFb/lbASAACFwHVBVOh8AAAAgDwkAHQvi/ToW+///2oA
UVbozQMAAGoAUOgxDAAAchVqAVDoJwwAAP+0JCEBAABW6BkJAAD/lbQSAACBxAEBAABoIL8CAP+V
uyIAAGHriKyEwHQDquv4w7gNCi0tq1ZRi3QkEIHuAAT//+jg////ZrgNCmarWV7DYcIEAGDoJu3/
/4uNbygAAOP4/41vKAAAi3wkJIu1LBgAAIsGhcB0J1BQ/5VfIgAAhcBYdRqLAIcGi/CtUK2HBCRQ
6Knu///zpJHotAUAAKr/hW8oAABhwgQAYOjQ7P//K8nGhXkcAAD5xoVuHAAA68eFdBwAABAAAAC+
AJBagoHsEwEAAIvUrYWEJDcBAAB1IIPGCP7BgPkgcuyB7O3+///rCMdEJCggg7jtYfnCBAAtUlFW
iI3FGAAAUlLoG/z//+jgAgAAXllacsbGhXkcAAD4i4QkNwEAAGDoCwAAALwgg7jtgwwkAutlZGf/
NgAAZGeJJgAAg8TsiaWtHAAAiQQkqSAAAAB1DqlAAAAAdQepAgAAAHQNi4QkewEAAIlEJAjrCbgg
g7jtiUQkCIuEJHcBAACJRCQEi4WfIgAAiUQkDIuFmyIAAIlEJBBU/9fo3Ov//4sEJKgEdQaoAnQC
DECogHVOqAF0NYO9dBwAAAh0CseFdBwAAAEAAADGhW4cAAA890QkOAEAAAB0EYtMJAiJjfIcAACL
fCQEiU/8qAh0EcaFbhwAADzHhXQcAAAIAAAAqEB0Cv90JDD/lb8iAACDxBRkZ48GAABY/zQk/5Wz
IgAAYem3/v//YIPsKIt0JFSNfhClpaWli2wkVItMJFCLVCRMwekDjXUQrYkEJPfQiUQkGK2JRCQE
99CJRCQcrYlEJBCJRCQgrYlEJBSJRCQkiwKJRCQIi0IEiUQkDIPCCI10JAiNfCQY6Dbq//+LBzFF
EItHBDFFFIv0jXwkIOgg6v//iwcxRRiLRwQxRRziloPEKGHCDADoGQAAAItkJAjHRCQg/////2Fk
Z48GAACDxATCEABkZ/82AABkZ4kmAAD/dCQY/3QkGP90JBj/dCQY6JoAAABgkePOQXTLg+kgdsaD
wRCLdCQwrDxAdATi+eu2i/4r7U9F6EYAAAByB4P9DHbyK+2D/QRy4yvti9eL/kdFg/0Uc9aAPy51
9IB/BC507oB/Ay506IPHBegSAAAAcghP6AoAAABzs1LojQkAAOuruz06LCDBywg4X/90HoB//wB0
GIB//350EoB//zx0DIB//z50BoD7PXXbqPnD6X5X//9gaOCTBADo3un///+VuyIAAGgEUJ+CagTo
9vz//13r/mHCBABgi1QkJItMJCiLRCQs4xj30DICQrMI0ehzBTUgg7jt/st18+Ls99CJRCQcYcIM
AGBqQOgJ+f//YcIEAGDohOn//8aFQiEAAPkPtoXFGAAAudgNUQCNBMGJRCQciwjjJr8AAAEAV2pA
i/H/lbciAACFwA+EkwEAAJeRV/OkX4k8JOkIAQAAK8BQaIAAAABqA1BqAWgAAACAUv+VqyIAAIvw
QA+EYwEAAL8AAAEAV2pA/5W3IgAAl4X/D4RMAQAAU4vcagBTUFdW/5WjIgAAhzQk/5WnIgAAg/5/
D4IrAQAA98YPAAAAD4UfAQAAiTwkV41UNxCDxoCNHDdWgcR4////i/xXahFqIFlYqyvA86tfU1JX
jYUKCQAAUOio6///gcSIAAAAiwwkwekDi3wkBIvyg+qA6DDo//+DxwiDxhA78nIGge6AAAAA4ulZ
iwQkgeqAAAAAUlFQi0IQi1oUi0oYi3oc6Af9//8zehxfD4WYAAAAM0IQD4WPAAAAM1oUD4WGAAAA
M0oYD4V9AAAAge0h3///VWT/MWSJIVRFj0UAahBU/9dd6we8qfRXAOsM6BLo///GhUIhAAD4ZGeP
BgAAXYdEJByJXCQQiUwkGIl0JASLCOMC6zOLNCRQgewAAgAAVOiG9///jUwkAbgAAAEA6BoAAACB
xAACAACL+FiJOIlIBLkAAAEA86T5YcIEAFFQ6DsAAADDYFQr7VRqBFX/dCQ0VVXom+f///+VryIA
AJHjEFFq8VH/lcMiAAD/lcciAABYYcIEAGoAUOgBAAAAw2Dobuf//yv//3QkKP90JChXagRXav//
lYsiAACFwHQTiUQkGP90JCRXV2oCUP+VjyIAAIlEJBxhwggAYGog6Kz2//9hwgQAYOgn5////3Qk
KIHtbd3///90JCj/VQD/VRRhwggAaBnraRnWeKdDCf5IlCfaHPq1GtAI3cU7FOt24YDfwL/rlO28
PhikFNu53H5sJS49XThmxxiX35cgSLXJ7q1+76chXQDTNWC4XNhJ4jG8QuAq4nsURGOS77Gzk3w+
ifB8zFHTe1dmQlbdRk+jsS3TEzoJzve/AKCBeMYK+r80e/e/tW/3vz9x97+g4Pi/1Hb3v9Vv97+Z
Dvq/Rnn3v55297+XIPi/Nz34vzxq97+sbfe/Gnf3vz1w979k4Pe/33r3v2pv979Bbve/uEj3v+kr
+b+tFfq/z/T4v4QP+b8sYvm/YIHsEwEAAIu8JDcBAAArwFdqYFnzq1/oEub//4hFEIHtO+f//4hF
AIvUV1JS6Kj1///obfz//3MeX4PHDFT/lfoJAAD+RQCAfQAgctuB7O3+//9hwgQA/oVL5///hzwk
lquTq5Gr/5XuCQAA69Zg6Lrl//9Vge1Y7f//6A0AAABddUroGgAAAHTqdT/oagD/dCQ4/3QkOP90
JDj/VQCL2EPD/5XIEgAABc3Y///DuWDoeeX//1WBxaQSAADozP///111CejZ////dOr5sPiJRCQc
YcIMAPxXagPoRAAAAEFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFy
c3R1dnd4eXowMTIzNDU2Nzg5Ky8AAAAAW1mZiVQLPffxi8hSrU6L0Og9AAAA6FYAAADoXgAAAOLr
WeMhrUl0Dw+30OgiAAAA6DsAAADrCg+20OgTAAAAQUGwPfOquA0KAABmq1kr+YfPw+gGAAAA6AgA
AADDi8LB6ALrHovCwOAEwOwECsTr8ovCwegIwOACwOwG6++LwsHoECQ/16qLQ0BAiUNAYGpMWZn3
8YXSYXUGZrgNCmarw2DoZeT//4iNxRgAAOkH9P//YGoAagFqAuhO5P///5W4EgAAi9hAD4QoAgAA
U4HsAAEAAIv8i7QkKAEAAKwsQHX7uHNtdHCrNF2q6Nzl///jIvOkkapU/5XAEgAAkYXJdRJUgcEe
DB0cMUwkBP+VwBIAAJGB7AD///+FyQ+EqAEAAItBDPj1lq1y+1Ir21NTUGgCAAAZi9xqEFP/dCQc
/5WsEgAAg+zwhcBaD4WZAQAAgeynAQAAi+xopwEAAFX/tCSvAQAA6OH9//8PgnMBAABVuAEHDQlo
AAEAAIv9NUlCQUarLSg4Qk+qi/dW6Hrj////laASAACFwHUH6Cvl//8D+Wa4DQpmq10r/ejZAAAA
agbHRQBSU0VUx0UEDQoAAF/owwAAALgE/wcGi/0FSUJBRqs1bQcbA2oPqzVtfHJzqzVzNyo8q1/o
nAAAALibhZGai/0tSUJBRqs1chcfbquA9Ghmq4u0JM8BAADouuT//+MC86Q1HjFFOqtPK/3oZgAA
AGoGgXUAdnRkYWbHRQQNCl/oSgAAAFWLtCTXAQAA6Ibk///jFFFW/7QkswEAAOg3/f//D4KHAAAA
XWoFx0UADQouDWbHRQQKAF/oGAAAAGoGgXUAY2B5dGbHRQQNCl9VuDM1NCDrBbgyNTAgVeh34v//
iYW0JgAAXVdV/7QkswEAAOjj/P//cjdopwEAAFX/tCSzAQAA6I78//9yI4F9ACCDuO11GsNqAFRq
/2oC6GD1//9YWFnjD3INkelI/v//XYHEpwEAAOgd4v///5W8EgAAYcIIAGDoDeL//2oJ6CQAAABy
wuuscMqL3w7H9KEgg7jtcuLLqE721a5P7daIQ/fRgk7w+e3obgAAAP80JP80JP+VeyIAAF6FwJZ0
OYPAEFBW/5WbIgAAhcB0KoHsmAEAAGicAQAAi+xonAEAAIvMVFRRVf/QXYHEoAEAAIXAdQUrxXQB
qPnoHQAAAFhYnFbog+H///+VdyIAAGjA1AEA/5W7IgAAnWHDnGCLdCQoi0wkLIE2IIO47a3i92Gd
w2CBxPz+//+L/GgEAQAAV+hF4f//xoVlKAAAPP+VhyIAAFcD+I11BmpcWKrB6Ailpapfi/BQagJq
BFBQaAAAAMBX/5WrIgAAi9iBxAQBAABAdHI5dCQodCFqAlZWU/+VcyIAAFCLxFZQagSNRCQ0UFP/
lX8iAABY60FqAFP/lW8iAACR4zVQi8RWUFFRakD/lbciAACL+FBT/5WjIgAAWcHpAleLRCQo8q90
AuMHxoVlKAAA6/+VsyIAAFP/laciAADrAaj5YcIIAGC5AQAAAOP56IPg//+B7ZHX////TQCLdCQk
K8msPCJ0EzwNdA88CnQLPD50B4TAdANB6+jjJ1GD6fCLwejS+P//hcBadBeLtb3v//+L+IcGq4fK
kquLdCQk86SRqv9FAGHCBABgg+wQVOgi4P///5VnIgAAWltYWMHrEA+322aB6tAHcncPt8rB6hAP
t8L2wQN1AUPjCIHDbQEAAOLwi9FIdD+Dwx9IdDmDwxxIdDODwx9IdC2Dwx5IdCeDwx9IdCGDwx5I
dBuDwx9IdBWDwx9IdA+Dwx5IdAmDwx9IdAODwx6D6xXR47g7AAAAk/fzhdJ0CEp0BYD6OXUBqPlh
w/////+xnB/x7FBeWZecADqOHa4/Kiv0sexuvMmQ64grzV54Cr+H/HywCSEdkIm40pvY6Nq3vguc
fuCtLIXAFsfKrNx9cg9qEWxL990BZsKwe4lsF/3sOH6JTOc2XDFjnPuRqkcXRU5HlezW+q+zeSXa
lTQWveC9Yf7xmwv0O8iA4RilwPGLtL1FE4QlDU+zGGEE6WeZUyBrgyOX9Nbf1bMQ3pA9UUbIZyrC
rBBpIPoEeiZ+BI27Za7mQ/LvldJ/3KJfcHCc7x4oSGCHQGWGpm07h6gb6fJVq+px5ILc2k26oB+x
3X19ZTAAmZ5Oo6jQIGwfMr6JkzYQdBfWf6PR33dcSqPsB4bcSfGge9948ihlNt175tXwzIzO1DD5
kM6OiRr20ryeIxVe5j/wsFY3+ilJtTquyKyNmo/Yh/Dv8sZLl24Uz9/THu0qrodasG9/PXB2OVEy
MSswKLlzyAKAJ513m0vB+/YE91TmNaySVwviGtGWH1Q2sIShvh45X94ISzcMALZak9ws6U+o/9PQ
vaMQtyjHx/FvfopyS8DlSEV4t2CUFn2pXRGuaHOumJnHq7l3JnzR3NXbgZ2hZMelopPIYXPZoffB
kVaTitcokrIc2ofMd2Wvn7TyJbL+pnWfED9J+EA8PMryZrkhIi4FBOtojxxo6Rqcx44+F7m01hQg
EWE3+/RVRfICgWLDezP0Wa268cjUae/TmE8d6qLASaSQTfZFidn/a25uKtalUsGLmIz0pkV68Hla
sw2yeZ88dsFXFlBjo12Hr6sXphJFUduoFlMrUcZIGVgln+Au6nIwrLEclBQvXyx2EVeUr3jH3xpQ
rUihEObcsT2CP/i7CzPz9q4XH64YUlmsNasRKcYMOm0tWn4o4PJ+01XroNuU35jZfG2Q+nwnznOo
TcsbC2C5TdKVfqSEspnCKi7qOUNmdoY3YAihm32TRu4290bK/vcf4yo1XnQLfkHBEZhgjyX8fY+Y
CbuRdflvsJZql5cjW/coBQC9AZlRUPxc/DSXvJhpe6lNcjnKKlT7wqxINfehnYqDvbJ5O29T0mxy
XF6H1gmbs1LmrTLZmLcF96nMDf47NUZzZXJ2AgAAADADAADGNNGjEyg1mrZvZ2ZVkYh95GVTepQb
9oL6+n6yEO+l5t7U1gzLQZZN5ja+FR4KcwFAF59y+3G3pmNkoQOgJ1w9ivRlnpVgUxWux9yF04HJ
mQhtk8mmZQIWg+Tv84UA3J9CLASaDZCayYxdA5A9aeB7acw4rHY+9gyFAEE0fQ0fQ5FNMrOTq9Lv
niQL1Kdn9vUwCKu8YxJ9Auk9jA5Kn2NT6HawUDq06k5On9LD/KdiFd9vipiG6+9rEHcML+Wgb7gI
laSTLU/sBMwZrvTmEWVOqsxbX4fL7KYiMvBAxMcz7dW9A1Q3ixwGfkYnZDrhSR3EkWh9/zeTh0aH
PsU3fHZcGuGAJE0ivd+I299Q3ol7MiaNNmwabhLWgWt7HS8+DcTVG7WR8MfANO2WZA9oL4k1MzRW
EahSMmtX7j7sY9htGlwMa4PnniTzImimP/82b2SmOEsJZdXKi+vh5IHFaafIlkBsgvpOJ+pE2Pe+
D4LrfRGBZa6UKqrsqSNQII9TebUsO4V7q/uqIcF85Q9HCjL2h6qHVpmk6ZmW+aDhiy4A7xHUJPal
xbTpaOlSE/CUyXmpSPeH3thaAPLN7K7SMJKrWj0G0RobVBgGOn9lMTXfsm2a1jJzV7WQUCa+NqNB
6FvKUe9HEZMf2Iil3AHnf/ElG9xivmO9ZnFl5QHcQufClLPOyO8bP5S8brtr7+WJrw7AIyH/YpNM
Gyoi/K7r9J6qMNn4DrVRX7yCCWmljzt64mfWpCBO6NLrZG8M1UDFXVHXxZVVZVkP7RTkNegwXu7e
SgzU4lgMYNhDa/B1XqmgewbPEujflxMur+OxamaHsd6no9xCu7AN/8gJTVpiEDedNeH7uP6ynA1v
Pv8qs2ImO6IPU++GPHdkpKX2Rl09jqvpAkMtUGxzvumNh2DF34Y+WGwjkPBB0ZrUujgJ0ASgpN/5
67XQMPbBp+k2LcHtg7riYWLvs1SOxAKjXxvI2hmrQ3ugz/r9RfboBqb+udMl4KBUjhm77y9QGAfR
U7IWQZsdga8UAVGcopzfw9GtUP5JoUSZ+qaouSQgKbHHQm+00xAV6KHB6TYcKfkpoMf5kduAzWub
WbSVM3FB3sQMxA1YPyzePn4bucVdsqBZhaxyTYIw8puBnTHTjb9jtV9YyGBS3JoBLx1jXAm1MBek
yjd/JuzL9hTwopCegCJNs/bsAXoL4OVM5vq16TK9SXv7Xh9Jx6Cha4OyVdiTP1AM91XWoPrhkuUQ
LbUb17LcVve4JlTxT7PMV1Qto4UtlpsWUVL3Rswin56oqtNIZhOx3iGgbkYl2VRrUWo4McSwfER9
YyH0kq4DIsSJ03s83Pp9MkdsVQSGodnNedw5TcRn4pRv1QkkXQI/hyHJRKlrn0RfZ83KJappO0x3
cTPe5w0KFRGX6uEMglTw8kXBuZwdvBeprmYYKZ0Y/DiHcabPMcxfge1JekwgLNJymun0RQ/ZzzLt
92NMYcEfUT7phc8z11VveZPHcLbfq8Csfkpv1tDwgLxSs/SZOEGghKcaupUDvDAIa6HvmmzzcqQQ
dcj5PGESY3uSMYw36kVGVBVPAbgb07E/vUpRoCtm8qIxekfI8+XcNJjOuUZ6B4iSqKljFxKHgGJj
08xNEX9L5yf3RR+abS5bkPtsNpnEZNc54oFGMiuAjWPARJUirl5vApkqx+oPbvhqX/n+8M09RE0/
Ye79/IC6U4TBfBOZGdva28TA2XVc+95bcA522xDxjwbMtsHh1Xp51YsQXNtVJwY0AuUsGyNbfSyD
WOMjVZ6xriBEqwiNnpSq0qRumFAcr3CSfwwqbHtUb04GU67+qgHeDCglG7+Py/gArl+NLdRjaLF0
i58foJxsB0AskViPXQRJexmT1wvDqrx/Ql0coZ4egUt66hbntuUsypupQomV6xvsHPsA+mHvPFYR
Mk4zYXcsWWgOSNWIVFnopxeXwli8GChriYpR31cDNehCyvsWdRL5fjwRkExRrmilIEhn44a1kVng
wYCTCfvLmOnVIb4QwZRUaCYY4YNiDOfLE7nNJeBiMKQopkVXECGnnoEKB2/ez6sf7yvBNP8y16qD
DxaztFUwd224wNdM+B8/ttrygO1shkjeorsxupJzFDBN7CX18qF15Hysldnh2UrGNMxOdr3MuxA/
g2QBt6elRk3+creBu59LSAjdfMMOs2xpkdiPo86OzN4jmJgo7F6znZKHQ3WVbiI+wM9Kso8HI3oS
vweAVsW1i9EfNuUv+PRpSXttO6cqVkLKwx5qc4Xli/iiQTAPHxBwZt3bOE9yJNbGSbEX8WP1ffts
jKSm4OudCOXuyWbnFf/1k66mbva0AAzsZe/Yrvl4mhh71ZOq9RF9cC5P0pBTPBvzgUaz/O8wzc24
AFN5HbE5FrHATNaLqBj4V6MmJv4C0wxfkFkkQkjdC2FBx0OICDtpT0TKHzRvH/MaOJpUZ12O44EA
OaRmBHZx3eba1HlY86r2z0qNIbPo+qnjzoq+pXQk1ozO9qm+CXqDJrPt6BJMYBFelh4uNkQg4RBY
An9AX4dtdCBZ/BslS5RWS+ybbBUfmr4IAUOsxeFxbd5kk8KZe+BvFpIygeusZppbiDD1bg7y+e4T
U5YMPb/5E/H2dmuJnbsaxqToQFZC4StpIGTLnl0pFVZVwQvkywnNFs/5Of5pGGpX04oyFbEKfPgT
/sxMxEIhQ3Twpw55d0UZURrBqKCWC+PqSt4aOMzNP0ZSAhcK95TcO0VJY4axgxzTnUE7+lAeip1S
/ITae8UzxXtXO8c09yrY2nElSEtoqxD77j1PJvMV8PBZXCejw0mdc6/ot/zdCR7dss9K8e23f60Y
zd9DyDjltDNzSn3q83ItCMBRkr/Av33NtmkhxvElI4aov3WN53HjSC2kXrAzCc5G07VB6VLfgXC7
+2tkEv4C0wxfkFkkgg8Fr4ae9jpaja/XyZML4+7PlryQ3Gt671Yp3y55x2PziChkbNNsdLBjaLkg
iQm1rUykfo/kOWIzI6xA5okFeAYAWR82gilDm4vfyG/c07LGeMHEJlPy8M2RTFpe7R1eEJU6dJ/k
5nsEFJqoj0d6llU95gTzH+JRd8gsp62uTC88DtT0Y7Hds+P1hQB9ZQ3xWZ6fYOuAySSgPGr55Zg+
wMp2jXM2jdZOis+Bre6QaJ//x0QuYjxhZfWbmv2t7G5wZRH06OJoNiU8e5cQ/HP2CMJiIJBXC+yM
GLDT7uNPOIekqJGkLAz7XjKU54yGXZh4Rf40N2C9ZYXvmhl0EZpDF2FmADwrOc2J/1E/NasMrjKZ
oLlxlxr9Z5tt5pn51qCVGXLkyZRi+NuNV62cbvT05Ld/8rRs0JbeexdAsmSqwY7Dw2IzZjVyeK6+
DKEABXDkePW/8ZZZrekVYJEHGfO/ZZ5SIGWYdM/uCRVSUPmcV8pTpeETW7LAQCJuviQg8STfMoeU
YK47yaR88XPw53oh8NxMHwMXqiv/cWgYMMRJrz9FTAKHUxJarSIMr2IpWSS3ruVrqduIunvM2xgb
y/upiRfu6OCdctXV4RHzuojOOmOB2IIuTqUK5ThDQvejCNupDsHiyyzwqzPioaBWSP4pofavxzTP
W3iFVPrUwE+bUQfblBpP6Nb+OmlfcnoBAQAAoAoAADnQVSmTyKTeTu8+mp03C636d4vNRdxPiVfq
k7h4rEreo7uCoqJCQVYVdsGqs+d+ObiNkmcOAixnbQd2TcHB/KGhMG1JNNF2EjEeyxN9jiOKyrD1
7vzvqG2ANaMQfXu9qEjMXiU+TtVmILwy6CpSYYSNlhf/rhl9g/A9SMXfqvaONlQMeUsbDHgjNUER
pJYk+kIR0YEUYk/261IzyPdJmaZsUqu3ZBG0uyKYoH79HTMfFCmXZunABK7m/9RXRlk3Tls5KBrL
R+ITNPwtJNc6lxwphKdpP+22foFHHKWDeofJKziXhTMdo/EPrGMkKLayCNqJjCr4pzUPkNuZGz9k
dWzHgjkCGbsMEgzlAUCyMDwT8rPfCg0CyWe+TfPg2DJUWj/9X7mzNqdLZbn2xAlYQW9lJA8FMyuo
d1l4DhXcbTCmw+4Y/mtvqxY86EPqWzCwPzCs5C9ymkiDTR1vyKP6+UfVcsey2ChtbXjSuXuLS2qM
Er5f2VL9TviVWN6nlvvLH7/Ahlfm0KM/z42m7rqcoIjmsqAgU6DLAENreysOJ4g8tsHeWT1YIk8W
0OZSSnNJDle6CO7/MPv0yzk6dZR6SrWmC+6yw4oyxVdOR4P0PTwdMfd8QEqkS7ZrEdjExE1P8njI
GsGM8JvYIcXwFxKztKVbx6cB7W/u1qoU9uzJ3j6Vr4SDzsHUMeJuyRkN65QyKOGs9m5NLdQMo9za
ZjXkive+OgYbPKmlgdgXnAGnQy8cTYrAZ020JEI6/F0bI0e8EhrPAH2FY6Xq63R/VpVAqKt9l0JB
9R11h6/IbnDbUEU9dV90y6w1pagUvHTLgbVh0kS4j+dd2v8UCM+f7S6e6rqDzVs0kGOxiIvEpA27
OaVF89LY6PbDqQEKDt/lgLLs3EfRU+T6HgfddDHysRihKv3oQy3l6C+z/B1I+IKX38K9rRPqaVvo
54Lg5Y5oMGK9dZ4as5T2WmVpj4DzTA8DZoGeL/3AYcDIeDqtwTrQ4t5wQMb4wY2fvAuXwhX3fkDM
6RZVXVnZUN4cSq9ctuRGcnoIP0pDYxyBjTDX0R2BkCPSLuovKG5P6fprhpOfnEGzTfOdeuropgXV
qo9mGeklsCxd7BobPYBb0Dp1r2DZrtdWt51LK0UZkb9nRjPP37wRilJuUqhU+IvELrozr95xE5Go
d7rauIJ2zfTILFEH/hEObweEI9VsMR5ovlKTZx6TcS69HYBGm9k13YC/S/xcrTPUr0huIGBgsGzO
7Ic2QoaFCfftXqe3jo0ICSq2GMbCAePvajQpMRLfg3XHBeRmQRSY+bGkEYbM6zCgV45WRrVdN8vb
q7vKiyG3keQ3RdOC37reCIXr1EF6AAZFcVpWtzlaUdkgjLRhgmivPCup1JXIsb9lGdXtOIWEiuaz
MXeZ3UPnkI449pAg4D1kJ6R17Q/ZDA7QjKgg41WUxuE+UcfV4lR0ywrDwcsl7GOKI4wPrEnxxyoo
FHqf+6v6e341ADn+lVzC7AKaYQeSRIr9J4yzK7vWdybWjiIh3p7Vb9cIg3PB8aaCsqQDIZbC13C/
qz6JDzA2qtvmBtNxteLTikRN4UtaX8n4tG2tyFfKUx2btH8X77BvHaa1o/SiGeG4WgCjelBe/a8/
sA5WZoY1f27AJYAS0eMUxCLYfMKkh/8kSCnAjHfKV/2hZIrURtEks4EM9Qmk9mbfX6WqIbeillo2
sJS7Po0euW5gkN88avhy1xdwBXU3k7QGBXi/6JVSuYJkn3NFipMNNRaCG1VbkB3w71IhoPKcX1XV
7z5xs0G7mNLWTXG0M9ud9ch1TxhqVDV5oZVzzIxF6dQTHoA/+CkYgFWx6r2xVb7u6ouMu2+qqoCi
zoMYag9nbx5MvkdFH9B9oBMLHgcDCtvquXvlU9Jo9i64OVAeXCCKz+qr6wWtKaAloMMWHTamhDsk
hnLONlzTkSKWB8veVRNV2Ls1HBGkO6HO88LNAb7bM4UcQ+pun3iblqJhuDyAUCmQceM068fecNfB
Ue2rMNXCVlqBWUzqLOU0E8UyDr4MN94a+OfHBBCfCB9QxH83snaERR6XCEzmRtaXVeg7XkvnM1G9
xA8lfERT2rA2pxyvO6t6aAyhrjx+Om8W1ZZO63B2P+GfOG3SxXelFHUPc8v4OJFaUW/oDKQTZ2ap
li8LGbUHMPWbKiXwt/Ot9uxsjkuexI+WlYKdolvzjkW03WODIFJPkluY/J/Fkm205baWwtZ8q+98
Jbndba8MSfjGlWaVXIs75f5XKuMjItcLc+tv2Caxo+Jp7I7wKv54lTHhp0YXEK2D/4VxfndC5/wG
cOJ71cxHDnJkRZZpUwT32ykucbjjWcqa3v8Hk1sSX7tHasgxQJpDJbMClvXItmIBRnsKroKkIFAq
5LTSdln+7rUpRNq488uQ1x6s0IQAtU5EzUOcHr9oMAXv/meh40J69F//Z9aC5nIDnRDDawH2MbOG
JNcNsbLeZNjJjY+jv0j+gMUvFqo5fSkmodO99NSWQ4FbOs8GjbzMdEJ5/q5u2PSljaDxJt4S59EK
Ei6W5ZaVzIJ6eEn18zjL+Ysq1liGVmmtpMLs5u7GBZROR6yoG6I7zRfLRko8OlLFDsaB8TKmKE3h
aH/XVgOE9/tgQQpRDtZROWBktqwfG6A6U1v19rNTV4IIjQkVlkB6wFk6E5Ie+UGWRPSLqbbvwb51
NZwT9paEL0JDVrICiouf4tN6v6mRgYEe5ZV7kTgW0c2DPW869Vyq1Dy9ZIib+dQlWWKSIuYoNgNA
SgrtMZ1UrIlP723bKjwaRysHDyo2xbHQy9istm7RFgKO7FiT/ZaehcnwkEg6u4p6LOzVF7UpKFVv
KM6a7+TezS6QYKYeqifKQ3g0Xe0TEftuRnRleHQCAAAAcAgAAIR5ooYjZ6LZf9/7w3yvusKHgbm8
SXi2AJwWrypH6oCRXcmg+F1tKSnGsGKvGSskcYsUUHfKbd4cnNJrPs51on6hpglIa1gThjGMANri
eog3gwcWfr5V7UFsxFWwb1LhB5Cz8Jf+GoOX0IzsVY5xEh6jojpCXLmTs6KcJHxdTPjqCh0g8kXK
fQkIhjDFshqrNNga2w6HzpROxN7H1J02he4WON3w3ASOiS1GDjijrEwfiEZgBh2ErUlFXHn0DtV7
zteiw8dgBGoErm0Kz7DTdv7HheX7MVOxo/lVtziOomDGNqe5Ou0HXyiqTkWUFFntvEJWkn7R2XQs
3ft6I7uSGSvl13/B+1y67omuZaWX/m54B6KNj1xsPHDbZTiXkHOtz6SA4wEVvjqtXJAdQsY1UYpq
Zf/Yp1czzAdrrhyeY+S88Yxh38M4LZG13cZPO/I/GCnqg9zE162RQihpFqYKC08bzRJ6NJ8ZTTNU
z9YBBxA3SZsXla+G2EHbDm7vAumjo1wfZgm4JRybC3UYtcOFJhxhdmlwAQAAAJABAABC6Q2D9vWf
pWxZYayHaWKj9V/NTb3VEf0IuWUmB4L3fOdR4beD/cjwc5o5vTSEc4O5MP5bafGZ+aIv+gExVGqQ
X343c/0RWthYfhBuWPadIStZrDCUR22Ubq2ZuIIUbxRTi14YHT/a+5kX6DqWr5XpPf6qbRZUf5yg
96uZmIH771AtsWn23SfzUhS8Bykd3F7sk9HDAAr/bvr4jENoPAyobWq9VKugXoA4YSzSwpNPr39P
HwQidhwtmkwCYWE8Lc09JNYJPAEBxP/cQWTSYNWr0Yj+B0Fr2KV43fd4kK8leeNf+YSFF+xW79F4
VmTq/AhBpF1ncWgpLrJOO7xeo9WtW9QKFBze/qYET83+0RBbrTvHR/T6xBbHsygq8y+I+VAaoX+Y
Pv3IPrbEgWzQZ18+ilQ7tiJR8g5qtfASd0Qokj3Fgr424d4wjjI+IHBmLJulbt7tadq22lH5nQ3g
r3vPCBeU568Tfwq3CBzP5tXaOoh7KFRDgWwY4pYW3dhql/qtiTAAU/k+GZZlPP0I1T9xDBKHqvLA
vjJ4oXhxshcU47gm/ug5kv36i0o8j/12ONYmHIIWQX7UWz9LvWJTvHPk5+hW8+DTUDaCh//f4GVb
Qt4p2GLUgzJ7cILAMg5XbLdC07VA/ml9fMU0GvQWFzBxJuHLoNyCF1azw6tCFKCZB0GbgpSg0Tdx
8j1ykG+BNJlscgYP8sCNt7ORf20Hrz8tHvnawOCSsAmQZSCRjVEO/YuOAiTzlLFp5jxJZLXSCVXx
PHeF5xSY21ycEmeuBK7vY0X38/JfAc0k+WEBK1432hGIdtLz1RwjbzvLBznh5EX0WIuThxQoJ6u7
ZJr17HjylbFgFwfcJkWVeZS7ICHG1D7hJ4yqYrCxyVLxC5qkTmzfpqwdxaHf1ZmbZ8rI6w4QcXMy
hNDOaZOGV5ju6DHGR3ie0tDXyYuKu/UugnmAgBVm0+GZ6wmRmX/N3FRSWLG61pDuI5JWwYXQ6uWj
hNgzoRXblO6eEUq/BLXZ0Fv4/Q1R4zNwOcVbdYorWlWxPBfEO8uRJiO1FL6n3hBsT7pbEDXp4yLQ
G+bgJfU5Q6tLKIXR+1fGAA+GLgHKv6YdAh5TwP6oNrI4h3s6JnJRvriwoir2R4iUcjUIJmk+XDY7
fuDMiZCU+DvGp6XmwgC4THIccmYUCcQduCzr9W8y8A3U0K83fCPQAa/hTKpYjHP5WzG4HzWg5VDs
yWwuLszr2hc5WX/4/kddZLuzTOAWro+hjUJR1PJcMUJI6qjr5OlnPZ80qv+ZD4T3hMTcDc18Ayfh
gP5WXqQMpiMRto1TKLZtl7i74jn2Jq9CE1Vkz2KVohYbTGl9/WZhncWfeI8ihGBQwk3DCCl7fZW7
hxWvNZxxW2e5RzmKqAzPUlfEq8WpNzwu8uL7QVeQRjq4wZrT5VgALXkHfms5r1MAJbueXKf9U8Gk
dTF00QmQnOkOAK6RNmPvlCUafRXh+h7pvlBOleUVJW2hddVbLwJyH1N1qnC3nM35MTT/lCRoQQz9
qv3c6ZL+eSt9TQx+hAgkSzLALZCfMstqbj0ZkVc5I55sZqyxyM2XkOGoVrAz7kn9u2P62Xoo7lz7
iVQEl5/qcM00Ll32lz9IKlkQOGpddwwqcbdap4DA3CqYONNWtUK4Cbcx6sSKVBxADpoCr1m8BRWV
Sx2PQ9Tw2V8eiO79iuAFHo0TCa1RA1no3E7yAZVjctRpn340EHfO2xiEPzG8zLHxqtcrcqp3IzHJ
KoHHGvSC606cDGh0dHACAAAAMAUAAA5/+IJnWs7WVAscosvo+dn39bgMbnyuUKhBGmF+rCynWFDf
6E0x2QVJqVKRukBrgo1XzhTG7XdKDjYyfQ43y1+cX9AKKOTXVwDpXLxnoHMRWlXmO36YDzBivO4E
h7GAnaJco0z9FfqPYsT0v49gurvEHDWixk/5GLnuwHTRyTBG20kvEvnQKEWWmonBHsnlpFnEPB3s
ttG/fZQsh5/3vqjkHgZ9vWPKnqZJbTTVt8ISJcZ1vj3z5j6Hsnh2B8x9ze7Lo3z2aNmMoWUaNPr7
db58b1oEyBQyLoHv33it/zdP/D06O/XdoZ+PLWfHnqx/4dqaNaXK5aBPqWQCP8ztjPGMBJwqyTSk
m1aeQUdjwBmLE+dH52MV3ol3gcVRTrRknGnJW4OVAdq6SCzBRsXV/M4S3Agxf99Is2YWRmMLLzAm
nUo+tTv+7b8KkNPoJCQF4foIJX8XRx5o0REbHvlCGpxSckPZeXsSJHXTd4E3wSxUySZHQC8t4jle
9DQ/X5BlS364ni/Ara+flpT0kWv5MmqUsetT8S/wqGH6zvr/jWq1GC+CV1aQo0JKO5vOB7cOr/vl
qfOvo+0g69h48fv40+BMHFQhlazcETWcm40l4W4AAxFDE/QwBhQUHgoKdwYeVhYmrl5rFtl0IiT3
zRlBkCpJf/bQPkQc8R3VKSh3BRZxrQWYWLTf5VTRaGhbrFELpp9iUrSGor+2YFkZ78+DyRzT+zFy
V3u9IAIt8kAd/sNB5riVO5ZxErVI+usYgjb2D5ZcmUEHpgWse76VeWCn2dRH3YWQQJg+G8vFoT21
NjaT7JB65Mdaqjqe3yM5GpsUhKZfF3tL11J6lM7v2ldx/TR6HsC3eCgCMl70relxQOIC9HKP3s8A
uIFxV6vUPpoMhtHO4lb5s7dVRG4G0Aw8H1AImDyd5m33UE1Bvj1yXWhGJUqR0XKDLFoahrBFYjV/
6lfAlneiIL5jt3dgG3zroe9nDMqObhNY98C8gk6A5eYKH7raOVCI9uWIC4Fc02/E9FHYA11CNlzF
WRRmMs77S7AkTV4M9a6RuWd7bfJSUD+THx47DhbHwbQm5l+CmSkBm56kXE7W8TA+j+fNlMXVLtrL
VFj8sL4spM0QUuoP6RynDX7b8gtkytPIpXqq07Mv+Qqhwg7Eyfp77DpotmxyWLl/3EUl5MyuSv+l
cvTVUBD5K4CeI6KeRQssFZBdXAPGEGu27ho/b30/83YWe1HpyuxynU5TwBNCW7RlkufkCxISjV+v
G8G8AsXAD6nUYX2cSNjOQbh7RL0oqbSkhCLCuBeD//IAAAyNQ7fEREOgszKx9F0aGVJju0Ezcpmp
IY158YQz09mnldhJQsO4lf0ffZkqHNX8ufbU4UCRWGNCtu/Df8ong1c7x3lSTQ6VLzhsriO+YFRg
z9CpiLsFY1w5QpGVrjQD+0sPCIlLfwW3jmHdi1/NnuefjLPTaYxD978dhWFJqIMzv6Mg+557DCOy
oZJE52dK6C59ESO6+uNaRR9eDlNyNhqpkCtCzV7CzLSWK6vpS/32UsavTNvR/Xj6KSTyUMLBYaoB
xc39MsL3YO+XRfJy+sRSs2d2VEZDCEFzbuZGPzbHWGLpt09sCVL9802p8leOVBd4SS94WlWpMe/t
dLsJuR54vZ5vQ9rRTgB12W+hAkOJkDCk9rnwVAnWgrOhgcuAJaxcFxrx6pgNBB+o2Sg125eM5ubI
TJXUN0CM7VUlrGG5CWWfdkfQOU0E9D3B4Vbi7PWeTtA1fIDqEl6C9Ic/2R12uhHaATVcO44YUE3M
KEsAAWl4rY4P6VgCsVfPFfxiwuB3iXagmnf59Y391HznsL3HaOp3H/ddEelw3tRSdsRDvc8QMfJE
+V+kdN1j4xnnWZriufkhDQ0sxrgtQqZEQKRVpee4X5ddfIMXwtlhlxr7iVPSIBSGDRtTXJzUonnZ
l7UbU/R24MxRmi4GQ0MVnvc0acSkJtiEfp+fy3YebBfuvlGWl92lDY4W4OdFoziC6iJl34hxZu+7
Hz3et9h/fsaLnzi+yVoQcFhVJhhXyJHeUleepON6BDAjjP/19pXOAEio0xSdGgCFICzZuZwkp54C
wM4WQapTS6phaAEHIMmeLcrdLh1QNGvKiZfYQ7qz2OfUOuxl1ZtcbrQ4CpFx7AQAYtSL4Nzk0lIW
yMcCu9L1VhOfd0pnh5qYqAqUSSu2AcQDapxDTnVesrdbzgJ60YZOfeXI4AvyeiqlEGx6OZfT2AhF
u9wDOlHLyHW7Xu8vqL39RFVjcZnaftNK6CCEaWT5kwdfznyNaxHH/W/V1Qm3/m56vhWgDYDKZAJJ
QzMwqcLPcvP5ugo2nj9BuCIj1kkVTw4uRwokpwUEFKmOV3WoC1QdsG+LfW8gDDWirdYIdyRWKTeq
Maa/1ZuhHiBqvupL+pSGSwgTVKwNUL2O+j6OmVejPAFlBxAjWrr3dpSm/DWJyQ3cELWQNKdUeopH
CkeFVKO1QKRf6TexuD7TwOkkqD1wjZ3TVq0ykjzMq8emyUt+tSJi56BqhYHo/fSWZ6foLnDDh2yb
fTYNU9dfCZgL9rI3PoCPeEV2NQKcIAUtcL3sA6RysFlirvwi2a7MdCoq9QWRyoFzh8G27OhV1ZZ8
1nueizE0XcT6VthXvn2F/YEDQNAMa5FdcBe7vfDcGZUM5OjXkB8+RTxTd+rusXkNzweXd881qriM
BLa+lWrneaT/VhkzuVWOkobEbOvUzwInE7XH6f6zM9mbNxqn7CBOmxLNC6kJ/7a/+2jQglawnYuL
UqIEmxboAKsA3GmwIvgBV8KDqNnDBwMxCiUKapWgt2oJaLwClKD5lmy/h1ssrA89PjLeV97vWpYF
mozY5zv6Z3zDufPlqU8qxmyPpz+MFhYqWYC3f3EcEhxiSvog6UsmCUBt6zgd2rrZ6E5BUOwlthh1
DaoJsSygiNUsgqJCmRyCSU4ePaq3xGDSs0GS/Dtej6P0UOHjFotwLewpF9khpsKqiYi39BR9CvAj
S7i5jumkn018haC18G1Dc39DpRywDkjwOirFqG/2w4zx9htmTyuMrD943/M1wm+psVc0QQFOrIm9
NGym0m0naoN2ICu/16PanhCJu2lr46T7mi2xrSYxKy5QH4kflq5uaCMSia7t8+4fsdZDE222xHrq
CSKHYXymhUs46OqzJi413Gc2TmfOxgLxhaPMIGOqflMCrZwPJYZoK9H/Vp4Kkmujn4ui7/g3ys+P
ASrq9Gc4OzFLhPD8ia9+lKT9EQzcBZnwdaPKn6nXG1HV7GQFMpN08jCYIgHVnjnJAAE2A3ldRzT+
zoj85VwHEZXrGvTol5+OCeZ+RvwzHmiYod3rGpr3x3n/ZjDPZs4NDk3P/BwAyMix6Bb2l+Ln1VoA
ZWuSEd5c8nsIkaZkQmXAzy1OyJpDC3BgbBd0UA631csPgfUaRMlGRaAI09zMcWkEMccjd/UubXuh
e2U7w+fBkjpn0Ln+U1t63tnFN9eunqYVfsw5R2mthEzNMKr90xpwsQ61u/LXme6N3sim/S7Xe1XU
cPBMe5fIi7VY6dQDhmNwVYFN8TufX1b1hYXVkgoown1zGKJXTp3rhwDSCsxhl8d/eEF2Xwdk3iOi
P/DrZ2IZXzu6TV2sw60/TyDAbcjjMBVOtrbobnRjEvb+vqDfNdIAgvx64F21aE8pc5fPCLhymPDP
fFqzBLH2YD5g5++86b8UTOkwGxbjIuJHcgFw8/t4HtfGldiIFHndA1MvIZ2+qBowJeuwTm3bCQ6c
nGHUnFuYj2QWHm7dLqsX8Wwpg6Di4jYu4ONa0GfFD6Xxg9cyKaSkw08nX//xKBKT6GFhLMCNEECy
xHyHzuTeiuPA/O5krlAueTl/tBHqMTCFsuXMrUG8NP3eupB4/lMC6y59xhsI76BOVuN2+/r7zr1I
MHRONLGdnZkv1bG3DlrzLiu/ka5/ifLzRSLXBWmtzO7Y41T1u5FEeLLLorkyAL2pUYrw+BYgnO3W
61PHt+Q1EDIQFX8v8yFZmiL4Ip9Q2CGC7xLfYRWohp3cvnBZ82rWDhVYBU8h8HYfGC/suAmf9eq/
G204JaYYeyc7P+pPVU1DdlpfLk76PjxETBrOhwDWZsqY4eEcensZYaAFIDkaWrmPrL9Gg5dwo5O7
j536cu2p30UteSv1L2pe2nA4qN5B4s54vG9A1fnZdB5KdEY5nHVOliMngv39i/UHjyIlEkDKarzo
dmMVxYJBHV90jezaOe/p25U3SOFj6fx4ZOXK5quuVeuhN3GHWFkgkTC0322OGHRXWoEpNARYNv+z
hT+CubmnKToNod9a4MfI76p6fmRNl9++ZOFR+O3zt7XzQOhqn31ZHjLg0nCJGpV70kQYXmqEkdJe
LdFeGOE2elBr+NS/ioiLYE+8JtSHktJVJOanjQ4PZe3gSkGMWpRanxyTaJOTRaME23oAPi3h9Axs
DprP79rIOTzBU+LQU/Hwxl3mapCAet2a6OBBcce/7wD+sA2se16kQwlZCIAGp88e/Pv5MCE3Bb0d
dm7LEzCoiHTyVvqLe7nu6KKiHI29/oDWVjrHrEVrHYt4rInxFM+6wo8ZVp7EWbpPvHCrwN7iU2QX
7ENNxZb2SefMHgDTfn87yF//NIasbekUM6o6Oe8bEU03tTS4Mj9v9nEyY4o/4vKvtKr5t+O0Zpuz
yrAoKYqrUzxdc1Rs3Tlv1YwsdzTFC8po63CbiJoIb7PbX4rlM6TVgW6MX1YJg2le+hTikcIEsTFu
ZXdzAgAAAPANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAADhwAAAAAAAAMHAAAAAAAAAAAAAATHAAAABwAAAAAAAAAAAAAAAAAAAAAAAA
AAAAADhwAAAAAAAAEQFHZXRNb2R1bGVIYW5kbGVBAABLRVJORUwzMi5kbGwAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAA

----VEVG5M7OXE7C1I38HEJ8XUVW127WT--


From owner-linux-xfs@oss.sgi.com Wed May  2 12:50:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42Jow609320
	for linux-xfs-outgoing; Wed, 2 May 2001 12:50:58 -0700
Received: from fluffy.biglal.net ([151.199.74.217])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42JouF09309
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 12:50:56 -0700
Received: by fluffy.biglal.net (Postfix, from userid 501)
	id 84A7EA68B5; Wed,  2 May 2001 15:55:34 -0400 (EDT)
Subject: OT: modem-13.kleins-butterfly.dialup.pol.co.uk: you have a virus
From: "H." Lally Singh <lally@vt.edu>
To: linux-xfs@oss.sgi.com
Content-Type: text/plain
X-Mailer: Evolution (0.9 - Preview Release)
Date: 02 May 2001 15:55:33 -0400
Mime-Version: 1.0
Message-Id: <20010502195534.84A7EA68B5@fluffy.biglal.net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, if anyone else has been getting an email message via
hahaha@sexyfun.net, look in the mail headers for the original machine,
because that one has a virus (I forget the name).  Any recent version of
antivirus software will fix that for you..

From owner-linux-xfs@oss.sgi.com Wed May  2 13:19:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42KJMB19158
	for linux-xfs-outgoing; Wed, 2 May 2001 13:19:22 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f42KJLF19149
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 13:19:21 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 2 May 2001 20:19:21 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001050214153685:141130 ;
          Wed, 2 May 2001 14:15:36 -0600 
Received: from amis.com ([172.16.17.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001050214190547:13326 ;
          Wed, 2 May 2001 14:19:05 -0600 
Message-ID: <3AF06BA4.AF3CAD60@amis.com>
Date: Wed, 02 May 2001 14:18:44 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de>
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 02:19:05 PM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 02:19:15 PM,
	Serialize complete at 05/02/2001 02:19:15 PM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 02:15:36 PM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 02:15:37 PM,
	Serialize complete at 05/02/2001 02:15:37 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks for the info -- I think I might have a non-xfs problem here.

I recreated the filesystem with ext2 and retested. It locked up just
the same.

eric



Andi Kleen wrote:
> 
> On Wed, May 02, 2001 at 11:40:27AM -0600, Eric Whiting wrote:
> > My hardware is Tyan 1854, PIII 866, 3com 905b, 3ware 6200 ide
> > controller, ibm 75G ide disk.
> > My base OS is SUSE 7.1
> 
> SuSE 7.1 comes with gcc 2.95; it is a bit safer to compile with an
> egcs 1.1 compiler because there have been problems with that compiler
> version and XFS in the past.
> 
> > Questions
> > ---------
> > 1. what debug can I do?
> 
> You could compile KDB in if you didn't do it already (it's part of the XFS
> tree); then either don't run X or put a serial console onto the box.
> When it hangs you have good chances that you see an KDB prompt (it could
> be happening already and often looks like a hang in X; if yes your keyboard
> lights should be blinking). Then enter bt and send the results to the list.
> It's easier with an serial console to do that of course.
> 
> If you get a hard hang it's much harder to debug. In this case it's also
> likely that you're running into a generic 2.4 kernel problem; contact
> linux-kernel@vger.kernel.org with your  hardware configuration and setup.
> 
> -Andi

-- 
__________________________________________________________________
Eric T. Whiting					AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Wed May  2 13:50:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42KoaY30388
	for linux-xfs-outgoing; Wed, 2 May 2001 13:50:36 -0700
Received: from foehn100.plesnik.bonsai.de (mail.plesnik.de [212.117.70.78])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42KoYF30372
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 13:50:34 -0700
Received: (from mas@localhost)
	by foehn100.plesnik.bonsai.de (8.9.1/8.9.1) id WAA07395
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 22:49:39 +0200
Message-ID: <20010502224939.A7331@foehn.plesnik.bonsai.de>
Date: Wed, 2 May 2001 22:49:39 +0200
From: Martin Spott <mas@plesnik.de>
To: linux-xfs@oss.sgi.com
Subject: Re: XFS for Linux 2.4.4 query
References: <200105021820.LAA05754@mail24.bigmailbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.1i
In-Reply-To: <200105021820.LAA05754@mail24.bigmailbox.com>; from Jonathan Day on Wed, May 02, 2001 at 11:20:21AM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 02, 2001 at 11:20:21AM -0700, Jonathan Day wrote:

>    Any idea if you'll be making a 2.4.4 patch?

As mentioned I think yesterday on this mailing list, a patch for 2.4.4 is on
the way,

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed May  2 14:02:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42L2GN02673
	for linux-xfs-outgoing; Wed, 2 May 2001 14:02:16 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42L2FF02663
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 14:02:15 -0700
Received: from [195.20.224.208] (helo=mrvdom01.schlund.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14v3lG-00073o-00
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 23:02:14 +0200
Received: from pd901e312.dip.t-dialin.net ([217.1.227.18] helo=kernelpanix.aura.of.mankind)
	by mrvdom01.schlund.de with esmtp (Exim 2.12 #2)
	id 14v3lF-0001dk-00
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 23:02:13 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f42KLwL11305
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 22:21:58 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 2 May 2001 22:21:58 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: linux-xfs@oss.sgi.com
Subject: source for cvsup
Message-ID: <20010502222158.A11282@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi

sorry for being a bit ot.

can someone give me a url for downloading cvsup. ftp.freebsd.org changed
there structure. i searched the net about one hour without luck.

or someone (at sgi) put it on a ftp server.


thanks.

utz

From owner-linux-xfs@oss.sgi.com Wed May  2 14:19:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42LJNW08664
	for linux-xfs-outgoing; Wed, 2 May 2001 14:19:23 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42LJLF08648
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 14:19:22 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA624712
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:19:18 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA46054; Wed, 2 May 2001 16:18:02 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f42LH1B18292;
	Wed, 2 May 2001 17:17:01 -0400
Message-ID: <3AF0794A.42EB2167@thebarn.com>
Date: Wed, 02 May 2001 17:16:59 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: utz lehmann <xfs@s2y4n2c.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: source for cvsup
References: <20010502222158.A11282@s2y4n2c.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

utz lehmann wrote:

> hi
>
> sorry for being a bit ot.
>
> can someone give me a url for downloading cvsup. ftp.freebsd.org changed
> there structure. i searched the net about one hour without luck.

freebsd's main site has been down due to some hardware problems
try one of the mirrors
ftp://ftp10.FreeBSD.org/pub/FreeBSD/development/CVSup/binaries/

>

>
>
> or someone (at sgi) put it on a ftp server.
>
> thanks.
>
> utz

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  2 14:36:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42LamD12064
	for linux-xfs-outgoing; Wed, 2 May 2001 14:36:48 -0700
Received: from chimaera.imperial-starfleet.net (pool4019.studentenheim.uni-tuebingen.de [134.2.214.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42LajF12054
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 14:36:46 -0700
Received: from student.uni-tuebingen.de (localhost.localdomain [127.0.0.1])
	by chimaera.imperial-starfleet.net (8.11.2/8.11.2) with ESMTP id f42LckB13033
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:38:46 +0200
Message-ID: <3AF07E66.5000001@student.uni-tuebingen.de>
Date: Wed, 02 May 2001 23:38:46 +0200
From: Simon Pabst <simon.pabst@student.uni-tuebingen.de>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686; en-US; 0.8.1) Gecko/20010425
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: RH7.1-XFS won't boot
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi all,
thanks for your help - I got it installed.
Looks like there is a problem if the root partition
is beyond the 1024 cylinder and you're using a bootdisk
to start it.
I moved /boot to the beginning of hda and now everything
works smoothly

thanks!
-Simon


From owner-linux-xfs@oss.sgi.com Wed May  2 14:48:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f42LmjX12489
	for linux-xfs-outgoing; Wed, 2 May 2001 14:48:45 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f42LmiF12486
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 14:48:44 -0700
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14v4UE-0001yB-00; Wed, 2 May 2001 23:48:42 +0200
Received: from pd901e312.dip.t-dialin.net ([217.1.227.18] helo=kernelpanix.aura.of.mankind)
	by mrvdom00.schlund.de with esmtp (Exim 2.12 #2)
	id 14v4UB-00010a-00; Wed, 2 May 2001 23:48:40 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f42L8Mr12205;
	Wed, 2 May 2001 23:08:22 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 2 May 2001 23:08:22 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: utz lehmann <xfs@s2y4n2c.de>, linux-xfs@oss.sgi.com
Subject: Re: source for cvsup
Message-ID: <20010502230822.A12168@s2y4n2c.de>
References: <20010502222158.A11282@s2y4n2c.de> <3AF0794A.42EB2167@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF0794A.42EB2167@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

btw, a "*default compress" should added to the supfile examples on
http://linux-xfs.sgi.com/projects/xfs/cvsup.html


utz

From owner-linux-xfs@oss.sgi.com Wed May  2 17:15:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430FpN16610
	for linux-xfs-outgoing; Wed, 2 May 2001 17:15:51 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430FoF16607
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:15:50 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id RAA09630
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:15:48 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA18385 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:14:31 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA35382
	for linux-xfs@oss.sgi.com; Thu, 3 May 2001 10:14:30 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105031014.ZM52193@wobbly.melbourne.sgi.com>
Date: Thu, 3 May 2001 10:14:29 -0500
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: linux-xfs@oss.sgi.com
Subject: (Fwd) Quota tools
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

FYI - for those following the quota releases, there's
a new version on sourceforge.  This package has made
its way into the Debian unstable release now also.

There were no changes directly related to XFS in this
version (and there are none pending).

cheers.


--- Forwarded mail from Jan Kara <jack@suse.cz>

Date: Wed, 2 May 2001 11:50:53 +0200
From: Jan Kara <jack@suse.cz>
To: mvw@planets.elm.net, nathans@wobbly.melbourne.sgi.com,
        Michael.Meskes@credativ.de, pblaha@suse.cz
Subject: Quota tools

  Hello.

  I've just made a -pre5 release of quota tools which should
include mainly various bugfixes...

						Honza

--
Jan Kara <jack@suse.cz>
SuSE Labs


---End of forwarded mail from Jan Kara <jack@suse.cz>


--- Forwarded mail from Michael Meskes <meskes@debian.org>

Resent-Date: Wed, 2 May 2001 12:28:03 -0700 (PDT)
From: Michael Meskes <meskes@debian.org>
To: debian-devel-changes@lists.debian.org
Subject: Installed quota 3.00pre01-2 (i386 source)
Date: Wed, 02 May 2001 15:06:17 -0400
Resent-From: debian-devel-changes@lists.debian.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed,  2 May 2001 14:13:23 +0200
Source: quota
Binary: quota
Architecture: source i386
Version: 3.00pre01-2
Distribution: unstable
Urgency: high
Maintainer: Michael Meskes <meskes@debian.org>
Changed-By: Michael Meskes <meskes@debian.org>
Description: 
 quota      - An implementation of the diskquota system.
Changes: 
 quota (3.00pre01-2) unstable; urgency=high
 .
   * New upstream version based on 3.01-pre5.
   * Fixed more bugs in postinst and init.d script.
   * Removed workarounds for two bugs that were fixed upstream.
Files: 
 4508cea937e08a4ba55f439682997f08 644 admin optional quota_3.00pre01-2.dsc
 b85d6f2c3b3957b4fa531002989272db 36059 admin optional quota_3.00pre01-2.diff.gz
 2f05941affa3687dd2deba8a766d01de 314256 admin optional quota_3.00pre01-2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Weitere Infos: siehe http://www.gnupg.org

iD8DBQE68AjQVkEm8inxm9ERAl4wAJ97CdKnRh18Pay68cUHw079YML05gCfa2I4
euyA1rbHX1BsL7dVOizLFB4=
=+8Sn
-----END PGP SIGNATURE-----


Installed:
quota_3.00pre01-2.diff.gz
  to pool/main/q/quota/quota_3.00pre01-2.diff.gz
quota_3.00pre01-2.dsc
  to pool/main/q/quota/quota_3.00pre01-2.dsc
quota_3.00pre01-2_i386.deb
  to pool/main/q/quota/quota_3.00pre01-2_i386.deb


--  
To UNSUBSCRIBE, email to debian-devel-changes-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


---End of forwarded mail from Michael Meskes <meskes@debian.org>


-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May  2 17:19:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430JRA16698
	for linux-xfs-outgoing; Wed, 2 May 2001 17:19:27 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430JQF16692
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:19:26 -0700
Received: from crom.corp.sgi.com ([130.62.63.32]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA03614
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:19:24 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA77235 for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:22:57 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 5748DCED7A
	for <linux-xfs@oss.sgi.com>; Wed,  2 May 2001 17:18:08 -0700 (PDT)
Subject: XFS-1.0 on SGI 1200
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 17:18:08 -0700
Message-Id: <988849088.12143.22.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


While installing XFS-1.0 on a SGI1200 with Mylex DAC960 card...

1. When the installer formatted the partitions, i got this:

mkfs.xfs: warning - cannot set blocksize on block device /tmp/rd/c0d0p5:
Invalid argument

...and the same thing for some other partitions, not just c0d0p5

2. After the system rebooted, it couldn't mount /dev/rd/c0d0p1 and
that's /boot on my system. :-/
The idea was to create a small /boot at the beginning of the disk,
formatted with Ext2, and a bunch of other partitions after that,
formatted with XFS.

3. Reinstall, this time with an XFS-formatted /boot
Now, i got the same errors while the installer formatted the partitions.
After reboot, no partition was mounted except for /
For all the other partitions, it complained about not finding the
specific device. :-(

4. At some point during the install, one of the four 36 GB HDD that are
tied into my RAID5 array started to light the red LED, and was marked as
bad by the RAID controller. :-(((

Oh, BTW, i'm using text-mode install.

-- 
Florin Andrei

"Bloat is not about being big. Bloat is about being slow and stupid and not
realizing that it's because of design mistakes." - Linus Torvalds


From owner-linux-xfs@oss.sgi.com Wed May  2 17:34:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430YY917153
	for linux-xfs-outgoing; Wed, 2 May 2001 17:34:34 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430YXF17150
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:34:33 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA28212
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:33:11 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA56040; Wed, 2 May 2001 19:33:16 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f430WFq02526;
	Wed, 2 May 2001 20:32:15 -0400
Message-ID: <3AF0A70D.C5CE4733@thebarn.com>
Date: Wed, 02 May 2001 20:32:13 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chmouel Boudjnah <chmouel@mandrakesoft.com>
CC: Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com> <m3bspbwotj.fsf@giants.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chmouel Boudjnah wrote:

> Sven Herzberg <herzi@runbox.com> writes:
>
> > First thanks to SGI and all the developers for the Release 1.0.
> > Now I've got a question: *Is there anyone providing RPMs for Mandrake
> > 8.0?* 'Cos the RedHat RPMs are conflicting with Mandrake's initscripts
> > (I think it was the file "install-kernel").
>
> We may provide some additional set...

Yes please.
I've  build a patch against the 8.0 kernel src rpm, haven't tested it
yet but it does compile.
Anybody want help finish it.?


If fact  I would to encourage some savvy installer programmer to add  XFS
support
to the mandrake installer. I've looked at the code and see reiserfs is
already in
there shouldn't be to much work to add xfs.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  2 17:34:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430YuP17165
	for linux-xfs-outgoing; Wed, 2 May 2001 17:34:56 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430YtF17162
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:34:55 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA03622
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:45:38 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA13363 for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:38:28 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 5F2C4CED7A
	for <linux-xfs@oss.sgi.com>; Wed,  2 May 2001 17:33:39 -0700 (PDT)
Subject: Re: XFS-1.0 on SGI 1200
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <988849088.12143.22.camel@stantz.corp.sgi.com>
References: <988849088.12143.22.camel@stantz.corp.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 17:33:39 -0700
Message-Id: <988850019.12141.23.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 02 May 2001 17:18:08 -0700, Florin Andrei wrote:
> 
> 4. At some point during the install, one of the four 36 GB HDD that are
> tied into my RAID5 array started to light the red LED, and was marked as
> bad by the RAID controller. :-(((

Forgot to tell you, the drive wasn't actually bad. After shuffling the
drives and rebuilding the RAID array, everything was fine.

-- 
Florin Andrei

"Bloat is not about being big. Bloat is about being slow and stupid and not
realizing that it's because of design mistakes." - Linus Torvalds


From owner-linux-xfs@oss.sgi.com Wed May  2 17:38:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430cnf17252
	for linux-xfs-outgoing; Wed, 2 May 2001 17:38:49 -0700
Received: from amorphis.linuxinside.com ([209.245.61.134])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430cmF17249
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:38:49 -0700
Received: (from pruchai@localhost)
	by amorphis.linuxinside.com (8.12.0.Beta7/8.12.0.Beta7) id f430fDdM021525
	for linux-xfs@oss.sgi.com; Wed, 2 May 2001 17:41:13 -0700
Date: Wed, 2 May 2001 17:41:13 -0700
From: Igor Pruchanskiy <igor@linuxinside.com>
To: linux-xfs@oss.sgi.com
Subject: linux-2.4-xfs-1.0.patch
Message-ID: <20010502174113.A21501@linuxinside.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Sender: igor@linuxinside.com
X-Operating-System: Linux 2.4.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

I was wondering if anyone actually got this patch to work....
It keeps complaining about existing /tmp/null/Makefile
and i end up with 3 makefiles

Makefile
Makefile~
Makefile.rej

I am doing patch -p0 <  patchfile  on /usr/src

igor
P.S. Please reply directly to me. I am not on this list.
thank you

From owner-linux-xfs@oss.sgi.com Wed May  2 17:41:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430fVX17305
	for linux-xfs-outgoing; Wed, 2 May 2001 17:41:31 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430fUF17301
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:41:30 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA28905
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:40:08 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA13945; Wed, 2 May 2001 19:40:13 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f430dCq02609;
	Wed, 2 May 2001 20:39:12 -0400
Message-ID: <3AF0A8B0.FD03D9E@thebarn.com>
Date: Wed, 02 May 2001 20:39:12 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chmouel Boudjnah <chmouel@mandrakesoft.com>,
   Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com> <m3bspbwotj.fsf@giants.mandrakesoft.com> <3AF0A70D.C5CE4733@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:

note to self: proof read your e-mail

>
> If fact  I would to encourage some savvy installer programmer to add  XFS

I would *like* to encourage

>
> support
> to the mandrake installer. I've looked at the code and see reiserfs is
> already in
> there shouldn't be to much work to add xfs.
>
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  2 17:43:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430hYb17367
	for linux-xfs-outgoing; Wed, 2 May 2001 17:43:34 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430hXF17364
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:43:33 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f430hWT29279;
	Wed, 2 May 2001 19:43:32 -0500 (CDT)
Message-ID: <3AF0AA07.C4A72E6C@sgi.com>
Date: Wed, 02 May 2001 19:44:55 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Pruchanskiy <igor@linuxinside.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Igor Pruchanskiy wrote:

> I am doing patch -p0 <  patchfile  on /usr/src

try patch -p1 < patchfile in /usr/src/linux (or whatever the top of your
tree is)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 17:47:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430lS717470
	for linux-xfs-outgoing; Wed, 2 May 2001 17:47:28 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430lRF17467
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:47:27 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14v7HA-0001vA-00; Thu, 03 May 2001 02:47:24 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f430kkl23333;
	Wed, 2 May 2001 20:46:46 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Florin Andrei <florin@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS-1.0 on SGI 1200
References: <988849088.12143.22.camel@stantz.corp.sgi.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 02 May 2001 20:46:46 -0400
In-Reply-To: <988849088.12143.22.camel@stantz.corp.sgi.com>
Message-ID: <yq1elu7l0nd.fsf@jcb.mkp.net>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Florin" == Florin Andrei <florin@sgi.com> writes:

Florin> While installing XFS-1.0 on a SGI1200 with Mylex DAC960
Florin> card...

Florin> mkfs.xfs: warning - cannot set blocksize on block device
Florin> /tmp/rd/c0d0p5: Invalid argument

Ah, my bad.  Will commit a fix shortly.

I don't have a DAC controller around, so I never added the appropriate
ioctl to that driver.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Wed May  2 17:50:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430owr17637
	for linux-xfs-outgoing; Wed, 2 May 2001 17:50:58 -0700
Received: from amorphis.linuxinside.com ([209.245.61.134])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430ovF17634
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:50:57 -0700
Received: (from pruchai@localhost)
	by amorphis.linuxinside.com (8.12.0.Beta7/8.12.0.Beta7) id f430rQPZ021545;
	Wed, 2 May 2001 17:53:26 -0700
Date: Wed, 2 May 2001 17:53:26 -0700
From: Igor Pruchanskiy <igor@linuxinside.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: Igor Pruchanskiy <igor@linuxinside.com>, linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
Message-ID: <20010502175326.B21501@linuxinside.com>
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF0AA07.C4A72E6C@sgi.com>; from sandeen@sgi.com on Wed, May 02, 2001 at 07:44:55PM -0500
X-Sender: igor@linuxinside.com
X-Operating-System: Linux 2.4.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

doh! my fault....

that worked, but now linux-2.4.4-xfsTEST.patch won't apply complaining about already patched files....

igor

On Wed 02 May 2001, Eric Sandeen wrote:
> Igor Pruchanskiy wrote:
> 
> > I am doing patch -p0 <  patchfile  on /usr/src
> 
> try patch -p1 < patchfile in /usr/src/linux (or whatever the top of your
> tree is)
> 
> -Eric
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.
> 

From owner-linux-xfs@oss.sgi.com Wed May  2 17:58:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f430wIM17932
	for linux-xfs-outgoing; Wed, 2 May 2001 17:58:18 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f430wHF17929
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 17:58:17 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f430wDT04357;
	Wed, 2 May 2001 19:58:13 -0500 (CDT)
Message-ID: <3AF0AD79.5712D5D9@sgi.com>
Date: Wed, 02 May 2001 19:59:37 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Pruchanskiy <igor@linuxinside.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Igor Pruchanskiy wrote:
> 
> doh! my fault....
> 
> that worked, but now linux-2.4.4-xfsTEST.patch won't apply complaining about already patched files....

That's because 2.4.4-xfsTEST is not a released version, and is packaged
differently.  It contains all patched files, while the official,
released patches are broken into "core linux" and "xfs filesystem"
patches.

I guess that's not obvious, but we don't expect people to mix-n-match
patches... :)

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 18:08:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4318D918192
	for linux-xfs-outgoing; Wed, 2 May 2001 18:08:13 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4318AF18186
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:08:10 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA01612
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:06:48 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id LAA21401;
	Thu, 3 May 2001 11:08:03 +1000
Date: Thu, 3 May 2001 11:08:03 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105030108.LAA21401@sherman.melbourne.sgi.com>
Subject: Sync xfs with kdb v1.8-2.4.4
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Wed May  2 18:06:46 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93918a
linux/mm/vmalloc.c - 1.30
	- Add missing include/config.h

linux/drivers/char/Makefile - 1.43
	- Detect errors from loadkeys instead of generating empty defkeymap.c



From owner-linux-xfs@oss.sgi.com Wed May  2 18:12:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431C3218311
	for linux-xfs-outgoing; Wed, 2 May 2001 18:12:03 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431C1F18308
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:12:02 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14v7ey-0001w4-00; Thu, 03 May 2001 03:12:00 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f431BNU25074;
	Wed, 2 May 2001 21:11:23 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: linux-xfs@oss.sgi.com
Subject: TAKE - DAC driver
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 02 May 2001 21:11:22 -0400
Message-ID: <yq1ae4vkzid.fsf@jcb.mkp.net>
Lines: 16
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Date:  Wed May  2 18:10:53 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/d0/mkp/XFS/slinx-pristine

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93919a
linux/drivers/block/DAC960.c - 1.25
        - Add BLKBSZSET ioctl

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Wed May  2 18:25:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431Pr218642
	for linux-xfs-outgoing; Wed, 2 May 2001 18:25:53 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431PqF18639
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:25:52 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id SAA03211
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:24:26 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18968; Thu, 3 May 2001 11:24:25 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
cc: Aaron Lehmann <aaronl@vitelus.com>, Andi Kleen <ak@suse.de>,
   linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs build broken 
In-reply-to: Your message of "Tue, 10 Apr 2001 09:00:40 EST."
             <10104100900.ZM38682@wobbly.melbourne.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 May 2001 11:24:25 +1000
Message-ID: <7443.988853065@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Apr 9,  1:53am, Aaron Lehmann wrote:
> Subject: Re: linux-2.4-xfs build broken
> loadkeys --mktable defkeymap.map | sed -e 's/^static *//' > defkeymap.c
> /bin/sh: loadkeys: command not found
> gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-2.4-xfs/linux/include  -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe  -march=i586    -c -o defkeymap.o defkeymap.c
> 
> That's really weird. It should have stopped the build.

Fixed by modid 2.4.x-xfs:slinx:93918a, just checked into the XFS
development tree.


From owner-linux-xfs@oss.sgi.com Wed May  2 18:27:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431R1L18680
	for linux-xfs-outgoing; Wed, 2 May 2001 18:27:01 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431R0F18677
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:27:00 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f431QbB13967;
	Wed, 2 May 2001 20:26:37 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0C118.90109F1B@thebarn.com>
Date: Wed, 02 May 2001 21:23:21 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Martin K. Petersen" <mkp@linuxcare.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: TAKE - DAC driver
References: <yq1ae4vkzid.fsf@jcb.mkp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Martin K. Petersen" wrote:

> Date:  Wed May  2 18:10:53 PDT 2001
> Workarea:  gibble.americas.sgi.com:/export/d0/mkp/XFS/slinx-pristine
>
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
>
> Modid:  2.4.x-xfs:slinx:93919a
> linux/drivers/block/DAC960.c - 1.25
> http://gibble.americas.sgi.com/cgi-bin/cvsweb.cgi/slinx_2.4.x-xfs-nodel/linux/drivers/block/DAC960.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
> http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/drivers/block/DAC960.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h
>         - Add BLKBSZSET ioctl

Good.
Now how do fix Florin's problem.
I suppose we could send him a patch for the 1.0 tree
and have him rebuild the kernel?


>
> --
> Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
> mkp@linuxcare.com, http://www.linuxcare.com/
> SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/


From owner-linux-xfs@oss.sgi.com Wed May  2 18:33:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431XLt18849
	for linux-xfs-outgoing; Wed, 2 May 2001 18:33:21 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431XKF18843
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:33:20 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f431X1B13975;
	Wed, 2 May 2001 20:33:01 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0C298.581B899A@thebarn.com>
Date: Wed, 02 May 2001 21:29:45 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Whiting <ewhiting@amis.com>
CC: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <3AF06BA4.AF3CAD60@amis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Whiting wrote:

> Thanks for the info -- I think I might have a non-xfs problem here.
>
> I recreated the filesystem with ext2 and retested. It locked up just
> the same.
>
> eric
>
> As a sanity check here did you run the test on a stock 2.4.4 kernel or

on with the XFS changes?

It's entirely possible some of th XFS kernel changes has interfered with
something else
it would be good to either confirm or eliminate that possibility.


>
>
> --
> __________________________________________________________________
> Eric T. Whiting                                 AMI Semiconductors


From owner-linux-xfs@oss.sgi.com Wed May  2 18:33:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431XLN18855
	for linux-xfs-outgoing; Wed, 2 May 2001 18:33:21 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431XKF18844
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:33:20 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14v7zb-0001x5-00; Thu, 03 May 2001 03:33:19 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f431WfB26768;
	Wed, 2 May 2001 21:32:41 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: linux-xfs@oss.sgi.com
Subject: TAKE - Compaq controllers
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 02 May 2001 21:32:41 -0400
Message-ID: <yq1r8y7jjye.fsf@jcb.mkp.net>
Lines: 20
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Date:  Wed May  2 18:32:09 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/d0/mkp/XFS/slinx-pristine

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93920a
linux/drivers/block/ps2esdi.c - 1.13
        - Well, ESDI hardly qualifies as a RAID controller, but...

linux/drivers/block/cpqarray.c - 1.21
linux/drivers/block/cciss.c - 1.7
        - Fix the other RAID controllers while I'm at it.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Wed May  2 18:34:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431Y7r18889
	for linux-xfs-outgoing; Wed, 2 May 2001 18:34:07 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431Y6F18886
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:34:06 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f431XrB13979;
	Wed, 2 May 2001 20:33:53 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0C2CD.ED6A0186@thebarn.com>
Date: Wed, 02 May 2001 21:30:37 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Whiting <ewhiting@amis.com>
CC: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <3AF06BA4.AF3CAD60@amis.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Whiting wrote:

> Thanks for the info -- I think I might have a non-xfs problem here.
>
> I recreated the filesystem with ext2 and retested. It locked up just
> the same.
>
> Ohh and the kdb backtrace couldn't hurt either way if you

can capture it.



>
>
> --
> __________________________________________________________________
> Eric T. Whiting                                 AMI Semiconductors


From owner-linux-xfs@oss.sgi.com Wed May  2 18:40:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431ec919021
	for linux-xfs-outgoing; Wed, 2 May 2001 18:40:38 -0700
Received: from io.cox-internet.com (io-cox.cox-internet.com [208.180.118.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431ebF19018
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:40:37 -0700
Received: from cdm-233-165-vict.cox-internet.com ([208.180.233.165])
          by io.cox-internet.com
          (InterMail vK.4.02.00.10 201-232-116-110 license d1ebd4f8b91132ed01cf0e3e933da025)
          with ESMTP
          id <20010503013936.TNME26424.io@cdm-233-165-vict.cox-internet.com>
          for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 20:39:36 -0500
Subject: xfs-redhat 7.1 installation from hardisk
From: Michael Vanderford <michaelv@cox-internet.com>
To: linux-xfs@oss.sgi.com
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 20:50:52 -0500
Message-Id: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sorry if this is a dumb question but is it possible to
install redhat 7.1-xfs from iso's downloaded to a second hard drive.


From owner-linux-xfs@oss.sgi.com Wed May  2 18:47:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431ljY19229
	for linux-xfs-outgoing; Wed, 2 May 2001 18:47:45 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431liF19226
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:47:44 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f431lfU01852;
	Wed, 2 May 2001 20:47:41 -0500 (CDT)
Message-ID: <3AF0B913.C9AB7E0F@sgi.com>
Date: Wed, 02 May 2001 20:49:07 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Vanderford <michaelv@cox-internet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

If it's possible with standard Red Hat (and I think it is...) then it's
probably possible w/ our version as well - although I have not tested
it.  Let us know.  :)

-Eric

Michael Vanderford wrote:
> 
> Sorry if this is a dumb question but is it possible to
> install redhat 7.1-xfs from iso's downloaded to a second hard drive.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 18:48:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431m7r19242
	for linux-xfs-outgoing; Wed, 2 May 2001 18:48:07 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431m6F19239
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:48:06 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f431lxB13997;
	Wed, 2 May 2001 20:48:00 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0C61B.53065F9B@thebarn.com>
Date: Wed, 02 May 2001 21:44:44 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Vanderford <michaelv@cox-internet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Michael Vanderford wrote:

> Sorry if this is a dumb question but is it possible to
> install redhat 7.1-xfs from iso's downloaded to a second hard drive.

Sure just copy all the rpm from RH disc1 & 2 and the SGI XFS disc to
a directory on the second hard drive and copy the "base" directory from
the SGI disc not the RH disc.



From owner-linux-xfs@oss.sgi.com Wed May  2 18:51:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431pLR19330
	for linux-xfs-outgoing; Wed, 2 May 2001 18:51:21 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f431pKF19327
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:51:20 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f431p0B14004;
	Wed, 2 May 2001 20:51:00 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0C6D0.B24049E8@thebarn.com>
Date: Wed, 02 May 2001 21:47:44 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: Igor Pruchanskiy <igor@linuxinside.com>, linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:

Please be aware anything in the "testing" directory should be considered potentially
broken.

This patch has been removed at this point since the devel tree has been updated to 2.4.4


> Igor Pruchanskiy wrote:
> >
> > doh! my fault....
> >
> > that worked, but now linux-2.4.4-xfsTEST.patch won't apply complaining about already patched files....
>
> That's because 2.4.4-xfsTEST is not a released version, and is packaged
> differently.  It contains all patched files, while the official,
> released patches are broken into "core linux" and "xfs filesystem"
> patches.
>
> I guess that's not obvious, but we don't expect people to mix-n-match
> patches... :)
>
> -Eric
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  2 18:59:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f431x2E19521
	for linux-xfs-outgoing; Wed, 2 May 2001 18:59:02 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f431x2F19518
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 18:59:02 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 3 May 2001 01:59:02 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001050219551756:144037 ;
          Wed, 2 May 2001 19:55:17 -0600 
Received: from amis.com ([172.16.19.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001050219585421:13499 ;
          Wed, 2 May 2001 19:58:54 -0600 
Message-ID: <3AF0BB46.E00CE356@amis.com>
Date: Wed, 02 May 2001 19:58:30 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-pre1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> 
	 <3AF06BA4.AF3CAD60@amis.com> <3AF0C298.581B899A@thebarn.com>
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 07:58:54 PM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/02/2001
 07:58:55 PM,
	Serialize complete at 05/02/2001 07:58:55 PM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 07:55:17 PM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/02/2001
 07:55:18 PM,
	Serialize complete at 05/02/2001 07:55:18 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

OK -- I went back to 2.2.19 -- in order to test the hardware. I've
been toasting the ext2 partition over nfs for about 6 hours now and it
is still up. The HW must be ok.

Next step -- try a clean 2.4.4 system. I'll let you know. I really
want to run xfs.

eric



Russell Cattelan wrote:
> 
> Eric Whiting wrote:
> 
> > Thanks for the info -- I think I might have a non-xfs problem here.
> >
> > I recreated the filesystem with ext2 and retested. It locked up just
> > the same.
> >
> > eric
> >
> > As a sanity check here did you run the test on a stock 2.4.4 kernel or
> 
> on with the XFS changes?
> 
> It's entirely possible some of th XFS kernel changes has interfered with
> something else
> it would be good to either confirm or eliminate that possibility.
> 
> >
> >
> > --
> > __________________________________________________________________
> > Eric T. Whiting                                 AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Wed May  2 19:01:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43219N19600
	for linux-xfs-outgoing; Wed, 2 May 2001 19:01:09 -0700
Received: from gloworm.cnchost.com (gloworm.concentric.net [207.155.248.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43218F19596
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 19:01:09 -0700
Received: by gloworm.cnchost.com
	id WAA28938; Wed, 2 May 2001 22:01:08 -0400 (EDT)
	[ConcentricHost SMTP Relay 1.11]
Message-ID: <200105030201.WAA28938@gloworm.cnchost.com>
From: Mark Pinto <mark.pinto@capitolcreag.com>
To: linux-xfs@oss.sgi.com
Subject: xfs r1 debs
Date: Wed, 02 May 2001 19:01:08 -0700 (PST)
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

For the Debian Sid/Progeny Debian distributions

http://www.markybob.com/xfsboot
tools and kernels.  

Mark Pinto
mark.pinto@markybob.com

From owner-linux-xfs@oss.sgi.com Wed May  2 19:02:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4322Hh19645
	for linux-xfs-outgoing; Wed, 2 May 2001 19:02:17 -0700
Received: from infa.abo.fi (IDENT:root@infa.abo.fi [130.232.208.126])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4322FF19642
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 19:02:15 -0700
Received: (from jweeriks@localhost)
	by infa.abo.fi (8.9.3/8.9.3) id FAA23730
	for linux-xfs@oss.sgi.com; Thu, 3 May 2001 05:02:14 +0300
Date: Thu, 3 May 2001 05:02:14 +0300
From: Johannes Eriksson <jweeriks@infa.abo.fi>
To: linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
Message-ID: <20010503050213.A21878@infa.abo.fi>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.10i
In-Reply-To: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com>; from michaelv@cox-internet.com on Wed, May 02, 2001 at 08:50:52PM -0500
X-Operating-System: Linux 2.2.19
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Michael Vanderford [Wed, May 02, 2001 at 08:50:52PM -0500]:
> Sorry if this is a dumb question but is it possible to
> install redhat 7.1-xfs from iso's downloaded to a second hard drive.

I had some problems when trying to do it (with test3). I copied all the
ISOs (XFS, seawolf-1, seawolf-2) to a directory on /home partition,
booted up with boot disk (from XFS iso) and pointed the anaconda
installer to ISOs. I chose to reformat all partitions as XFS except
/home. Installation went without a hitch but when it rebooted the new
kernel paniced; it could not mount root device - unsupported
filesystem. So I reboot with XFS-enabled boot disk and have a look
around. I turned out that anaconda had installed Red Hat's kernel
instead of SGI's, so it had no XFS support. Luckily I a had prepared a
boot disk earlier!

So I installed the XFS kernel rpm and rebooted. I figured some other
things might have gone wrong in the install so I decided to burn the 
ISO's and reinstall from CD-ROM.

-- 
Johannes Eriksson
<joheriks@abo.fi>

From owner-linux-xfs@oss.sgi.com Wed May  2 19:04:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4324Gt19723
	for linux-xfs-outgoing; Wed, 2 May 2001 19:04:16 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4324FF19720
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 19:04:15 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f43248U06741;
	Wed, 2 May 2001 21:04:08 -0500 (CDT)
Message-ID: <3AF0BCED.E05CB036@sgi.com>
Date: Wed, 02 May 2001 21:05:33 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Michael Vanderford <michaelv@cox-internet.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com> <3AF0C61B.53065F9B@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Michael Vanderford wrote:
> 
> > Sorry if this is a dumb question but is it possible to
> > install redhat 7.1-xfs from iso's downloaded to a second hard drive.
> 
> Sure just copy all the rpm from RH disc1 & 2 and the SGI XFS disc to
> a directory on the second hard drive and copy the "base" directory from
> the SGI disc not the RH disc.

Actually, I don't think that will work.  Hard-drive installs used to
work this way, but now they want the ISO, not the RPMS, on the hard
drive, since people could never figure out how the directories were
supposed to be structured.  

It's in the release notes, and a quick look at the manual doesn't say
how to do this, but I've seen the discussion on the Red Hat list -
thread starting here:

https://listman.redhat.com/pipermail/seawolf-list/2001-May/001491.html

Apparently the kickstart installs still use the old-style hard drive
layout...

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 19:44:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f432iLo20438
	for linux-xfs-outgoing; Wed, 2 May 2001 19:44:21 -0700
Received: from amorphis.linuxinside.com ([209.245.61.134])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f432iJF20435
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 19:44:19 -0700
Received: (from pruchai@localhost)
	by amorphis.linuxinside.com (8.12.0.Beta7/8.12.0.Beta7) id f432kgW6021692;
	Wed, 2 May 2001 19:46:42 -0700
Date: Wed, 2 May 2001 19:46:42 -0700
From: Igor Pruchanskiy <igor@linuxinside.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: Igor Pruchanskiy <igor@linuxinside.com>, linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
Message-ID: <20010502194642.A21682@linuxinside.com>
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF0AD79.5712D5D9@sgi.com>; from sandeen@sgi.com on Wed, May 02, 2001 at 07:59:37PM -0500
X-Sender: igor@linuxinside.com
X-Operating-System: Linux 2.4.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The funny thing is that either one of the patches applys cleanly on it's own.
but as soon as you start adding a second patch it starts complaining.....

igor

On Wed 02 May 2001, Eric Sandeen wrote:
> Igor Pruchanskiy wrote:
> > 
> > doh! my fault....
> > 
> > that worked, but now linux-2.4.4-xfsTEST.patch won't apply complaining about already patched files....
> 
> That's because 2.4.4-xfsTEST is not a released version, and is packaged
> differently.  It contains all patched files, while the official,
> released patches are broken into "core linux" and "xfs filesystem"
> patches.
> 
> I guess that's not obvious, but we don't expect people to mix-n-match
> patches... :)
> 
> -Eric
> 
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.
> 

From owner-linux-xfs@oss.sgi.com Wed May  2 19:47:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f432lPd20498
	for linux-xfs-outgoing; Wed, 2 May 2001 19:47:25 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f432lNF20494
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 19:47:24 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f432lKd20113;
	Wed, 2 May 2001 21:47:20 -0500 (CDT)
Message-ID: <3AF0C70F.F5F0488E@sgi.com>
Date: Wed, 02 May 2001 21:48:47 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Pruchanskiy <igor@linuxinside.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com> <20010502194642.A21682@linuxinside.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Igor Pruchanskiy wrote:
> 
> The funny thing is that either one of the patches applys cleanly on it's own.
> but as soon as you start adding a second patch it starts complaining.....

Yes, that's expected.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 20:14:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f433EaY20993
	for linux-xfs-outgoing; Wed, 2 May 2001 20:14:36 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f433EZF20989
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 20:14:35 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f433EKB14304;
	Wed, 2 May 2001 22:14:20 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0DA57.7376774D@thebarn.com>
Date: Wed, 02 May 2001 23:11:04 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Pruchanskiy <igor@linuxinside.com>
CC: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com> <20010502194642.A21682@linuxinside.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Igor Pruchanskiy wrote:

> The funny thing is that either one of the patches applys cleanly on it's own.
> but as soon as you start adding a second patch it starts complaining.....
>

I'm not sure what you are expecting of these patches but please take a moment
to understand what a patch is for before blinding applying applying things.

I will have to says thing are getting out of hand in terms of shear number of
kernels and patches that are being produced and attempted.

Currently I have 4 different trees for the 1.0 release.
vanilla 2.4.2
vanilla 2.4.3
RH7.1
Mandrake 8.0
and a 5th just waiting to be completed
vanilla 2.4.4

And the 6th tree: current which fortunately has only one flavor and
is usually up to date with Linus's releases.

The only 2 trees that have been extensively test are the 2.4.2 and the RH7.1,
everything else should used with caution and a willingness to put up with
potential problems.

-Russell


From owner-linux-xfs@oss.sgi.com Wed May  2 20:22:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f433MsH21392
	for linux-xfs-outgoing; Wed, 2 May 2001 20:22:54 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f433MrF21388
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 20:22:53 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f433MjB14325;
	Wed, 2 May 2001 22:22:45 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF0DC50.59DEF191@thebarn.com>
Date: Wed, 02 May 2001 23:19:29 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: Michael Vanderford <michaelv@cox-internet.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com> <3AF0C61B.53065F9B@thebarn.com> <3AF0BCED.E05CB036@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:

> Russell Cattelan wrote:
> >
> > Michael Vanderford wrote:
> >
> > > Sorry if this is a dumb question but is it possible to
> > > install redhat 7.1-xfs from iso's downloaded to a second hard drive.
> >
> > Sure just copy all the rpm from RH disc1 & 2 and the SGI XFS disc to
> > a directory on the second hard drive and copy the "base" directory from
> > the SGI disc not the RH disc.
>
> Actually, I don't think that will work.

Ahh S*** your right I did run across that at some point.
Sorry for the misinformation folks.

I guess the best suggestion would be either an nfs install or
a kickstart install.

> Hard-drive installs used
> work this way, but now they want the ISO, not the RPMS, on the hard
> drive, since people could never figure out how the directories were
> supposed to be structured.
>
> It's in the release notes, and a quick look at the manual doesn't say
> how to do this, but I've seen the discussion on the Red Hat list -
> thread starting here:
>
> https://listman.redhat.com/pipermail/seawolf-list/2001-May/001491.html
>
> Apparently the kickstart installs still use the old-style hard drive
> layout...
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  2 20:46:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f433kmv22128
	for linux-xfs-outgoing; Wed, 2 May 2001 20:46:48 -0700
Received: from amorphis.linuxinside.com ([209.245.61.134])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f433klF22125
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 20:46:47 -0700
Received: (from pruchai@localhost)
	by amorphis.linuxinside.com (8.12.0.Beta7/8.12.0.Beta7) id f433mqVX021764;
	Wed, 2 May 2001 20:48:52 -0700
Date: Wed, 2 May 2001 20:48:51 -0700
From: Igor Pruchanskiy <igor@linuxinside.com>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Igor Pruchanskiy <igor@linuxinside.com>, Eric Sandeen <sandeen@sgi.com>,
   linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
Message-ID: <20010502204851.B21682@linuxinside.com>
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com> <20010502194642.A21682@linuxinside.com> <3AF0DA57.7376774D@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF0DA57.7376774D@thebarn.com>; from cattelan@thebarn.com on Wed, May 02, 2001 at 11:11:04PM -0500
X-Sender: igor@linuxinside.com
X-Operating-System: Linux 2.4.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

What am i expecting from those patches? 
hm.. this is a good question....
Me, as well, as other users of 2.4.x, expecting XFS-Release-1.0
                                                    ^^^^^^^
Isn't it ? and i would assume that "vanilla 2.4.x" would include 
.0, .1, .2, .3 and .4 ...

> vanilla 2.4.2
Um... month and a half old....

> RH7.1
> Mandrake 8.0 
Thanks , but no thanks.There are _other_ distributions
I use slackware.... And correct me if i am wrong, but isn't RH7.1 using 2.4.2 ?
And isn't mandrake the same thing with different installer and config tools ?

If yes, then all the development tree you guys are talking about is redhat....
redhat != linux 

I really appologize if i affended anyone but there are lots of people that use
other distributions and non-stock kernels....

Sincerely,
igor

On Wed 02 May 2001, Russell Cattelan wrote:
> Igor Pruchanskiy wrote:
> 
> > The funny thing is that either one of the patches applys cleanly on it's own.
> > but as soon as you start adding a second patch it starts complaining.....
> >
> 
> I'm not sure what you are expecting of these patches but please take a moment
> to understand what a patch is for before blinding applying applying things.
> 
> I will have to says thing are getting out of hand in terms of shear number of
> kernels and patches that are being produced and attempted.
> 
> Currently I have 4 different trees for the 1.0 release.
> vanilla 2.4.2
> vanilla 2.4.3
> RH7.1
> Mandrake 8.0
> and a 5th just waiting to be completed
> vanilla 2.4.4
> 
> And the 6th tree: current which fortunately has only one flavor and
> is usually up to date with Linus's releases.
> 
> The only 2 trees that have been extensively test are the 2.4.2 and the RH7.1,
> everything else should used with caution and a willingness to put up with
> potential problems.
> 
> -Russell
> 

From owner-linux-xfs@oss.sgi.com Wed May  2 21:08:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4348wW23521
	for linux-xfs-outgoing; Wed, 2 May 2001 21:08:58 -0700
Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4348vF23518
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 21:08:57 -0700
Message-ID: <20010503040857.94125.qmail@web9807.mail.yahoo.com>
Received: from [200.241.126.254] by web9807.mail.yahoo.com; Wed, 02 May 2001 21:08:57 PDT
Date: Wed, 2 May 2001 21:08:57 -0700 (PDT)
From: Robert Mena <rt_mena@yahoo.com>
Subject: /dev strange : where is my ttySX
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, I've donwloaded and installed kernel(smp),
headers, devfsd and xfprogs.

I've rebooted ok and created/mounted a xfs partition. 

Stangely I could not access Internet since it shows no
/dev/ttyS1 where my pnp modem is located.

Rebooting back to RH7.1 regular kernel gives me back
the access.

Any ideias ?

Thanks.
PS. Please send me a CC of the email

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Wed May  2 21:13:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f434DfS23623
	for linux-xfs-outgoing; Wed, 2 May 2001 21:13:41 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434DeF23620
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 21:13:40 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f434DcK02815;
	Wed, 2 May 2001 23:13:38 -0500 (CDT)
Message-ID: <3AF0DB46.6F793418@sgi.com>
Date: Wed, 02 May 2001 23:15:02 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Pruchanskiy <igor@linuxinside.com>
CC: Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: linux-2.4-xfs-1.0.patch
References: <20010502174113.A21501@linuxinside.com> <3AF0AA07.C4A72E6C@sgi.com> <20010502175326.B21501@linuxinside.com> <3AF0AD79.5712D5D9@sgi.com> <20010502194642.A21682@linuxinside.com> <3AF0DA57.7376774D@thebarn.com> <20010502204851.B21682@linuxinside.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Igor Pruchanskiy wrote:
> 
> What am i expecting from those patches?
> hm.. this is a good question....
> Me, as well, as other users of 2.4.x, expecting XFS-Release-1.0
>                                                     ^^^^^^^

It's not a distribution issue, it's an issue of turn-around when new
kernels come out.  While 2.4.2 is a month old, 2.4.4 is currently what,
4 days old?  Maybe 5?  Kernel internals change, it's not necessarily
trivial to move something like XFS from one release to the next.  It'll
happen, but you have to be a bit patient.

You say you want "Release 1.0," I assume that means you want something
that's feature-rich, tested and stable.  That's XFS on 2.4.2/2.4.3,
that's what's currently supported on this release.

If you want bleeding edge, which is currently 2.4.4, that's available as
well - just do a CVS checkout of the development tree.

You've got tested & stable available, you've got bleeding edge as well. 
I'm really not sure where the problem lies...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 21:24:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f434O2U25013
	for linux-xfs-outgoing; Wed, 2 May 2001 21:24:02 -0700
Received: from europa.cox-internet.com (europa-cox.cox-internet.com [208.180.118.40])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434O1F25008
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 21:24:01 -0700
Received: from cdm-233-165-vict.cox-internet.com ([208.180.233.165])
          by europa.cox-internet.com
          (InterMail vK.4.02.00.10 201-232-116-110 license d1ebd4f8b91132ed01cf0e3e933da025)
          with ESMTP
          id <20010503042200.SHOF21636.europa@cdm-233-165-vict.cox-internet.com>;
          Wed, 2 May 2001 23:22:00 -0500
Subject: Re: xfs-redhat 7.1 installation from hardisk
From: Michael Vanderford <michaelv@cox-internet.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3AF0B913.C9AB7E0F@sgi.com>
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com> 
	<3AF0B913.C9AB7E0F@sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 23:34:15 -0500
Message-Id: <988864461.1154.0.camel@cdm-233-165-vict.cox-internet.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I put all three iso's in the same directory (redhat-xfs,seawolf1
& seawolf2) Then i grabbed the boot.img from sgi and made a
boot disk. The problem i'm seeing is that the boot disk bypasses the
redhat-xfs.iso and loads the seawolf1.iso instead.
Any suggestions.

On 02 May 2001 20:49:07 -0500, Eric Sandeen wrote:
> If it's possible with standard Red Hat (and I think it is...) then it's
> probably possible w/ our version as well - although I have not tested
> it.  Let us know.  :)
> 
> -Eric
> 
> Michael Vanderford wrote:
> > 
> > Sorry if this is a dumb question but is it possible to
> > install redhat 7.1-xfs from iso's downloaded to a second hard drive.
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  2 21:25:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f434PxF25109
	for linux-xfs-outgoing; Wed, 2 May 2001 21:25:59 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434PwF25106
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 21:25:58 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f434Ptd13416;
	Wed, 2 May 2001 23:25:55 -0500 (CDT)
Message-ID: <3AF0DE2B.8EFB0202@sgi.com>
Date: Wed, 02 May 2001 23:27:23 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Mena <rt_mena@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: /dev strange : where is my ttySX
References: <20010503040857.94125.qmail@web9807.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Robert Mena wrote:
> 
> Hi, I've donwloaded and installed kernel(smp),
> headers, devfsd and xfprogs.
> 
> I've rebooted ok and created/mounted a xfs partition.
> 
> Stangely I could not access Internet since it shows no
> /dev/ttyS1 where my pnp modem is located.

Hi Robert -

That's probably devfs.  Do you have /dev/tts/1?

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 21:38:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f434cLj26249
	for linux-xfs-outgoing; Wed, 2 May 2001 21:38:21 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f434cKF26246
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 21:38:20 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f434cKK10359;
	Wed, 2 May 2001 23:38:20 -0500 (CDT)
Message-ID: <3AF0E111.F7D1292F@sgi.com>
Date: Wed, 02 May 2001 23:39:45 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Vanderford <michaelv@cox-internet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs-redhat 7.1 installation from hardisk
References: <988854653.1900.2.camel@cdm-233-165-vict.cox-internet.com> 
		<3AF0B913.C9AB7E0F@sgi.com> <988864461.1154.0.camel@cdm-233-165-vict.cox-internet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Michael Vanderford wrote:
> 
> I put all three iso's in the same directory (redhat-xfs,seawolf1
> & seawolf2) Then i grabbed the boot.img from sgi and made a
> boot disk. The problem i'm seeing is that the boot disk bypasses the
> redhat-xfs.iso and loads the seawolf1.iso instead.
> Any suggestions.

Grab http://lager.dyndns.org/harddrive.py, copy it to an ext2 formatted
floppy, and type "linux updates" at the installer prompt, then insert
your floppy when it asks for it.

It might work, but no guarantees... :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  2 23:34:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436Yfi29814
	for linux-xfs-outgoing; Wed, 2 May 2001 23:34:41 -0700
Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436YaF29806
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:34:36 -0700
Received: from fosi (203-79-83-162.cable.paradise.net.nz [203.79.83.162])
	by deborah.paradise.net.nz (8.11.3/8.11.3) with SMTP id f436YX889151
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 18:34:33 +1200 (NZST)
From: "Steve Wray" <steve.wray@the.net.nz>
To: <linux-xfs@oss.sgi.com>
Subject: compilation failure
Date: Thu, 3 May 2001 18:31:47 +1200
Message-ID: <NBBBKLKHMJHIJLHOGAOJMEHOIOAA.steve.wray@the.net.nz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mandrake 8.0 system,
got the release 1 thru CVS,
configured and tried
make dep clean bzImage modules

make modules chokes and dies with:

make[2]: Nothing to be done for `modules'.
make[2]: Leaving directory
`/home/steve/linux-2.4-xfs-r1.0/linux/fs/vfat'
make -C xfs modules
make[2]: Entering directory
`/home/steve/linux-2.4-xfs-r1.0/linux/fs/xfs'
gcc  -D__KERNEL__ -I/home/steve/linux-2.4-xfs-r1.0/linux/include 
- -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing
- -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6
- -DMODULE -DMODVERSIONS -include
/home/steve/linux-2.4-xfs-r1.0/linux/include/linux/modversions.h
- -Wno-unused  -Wno-parentheses -Wno-uninitialized -I.
- -I/home/steve/linux-2.4-xfs-r1.0/linux/fs -funsigned-char 
- -Wno-unknown-pragmas  -c -o xfs_bmap.o xfs_bmap.c
xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not
give a valid preprocessing token
xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not
give a valid preprocessing token
xfs_bmap.c: In function `xfs_bmap_alloc':
xfs_bmap.c:2721: Unrecognizable insn:
(insn/i 137 3626 3620 (parallel[ 
            (set (reg:SI 0 eax)
                (asm_operands ("") ("=a") 0[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 287))
            (set (reg:SI 1 edx)
                (asm_operands ("") ("=d") 1[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 287))
            (clobber (reg:QI 19 dirflag))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ] ) -1 (nil)
    (nil))
xfs_bmap.c:2721: confused by earlier errors, bailing out
make[2]: *** [xfs_bmap.o] Error 2
make[2]: Leaving directory
`/home/steve/linux-2.4-xfs-r1.0/linux/fs/xfs'
make[1]: *** [_modsubdir_xfs] Error 2
make[1]: Leaving directory `/home/steve/linux-2.4-xfs-r1.0/linux/fs'
make: *** [_mod_fs] Error 2


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOvD7UghKySqSS+rVEQKT9QCg/S8PVnQj0yUOVBlDBd0N3a2DhHcAoLlm
QOrj/+7O+IubzsAuMVX39GJ6
=S+0t
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Wed May  2 23:41:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436f2V30195
	for linux-xfs-outgoing; Wed, 2 May 2001 23:41:02 -0700
Received: from pc.home.local (adsl-63-196-0-92.dsl.snfc21.pacbell.net [63.196.0.92])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436esF30189
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:40:54 -0700
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by pc.home.local (Postfix) with ESMTP id A582B8AE51D
	for <linux-xfs@oss.sgi.com>; Wed,  2 May 2001 23:40:58 -0700 (PDT)
Subject: XFS-1.0 on i815
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
Content-Type: multipart/mixed; boundary="=-s/JpgeixViFvVUomyAmf"
X-Mailer: Evolution/0.10 (Preview Release)
Date: 02 May 2001 23:40:58 -0700
Message-Id: <988872058.1249.3.camel@pc.home.local>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--=-s/JpgeixViFvVUomyAmf
Content-Type: text/plain

While installing XFS-1.0 on my El Cheapo Intel815-based home computer...

It was a custom install, i selected various X, media, games and
development stuff. Right after that, the system was upgraded to Ximian
Gnome-1.4 (and Evolution-0.10 "of course" ;-))
The complete package list is attached.
The /var/log/dmesg file is attached.

Noticeable stuff:

1. During the first install attempt, when the kernel package was
decompressing, something weird happened:
- the HDD started to make scary noises
- the installer was frozen
- lots of messages regarding some problems with hda (was it "lost
interrupt"? - i don't remember) were running like hell on one of the
consoles
After resetting the system and the installer booted again, it complained
about not being able to find any suitable media to install Linux!
At that point, i was sure all my data was going bye-bye... :-/
Fortunately, i know how to deal with cheap and buggy hardware, so i
powered off the system and waited for 5 minutes (yeah, why are you
laughing? =)). After that, everything was fine.
Now, this is strange, because i had similar problems with a RAID array
on another system (one of the disks was going mad), and i'm pretty sure
it happened at the same place: while decompressing the kernel package,
or very close to that.
Hmmm...

2. While the installed system boots up:
- there are two swapon calls, one of them obviously failing
- after the system is booted, on the first console i can see these two
messages:
devfs: devfs_register(): device already registered: "2"
devfs: devfs_register(): device already registered: "a2"

3. While the installed system shuts down:
- i can see these messages:
Unmounting file systems: umount2: Device or resource busy
umount: /dev: device is busy

4. [removed]

5. Red Hat 7.1 does a very nice trick. If you have a CD-Writer in your
system, it appends "hdc=ide-scsi" to kernel boot parameters, so the
writer is automatically seen as a pseudo-SCSI device, and /dev/cdrom
points to /dev/scd0.
Now, i'm not a big fan of getting everything already done, but it would
be nice to have a similar trick in RH-7.1-XFS. Apparently, the XFS
version doesn't do that. Here's my /etc/fstab:
/dev/hda7               /                       xfs     defaults
1 1
LABEL=/boot             /boot                   ext2    defaults
1 2
/dev/fd0                /mnt/floppy             auto    noauto,owner
0 0
none                    /proc                   proc    defaults
0 0
none                    /dev/pts                devpts  gid=5,mode=620
0 0
/dev/hda5               swap                    swap    defaults
0 0
/dev/hda2		/win/winme		vfat	defaults	1 2
/dev/hda6		/win/win2k_d		vfat	defaults	1 2
There's nothing pointing to my CD-Writer (which is master on secondary).
Even worse, there's nothing pointing to my CD-ROM (which is slave on
secondary).

6. While downloading (wget blah) the FreeBSD-4.3 ISO image
(150kbytes/sec sustained, on DSL, with pppoe) on the first console, if i
logged into the second text console (ALT-F2) and tried to run "mcedit
blah", mcedit was frozen, nothing happened, i could not kill it with
CTRL-C. I had to log into the third console and run killall mcedit.
Now after the download is finished, mcedit works again in the text
console.

7. [root@pc /root]# cat /var/log/messages | grep devfsd
May  1 15:32:53 pc devfsd[15]: Error making directory
"/dev-state"^IRead-only file system  <27>May  1 15:32:53 devfsd[15]:
error making tree for: "/dev-state/log" 
May  1 23:03:11 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  1 23:03:11 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  1 23:57:55 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  1 23:57:55 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 00:10:00 pc devfsd[15]: action_compat: error unlinking:
"cdrom0"^INo such file or directory 
May  2 02:19:17 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 02:19:17 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 02:28:12 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 02:28:12 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 02:31:01 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 02:31:01 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 02:40:00 pc devfsd[15]: action_compat: error unlinking:
"cdrom0"^INo such file or directory 
May  2 21:50:00 pc devfsd[15]: action_compat: error unlinking:
"cdrom0"^INo such file or directory 
May  2 22:51:28 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 22:51:28 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 22:55:47 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 22:55:47 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory 
May  2 23:10:00 pc devfsd[15]: action_compat: error unlinking:
"cdrom0"^INo such file or directory 
May  2 23:16:58 pc devfsd[15]: action_compat: error unlinking:
"vcs2"^INo such file or directory 
May  2 23:16:58 pc devfsd[15]: action_compat: error unlinking:
"vcsa2"^INo such file or directory

8. I'm running a handful of services, like Postfix, djbdns... So far,
everything seems to be normal.

Well, that's it. Hope it helps.
Time to burn that FreeBSD image... ;-)

Cheers,

-- 
Florin Andrei

--=-s/JpgeixViFvVUomyAmf
Content-Type: text/plain
Content-Disposition: attachment; filename=package_list
Content-ID: 988869995.1128.0.camel@pc.home.local
Content-Transfer-Encoding: 7bit

bzip2-1.0.1-3
sendmail-cf-8.11.2-14
ppp-2.4.0-2
util-linux-2.10s-12
wu-ftpd-2.6.1-16
diffstat-1.27-5
qt-devel-2.3.0-3
gtk-engines-0.12-ximian.1
GConf-devel-1.0.0-ximian.4
ghostscript-fonts-5.50-3
dip-3.3.7o-22
libstdc++-2.96-81
nmh-1.0.4-8
dev-3.1.0-14
dmapi-0.1.1-0
tksysv-1.3-2
4Suite-0.10.1-1
pciutils-2.1.8-19
htmlview-1.1.0-2
xboard-4.1.0-1
mod_perl-1.24_01-2
w3c-libwww-5.2.8-6
gcc-2.96-81
kdelibs-sound-devel-2.1.1-5
freetype-2.0.1-4
gnet-1.0.4-ximian.2
xmms-1.2.4-ximian.4
glade-0.6.2-ximian.2
gnome-pim-devel-1.4.0-ximian.3
zlib-devel-1.1.3-22
openssh-askpass-gnome-2.9p1-1
gnome-audio-extra-1.0.0-12
eject-2.0.2-7
MAKEDEV-3.1.0-14
LPRng-3.7.4-22
gnupg-1.0.4-11
isdn4k-utils-3.1-39
internet-config-0.40-1
xpaint-2.6.1-1
slang-1.4.2-2
mkbootdisk-1.4.2-1
tetex-1.0.7-15
newt-devel-0.50.22-2
gnome-print-0.25-ximian.6
dia-0.86-ximian.3
gnome-pilot-0.1.57-ximian.2
evolution-0.10-100_helix_200104260701
perl-DBD-Pg-0.95-1
gd-devel-1.8.3-7
libmng-devel-1.0.0-2
ammonite-devel-1.0.0-ximian.1
mailcap-2.1.4-2
fortune-mod-1.0-13
mpg123-0.59r-10
ntsysv-1.2.22-1
playmidi-2.4-12
nss_ldap-149-1
libtiff-3.5.5-10
sndconfig-0.64.8-1
kdemultimedia-2.1.1-1
xpuzzles-5.5.2-4
time-1.7-13
modemtool-1.22-3
bindconf-1.4-1
bison-1.28-5
gnome-objc-devel-1.0.2-11
mod_ssl-2.8.1-5
gnome-vfs-devel-1.0-ximian.2
vorbis-devel-1.0beta4-3
rhn_register-1.3.2-1
libglade-0.16-ximian.1
gqview-0.10.1-ximian.3
xscreensaver-gl-3.32-ximian.6
setup-2.4.7-1
gmp-3.1.1-3
info-4.0-20
logrotate-3.5.4-1
slrn-0.9.6.4-2
traceroute-1.4a5-25
pine-4.33-8
lynx-2.8.4-9
python-1.5.2-30
xinitrc-3.6-1
htdig-3.2.0-0.b3.4
xbill-2.0-13
mod_dav-1.0.2-4
docbook-utils-pdf-0.6-13
glibc-devel-2.2.2-10
ncurses-devel-5.2-8
efax-0.9-8
rep-gtk-0.15-ximian.4
bonobo-1.0.0-ximian.1
gedit-0.9.5-ximian.1
librep-devel-0.13.4-ximian.6
slib-2d1-ximian.3
glibc-2.2.2-10
iputils-20001110-1
ed-0.2-19
psmisc-19-4
syslinux-1.52-1
SysVinit-2.78-15
vixie-cron-3.0.1-62
utempter-0.5.2-4
kdebase-2.1.1-8
xinetd-2.1.8.9pre14-6
ucd-snmp-utils-4.2-12
cvs-1.11-3
openldap-devel-2.0.7-14
lsof-4.51-1
helix-sweetpill-1.0-ximian.2
control-center-1.4.0.1-ximian.5
mozilla-mail-0.8.1-ximian.13
libghttp-devel-1.0.9-ximian.5
guile-1.4-ximian.9
gsm-devel-1.0.10-2
libjpeg-6b-15
findutils-4.1.6-2
psutils-1.17-10
tcl-8.3.1-53
pythonlib-1.28-1
rp-pppoe-2.6-5
extace-1.4.4-2
kdelibs-sound-2.1.1-5
xpilot-4.3.0-2
bind-9.1.0-10
binutils-2.10.91.0.2-3
gnome-objc-1.0.2-11
fping-2.2b1-1
mc-4.5.54-ximian.6
pan-0.9.6-ximian.2
vorbis-1.0beta4-3
mozilla-chatzilla-0.8.1-ximian.13
mozilla-devel-0.8.1-ximian.13
gnome-guile-0.20-ximian.3
openssl-devel-0.9.6-3
libtermcap-2.0.8-26
grep-2.4.2-5
rdate-1.0-7
metamail-2.7-27
ghostscript-5.50-17
whois-1.0.6-1
gq-0.4.0-2
kdeutils-2.1.1-1
inn-2.3.1-2
docbook-dtd41-sgml-1.0-10
dev86-0.15.0-5
libtermcap-devel-2.0.8-26
arpwatch-2.1a10-39
audiofile-0.2.1-ximian.2
oaf-0.6.5-ximian.3
xchat-1.6.4-ximian.1
gal-devel-0.7-ximian.2
mtr-0.42-8
gnome-pilot-devel-0.1.57-ximian.2
awesfx-0.4.3a-7
losetup-2.10r-5
gzip-1.3-12
textutils-2.0.11-7
pam-0.74-22
playmidi-X11-2.4-12
rpm-python-4.0.2-8
lm_sensors-2.5.5-3
sysstat-3.3.5-3
ucd-snmp-4.2-12
ctags-4.0.3-1
rpm-devel-4.0.2-8
kdetoys-2.1.1-2
libunicode-0.4.gnome-ximian.1
gnome-applets-1.4.0.1-ximian.5
xsane-gimp-0.75-ximian.2
gnome-print-devel-0.25-ximian.6
nautilus-trilobite-1.0.2-ximian.2
cdparanoia-alpha9.7-7
mingetty-0.9.4-16
make-3.79.1-5
rsh-0.17-2.5
kernel-headers-2.4.2-SGI_XFS_1.0
gpm-1.19.3-16
smpeg-0.4.2-2
iptables-1.2.1a-1
qt-2.3.0-3
postgresql-devel-7.0.3-8
tetex-fonts-1.0.7-15
strace-4.2.20010119-3
stunnel-3.13-3
libgal3-0.4.1-3
xmorph-2000.04.28-9
libgnomeprint11-0.25-ximian.6
abisuite-0.7.13-ximian.6
gnome-pim-conduits-1.4.0-ximian.3
freetype2-devel-2.0.1-ximian.1
freetype-devel-2.0.1-4
netscape-common-4.77-1
compat-libstdc++-6.2-2.9.0.14
bash-2.04-21
minicom-1.83.1-5
xfsprogs-1.2.0-0
sed-3.02-9
exmh-2.2-9
urlview-0.9-2
chkfontpath-1.9.5-1
VFlib2-2.25.1-12
zip-2.3-8
docbook-dtd40-sgml-1.0-11
db3-utils-3.1.17-7
gcc-c++-2.96-81
libghttp-1.0.9-ximian.5
red-carpet-1.0-ximian.10
gftp-2.0.7b-ximian.5
libgtop-devel-1.0.12-ximian.3
gnome-games-1.4.0.1-ximian.10
cleanfeed-0.95.7b-10
patch-2.5.4-9
shapecfg-2.2.12-5
desktop-backgrounds-1.1-4
netpbm-9.9-5
db2-2.4.14-5
setserial-2.17-2
sh-utils-2.0-13
XFree86-twm-4.0.3-5
autorun-2.65-1
gd-1.8.3-7
rcs-5.7-14
xpdf-0.92-3
imlib-1.9.10-ximian.2
acl-1.0.1-0
timetool-2.8-1
pygnome-libglade-0.6.6-7
ximian-menus-1.0-ximian.3
trojka-1.1-17
jadetex-3.3-1
gphoto-0.4.3-ximian.4
libunicode-devel-0.4.gnome-ximian.1
gnucash-devel-1.4.11-ximian.5
glibc-common-2.2.2-10
dosfstools-2.2-8
arts-2.1.1-5
openssl-0.9.6-3
nscd-2.2.2-10
quota-3.01-SGI_5
krb5-libs-1.2.2-4
Xaw3d-1.5-9
ipchains-1.3.10-7
mkxauth-1.7-15
unix2dos-2.2-11
postgresql-7.0.3-8
sgml-tools-1.0.9-9
flex-2.5.4a-13
memprof-0.4.1-3
qt-designer-2.3.0-3
gnome-audio-1.4.0-ximian.1
xmms-gnome-1.2.4-ximian.4
ghex-1.2-ximian.5
openssh-clients-2.9p1-1
xmms-devel-1.2.4-ximian.4
gnome-users-guide-1.2-3
file-3.33-1
modutils-2.4.2-5
perl-5.6.0-12
newt-0.50.22-2
mouseconfig-4.21-1
openldap-2.0.7-14
pump-0.8.11-1
libmng-1.0.0-2
kdeadmin-2.1.1-3
xpat2-1.06-5
tux-2.0.26-1
automake-1.4-8
nmap-2.54BETA7-3
mcserv-4.5.54-ximian.6
gnomeicu-0.96.1-ximian.2
mozilla-xmlterm-0.8.1-ximian.13
python-xmlrpc-1.4-1
plugger-3.2-9
sane-devel-1.0.3-ximian.2
gnome-guile-devel-0.20-ximian.3
redhat-logos-1.1.2-3
gdbm-1.8.0-5
ncurses-5.2-8
pnm2ppa-1.04-1
setuptool-1.7-2
tmpwatch-2.7.1-1
openldap-clients-2.0.7-14
ImageMagick-5.2.7-2
XFree86-tools-4.0.3-5
pygtk-libglade-0.6.6-7
yp-tools-2.4-7
Maelstrom-3.0.1-11
tetex-latex-1.0.7-15
Xaw3d-devel-1.5-9
php-pgsql-4.0.4pl1-9
libgtop-1.0.12-ximian.3
libogg-1.0beta4-ximian.3
expat-1.95.1-1
sawfish-themes-0.2-ximian.1
gtkhtml-devel-0.9.2-ximian.2
rhn_register-gnome-1.3.2-1
filesystem-2.0.7-1
cpio-2.4.2-20
procmail-3.14-6
hdparm-3.9-6
sox-12.17.1-2
umb-scheme-3.2-18
rpm-4.0.2-8
kpppload-1.04-23
rwall-server-0.17-9
tcpdump-3.4-39
cproto-4.6-7
krb5-devel-1.2.2-4
kdesupport-devel-2.1-3
freetype2-2.0.1-ximian.1
gnome-pim-1.4.0-ximian.3
bonobo-devel-1.0.0-ximian.1
xmms-gl-1.2.4-ximian.4
openssh-2.9p1-1
statserial-1.1-20
ksymoops-2.4.0-3
fileutils-4.0.36-4
pspell-0.11.2-2
talk-0.17-9
vim-common-6.0-0.27
wvdial-1.41-12
netpbm-progs-9.9-5
pygnome-1.0.53-7
nfs-utils-0.3.1-5
kdelibs-2.1.1-5
xloadimage-4.1-16
xjewel-1.6-15
php-ldap-4.0.4pl1-9
autoconf-2.13-10
gmp-devel-3.1.1-3
rsync-2.4.6-2
sawfish-0.38-ximian.4
mozilla-psm-0.8.1-ximian.13
gtk+-devel-1.2.10-ximian.8
gnumeric-0.64-ximian.3
glib-1.2.10-ximian.2
kudzu-devel-0.98.10-1
gawk-3.0.6-1
pwdb-0.61.1-1
tcp_wrappers-7.6-18
wget-1.6-2
control-panel-3.18-4
XFree86-xfs-4.0.3-5
xtt-fonts-0.19990222-9
unzip-5.41-3
ypserv-1.3.11-13
docbook-dtd31-sgml-1.0-10
db3-devel-3.1.17-7
libstdc++-devel-2.96-81
pmake-1.45-1
stat-2.2-2
gtk+-1.2.10-ximian.8
scrollkeeper-0.1.4-ximian.2
gtk-themes-0.1-ximian.2
imlib-devel-1.9.10-ximian.2
gnome-games-devel-1.4.0.1-ximian.10
pciutils-devel-2.1.8-19
ash-0.3.7-1
readline-4.1-9
elm-2.5.3-11
libtool-libs-1.3.5-8
libungif-4.1.0-7
gnorpm-0.96-1
magicdev-0.3.5-3
koffice-2.0.1-2
rusers-server-0.17-10
words-2-16
Mesa-devel-3.4-13
bc-1.06-2
esound-0.2.22-ximian.3
GConf-1.0.0-ximian.4
ggv-1.0-ximian.2
audiofile-devel-0.2.1-ximian.2
mtr-gtk-0.42-8
rdist-6.1.5-14
cdecl-2.5-17
indent-2.2.6-1
libogg-devel-1.0beta4-ximian.3
bdflush-1.5-16
less-358-16
rmt-0.4b21-3
mount-2.10r-5
lrzsz-0.12.20-7
authconfig-4.1.6-1
rxvt-2.7.5-15
aumix-2.7-2
Mesa-3.4-13
balsa-1.1.1-3
samba-client-2.0.7-36
perl-DBI-1.14-10
docbook-utils-0.6-13
expat-devel-1.95.1-1
ltrace-0.3.10-5
netpbm-devel-9.9-5
ical-2.2-21
rep-gtk-gnome-0.15-ximian.4
gnome-vfs-1.0-ximian.2
libnspr4-4.1-ximian.3
glib-devel-1.2.10-ximian.2
gtk-engines-thinice-1.0.4-ximian.1
cdrecord-1.9-6
mkisofs-1.9-6
man-1.5h1-20
rusers-0.17-10
devfsd-1.3.11-sgi
kudzu-0.98.10-1
switchdesk-gnome-3.9.5-1
tkinter-1.5.2-30
xsri-1.0-8
switchdesk-kde-3.9.5-1
telnet-server-0.17-10
docbook-dtd30-sgml-1.0-10
db2-devel-2.4.14-5
libpng-devel-1.0.9-1
texinfo-4.0-20
samba-2.0.7-36
libgal6-0.7-ximian.2
gimp-1.2.1-ximian.5
gtop-1.0.13-ximian.1
gnet-devel-1.0.4-ximian.2
netscape-communicator-4.77-1
cracklib-2.7-8
ncftp-3.0.2-1
console-tools-19990829-34
xfsprogs-devel-1.2.0-0
expect-5.31-53
XFree86-75dpi-fonts-4.0.3-5
passwd-0.64.1-4
ypbind-1.7-6
gnuchess-4.0.pl80-6
apacheconf-0.7-2
tetex-dvips-1.0.7-15
XFree86-devel-4.0.3-5
gdm-2.2.0-ximian.13
sawfish-themer-0.38-ximian.4
libvorbis-1.0beta4-ximian.4
oaf-devel-0.6.5-ximian.3
up2date-2.5.4-1
gal-0.4.1-3
db3-3.1.17-7
hotplug-2001_02_14-15
nkf-1.92-4
shadow-utils-20000826-4
a2ps-4.13b-13
tix-4.1.0.6-53
apmd-3.0final-29
XFree86-4.0.3-5
attr-1.0.1-0
samba-common-2.0.7-36
cpp-2.96-81
perl-SGMLSpm-1.03ii-4
libungif-devel-4.1.0-7
readline-devel-4.1-9
kdegames-2.1.1-1
ximian-utils-0.2-ximian.1
sane-1.0.3-ximian.2
gnome-libs-devel-1.2.13-ximian.8
nautilus-1.0.2-ximian.2
imlib-cfgeditor-1.9.10-ximian.2
e2fsprogs-1.19-4
groff-1.16.1-7
bind-utils-9.1.0-10
sharutils-4.2.1-7
lilo-21.4.4-13
krbafs-1.0.5-1
pygtk-0.6.6-7
portmap-4.0-35
xisdnload-1.38-39
kdesupport-2.1-3
php-imap-4.0.4pl1-9
gcc-objc-2.96-81
zlib-1.1.3-22
xgammon-0.98-19
slang-devel-1.4.2-2
kdoc-2.1.1-1
gnome-libs-1.2.13-ximian.8
ximian-wallpapers-0.2-ximian.1
pilot-link-0.9.5pre5-ximian.2
libglade-devel-0.16-ximian.1
nautilus-devel-1.0.2-ximian.2
indexhtml-7.1-2
finger-0.17-7
mpage-2.5.1-5
groff-perl-1.16.1-7
kbdconfig-1.9.12-1
switchdesk-3.9.5-1
autofs-3.1.7-14
libpng-1.0.9-1
locale_config-0.2-4
netcfg-2.36-3
XFree86-100dpi-fonts-4.0.3-5
printconf-gui-0.2.12-1
apache-1.3.19-5
tetex-dvilj-1.0.7-15
gdbm-devel-1.8.0-5
nmap-frontend-2.54BETA7-3
monkeytalk-1.0-ximian.4
gnapster-1.4.2-ximian.3
gnome-core-devel-1.4.0.2-ximian.8
pilot-link-devel-0.9.5pre5-ximian.2
postfix-20010228_pl02release-2
redhat-release-7.1-1
cdp-0.33-20
popt-1.6.2-8
crontabs-1.9-2
pam_krb5-1.31-1
usermode-1.42-1
kdenetwork-ppp-2.1.1-1
rsh-server-0.17-2.5
gpm-devel-1.19.3-16
dump-0.4b21-3
librep-0.13.4-ximian.6
mt-st-0.5b-10
bzip2-devel-1.0.1-3
ammonite-1.0.0-ximian.1
gnome-utils-1.4.0-ximian.4
ncompress-4.2.4-21
esound-devel-0.2.22-ximian.3
libvorbis-devel-1.0beta4-ximian.4
basesystem-7.0-2
inews-2.3.1-2
diffutils-2.7-21
procps-2.0.7-8
sysklogd-1.4-7
alchemist-0.16-3
pidentd-3.0.12-4
XFree86-xdm-4.0.3-5
firewall-config-0.95-2
xboing-2.4-12
php-4.0.4pl1-9
tetex-xdvi-1.0.7-15
gcc-g77-2.96-81
kdelibs-devel-2.1.1-5
gmc-4.5.54-ximian.6
grip-2.95-ximian.3
xmms-mikmod-1.2.4-ximian.4
gimp-devel-1.2.1-ximian.5
openssh-askpass-2.9p1-1
termcap-11.0.1-8
at-3.1.8-16
aspell-0.32.6-2
tar-1.13.19-4
vim-minimal-6.0-0.27
XFree86-libs-4.0.3-5
timidity++-2.10.3-0.a2.3
xcdroast-0.98a8-2
rp3-1.1.10-1
kdepim-2.1.1-1
sgml-common-0.5-5
kdevelop-1.4.1-2
talk-server-0.17-9
db1-devel-1.85-5
grdb-0.2.4-ximian.1
gaim-0.11.0pre9-ximian.3
glimmer-1.0.1-ximian.3
libnspr4-devel-4.1-ximian.3
openssh-server-2.9p1-1
man-pages-1.35-5
libole2-0.1.7-2
gettext-0.10.35-31
raidtools-0.90-20
tcsh-6.10-5
which-2.12-1
ee-0.3.12-3
timeconfig-3.2-1
kdenetwork-2.1.1-1
caching-nameserver-7.1-3
python-devel-1.5.2-30
sudo-1.6.3p6-1
gdk-pixbuf-0.10.1-ximian.3
ximian-faq-1.0-ximian.2
xscreensaver-3.29-3
byacc-1.9-18
xmms-esd-1.2.4-ximian.4
libxml-devel-1.8.11-ximian.1
guile-devel-1.4-ximian.9
pump-devel-0.8.11-1
dhcpcd-1.3.18pl8-10
ftp-0.17-7
telnet-0.17-10
multimedia-2.1-21
initscripts-5.83-1
urw-fonts-2.0-12
cracklib-dicts-2.7-8
gv-3.5.8-11
mtools-3.9.7-4
anonftp-4.0-4
docbook-style-dsssl-1.59-10
e2fsprogs-devel-1.19-4
libtool-1.3.5-8
rpm-build-4.0.2-8
kdegraphics-2.1.1-1
libxml-1.8.11-ximian.1
gnome-core-1.4.0.2-ximian.8
xsane-0.75-ximian.2
control-center-devel-1.4.0.1-ximian.5
nautilus-mozilla-1.0.2-ximian.2
cdda2wav-1.9-6
mailx-8.1.1-20
m4-1.4.1-4
mkinitrd-3.0.10-1
cyrus-sasl-1.5.24-17
SDL-1.1.7-3
anacron-2.3-16
rootfiles-7.0-4
finger-server-0.17-7
dialog-0.9a-4
cyrus-sasl-devel-1.5.24-17
libjpeg-devel-6b-15
njamd-0.8.0-3
iproute-2.2.4-10
bug-buddy-2.0.1-ximian.1
mozilla-0.8.1-ximian.13
ORBit-devel-0.5.7-ximian.3
rep-gtk-libglade-0.15-ximian.4
ximian-doorman-1.0-ximian.5
chkconfig-1.2.22-1
mikmod-3.1.6-10
mktemp-1.5-8
rwho-0.17-10
kernel-2.4.2-SGI_XFS_1.0
tk-8.3.1-53
lokkit-0.43-6
Xconfigurator-4.9.27-1
links-0.95-2
printconf-0.2.12-1
freeciv-1.11.4-5
postgresql-server-7.0.3-8
tetex-afm-1.0.7-15
gdb-5.0rh-5
pam-devel-0.74-22
screen-3.9.8-3
ORBit-0.5.7-ximian.3
gtkhtml-0.9.2-ximian.2
eog-0.6-ximian.4
gdk-pixbuf-devel-0.10.1-ximian.3
gnucash-1.4.11-ximian.5
db1-1.85-5
net-tools-1.57-6
xfsdump-1.0.5-0
tclx-8.2.0-53
dos2unix-3.1-6
openjade-1.3-13
libtiff-devel-3.5.5-10
gnome-user-docs-1.4.1-ximian.2
gnome-media-1.2.1-ximian.5
up2date-gnome-2.5.4-1

--=-s/JpgeixViFvVUomyAmf
Content-Type: text/plain
Content-Disposition: attachment; filename=dmesg
Content-ID: 988870083.1128.1.camel@pc.home.local
Content-Transfer-Encoding: 7bit

Linux version 2.4.2-SGI_XFS_1.0 (root@exclaim) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Fri Apr 27 19:30:49 CDT 2001
BIOS-provided physical RAM map:
 BIOS-e820: 000000000009fc00 @ 0000000000000000 (usable)
 BIOS-e820: 0000000000000400 @ 000000000009fc00 (reserved)
 BIOS-e820: 0000000000020000 @ 00000000000e0000 (reserved)
 BIOS-e820: 0000000007dc0000 @ 0000000000100000 (usable)
 BIOS-e820: 0000000000018000 @ 0000000007ee0000 (ACPI data)
 BIOS-e820: 0000000000008000 @ 0000000007ef8000 (ACPI NVS)
 BIOS-e820: 0000000000020000 @ 0000000007ec0000 (ACPI data)
 BIOS-e820: 0000000000080000 @ 00000000ffb80000 (reserved)
 BIOS-e820: 0000000000100000 @ 00000000fff00000 (reserved)
On node 0 totalpages: 32448
zone(0): 4096 pages.
zone DMA has max 32 cached pages.
zone(1): 28352 pages.
zone Normal has max 221 cached pages.
zone(2): 0 pages.
zone HighMem has max 1 cached pages.
Kernel command line: BOOT_IMAGE=linux ro root=307 BOOT_FILE=/boot/vmlinuz-2.4.2-SGI_XFS_1.0 hdc=ide-scsi
ide_setup: hdc=ide-scsi
Initializing CPU#0
Detected 598.063 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1192.75 BogoMIPS
Memory: 124652k/129792k available (1924k kernel code, 4752k reserved, 96k data, 220k init, 0k highmem)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
VFS: Diskquotas version dquot_6.5.0 initialized
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU: Common caps: 0383f9ff 00000000 00000000 00000000
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfda95, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX [8086/2440] at 00:1f.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x0b (Driver version 1.14)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
block: queued sectors max/low 82658kB/27552kB, 256 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev f9
PIIX4: chipset revision 1
PIIX4: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:DMA
hda: QUANTUM FIREBALLP LM20.5, ATA DISK drive
hdc: CD-W58E, ATAPI CD/DVD-ROM drive
hdd: TOSHIBA CD-ROM XM-6702B, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 40132503 sectors (20548 MB) w/1900KiB Cache, CHS=2498/255/63, UDMA(66)
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md.c: sizeof(mdp_super_t) = 4096
autodetecting RAID arrays
autorun ...
... autorun DONE.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
devfs: v0.102 (20000622) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x0
Start mounting filesystem: ide0(3,7)
Ending clean XFS mount for filesystem: ide0(3,7)
VFS: Mounted root (xfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 220k freed
Adding Swap: 530104k swap-space (priority -1)
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-uhci.c: $Revision: 1.251 $ time 19:48:52 Apr 27 2001
usb-uhci.c: High bandwidth mode enabled
PCI: Found IRQ 11 for device 00:1f.2
PCI: Setting latency timer of device 00:1f.2 to 64
usb-uhci.c: USB UHCI at I/O 0xef40, IRQ 11
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 10 for device 00:1f.4
PCI: Setting latency timer of device 00:1f.4 to 64
usb-uhci.c: USB UHCI at I/O 0xef80, IRQ 10
usb-uhci.c: Detected 2 ports
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
SCSI subsystem driver Revision: 1.00
hdd: ATAPI 48X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
i2c-core.o: i2c core module
i2c-algo-bit.o: i2c bit algorithm module
Linux video capture interface: v1.00
bttv: driver version 0.7.57 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
i2c-core.o: i2c core module
i2c-algo-bit.o: i2c bit algorithm module
Linux video capture interface: v1.00
bttv: driver version 0.7.57 loaded
bttv: using 2 buffers with 2080k (4160k total) for capture
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
  Vendor: TEAC      Model: CD-W58E           Rev: 1.0A
  Type:   CD-ROM                             ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
sr0: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray

--=-s/JpgeixViFvVUomyAmf--


From owner-linux-xfs@oss.sgi.com Wed May  2 23:49:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436nts30841
	for linux-xfs-outgoing; Wed, 2 May 2001 23:49:55 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436nsF30837
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:49:54 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA05314
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 00:00:36 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21151; Thu, 3 May 2001 16:48:36 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA53172;
	Thu, 3 May 2001 16:48:34 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105031648.ZM53240@wobbly.melbourne.sgi.com>
Date: Thu, 3 May 2001 16:48:33 -0500
In-Reply-To: "Steve Wray" <steve.wray@the.net.nz>
        "compilation failure" (May  3,  6:31pm)
References: <NBBBKLKHMJHIJLHOGAOJMEHOIOAA.steve.wray@the.net.nz>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Steve Wray" <steve.wray@the.net.nz>, <linux-xfs@oss.sgi.com>
Subject: Re: compilation failure
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

Try compiling with gcc 2.91.66 (or get either the kgcc
or egcs-compat rpm, both of which are 2.91.66 I think).
If you want to stick with your current compiler, you'll
need to use the development cvs tree which has Steve's
recent-compiler-versions fixes in it).

http://linux-xfs.sgi.com/projects/xfs/faq.html ...
"Q: Are there any known issues about gcc 2.95 for compiling
the XFS kernel tree?"

cheers.


On May 3,  6:31pm, Steve Wray wrote:
> Subject: compilation failure
>  
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mandrake 8.0 system,
> got the release 1 thru CVS,
> configured and tried
> make dep clean bzImage modules
> 
> make modules chokes and dies with:
> 
> make[2]: Nothing to be done for `modules'.
> make[2]: Leaving directory
> `/home/steve/linux-2.4-xfs-r1.0/linux/fs/vfat'
> make -C xfs modules
> make[2]: Entering directory
> `/home/steve/linux-2.4-xfs-r1.0/linux/fs/xfs'
> gcc  -D__KERNEL__ -I/home/steve/linux-2.4-xfs-r1.0/linux/include 
> - -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing
> - -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6
> - -DMODULE -DMODVERSIONS -include
> /home/steve/linux-2.4-xfs-r1.0/linux/include/linux/modversions.h
> - -Wno-unused  -Wno-parentheses -Wno-uninitialized -I.
> - -I/home/steve/linux-2.4-xfs-r1.0/linux/fs -funsigned-char 
> - -Wno-unknown-pragmas  -c -o xfs_bmap.o xfs_bmap.c
> xfs_bmap.c:543:9: warning: pasting "." and "xs_add_exlist" does not
> give a valid preprocessing token
> xfs_bmap.c:2830:9: warning: pasting "." and "xs_del_exlist" does not
> give a valid preprocessing token
> xfs_bmap.c: In function `xfs_bmap_alloc':
> xfs_bmap.c:2721: Unrecognizable insn:
> (insn/i 137 3626 3620 (parallel[ 
>             (set (reg:SI 0 eax)
>                 (asm_operands ("") ("=a") 0[ 
>                         (reg:DI 1 edx)
>                     ] 
>                     [ 
>                         (asm_input:DI ("A"))
>                     ]  ("linux/xfs_linux.h") 287))
>             (set (reg:SI 1 edx)
>                 (asm_operands ("") ("=d") 1[ 
>                         (reg:DI 1 edx)
>                     ] 
>                     [ 
>                         (asm_input:DI ("A"))
>                     ]  ("linux/xfs_linux.h") 287))
>             (clobber (reg:QI 19 dirflag))
>             (clobber (reg:QI 18 fpsr))
>             (clobber (reg:QI 17 flags))
>         ] ) -1 (nil)
>     (nil))
> xfs_bmap.c:2721: confused by earlier errors, bailing out
> make[2]: *** [xfs_bmap.o] Error 2
> make[2]: Leaving directory
> `/home/steve/linux-2.4-xfs-r1.0/linux/fs/xfs'
> make[1]: *** [_modsubdir_xfs] Error 2
> make[1]: Leaving directory `/home/steve/linux-2.4-xfs-r1.0/linux/fs'
> make: *** [_mod_fs] Error 2
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
> 
> iQA/AwUBOvD7UghKySqSS+rVEQKT9QCg/S8PVnQj0yUOVBlDBd0N3a2DhHcAoLlm
> QOrj/+7O+IubzsAuMVX39GJ6
> =S+0t
> -----END PGP SIGNATURE-----
>-- End of excerpt from Steve Wray



-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May  2 23:50:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436o7a30864
	for linux-xfs-outgoing; Wed, 2 May 2001 23:50:07 -0700
Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436o3F30859
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:50:03 -0700
Received: by bobas.nowytarg.top.pl with BSMTP id <S188527AbRECGta>;
	Thu, 3 May 2001 08:49:30 +0200
Received: by witch.underley.eu.org id <S5281240AbRECGsE>;
	Thu, 3 May 2001 08:48:04 +0200
Date:   Thu, 3 May 2001 08:48:03 +0200
From: Daniel Podlejski <underley@underley.eu.org>
To: linux-xfs@oss.sgi.com
Subject: missing bfd.h ?
Message-ID: <20010503084803.A10696@witch.underley.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9  66 AD F6 EA C9 17 CD 82
X-GPG-Fingerprint: 299F 1820 582B 283A 5F50  37D9 AA0B 6E10 03D4 EA5D
X-Homepage: http://www.underley.eu.org/
X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, durning compile linux kernel with kdb and xfs I got:

In file included from /arc/src/linux/include/linux/kdbprivate.h:26,
                 from kdb_bt.c:37:
/arc/src/linux/include/linux/dis-asm.h:43: bfd.h: No such file or directory
In file included from kdb_bt.c:37:
/arc/src/linux/include/linux/kdbprivate.h:29: bfd.h: No such file or directory
In file included from /arc/src/linux/include/linux/kdbprivate.h:26,
                 from kdb_bt.c:37:
/arc/src/linux/include/linux/dis-asm.h:77: field `flavour' has incomplete type
/arc/src/linux/include/linux/dis-asm.h:79: field `arch' has incomplete type
/arc/src/linux/include/linux/dis-asm.h:83: field `endian' has incomplete type
/arc/src/linux/include/linux/dis-asm.h:90: parse error before `asymbol'
/arc/src/linux/include/linux/dis-asm.h:90: warning: no semicolon at end of struct or union
/arc/src/linux/include/linux/dis-asm.h:107: parse error before `memaddr'
/arc/src/linux/include/linux/dis-asm.h:108: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:115: parse error before `bfd_vma'
/arc/src/linux/include/linux/dis-asm.h:115: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:119: parse error before `addr'
/arc/src/linux/include/linux/dis-asm.h:119: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:129: parse error before `addr'
/arc/src/linux/include/linux/dis-asm.h:129: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:132: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:132: warning: type defaults to `int' in declaration of `buffer'
/arc/src/linux/include/linux/dis-asm.h:132: warning: data definition has no type or storage class
/arc/src/linux/include/linux/dis-asm.h:133: parse error before `buffer_vma'
/arc/src/linux/include/linux/dis-asm.h:133: warning: type defaults to `int' in declaration of `buffer_vma'
/arc/src/linux/include/linux/dis-asm.h:133: warning: data definition has no type or storage class
/arc/src/linux/include/linux/dis-asm.h:167: parse error before `target'
/arc/src/linux/include/linux/dis-asm.h:167: warning: type defaults to `int' in declaration of `target'
/arc/src/linux/include/linux/dis-asm.h:167: warning: data definition has no type or storage class
/arc/src/linux/include/linux/dis-asm.h:169: parse error before `target2'
/arc/src/linux/include/linux/dis-asm.h:169: warning: type defaults to `int' in declaration of `target2'
/arc/src/linux/include/linux/dis-asm.h:169: warning: data definition has no type or storage class
/arc/src/linux/include/linux/dis-asm.h:174: parse error before `}'
/arc/src/linux/include/linux/dis-asm.h:174: warning: type defaults to `int' in declaration of `disassemble_info'
/arc/src/linux/include/linux/dis-asm.h:174: warning: data definition has no type or storage class
/arc/src/linux/include/linux/dis-asm.h:180: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:180: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:182: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:182: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:183: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:183: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:184: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:184: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:185: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:185: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:186: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:186: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:187: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:187: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:188: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:188: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:189: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:189: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:190: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:190: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:191: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:191: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:192: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:192: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:193: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:193: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:194: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:194: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:195: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:195: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:196: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:196: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:197: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:197: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:199: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:199: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:200: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:200: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:201: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:201: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:202: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:202: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:203: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:203: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:204: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:204: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:205: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:205: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:206: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:206: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:207: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:207: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:208: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:208: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:209: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:209: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:210: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:210: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:211: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:211: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:212: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:212: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:213: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:213: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:214: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:214: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:215: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:215: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:216: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:216: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:217: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:217: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:218: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:218: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:219: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:219: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:220: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:220: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:221: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:221: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:222: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:222: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:223: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:223: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:224: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:224: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:225: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:225: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:226: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:226: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:227: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:227: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:228: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:228: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:229: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:229: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:238: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:238: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:250: parse error before `*'
/arc/src/linux/include/linux/dis-asm.h:250: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:254: parse error before `bfd_vma'
/arc/src/linux/include/linux/dis-asm.h:254: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:261: parse error before `struct'
/arc/src/linux/include/linux/dis-asm.h:261: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/dis-asm.h:265: parse error before `struct'
/arc/src/linux/include/linux/dis-asm.h:265: warning: function declaration isn't a prototype
In file included from kdb_bt.c:37:
/arc/src/linux/include/linux/kdbprivate.h:88: parse error before `bfd_vma'
/arc/src/linux/include/linux/kdbprivate.h:88: warning: no semicolon at end of struct or union
/arc/src/linux/include/linux/kdbprivate.h:91: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:93: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:94: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:96: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:97: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:98: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:99: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:100: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:101: parse error before `:'
/arc/src/linux/include/linux/kdbprivate.h:107: parse error before `}'
/arc/src/linux/include/linux/kdbprivate.h:107: warning: type defaults to `int' in declaration of `kdb_bp_t'
/arc/src/linux/include/linux/kdbprivate.h:107: warning: data definition has no type or storage class
/arc/src/linux/include/linux/kdbprivate.h:112: parse error before `kdb_breakpoints'
/arc/src/linux/include/linux/kdbprivate.h:112: warning: type defaults to `int' in declaration of `kdb_breakpoints'
/arc/src/linux/include/linux/kdbprivate.h:112: warning: data definition has no type or storage class
/arc/src/linux/include/linux/kdbprivate.h:119: parse error before `*'
/arc/src/linux/include/linux/kdbprivate.h:119: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:123: parse error before `kdb_bp_t'
/arc/src/linux/include/linux/kdbprivate.h:123: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:239: parse error before `*'
/arc/src/linux/include/linux/kdbprivate.h:239: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:240: parse error before `*'
/arc/src/linux/include/linux/kdbprivate.h:240: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:254: parse error before `kdb_bp_t'
/arc/src/linux/include/linux/kdbprivate.h:254: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:255: parse error before `*'
/arc/src/linux/include/linux/kdbprivate.h:255: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:288: parse error before `kdb_di'
/arc/src/linux/include/linux/kdbprivate.h:288: warning: type defaults to `int' in declaration of `kdb_di'
/arc/src/linux/include/linux/kdbprivate.h:288: warning: data definition has no type or storage class
/arc/src/linux/include/linux/kdbprivate.h:293: parse error before `disassemble_info'
/arc/src/linux/include/linux/kdbprivate.h:293: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:294: parse error before `disassemble_info'
/arc/src/linux/include/linux/kdbprivate.h:294: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:295: parse error before `disassemble_info'
/arc/src/linux/include/linux/kdbprivate.h:295: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:296: parse error before `*'
/arc/src/linux/include/linux/kdbprivate.h:296: warning: function declaration isn't a prototype
/arc/src/linux/include/linux/kdbprivate.h:112: warning: array `kdb_breakpoints' assumed to have one element
/arc/src/linux/include/linux/dis-asm.h:148: storage size of `display_endian' isn't known
make[3]: *** [kdb_bt.o] Error 1
make[2]: *** [first_rule] Error 2
make[1]: *** [_dir_kdb] Error 2
make: *** [stamp-build] Error 2

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... Some dance to remember
   Some dance to forget ...

From owner-linux-xfs@oss.sgi.com Wed May  2 23:55:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436tp731265
	for linux-xfs-outgoing; Wed, 2 May 2001 23:55:51 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436tmF31262
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:55:48 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id IAA715642
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:55:42 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21179; Thu, 3 May 2001 16:54:21 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA46458;
	Thu, 3 May 2001 16:54:20 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105031654.ZM53002@wobbly.melbourne.sgi.com>
Date: Thu, 3 May 2001 16:54:19 -0500
In-Reply-To: Daniel Podlejski <underley@underley.eu.org>
        "missing bfd.h ?" (May  3,  8:48am)
References: <20010503084803.A10696@witch.underley.eu.org>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Daniel Podlejski <underley@underley.eu.org.com>, linux-xfs@oss.sgi.com
Subject: Re: missing bfd.h ?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 3,  8:48am, Daniel Podlejski wrote:
> Subject: missing bfd.h ?
> Hi, durning compile linux kernel with kdb and xfs I got:
> 
> In file included from /arc/src/linux/include/linux/kdbprivate.h:26,
>                  from kdb_bt.c:37:
> /arc/src/linux/include/linux/dis-asm.h:43: bfd.h: No such file or directory
> ...

using Debian?  you need to install the "binutils-dev" package.

or alternatively the "binutils" package, on an rpm-based system.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May  2 23:59:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f436xm331458
	for linux-xfs-outgoing; Wed, 2 May 2001 23:59:48 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f436xkF31453
	for <linux-xfs@oss.sgi.com>; Wed, 2 May 2001 23:59:47 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 14209CE62; Thu,  3 May 2001 08:57:54 +0100 (BST)
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
	<m3bspbwotj.fsf@giants.mandrakesoft.com>
	<3AF0A70D.C5CE4733@thebarn.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 03 May 2001 08:57:54 +0100
In-Reply-To: <3AF0A70D.C5CE4733@thebarn.com> (Russell Cattelan's message of "Wed, 02 May 2001 20:32:13 -0400")
Message-ID: <m37kzyrhj1.fsf@giants.mandrakesoft.com>
Lines: 37
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

> Yes please.

Ok they are ready :

ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-devel/contrib/RPMS/

it's :

acl-1.0.1-1mdk.i586.rpm
acl-devel-1.0.1-1mdk.i586.rpm
attr-1.0.1-1mdk.i586.rpm
attr-devel-1.0.1-1mdk.i586.rpm
xfsprogs-1.2.0-1mdk.i586.rpm
xfsprogs-devel-1.2.0-1mdk.i586.rpm
dmapi-0.1.1-1mdk.i586.rpm
dmapi-devel-0.1.1-1mdk.i586.rpm
xfsdump-1.0.5-1mdk.i586.rpm

and :

kernel-xfs-2.4.4-1mdk.i586.rpm

> I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> yet but it does compile.
> Anybody want help finish it.?

Could you send me the patch, i had a lot of conflict and i did the
kernel-xfs on a vanilla 2.4.4 generated patch from cvs.

> If fact I would to encourage some savvy installer programmer to add
> XFS support to the mandrake installer. I've looked at the code and
> see reiserfs is already in there shouldn't be to much work to add
> xfs.

I already begin it, it should be fairly simple...

From owner-linux-xfs@oss.sgi.com Thu May  3 00:26:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f437QRf32358
	for linux-xfs-outgoing; Thu, 3 May 2001 00:26:27 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f437QQF32353
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 00:26:26 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id CF341CE62; Thu,  3 May 2001 09:24:33 +0100 (BST)
To: "Steve Wray" <steve.wray@the.net.nz>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: compilation failure
References: <NBBBKLKHMJHIJLHOGAOJMEHOIOAA.steve.wray@the.net.nz>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 03 May 2001 09:24:33 +0100
In-Reply-To: <NBBBKLKHMJHIJLHOGAOJMEHOIOAA.steve.wray@the.net.nz> ("Steve Wray"'s message of "Thu, 3 May 2001 18:31:47 +1200")
Message-ID: <m3hez2on5q.fsf@giants.mandrakesoft.com>
Lines: 24
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Steve Wray" <steve.wray@the.net.nz> writes:

>  
> On Mandrake 8.0 system,
> got the release 1 thru CVS,
> configured and tried
> make dep clean bzImage modules

You compile it with a gcc-2.96 use kgcc from the egcs package.

> make modules chokes and dies with:
> 
> make[2]: Nothing to be done for `modules'.
> make[2]: Leaving directory
> `/home/steve/linux-2.4-xfs-r1.0/linux/fs/vfat'
> make -C xfs modules
> make[2]: Entering directory
> `/home/steve/linux-2.4-xfs-r1.0/linux/fs/xfs'
> gcc  -D__KERNEL__ -I/home/steve/linux-2.4-xfs-r1.0/linux/include 
> -Wall -Wstrict-prototypes -O2 -fno-strict-aliasing
> -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=k6
> -DMODULE -DMODVERSIONS -include



From owner-linux-xfs@oss.sgi.com Thu May  3 00:31:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f437VaW32656
	for linux-xfs-outgoing; Thu, 3 May 2001 00:31:36 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f437VZF32650
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 00:31:35 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 386AFCE62; Thu,  3 May 2001 09:29:43 +0100 (BST)
To: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Cc: "Steve Wray" <steve.wray@the.net.nz>, <linux-xfs@oss.sgi.com>
Subject: Re: compilation failure
References: <NBBBKLKHMJHIJLHOGAOJMEHOIOAA.steve.wray@the.net.nz>
	<10105031648.ZM53240@wobbly.melbourne.sgi.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 03 May 2001 09:29:43 +0100
In-Reply-To: <10105031648.ZM53240@wobbly.melbourne.sgi.com> ("Nathan Scott"'s message of "Thu, 3 May 2001 16:48:33 -0500")
Message-ID: <m3d79qomx4.fsf@giants.mandrakesoft.com>
Lines: 30
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> writes:

> http://linux-xfs.sgi.com/projects/xfs/faq.html ...
> "Q: Are there any known issues about gcc 2.95 for compiling
> the XFS kernel tree?"


Would be possible to make this changes in the FAQ :

--- /tmp/faq    Thu May  3 09:25:24 2001
+++ /tmp/faq.new        Thu May  3 09:29:06 2001
@@ -1,12 +1,15 @@
 Q: Are there any known issues about gcc 2.95 for compiling the XFS kernel tree?
 
 Yes. So far there were some problems reported with kernels built with
-gcc 2.95 which were solved by compiling it with egcs 2.91.66 (or kgcc
-on RedHat 7.x systems). So for now please use version gcc 2.91.66 (aka
-egcs 1.1.2) to build your XFS kernel. If you are using a debian or
+gcc 2.95 which were solved by compiling it with egcs 2.91.66[*] So for
+now please use version gcc 2.91.66[*] to build your XFS kernel. If you are using a debian or
 SuSE based system this means that you may have to find and install
 this egcs version. Please note that the problems with gcc 2.95 seem to
 be restriced to the i386 platform - on the ppc it works just fine with
 2.95 for instance. All said for gcc 2.95 also applies to redhat's gcc
 2.96. On the other hand the gcc 2.95.3 (20010125) from debian unstalbe
 seems to work.
+
+[*] It's called kgcc on a Red Hat system and are located in the
+compat-egcs package, on a Linux-Mandrake system it's located in the
+egcs package.

From owner-linux-xfs@oss.sgi.com Thu May  3 01:33:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f438X3Z04098
	for linux-xfs-outgoing; Thu, 3 May 2001 01:33:03 -0700
Received: from mailb.telia.com (root@mailb.telia.com [194.22.194.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f438WvF04093
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 01:32:57 -0700
Received: from d1o980.telia.com (d1o980.telia.com [213.65.208.241])
	by mailb.telia.com (8.9.3/8.9.3) with ESMTP id KAA01173;
	Thu, 3 May 2001 10:32:51 +0200 (CEST)
Received: from student.liu.se (h222n2fls22o980.telia.com [213.66.251.222])
	by d1o980.telia.com (8.10.2/8.10.1) with ESMTP id f438Wo021430;
	Thu, 3 May 2001 10:32:50 +0200 (CEST)
Message-ID: <3AF117B2.1070503@student.liu.se>
Date: Thu, 03 May 2001 10:32:50 +0200
From: Joakim Bodin <joabo552@student.liu.se>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.8.1+) Gecko/20010502
X-Accept-Language: sv, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
CC: Sven Herzberg <herzi@runbox.com>,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com> <m3bspbwotj.fsf@giants.mandrakesoft.com> <3AF0A70D.C5CE4733@thebarn.com> <m37kzyrhj1.fsf@giants.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chmouel Boudjnah wrote:

>Russell Cattelan <cattelan@thebarn.com> writes:
>
>>Yes please.
>>
>
>Ok they are ready :
>
>ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-devel/contrib/RPMS/
>
>it's :
>
>acl-1.0.1-1mdk.i586.rpm
>acl-devel-1.0.1-1mdk.i586.rpm
>attr-1.0.1-1mdk.i586.rpm
>attr-devel-1.0.1-1mdk.i586.rpm
>xfsprogs-1.2.0-1mdk.i586.rpm
>xfsprogs-devel-1.2.0-1mdk.i586.rpm
>dmapi-0.1.1-1mdk.i586.rpm
>dmapi-devel-0.1.1-1mdk.i586.rpm
>xfsdump-1.0.5-1mdk.i586.rpm
>
>and :
>
>kernel-xfs-2.4.4-1mdk.i586.rpm
>
>>I've  build a patch against the 8.0 kernel src rpm, haven't tested it
>>yet but it does compile.
>>Anybody want help finish it.?
>>
>
>Could you send me the patch, i had a lot of conflict and i did the
>kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
>
>>If fact I would to encourage some savvy installer programmer to add
>>XFS support to the mandrake installer. I've looked at the code and
>>see reiserfs is already in there shouldn't be to much work to add
>>xfs.
>>
>
>I already begin it, it should be fairly simple...
>
I'd just like to give thanks to Chmouel for theses packages and 
hopefully a xfs-enabled Mdk 8.1 install. Mdk is just getting better and 
better :)

Joakim Bodin


From owner-linux-xfs@oss.sgi.com Thu May  3 02:22:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f439Maj06808
	for linux-xfs-outgoing; Thu, 3 May 2001 02:22:36 -0700
Received: from mail.celestix.com ([203.126.57.231])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f439MVF06800
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 02:22:32 -0700
Received: from mail.celestix.com (localhost.localdomain [127.0.0.1])
	by localhost (Postfix) with SMTP id D9C6A1B8046
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 17:26:49 +0800 (SGT)
Received: FROM localhost.localdomain ([127.0.0.1])
	BY mail.celestix.com (Sophos Anti-Virus for SMTP v1.5.1 build 13) ;
	Thu, 3 May 2001 17:26:49 +0000
Received: from groovindarkness.celestix.com (unknown [203.126.57.234])
	by mail.celestix.com (Postfix) with SMTP id B4E6F1B8033
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 17:26:47 +0800 (SGT)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Thibaut LAURENT <thibaut@celestix.com>
Organization: Celestix Networks Pte Ltd
To: linux-xfs@oss.sgi.com
Subject: XFS in Linus kernel tree ?
Date: Thu, 3 May 2001 17:18:37 +0800
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01050317183703.01483@groovindarkness.celestix.com>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi !

I guess this question has already been asked a thousand times but I could not 
find the answer anywhere (may the great Tux blue-screen me if I was too 
lazy) : now there's a pretty stable release of XFS, is it meant to be 
integrated into the standard Linus kernel as reiserfs ?
BTW, do you guys have an idea of how long it will take to implement group 
quotas ?
Thanks for all your great work,

Thibaut
 
Thibaut Laurent
R&D Engineer
Celestix Networks Pte Ltd, Singapore
http://www.celestix.com


From owner-linux-xfs@oss.sgi.com Thu May  3 02:35:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f439ZId07290
	for linux-xfs-outgoing; Thu, 3 May 2001 02:35:18 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f439ZEF07286
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 02:35:14 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id LAA696939
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:35:09 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA21871; Thu, 3 May 2001 19:33:49 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA53229;
	Thu, 3 May 2001 19:33:47 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105031933.ZM42931@wobbly.melbourne.sgi.com>
Date: Thu, 3 May 2001 19:33:47 -0500
In-Reply-To: Thibaut LAURENT <thibaut@celestix.com>
        "XFS in Linus kernel tree ?" (May  3,  5:18pm)
References: <01050317183703.01483@groovindarkness.celestix.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Thibaut LAURENT <thibaut@celestix.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS in Linus kernel tree ?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 3,  5:18pm, Thibaut LAURENT wrote:
> Subject: XFS in Linus kernel tree ?
> Hi !
> 
> I guess this question has already been asked a thousand times but I could not 
> find the answer anywhere (may the great Tux blue-screen me if I was too 
> lazy) : now there's a pretty stable release of XFS, is it meant to be 
> integrated into the standard Linus kernel as reiserfs ?

I'm not going to make a guess on that one, but...

> BTW, do you guys have an idea of how long it will take to implement group 
> quotas ?

Group quotas are already supported (in the 1.0 release).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 03:04:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43A4dF08346
	for linux-xfs-outgoing; Thu, 3 May 2001 03:04:39 -0700
Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43A4bF08343
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:04:38 -0700
Received: from granbar-192.ii.uib.no (granbar.ii.uib.no) [129.177.192.137] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 14vFyV-0004kv-00 
	for <linux-xfs@oss.sgi.com>; Thu, 03 May 2001 12:04:43 +0200
Received: (from jfm@localhost)
	by granbar.ii.uib.no (8.9.3+Sun/8.9.3) id MAA13739
	for linux-xfs@oss.sgi.com; Thu, 3 May 2001 12:04:35 +0200 (MEST)
Date: Thu, 3 May 2001 12:04:35 +0200
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: linux-xfs@oss.sgi.com
Subject: strange files, XFS bug?
Message-ID: <20010503120435.A13673@ii.uib.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi, 

I've been seeing some strange errors with my XFS filesystem lately. When
doing 'ls' of different directories I get errors saying "No such file or
directory". Is this an XFS bug, or something else?

%  uname -a
Linux mushkin.ii.uib.no 2.4.2-XFS #1 fre mar 16 23:07:22 CET 2001 i586 unknown
%  df -k .
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/ide/host0/bus1/target1/lun0/part1
                      14107168  12971344   1135824  92% /home
%  mount | grep home
/dev/ide/host0/bus1/target1/lun0/part1 on /home type xfs (rw)
%  grep home /etc/fstab 
/dev/discs/disc1/part1               /home              xfs    defaults 1 1
%  ls
ls: Spm.+Ref.liste i MAR316.sdw: No such file or directory
ls: tysse.doc: No such file or directory
ls: Jobbsøkn.3.sdw: Invalid or incomplete multibyte or wide character
ls: Jobbsøkn.4.doc: Invalid or incomplete multibyte or wide character
ls: OppgaveMAR304.sdw: No such file or directory
JobbS?knad.sdw           Sammendr.MAR316.doc          VociNob.Regn.2001.sdw
Jobbs?kn.4.sdw           Sammendr.MAR316.doc.sdw VociNob.?rsregn.2000.doc
Jobbs?knad,2.doc         SammendragMAR316.sdw VociNob.?rsregn.2000.sdw
Jobbs?knad,2.sdw         Spm.+Ref.liste i MAR316.doc  innbydelse.9A.doc
KLASSE9A.doc             S?kn.DnB.doc                 innbydelse.9A.sdw
KLASSE9A.sdw             S?kn.DnB.sdw                 kabelinfo..sdw
MAR303.oppg.2.doc        S?kn.Halliburton.sdw         mf.doc
MAR303.oppg.2.sdw        S?kn.Rieber.doc              mf.sdw
OppgaveMAR304.doc        S?kn.Rieber.sdw              mm.sdw
OppgaveMAR316.doc        S?kn.Spareb.1.doc            regning.sdw
OppgaveMAR316.sdw        S?kn.Str?lfors.sdw           tysse.sdw
Presentasjon,MAR316.sdw  VociNob.Regn..sdw            tysse2.doc
%  ls -al tysse.doc
ls: tysse.doc: No such file or directory
%  ls -ld .
drwxr-xr-x    2 siri     users        4096 Apr 29 22:12 .

Same thing happens as root, so it's not a permission problem. I have several
directories showing the same problem. Any ideas?

I'm running a bit old version of 2.4.2-XFS because I random lockups with
2.4.3-XFS, hard hangs and once a message about

kernel: spurious APIC interrupt on CPU#0, should never happen.
kernel: NETDEV WATCHDOG: eth0: transmit timed out
kernel: ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
kernel: hdc: lost interrupt


Will upgrade to 2.4.4-XFS as soon as it's stable..
	

  -jf

From owner-linux-xfs@oss.sgi.com Thu May  3 03:27:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43AR3V09168
	for linux-xfs-outgoing; Thu, 3 May 2001 03:27:03 -0700
Received: from indonesia.kscanners.no (indonesia.kscanners.no [193.214.130.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AQmF09156
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:26:52 -0700
Received: from localhost.localdomain
	([127.0.0.1] helo=kscanners.com ident=toralf)
	by indonesia.kscanners.no with esmtp (Exim 3.22 #1)
	id 14vGJh-0000as-00; Thu, 03 May 2001 12:26:37 +0200
Message-ID: <3AF1325D.9B68F5C9@kscanners.com>
Date: Thu, 03 May 2001 12:26:37 +0200
From: Toralf Lund <toralf@kscanners.com>
Organization: Kongsberg Scanners AS
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: NFS problems
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is not directly related to XFS, but it's a bit disappointing to see
that SGI has released a kernel (kernel-2.4.2-SGI_XFS_1.0) that has
compatibility problems with IRIX servers - specifically, mounting file
systems from an IRIX server reveals a bug in the NFS driver.

For more info, please refer to

     http://www.fys.uio.no/~trondmy/src/2.4.3/
     (linux-2.4.3-dir.dif)

and

     http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897

--
Toralf Lund <toralf@kscanners.com>  +47 66 85 51 22
Kongsberg Scanners AS               +47 66 85 51 00 (switchboard)
http://www.kscanners.no/~toralf     +47 66 85 51 01 (fax)




From owner-linux-xfs@oss.sgi.com Thu May  3 03:28:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43AS4T09221
	for linux-xfs-outgoing; Thu, 3 May 2001 03:28:04 -0700
Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AS2F09217
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:28:02 -0700
Received: from fosi (203-79-83-162.cable.paradise.net.nz [203.79.83.162])
	by deborah.paradise.net.nz (8.11.3/8.11.3) with SMTP id f43ARZ866536;
	Thu, 3 May 2001 22:27:35 +1200 (NZST)
From: "Steve Wray" <steve.wray@the.net.nz>
To: "Chmouel Boudjnah" <chmouel@mandrakesoft.com>,
   "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: compilation failure
Date: Thu, 3 May 2001 22:24:49 +1200
Message-ID: <NBBBKLKHMJHIJLHOGAOJIEIAIOAA.steve.wray@the.net.nz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <m3d79qomx4.fsf@giants.mandrakesoft.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sorry, I had been under the (obviously  mistaken) impression
that since I had the latest release of Mandrake, that it would
have a (default) C compiler that actually compiled basic things
like the kernel.

Crazy... we still have to have 2 different C compilers!
I thought this was just a bug in what was it Redhat 6 or something?

Why on earth are we still suffering this?

And thanks for the swift response!


> -----Original Message-----
> From: Chmouel Boudjnah [mailto:chmouel@mandrakesoft.com]
> Sent: Thursday, May 03, 2001 8:30 PM
> To: Nathan Scott
> Cc: Steve Wray; linux-xfs@oss.sgi.com
> Subject: Re: compilation failure
> 
> 
> "Nathan Scott" <nathans@wobbly.melbourne.sgi.com> writes:
> 
> > http://linux-xfs.sgi.com/projects/xfs/faq.html ...
> > "Q: Are there any known issues about gcc 2.95 for compiling
> > the XFS kernel tree?"
> 
> 
> Would be possible to make this changes in the FAQ :
> 
> --- /tmp/faq    Thu May  3 09:25:24 2001
> +++ /tmp/faq.new        Thu May  3 09:29:06 2001
> @@ -1,12 +1,15 @@
>  Q: Are there any known issues about gcc 2.95 for compiling the 
> XFS kernel tree?
>  
>  Yes. So far there were some problems reported with kernels built with
> -gcc 2.95 which were solved by compiling it with egcs 2.91.66 (or kgcc
> -on RedHat 7.x systems). So for now please use version gcc 2.91.66 (aka
> -egcs 1.1.2) to build your XFS kernel. If you are using a debian or
> +gcc 2.95 which were solved by compiling it with egcs 2.91.66[*] So for
> +now please use version gcc 2.91.66[*] to build your XFS kernel. 
> If you are using a debian or
>  SuSE based system this means that you may have to find and install
>  this egcs version. Please note that the problems with gcc 2.95 seem to
>  be restriced to the i386 platform - on the ppc it works just fine with
>  2.95 for instance. All said for gcc 2.95 also applies to redhat's gcc
>  2.96. On the other hand the gcc 2.95.3 (20010125) from debian unstalbe
>  seems to work.
> +
> +[*] It's called kgcc on a Red Hat system and are located in the
> +compat-egcs package, on a Linux-Mandrake system it's located in the
> +egcs package.
> 

From owner-linux-xfs@oss.sgi.com Thu May  3 03:31:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43AVYL09466
	for linux-xfs-outgoing; Thu, 3 May 2001 03:31:34 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AVYF09461
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:31:34 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 45419CE62; Thu,  3 May 2001 12:29:41 +0100 (BST)
To: "Steve Wray" <steve.wray@the.net.nz>
Cc: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>, <linux-xfs@oss.sgi.com>
Subject: Re: compilation failure
References: <NBBBKLKHMJHIJLHOGAOJIEIAIOAA.steve.wray@the.net.nz>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 03 May 2001 12:29:41 +0100
In-Reply-To: <NBBBKLKHMJHIJLHOGAOJIEIAIOAA.steve.wray@the.net.nz> ("Steve Wray"'s message of "Thu, 3 May 2001 22:24:49 +1200")
Message-ID: <m31yq6k6vu.fsf@giants.mandrakesoft.com>
Lines: 15
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Steve Wray" <steve.wray@the.net.nz> writes:

> Sorry, I had been under the (obviously  mistaken) impression
> that since I had the latest release of Mandrake, that it would
> have a (default) C compiler that actually compiled basic things
> like the kernel.

the problem is only when compiler XFS not the kernel himsef.

> Crazy... we still have to have 2 different C compilers!
> I thought this was just a bug in what was it Redhat 6 or something?

?????????, it's not a bug but a "Distribution design features <sigh>"



From owner-linux-xfs@oss.sgi.com Thu May  3 03:45:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43AjS410814
	for linux-xfs-outgoing; Thu, 3 May 2001 03:45:28 -0700
Received: from smtp-server2.tampabay.rr.com (smtp-server2.tampabay.rr.com [65.32.1.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AjRF10811
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:45:28 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f43Aiov14619;
	Thu, 3 May 2001 06:44:50 -0400 (EDT)
Message-ID: <3AF137CB.5DE970F6@cfl.rr.com>
Date: Thu, 03 May 2001 06:49:47 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: utz lehmann <xfs@s2y4n2c.de>
CC: Andi Kleen <ak@suse.de>, Eric Whiting <ewhiting@amis.com>,
   linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <20010502203454.A9561@s2y4n2c.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

utz lehmann wrote:
> 
> Andi Kleen [ak@suse.de] wrote:
> > On Wed, May 02, 2001 at 11:40:27AM -0600, Eric Whiting wrote:
> > > My hardware is Tyan 1854, PIII 866, 3com 905b, 3ware 6200 ide
> > > controller, ibm 75G ide disk.
> > > My base OS is SUSE 7.1
> >
> > SuSE 7.1 comes with gcc 2.95; it is a bit safer to compile with an
> > egcs 1.1 compiler because there have been problems with that compiler
> > version and XFS in the past.
> 
> btw: you can install the redhat 7.0 kgcc rpm on suse 7.1. it works.
> dont forget to change the linux makefile to use kgcc and all makefiles for
> other kernel modules (nvidia driver).
> 
> utz

I've heard rumors on the SuSE-e list that the lastest stable release
2.95.3 works
ok woth XFS. Haven't tried it yet. Get SuSE's rpm and try it first.

-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Thu May  3 03:52:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Aq0g11007
	for linux-xfs-outgoing; Thu, 3 May 2001 03:52:00 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43ApvF11003
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:51:58 -0700
Received: (qmail 3071 invoked from network); 3 May 2001 10:51:53 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 3 May 2001 10:51:53 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Steve Wray" <steve.wray@the.net.nz>
cc: "Chmouel Boudjnah" <chmouel@mandrakesoft.com>, linux-xfs@oss.sgi.com
Subject: Re: compilation failure 
In-reply-to: Your message of "Thu, 03 May 2001 22:24:49 +1200."
             <NBBBKLKHMJHIJLHOGAOJIEIAIOAA.steve.wray@the.net.nz> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 May 2001 20:51:53 +1000
Message-ID: <16030.988887113@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 3 May 2001 22:24:49 +1200, 
"Steve Wray" <steve.wray@the.net.nz> wrote:
>Sorry, I had been under the (obviously  mistaken) impression
>that since I had the latest release of Mandrake, that it would
>have a (default) C compiler that actually compiled basic things
>like the kernel.

The kernel is notorious as being a bad test case for gcc.  There are
unusual C and assembler constructs that are ambiguously defined or
simply not in the gcc documentation but happen to work.  Most people do
not try anything unusual but the kernel is full of special case code.

If gcc changes something that was fully documented then it is a gcc
bug.  But if gcc changes undocumented or ambiguous behaviour then we
get arguments about whether gcc or the kernel is wrong.  In that
situation the kernel developers recommend specific versions of gcc for
compiling the kernel.  Sometimes distributions have to ship two
compilers, an older one which is known to compile the kernel correctly
and a newer one for user space which might compile the kernel or might
not.  linux/Dcoumentation/Changes lists the required versions of gcc
for the kernel.


From owner-linux-xfs@oss.sgi.com Thu May  3 03:56:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43AutE11179
	for linux-xfs-outgoing; Thu, 3 May 2001 03:56:55 -0700
Received: from mail.crc.dk (mail.crc.dk [130.226.184.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AuqF11176
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:56:53 -0700
Received: from crc.dk (k020-03.crc.dk [130.226.182.195])
	by mail.crc.dk (8.9.3/8.9.3) with ESMTP id MAA00867;
	Thu, 3 May 2001 12:56:49 +0200
Message-ID: <3AF13971.C7E78689@crc.dk>
Date: Thu, 03 May 2001 12:56:49 +0200
From: Mogens Kjaer <mk@crc.dk>
Organization: Carlsberg Laboratory
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2nfs i686)
X-Accept-Language: da, en, de
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: NFS problems
References: <3AF1325D.9B68F5C9@kscanners.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Toralf Lund wrote:
> 
> This is not directly related to XFS, but it's a bit disappointing to see
> that SGI has released a kernel (kernel-2.4.2-SGI_XFS_1.0) that has
> compatibility problems with IRIX servers - specifically, mounting file
> systems from an IRIX server reveals a bug in the NFS driver.
> 
> For more info, please refer to
> 
>      http://www.fys.uio.no/~trondmy/src/2.4.3/
>      (linux-2.4.3-dir.dif)
> 
> and
> 
>      http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897
> 
> --
> Toralf Lund <toralf@kscanners.com>  +47 66 85 51 22
> Kongsberg Scanners AS               +47 66 85 51 00 (switchboard)
> http://www.kscanners.no/~toralf     +47 66 85 51 01 (fax)

I've done the following:

Downloaded SGI's RH7.1-SGI-XFS-1.0.iso file, installed the kernel
SRPM file, added Trond's patch and build the different rpm's.

I've replaced SGI's rpms with the new ones and made an iso file
out of it.

This can be found at: ftp://ftp.crc.dk/pub/rh71irixnfspatch/

in the XFS subdirectory.

BTW[1], I had to name the RPM's the same as on the original CD, as
I couldn't get genhdlist to work. What is the right way of doing
this?

BTW[2], I couldn't do a graphical installation on an intel 815
based machine, X won't start. Have some modules been taken
out of the boot image (i.e. agpgart) in order to make room for xfs?

Mogens
-- 
Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

From owner-linux-xfs@oss.sgi.com Thu May  3 03:58:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Awlj11239
	for linux-xfs-outgoing; Thu, 3 May 2001 03:58:47 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43AwkF11235
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 03:58:46 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id AFCFC1E2ED; Thu,  3 May 2001 12:58:45 +0200 (MEST)
Date: Thu, 3 May 2001 12:58:44 +0200
From: Andi Kleen <ak@suse.de>
To: Mark Hounschell <dmarkh@cfl.rr.com>
Cc: utz lehmann <xfs@s2y4n2c.de>, Andi Kleen <ak@suse.de>,
   Eric Whiting <ewhiting@amis.com>, linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
Message-ID: <20010503125844.C28596@gruyere.muc.suse.de>
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <20010502203454.A9561@s2y4n2c.de> <3AF137CB.5DE970F6@cfl.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF137CB.5DE970F6@cfl.rr.com>; from dmarkh@cfl.rr.com on Thu, May 03, 2001 at 06:49:47AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 03, 2001 at 06:49:47AM -0400, Mark Hounschell wrote:
> I've heard rumors on the SuSE-e list that the lastest stable release
> 2.95.3 works
> ok woth XFS. Haven't tried it yet. Get SuSE's rpm and try it first.

The latest XFS tree has some workaround for known 2.95 long long bugs (mainly 
division) and they seem to work somehow; but nobody knows if that really 
catched all cases or if there isn't miscompilation in more obscure code 
paths left. XFS is full of long long computation (you wanted a "64bit 
filesystem", didn't you?). Using egcs 1.1 is definitely safer, with it 
XFS has been tested a lot more.  You could also use XFS on a 64bit 
architecture like an Alpha.


-Andi


From owner-linux-xfs@oss.sgi.com Thu May  3 04:23:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43BNsc12255
	for linux-xfs-outgoing; Thu, 3 May 2001 04:23:54 -0700
Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43BNrF12251
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 04:23:53 -0700
Received: from pacbell.net ([64.171.2.231])
 by mta7.pltn13.pbi.net (Sun Internet Mail Server
 sims.3.5.2000.03.23.18.03.p10) with ESMTP id
 <0GCQ00BSWX1FG0@mta7.pltn13.pbi.net> for linux-xfs@oss.sgi.com; Wed,
 2 May 2001 23:08:03 -0700 (PDT)
Date: Wed, 02 May 2001 23:07:35 -0700
From: Jake Bishop <jb3insf@pacbell.net>
Subject: Recompile the Red hat xfs kernel
To: linux-xfs@oss.sgi.com
Message-id: <3AF0F5A7.C96004A4@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,
I have installed the Red Hat 7.1 system with the XFS kernel.The system
seems to run very well.
I would like to recompile the kernel to better fit my system.How is this
done?. There is no /usr/src/linux
dir.I am new to Redhat, not to sure about there methods, I like to use
Slackware, to me a much easier
distro to deal with.
Thanks


From owner-linux-xfs@oss.sgi.com Thu May  3 04:37:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Bbl212998
	for linux-xfs-outgoing; Thu, 3 May 2001 04:37:47 -0700
Received: from mail.crc.dk (mail.crc.dk [130.226.184.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43BbjF12993
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 04:37:45 -0700
Received: from crc.dk (k020-03.crc.dk [130.226.182.195])
	by mail.crc.dk (8.9.3/8.9.3) with ESMTP id NAA04190;
	Thu, 3 May 2001 13:37:43 +0200
Message-ID: <3AF14307.12DF22F2@crc.dk>
Date: Thu, 03 May 2001 13:37:43 +0200
From: Mogens Kjaer <mk@crc.dk>
Organization: Carlsberg Laboratory
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2nfs i686)
X-Accept-Language: da, en, de
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Recompile the Red hat xfs kernel
References: <3AF0F5A7.C96004A4@pacbell.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jake Bishop wrote:
> 
> Hello,
> I have installed the Red Hat 7.1 system with the XFS kernel.The system
> seems to run very well.
> I would like to recompile the kernel to better fit my system.How is this
> done?. There is no /usr/src/linux
> dir.

It's called /usr/src/linux-2.4.2.

If this doesn't exist, you havn't installed the kernel-source rpm.

Mogens

-- 
Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

From owner-linux-xfs@oss.sgi.com Thu May  3 04:40:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43BeZx13053
	for linux-xfs-outgoing; Thu, 3 May 2001 04:40:35 -0700
Received: from mail.crc.dk (mail.crc.dk [130.226.184.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43BeXF13050
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 04:40:33 -0700
Received: from crc.dk (k020-03.crc.dk [130.226.182.195])
	by mail.crc.dk (8.9.3/8.9.3) with ESMTP id NAA04454;
	Thu, 3 May 2001 13:40:31 +0200
Message-ID: <3AF143AF.8D7C94C0@crc.dk>
Date: Thu, 03 May 2001 13:40:31 +0200
From: Mogens Kjaer <mk@crc.dk>
Organization: Carlsberg Laboratory
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2nfs i686)
X-Accept-Language: da, en, de
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: NFS problems
References: <3AF1325D.9B68F5C9@kscanners.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Toralf Lund wrote:
...
>      http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897

I have a private theory on, why Trond's patch isn't included
in the kernel:

The kernel people claims that it is a glibc bug.
The glibc people claims that it is a kernel bug.
Everybody says it's an SGI bug.

:-)

Mogens
-- 
Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

From owner-linux-xfs@oss.sgi.com Thu May  3 04:43:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43BhBS13120
	for linux-xfs-outgoing; Thu, 3 May 2001 04:43:11 -0700
Received: from oxera.wanadoo.fr (smtp-rt-13.wanadoo.fr [193.252.19.223])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Bh9F13117
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 04:43:09 -0700
Received: from amyris.wanadoo.fr (193.252.19.150) by oxera.wanadoo.fr; 3 May 2001 13:43:01 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by amyris.wanadoo.fr; 3 May 2001 13:37:50 +0200
Subject: Re: strange files, XFS bug?
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Jan-Frode Myklebust <janfrode@parallab.uib.no>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010503120435.A13673@ii.uib.no>
References: <20010503120435.A13673@ii.uib.no>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 13:39:14 +0200
Message-Id: <988889956.4975.0.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 03 May 2001 12:04:35 +0200, Jan-Frode Myklebust a écrit :
> I've been seeing some strange errors with my XFS filesystem lately. When
> doing 'ls' of different directories I get errors saying "No such file or
> directory". Is this an XFS bug, or something else?

I had this kind problem and xfs_repair allowed me to correct the
corrupted fileystem (the filesystem should not be mounted).

> Will upgrade to 2.4.4-XFS as soon as it's stable..

2.4.4-xfs does not correct the problem for me, use xfs_repair

-David


From owner-linux-xfs@oss.sgi.com Thu May  3 05:10:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43CA9O14248
	for linux-xfs-outgoing; Thu, 3 May 2001 05:10:09 -0700
Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CA7F14245
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:10:08 -0700
Received: from granbar-192.ii.uib.no (granbar.ii.uib.no) [129.177.192.137] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 14vHvy-0005NP-00 ; Thu, 03 May 2001 14:10:14 +0200
Received: (from jfm@localhost)
	by granbar.ii.uib.no (8.9.3+Sun/8.9.3) id OAA14221;
	Thu, 3 May 2001 14:09:56 +0200 (MEST)
Date: Thu, 3 May 2001 14:09:56 +0200
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: "redhat.angus" <redhat.angus@wanadoo.fr>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
Message-ID: <20010503140956.A14103@ii.uib.no>
References: <20010503120435.A13673@ii.uib.no> <988889956.4975.0.camel@adslgw>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <988889956.4975.0.camel@adslgw>; from redhat.angus@wanadoo.fr on Thu, May 03, 2001 at 01:39:14PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 03, 2001 at 01:39:14PM +0200, redhat.angus wrote:
> 
> I had this kind problem and xfs_repair allowed me to correct the
> corrupted fileystem (the filesystem should not be mounted).
> 

Thanks, looks like xfs_repair fixed it. Anyway, does anybody know 
what's causing this? Should i be worried?


  -jf

From owner-linux-xfs@oss.sgi.com Thu May  3 05:14:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43CEmM14482
	for linux-xfs-outgoing; Thu, 3 May 2001 05:14:48 -0700
Received: from ns.tecosim.de (ns.tecosim.de [194.24.222.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CEkF14478
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:14:46 -0700
Received: from donner.tecosim.de (root@donner.tecosim.de [194.24.222.109])
	by ns.tecosim.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id OAA03304;
	Thu, 3 May 2001 14:14:43 +0200
Received: (from leh@localhost)
	by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f43CEfA29109;
	Thu, 3 May 2001 14:14:41 +0200
Date: Thu, 3 May 2001 14:14:41 +0200
From: Utz Lehmann <leh@tecosim.de>
To: Jan-Frode Myklebust <janfrode@parallab.uib.no>
Cc: "redhat.angus" <redhat.angus@wanadoo.fr>, linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
Message-ID: <20010503141440.C23836@tecosim.de>
References: <20010503120435.A13673@ii.uib.no> <988889956.4975.0.camel@adslgw> <20010503140956.A14103@ii.uib.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010503140956.A14103@ii.uib.no>; from janfrode@parallab.uib.no on Thu, May 03, 2001 at 02:09:56PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jan-Frode Myklebust [janfrode@parallab.uib.no] wrote:
> On Thu, May 03, 2001 at 01:39:14PM +0200, redhat.angus wrote:
> > 
> > I had this kind problem and xfs_repair allowed me to correct the
> > corrupted fileystem (the filesystem should not be mounted).
> > 
> 
> Thanks, looks like xfs_repair fixed it. Anyway, does anybody know 
> what's causing this? Should i be worried?

i had this using a bad compiler (gcc 2.96).

egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.


utz

From owner-linux-xfs@oss.sgi.com Thu May  3 05:41:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43CfCN15808
	for linux-xfs-outgoing; Thu, 3 May 2001 05:41:12 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CfAF15804
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:41:11 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f43CefK10224;
	Thu, 3 May 2001 14:40:42 +0200
Message-Id: <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 May 2001 14:40:50 +0200
To: Jan-Frode Myklebust <janfrode@parallab.uib.no>,
   "redhat.angus" <redhat.angus@wanadoo.fr>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: strange files, XFS bug?
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010503140956.A14103@ii.uib.no>
References: <988889956.4975.0.camel@adslgw>
 <20010503120435.A13673@ii.uib.no>
 <988889956.4975.0.camel@adslgw>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:09 3-5-2001 +0200, Jan-Frode Myklebust wrote:
>On Thu, May 03, 2001 at 01:39:14PM +0200, redhat.angus wrote:
> >
> > I had this kind problem and xfs_repair allowed me to correct the
> > corrupted fileystem (the filesystem should not be mounted).
> >
>
>Thanks, looks like xfs_repair fixed it. Anyway, does anybody know
>what's causing this? Should i be worried?

I believe that the other one that also suffered corruption also had a SMP 
machine with a via chipset?
Am I correct, or just mixing things up.

The SMP machine at work uses a ServerWorks Chipset in a Dell 2450. And I 
can't provoke it.
Was this on scsi or IDE or even hardware/software Raid ?

There have been some serious DMA issues with via chipsets and IDE.
Get your latest bios in that case (according to the AC diary) which should 
fix it.
Don't know what -ac patch this belongs to. I believe 2.4.3 or later. Not sure

If anything is incorrect, shoot.. err... say so.

Bye
--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Thu May  3 05:41:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43CfcJ15829
	for linux-xfs-outgoing; Thu, 3 May 2001 05:41:38 -0700
Received: from areca.wanadoo.fr (smtp-rt-4.wanadoo.fr [193.252.19.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43CfXF15825
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:41:35 -0700
Received: from amyris.wanadoo.fr (193.252.19.150) by areca.wanadoo.fr; 3 May 2001 14:41:25 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by amyris.wanadoo.fr; 3 May 2001 14:39:59 +0200
Subject: Re: strange files, XFS bug?
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <20010503141440.C23836@tecosim.de>
References: <20010503120435.A13673@ii.uib.no>
	<988889956.4975.0.camel@adslgw> <20010503140956.A14103@ii.uib.no> 
	<20010503141440.C23836@tecosim.de>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 14:41:22 +0200
Message-Id: <988893685.6072.1.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 03 May 2001 14:14:41 +0200, Utz Lehmann a écrit :
> i had this using a bad compiler (gcc 2.96).
> 
> egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.

Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
compile kernel-2.4-xfs.

-David


From owner-linux-xfs@oss.sgi.com Thu May  3 05:46:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Ck6W15978
	for linux-xfs-outgoing; Thu, 3 May 2001 05:46:06 -0700
Received: from embelia.wanadoo.fr (smtp-rt-7.wanadoo.fr [193.252.19.161])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Ck1F15968
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:46:03 -0700
Received: from antholoma.wanadoo.fr (193.252.19.153) by embelia.wanadoo.fr; 3 May 2001 14:45:52 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by antholoma.wanadoo.fr; 3 May 2001 14:45:11 +0200
Subject: Re: strange files, XFS bug?
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Seth Mos <knuffie@xs4all.nl>
Cc: Jan-Frode Myklebust <janfrode@parallab.uib.no>, linux-xfs@oss.sgi.com
In-Reply-To: <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
References: <988889956.4975.0.camel@adslgw>
	<20010503120435.A13673@ii.uib.no> <988889956.4975.0.camel@adslgw> 
	<4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 14:46:32 +0200
Message-Id: <988893996.6067.2.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 03 May 2001 14:40:50 +0200, Seth Mos a écrit :
> I believe that the other one that also suffered corruption also had a SMP 
> machine with a via chipset?
> Am I correct, or just mixing things up.

no SMP and no via chipset for me, pure SCSI
I always use linux-2.4-xfs cvs branch and sometimes gcc-2.96RH

-David


From owner-linux-xfs@oss.sgi.com Thu May  3 05:57:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Cv3G16799
	for linux-xfs-outgoing; Thu, 3 May 2001 05:57:03 -0700
Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Cv1F16793
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:57:01 -0700
Received: from granbar-192.ii.uib.no (granbar.ii.uib.no) [129.177.192.137] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 14vIfI-0001mE-00 ; Thu, 03 May 2001 14:57:04 +0200
Received: (from jfm@localhost)
	by granbar.ii.uib.no (8.9.3+Sun/8.9.3) id OAA14417;
	Thu, 3 May 2001 14:56:56 +0200 (MEST)
Date: Thu, 3 May 2001 14:56:56 +0200
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: Seth Mos <knuffie@xs4all.nl>
Cc: "redhat.angus" <redhat.angus@wanadoo.fr>, linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
Message-ID: <20010503145656.B14333@ii.uib.no>
References: <988889956.4975.0.camel@adslgw> <20010503120435.A13673@ii.uib.no> <988889956.4975.0.camel@adslgw> <20010503140956.A14103@ii.uib.no> <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, May 03, 2001 at 02:40:50PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 03, 2001 at 02:40:50PM +0200, Seth Mos wrote:
> 
> I believe that the other one that also suffered corruption also had a SMP 
> machine with a via chipset?
> Am I correct, or just mixing things up.

This is on a single cpu, but it might be the VIA issue:

[root@mushkin lost+found]# hinv
Main memory size: 256 Mbytes
1 AuthenticAMD AMD-K6(tm) 3D processor processor
1 vga+ graphics device
PCI bus devices:
    Host bridge: VIA Technologies, Inc. VT82C597 [Apollo VP3] (rev 4).
    PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (rev 0).
    ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South] (rev 34).
    IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 16).
    Host bridge: VIA Technologies, Inc. VT82C596 Power Management (rev 48).
    SCSI storage controller: Symbios Logic Inc. (formerly NCR) 53c875 (rev 3).
    Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 6).
    Input device controller: Creative Labs SB Live! (rev 6).
    VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 130).


> 
> Was this on scsi or IDE or even hardware/software Raid ?

IDE, no raid.

> 
> There have been some serious DMA issues with via chipsets and IDE.
> Get your latest bios in that case (according to the AC diary) which should 
> fix it.

Will look for it, thanks.


  -jf

From owner-linux-xfs@oss.sgi.com Thu May  3 05:57:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43CvlF16921
	for linux-xfs-outgoing; Thu, 3 May 2001 05:57:47 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43CvjF16911
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 05:57:45 -0700
Received: (qmail 4342 invoked from network); 3 May 2001 12:57:42 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 3 May 2001 12:57:42 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "redhat.angus" <redhat.angus@wanadoo.fr>
cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: strange files, XFS bug? 
In-reply-to: Your message of "03 May 2001 14:41:22 +0200."
             <988893685.6072.1.camel@adslgw> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 03 May 2001 22:57:41 +1000
Message-ID: <17303.988894661@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 03 May 2001 14:41:22 +0200, 
"redhat.angus" <redhat.angus@wanadoo.fr> wrote:
>> egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.
>
>Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
>compile kernel-2.4-xfs.

gcc 2.96 is not an official release, it is a RedHat special.  2.96 does
not correctly compile the kernel, even without XFS.


From owner-linux-xfs@oss.sgi.com Thu May  3 06:01:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43D1dH17400
	for linux-xfs-outgoing; Thu, 3 May 2001 06:01:39 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43D1bF17392
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 06:01:37 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f43D0wK10290;
	Thu, 3 May 2001 15:00:58 +0200
Message-Id: <4.3.2.7.2.20010503145911.0372ebd0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 May 2001 15:01:07 +0200
To: "redhat.angus" <redhat.angus@wanadoo.fr>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: strange files, XFS bug?
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <988893685.6072.1.camel@adslgw>
References: <20010503141440.C23836@tecosim.de>
 <20010503120435.A13673@ii.uib.no>
 <988889956.4975.0.camel@adslgw>
 <20010503140956.A14103@ii.uib.no>
 <20010503141440.C23836@tecosim.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f43D1cF17395
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:41 3-5-2001 +0200, you wrote:
>Le 03 May 2001 14:14:41 +0200, Utz Lehmann a écrit :
> > i had this using a bad compiler (gcc 2.96).
> >
> > egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.
>
>Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
>compile kernel-2.4-xfs.

The updated 2.96 RH compiler available does compile but is not supported.
If you want a kernel that has been tested a lot compile it with 2.91.66.
This is known to work.


>-David

Bye

--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Thu May  3 06:03:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43D3IX17474
	for linux-xfs-outgoing; Thu, 3 May 2001 06:03:18 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43D3GF17470
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 06:03:16 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f43D2wK10312;
	Thu, 3 May 2001 15:02:58 +0200
Message-Id: <4.3.2.7.2.20010503150132.036cdea8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 03 May 2001 15:03:07 +0200
To: "redhat.angus" <redhat.angus@wanadoo.fr>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: strange files, XFS bug?
Cc: Jan-Frode Myklebust <janfrode@parallab.uib.no>, linux-xfs@oss.sgi.com
In-Reply-To: <988893996.6067.2.camel@adslgw>
References: <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
 <988889956.4975.0.camel@adslgw>
 <20010503120435.A13673@ii.uib.no>
 <988889956.4975.0.camel@adslgw>
 <4.3.2.7.2.20010503143610.0372ba08@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f43D3HF17472
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:46 3-5-2001 +0200, redhat.angus wrote:
>Le 03 May 2001 14:40:50 +0200, Seth Mos a écrit :
> > I believe that the other one that also suffered corruption also had a SMP
> > machine with a via chipset?
> > Am I correct, or just mixing things up.
>
>no SMP and no via chipset for me, pure SCSI
>I always use linux-2.4-xfs cvs branch and sometimes gcc-2.96RH

What is the scsi controller used in this system?
And it is better not to use the gcc-2.96RH unless it's the updated one.


>-David

Cheers

--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Thu May  3 06:14:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43DEUN17885
	for linux-xfs-outgoing; Thu, 3 May 2001 06:14:30 -0700
Received: from apeiba.wanadoo.fr (smtp-rt-2.wanadoo.fr [193.252.19.154])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43DEQF17878
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 06:14:27 -0700
Received: from andira.wanadoo.fr (193.252.19.152) by apeiba.wanadoo.fr; 3 May 2001 15:14:20 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by andira.wanadoo.fr; 3 May 2001 15:10:50 +0200
Subject: Re: strange files, XFS bug?
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Keith Owens <kaos@melbourne.sgi.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>, knuffie@xs4all.nl
In-Reply-To: <17303.988894661@ocs3.ocs-net>
References: <17303.988894661@ocs3.ocs-net>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 15:12:11 +0200
Message-Id: <988895536.6072.3.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 03 May 2001 22:57:41 +1000, Keith Owens a écrit :
> gcc 2.96 is not an official release, it is a RedHat special.  2.96 does
> not correctly compile the kernel, even without XFS.

I know. There is a long thread on this on slashdot, lkm and others
But RedHat compile kernel RPM with this gcc snapshot (alan cox himself
see
http://marc.theaimsgroup.com/?l=linux-kernel&m=98350147716979&w=2

and there was a request on this mailing list for testing exotic gcc with
linux-2.4-xfs :) so I test

My SCSI controller to answer to Seth is an initio 9100UW

but i am rather among those which accuses the compiler so i will use
kgcc for production.

-David

 


From owner-linux-xfs@oss.sgi.com Thu May  3 06:31:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43DVmM20153
	for linux-xfs-outgoing; Thu, 3 May 2001 06:31:48 -0700
Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43DVkF20131
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 06:31:46 -0700
Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged))
	by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id PAA04523;
	Thu, 3 May 2001 15:31:36 +0200
Received: from localhost (localhost [127.0.0.1])
	by vie-ac.office.ecetra.com (8.11.3/8.11.3) with ESMTP id f43DU6310598;
	Thu, 3 May 2001 15:30:06 +0200
Date: Thu, 3 May 2001 15:30:06 +0200 (CEST)
From: Adam Cioccarelli <alciocca@ecetra.com>
To: Seth Mos <knuffie@xs4all.nl>
cc: "redhat.angus" <redhat.angus@wanadoo.fr>,
   Jan-Frode Myklebust <janfrode@parallab.uib.no>, <linux-xfs@oss.sgi.com>
Subject: Re: strange files, XFS bug?
In-Reply-To: <4.3.2.7.2.20010503150132.036cdea8@pop.xs4all.nl>
Message-ID: <Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It is better not to use any version of gcc 2.96

see http://www.gnu.org/software/gcc/gcc-2.96.html

Adam



On Thu, 3 May 2001, Seth Mos wrote:

> At 14:46 3-5-2001 +0200, redhat.angus wrote:
> >Le 03 May 2001 14:40:50 +0200, Seth Mos a écrit :
> > > I believe that the other one that also suffered corruption also had a SMP
> > > machine with a via chipset?
> > > Am I correct, or just mixing things up.
> >
> >no SMP and no via chipset for me, pure SCSI
> >I always use linux-2.4-xfs cvs branch and sometimes gcc-2.96RH
>
> What is the scsi controller used in this system?
> And it is better not to use the gcc-2.96RH unless it's the updated one.
>
>
> >-David
>
> Cheers
>
> --
> Seth
> Every program has two purposes
> one for which it was written and
> another for which it wasn't
> I make the last kind.
>


From owner-linux-xfs@oss.sgi.com Thu May  3 06:48:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Dmbx28056
	for linux-xfs-outgoing; Thu, 3 May 2001 06:48:37 -0700
Received: from camelia.wanadoo.fr (smtp-rt-10.wanadoo.fr [193.252.19.59])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43DmWF28018
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 06:48:34 -0700
Received: from antholoma.wanadoo.fr (193.252.19.153) by camelia.wanadoo.fr; 3 May 2001 15:48:25 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by antholoma.wanadoo.fr; 3 May 2001 15:40:02 +0200
Subject: Re: strange files, XFS bug?
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Adam Cioccarelli <alciocca@ecetra.com>
Cc: Seth Mos <knuffie@xs4all.nl>,
   Jan-Frode Myklebust
	 <janfrode@parallab.uib.no>, linux-xfs@oss.sgi.com
In-Reply-To: 
	<Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
References: 
	<Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 15:41:27 +0200
Message-Id: <988897288.6401.0.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 03 May 2001 15:30:06 +0200, Adam Cioccarelli a écrit :
> It is better not to use any version of gcc 2.96
> 
> see http://www.gnu.org/software/gcc/gcc-2.96.html

There is different point of view on this subject.

see http://www.bero.org/gcc296.html

One could resume this has the approach according to Alan Cox and the
approach according to Linus Torvalds  (pro and con of gcc-2.96) ;-)

-David


From owner-linux-xfs@oss.sgi.com Thu May  3 07:05:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43E52V02323
	for linux-xfs-outgoing; Thu, 3 May 2001 07:05:02 -0700
Received: from apicra.wanadoo.fr (smtp-rt-3.wanadoo.fr [193.252.19.155])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43E4xF02303
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 07:05:01 -0700
Received: from andira.wanadoo.fr (193.252.19.152) by apicra.wanadoo.fr; 3 May 2001 16:04:52 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by andira.wanadoo.fr; 3 May 2001 15:53:28 +0200
Subject: Re: SGI CD installer and RedHat disc1: two in one
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: linux-xfs <linux-xfs@oss.sgi.com>
Cc: sandeen@sgi.com, cattelan@thebarn.com
In-Reply-To: <988816831.4045.0.camel@adslgw>
References: <988816831.4045.0.camel@adslgw>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 15:54:51 +0200
Message-Id: <988898093.6402.1.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It's worked !
With the help of Russell and Eric.

Thanks again.

-David


From owner-linux-xfs@oss.sgi.com Thu May  3 07:37:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43EbMu14950
	for linux-xfs-outgoing; Thu, 3 May 2001 07:37:22 -0700
Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43EbKF14932
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 07:37:20 -0700
Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com)
	by moving-picture.com with esmtp (Exim 3.16 #1)
	id 14vKDy-0003aQ-00
	for linux-xfs@oss.sgi.com; Thu, 03 May 2001 15:36:58 +0100
Message-ID: <3AF16D0A.2D12C344@moving-picture.com>
Date: Thu, 03 May 2001 15:36:58 +0100
From: James Pearson <james-p@moving-picture.com>
Organization: Moving Picture Company
X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Problem setting up quotas ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've just installed RedHat 7.1/XFS1.0 on a Athlon based system and I'm
trying to get quotas working - so far without success.

I've made a XFS file system and mounted it with -o quota and tried to
follow the instructions in the quotaon man page and
/usr/share/doc/xfsprogs/README.quota but get the following:

# rpm -q quota
quota-3.01-SGI_5

# uname -r
2.4.2-SGI_XFS_1.0

# mount | grep quota
/dev/hda4 on /disk1 type xfs (rw,quota)

# setquota james 600 800 15 20 /disk1
Not all specified mountpoints are using quota.

# repquota /disk1
Not all specified mountpoints are using quota.

# edquota james
No filesystems with quota detected.

I've also recompiled the kernel with CONFIG_QUOTA=y and
CONFIG_XFS_QUOTA=y just in case the supplied kernel didn't have quotas
enabled - but with the same results.

Is there anything else I need to do?

Incidentally, the examples in /usr/share/doc/xfsprogs/README.quota and
the quotaon man page don't agree with the actual commands e.g.

in README.quota the syntax to the setquota example is incorrect.

in quotaon(8), the examples talk about a -s option to repquota and a -o
option to quotaoff which don't seem to exist ...

Thanks

James Pearson

From owner-linux-xfs@oss.sgi.com Thu May  3 07:54:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Eslk21739
	for linux-xfs-outgoing; Thu, 3 May 2001 07:54:47 -0700
Received: from sith.mimuw.edu.pl (qmailr@sith.mimuw.edu.pl [193.0.97.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43EsiF21728
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 07:54:45 -0700
Received: (qmail 32010 invoked by uid 1645); 3 May 2001 15:00:18 -0000
Date: Thu, 3 May 2001 17:00:18 +0200
From: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
To: James Pearson <james-p@moving-picture.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
Message-ID: <20010503170018.A31942@sith.mimuw.edu.pl>
References: <3AF16D0A.2D12C344@moving-picture.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AF16D0A.2D12C344@moving-picture.com>; from james-p@moving-picture.com on Thu, May 03, 2001 at 03:36:58PM +0100
X-Operating-System: Linux 2.4.2 i686
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 03 May 2001, James Pearson wrote:

> I've just installed RedHat 7.1/XFS1.0 on a Athlon based system and I'm
> trying to get quotas working - so far without success.
> 
> I've made a XFS file system and mounted it with -o quota and tried to
> follow the instructions in the quotaon man page and
> /usr/share/doc/xfsprogs/README.quota but get the following:
> 
> # rpm -q quota
> quota-3.01-SGI_5
> 
> # uname -r
> 2.4.2-SGI_XFS_1.0
> 
> # mount | grep quota
> /dev/hda4 on /disk1 type xfs (rw,quota)
> 
> # setquota james 600 800 15 20 /disk1
> Not all specified mountpoints are using quota.
> 
> # repquota /disk1
> Not all specified mountpoints are using quota.
> 
> # edquota james
> No filesystems with quota detected.
> 
> I've also recompiled the kernel with CONFIG_QUOTA=y and
> CONFIG_XFS_QUOTA=y just in case the supplied kernel didn't have quotas
> enabled - but with the same results.
> 
> Is there anything else I need to do?

I had the same problem. It may be the effect of misplaced patch.

Look in the fs/dquot.c file somewhere around line 1450,
and move the following after the if (special != NULL...) statement:

        if (sb && sb->s_op && sb->s_op->quotactl) {
                unlock_kernel();
                return sb->s_op->quotactl(sb, cmds, type, id, addr);
        }

        if (id & ~0xFFFF)
                goto out;

I don't know why, but it happened.

Jan
-- 
Jan Rêkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio

From owner-linux-xfs@oss.sgi.com Thu May  3 07:59:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43ExJc23621
	for linux-xfs-outgoing; Thu, 3 May 2001 07:59:19 -0700
Received: from femail24.sdc1.sfba.home.com (femail24.sdc1.sfba.home.com [24.0.95.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43ExHF23603
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 07:59:17 -0700
Received: from cr598116-a.wlfdle1.on.wave.home.com ([24.112.74.120])
          by femail24.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010503145912.CIMF627.femail24.sdc1.sfba.home.com@cr598116-a.wlfdle1.on.wave.home.com>;
          Thu, 3 May 2001 07:59:12 -0700
From: Gerald Henriksen <ghenriks@home.com>
To: Keith Owens <kaos@melbourne.sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug? 
Date: Thu, 03 May 2001 11:00:11 -0400
Message-ID: <vfs2ft42cm5v49grp8gtt5ksorj2tdu64h@4ax.com>
References: <988893685.6072.1.camel@adslgw> <17303.988894661@ocs3.ocs-net>
In-Reply-To: <17303.988894661@ocs3.ocs-net>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f43ExIF23604
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 03 May 2001 22:57:41 +1000, you wrote:

>On 03 May 2001 14:41:22 +0200, 
>"redhat.angus" <redhat.angus@wanadoo.fr> wrote:
>>> egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.
>>
>>Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
>>compile kernel-2.4-xfs.
>
>gcc 2.96 is not an official release, it is a RedHat special.  2.96 does
>not correctly compile the kernel, even without XFS.

I am sure that this will come as a surprise to Red Hat, who are
shipping Red Hat 7.1 with a kernel compiled with gcc 2.96

The kernel issue was with kernels 2.2 and before, which had incorrect
code in them that previous versions of gcc would accept.  With the
move to 2.4, this issue is gone.

From owner-linux-xfs@oss.sgi.com Thu May  3 08:26:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43FQZJ01521
	for linux-xfs-outgoing; Thu, 3 May 2001 08:26:35 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43FQYF01511
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:26:34 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 3 May 2001 15:26:34 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001050309224801:148512 ;
          Thu, 3 May 2001 09:22:48 -0600 
Received: from amis.com ([172.16.17.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001050309262973:13860 ;
          Thu, 3 May 2001 09:26:29 -0600 
Message-ID: <3AF1788F.6F12BD53@amis.com>
Date: Thu, 03 May 2001 09:26:07 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: Mark Hounschell <dmarkh@cfl.rr.com>, utz lehmann <xfs@s2y4n2c.de>,
   linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <20010502203454.A9561@s2y4n2c.de> <3AF137CB.5DE970F6@cfl.rr.com> <20010503125844.C28596@gruyere.muc.suse.de>
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/03/2001
 09:26:29 AM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/03/2001
 09:26:29 AM,
	Serialize complete at 05/03/2001 09:26:30 AM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/03/2001
 09:26:30 AM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/03/2001
 09:22:48 AM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/03/2001
 09:22:50 AM,
	Serialize complete at 05/03/2001 09:22:50 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm trying the 2.95.3. I'll recompile the kernel with 2.95.3 -- do I
need to recompile the tools as well? I'll do it, but I'm curious where
the longlong stuff really comes into play. 

eric




Andi Kleen wrote:
> 
> On Thu, May 03, 2001 at 06:49:47AM -0400, Mark Hounschell wrote:
> > I've heard rumors on the SuSE-e list that the lastest stable release
> > 2.95.3 works
> > ok woth XFS. Haven't tried it yet. Get SuSE's rpm and try it first.
> 
> The latest XFS tree has some workaround for known 2.95 long long bugs (mainly
> division) and they seem to work somehow; but nobody knows if that really
> catched all cases or if there isn't miscompilation in more obscure code
> paths left. XFS is full of long long computation (you wanted a "64bit
> filesystem", didn't you?). Using egcs 1.1 is definitely safer, with it
> XFS has been tested a lot more.  You could also use XFS on a 64bit
> architecture like an Alpha.
> 
> -Andi

-- 
__________________________________________________________________
Eric T. Whiting					AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Thu May  3 08:30:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43FUNi02909
	for linux-xfs-outgoing; Thu, 3 May 2001 08:30:23 -0700
Received: from mail.compro.net (cpe-66-1-218-52.fl.sprintbbd.net [66.1.218.52])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43FUIF02879
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:30:22 -0700
Received: from compro.net ([10.10.10.120])
	by mail.compro.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA28874;
	Thu, 3 May 2001 11:29:09 -0500
X-Authentication-Warning: mail.compro.net: Host [10.10.10.120] claimed to be compro.net
Message-ID: <3AF179A8.6B772999@compro.net>
Date: Thu, 03 May 2001 11:30:49 -0400
From: Mark Hounschell <markh@compro.net>
Reply-To: markh@compro.net
Organization: Compro Computer Svcs.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Gerald Henriksen <ghenriks@home.com>
CC: Keith Owens <kaos@melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
References: <988893685.6072.1.camel@adslgw> <17303.988894661@ocs3.ocs-net> <vfs2ft42cm5v49grp8gtt5ksorj2tdu64h@4ax.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Gerald Henriksen wrote:
> 
> On Thu, 03 May 2001 22:57:41 +1000, you wrote:
> 
> >On 03 May 2001 14:41:22 +0200,
> >"redhat.angus" <redhat.angus@wanadoo.fr> wrote:
> >>> egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.
> >>
> >>Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
> >>compile kernel-2.4-xfs.
> >
> >gcc 2.96 is not an official release, it is a RedHat special.  2.96 does
> >not correctly compile the kernel, even without XFS.
> 
> I am sure that this will come as a surprise to Red Hat, who are
> shipping Red Hat 7.1 with a kernel compiled with gcc 2.96
> 
> The kernel issue was with kernels 2.2 and before, which had incorrect
> code in them that previous versions of gcc would accept.  With the
> move to 2.4, this issue is gone.


See http://www.gnu.org/software/gcc/gcc-2.96.html. So why would ANYBODY
use 2.96?

From owner-linux-xfs@oss.sgi.com Thu May  3 08:32:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43FWoc03758
	for linux-xfs-outgoing; Thu, 3 May 2001 08:32:50 -0700
Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43FWmF03745
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:32:48 -0700
Received: from vador.mandrakesoft.com (anakin.mandrakesoft.com [192.168.1.4])
	by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id RAA23247;
	Thu, 3 May 2001 17:32:46 +0200
To: Austin Gonyou <austin@coremetrics.com>
Cc: Alan Eldridge <alane@geeksrus.net>, <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
X-URL: <http://www.linux-mandrake.com/
Organization: MandrakeSoft
From: Thierry Vignaud <tvignaud@mandrakesoft.com>
Date: 03 May 2001 17:41:46 +0200
In-Reply-To: <Pine.LNX.4.33.0105021102050.10052-100000@UberGeek.coremetrics.com>
Message-ID: <m17kzyjv7p.fsf@vador.mandrakesoft.com>
Lines: 13
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou <austin@coremetrics.com> writes:

> Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?

if you look at it:

[tv]$ rpm -qpi devfsd-2.4.2-0.1.28.i386.rpm
Name        : devfsd                       Relocations: (not relocateable)
Version     : 2.4.2                             Vendor: Red Hat, Inc.
Release     : 0.1.28                        Build Date: Tue Mar 13 22:00:42 2001
Install date: (not installed)               Build Host: porky.devel.redhat.com
Group       : System Environment/Kernel     Source RPM: kernel-2.4.2-0.1.28.src.rpm
                                                               /////\\\\


From owner-linux-xfs@oss.sgi.com Thu May  3 08:48:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Fm7b04658
	for linux-xfs-outgoing; Thu, 3 May 2001 08:48:07 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Fm6F04655
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:48:06 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43FlcR20439;
	Thu, 3 May 2001 10:47:38 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 10:47:37 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Thierry Vignaud <tvignaud@mandrakesoft.com>
cc: Alan Eldridge <alane@geeksrus.net>, <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
In-Reply-To: <m17kzyjv7p.fsf@vador.mandrakesoft.com>
Message-ID: <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

How easy would it be to just patch a 2.4.4 kernel and NOT use devfsd. I'm
having too many problems to actually spend as much time as I'll have to to
fix it. I DO want to spend the time, but I don't have the time to spend
right now. Ideas?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 3 May 2001, Thierry Vignaud wrote:

> Austin Gonyou <austin@coremetrics.com> writes:
>
> > Is it possible to update devfsd to 2.x, the one that comes with RH 7.1?
>
> if you look at it:
>
> [tv]$ rpm -qpi devfsd-2.4.2-0.1.28.i386.rpm
> Name        : devfsd                       Relocations: (not relocateable)
> Version     : 2.4.2                             Vendor: Red Hat, Inc.
> Release     : 0.1.28                        Build Date: Tue Mar 13 22:00:42 2001
> Install date: (not installed)               Build Host: porky.devel.redhat.com
> Group       : System Environment/Kernel     Source RPM: kernel-2.4.2-0.1.28.src.rpm
>                                                                /////\\\\
>


From owner-linux-xfs@oss.sgi.com Thu May  3 08:48:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43FmJ904676
	for linux-xfs-outgoing; Thu, 3 May 2001 08:48:19 -0700
Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43FmHF04671
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:48:17 -0700
Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com)
	by moving-picture.com with esmtp (Exim 3.16 #1)
	id 14vLKM-0004DQ-00; Thu, 03 May 2001 16:47:38 +0100
Message-ID: <3AF17D9A.D9B648A4@moving-picture.com>
Date: Thu, 03 May 2001 16:47:38 +0100
From: James Pearson <james-p@moving-picture.com>
Organization: Moving Picture Company
X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
References: <3AF16D0A.2D12C344@moving-picture.com> <20010503170018.A31942@sith.mimuw.edu.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jan Rekorajski wrote:
> 
> On Thu, 03 May 2001, James Pearson wrote:
> 
> > I've just installed RedHat 7.1/XFS1.0 on a Athlon based system and I'm
> > trying to get quotas working - so far without success.
> >
> > I've made a XFS file system and mounted it with -o quota and tried to
> > follow the instructions in the quotaon man page and
> > /usr/share/doc/xfsprogs/README.quota but get the following:
> >
> > # rpm -q quota
> > quota-3.01-SGI_5
> >
> > # uname -r
> > 2.4.2-SGI_XFS_1.0
> >
> > # mount | grep quota
> > /dev/hda4 on /disk1 type xfs (rw,quota)
> >
> > # setquota james 600 800 15 20 /disk1
> > Not all specified mountpoints are using quota.
> >
> > # repquota /disk1
> > Not all specified mountpoints are using quota.
> >
> > # edquota james
> > No filesystems with quota detected.
> >
> > I've also recompiled the kernel with CONFIG_QUOTA=y and
> > CONFIG_XFS_QUOTA=y just in case the supplied kernel didn't have quotas
> > enabled - but with the same results.
> >
> > Is there anything else I need to do?
> 
> I had the same problem. It may be the effect of misplaced patch.
> 
> Look in the fs/dquot.c file somewhere around line 1450,
> and move the following after the if (special != NULL...) statement:
> 
>         if (sb && sb->s_op && sb->s_op->quotactl) {
>                 unlock_kernel();
>                 return sb->s_op->quotactl(sb, cmds, type, id, addr);
>         }
> 
>         if (id & ~0xFFFF)
>                 goto out;
> 
> I don't know why, but it happened.
> 

Not quite sure what needs to be moved where - there's nothing like that
around line 1450, but at around line 2050 there is:

        dev = NODEV;
        if (special != NULL || (cmds != Q_SYNC && cmds != Q_GETSTATS)) {
                mode_t mode;
                struct nameidata nd;

                ret = user_path_walk(special, &nd);
                if (ret)
                        goto out;

                dev = nd.dentry->d_inode->i_rdev;
                mode = nd.dentry->d_inode->i_mode;
                path_release(&nd);

                ret = -ENOTBLK;
                if (!S_ISBLK(mode))
                        goto out;
                ret = -ENODEV;
                sb = get_super(dev);
                if (!sb)
                        goto out;
        }

        if (sb && sb->s_op && sb->s_op->quotactl) {
                unlock_kernel();
                return sb->s_op->quotactl(sb, cmds, type, id, addr);
        }

        if (id & ~0xFFFF)
                goto out;

        ret = -EINVAL;


What needs to be changed?

Thanks

James Pearson

From owner-linux-xfs@oss.sgi.com Thu May  3 08:54:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Fs7704827
	for linux-xfs-outgoing; Thu, 3 May 2001 08:54:07 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Fs6F04824
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 08:54:06 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f43FrwL28945;
	Thu, 3 May 2001 10:53:59 -0500 (CDT)
Message-ID: <3AF17F70.B1895FAD@sgi.com>
Date: Thu, 03 May 2001 10:55:28 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> How easy would it be to just patch a 2.4.4 kernel and NOT use devfsd. I'm
> having too many problems to actually spend as much time as I'll have to to
> fix it. I DO want to spend the time, but I don't have the time to spend
> right now. Ideas?

To get rid of devfsd, just turn it off in the kernel config, or pass
"devfsd=nomount" on the lilo command line.

Also, please remember that 2.4.4 is not yet well tested at all...

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 09:08:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43G8J205217
	for linux-xfs-outgoing; Thu, 3 May 2001 09:08:19 -0700
Received: from ci982177-a.sptnbrg1.sc.home.com (root@ci982177-a.sptnbrg1.sc.home.com [24.21.244.18])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43G8IF05214
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 09:08:18 -0700
Received: from home.com (walkerb@stan.house.org [10.0.1.2])
	by ci982177-a.sptnbrg1.sc.home.com (8.9.3/8.9.3) with ESMTP id KAA07950
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:59:43 -0400
Message-ID: <3AF18119.1030704@home.com>
Date: Thu, 03 May 2001 12:02:33 -0400
From: Brian Walker <walkerbm@home.com>
Organization: Cable Communists
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4 i686; en-US; 0.8.1) Gecko/20010326
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: xfs compile problem
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm running Redhat 7.1 and I wanted to recompile my kernel. I'm using 
the stock 2.4.2 kernel with XFS support installed by the XFS iso image 
and the redhat 7.1 iso images. I am getting the following when doing a 
make bzImage:

ld -m elf_i386 -Ttext 0x0 -s --oformat binary -e begtext -o bsetup bsetup.o
bsetup.o: In function `start_of_setup':
bsetup.o(.text+0x43e): undefined reference to `SIG1'
bsetup.o(.text+0x446): undefined reference to `SIG2'
bsetup.o: In function `bad_sig':
bsetup.o(.text+0x4c6): undefined reference to `SIG1'
bsetup.o(.text+0x4ce): undefined reference to `SIG2'
bsetup.o: In function `meme820':
bsetup.o(.text+0x528): undefined reference to `E820MAP'
bsetup.o: In function `jmpe820':
bsetup.o(.text+0x532): undefined reference to `SMAP'
bsetup.o(.text+0x544): undefined reference to `SMAP'
bsetup.o: In function `good820':
bsetup.o(.text+0x54e): undefined reference to `E820MAX'
make[1]: *** [bsetup] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.2/arch/i386/boot'
make: *** [bzImage] Error 2 


Any ideas? Thanks!

Brian


From owner-linux-xfs@oss.sgi.com Thu May  3 09:15:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43GFaW05500
	for linux-xfs-outgoing; Thu, 3 May 2001 09:15:36 -0700
Received: from office.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43GFXF05497
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 09:15:33 -0700
Received: from vador.mandrakesoft.com (anakin.mandrakesoft.com [192.168.1.4])
	by office.mandrakesoft.com (8.9.3/8.9.3) with ESMTP id SAA23899;
	Thu, 3 May 2001 18:15:32 +0200
To: Austin Gonyou <austin@coremetrics.com>
Cc: Alan Eldridge <alane@geeksrus.net>, <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
References: <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>
X-URL: <http://www.linux-mandrake.com/
Organization: MandrakeSoft
From: Thierry Vignaud <tvignaud@mandrakesoft.com>
Date: 03 May 2001 18:24:32 +0200
In-Reply-To: <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>
Message-ID: <m13damjt8f.fsf@vador.mandrakesoft.com>
Lines: 8
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou <austin@coremetrics.com> writes:

> How easy would it be to just patch a 2.4.4 kernel and NOT use devfsd. I'm
> having too many problems to actually spend as much time as I'll have to to
> fix it. I DO want to spend the time, but I don't have the time to spend
> right now. Ideas?

devfs=noboot on kernel cmdline


From owner-linux-xfs@oss.sgi.com Thu May  3 10:11:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HBJB08524
	for linux-xfs-outgoing; Thu, 3 May 2001 10:11:19 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HBHF08520
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:11:17 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA08409
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:21:57 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA32354; Thu, 3 May 2001 12:09:57 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43H8tq08838;
	Thu, 3 May 2001 13:08:56 -0400
Message-ID: <3AF190A6.2EC95E44@thebarn.com>
Date: Thu, 03 May 2001 13:08:54 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mogens Kjaer <mk@crc.dk>
CC: linux-xfs@oss.sgi.com
Subject: Re: NFS problems
References: <3AF1325D.9B68F5C9@kscanners.com> <3AF143AF.8D7C94C0@crc.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mogens Kjaer wrote:

> Toralf Lund wrote:
> ...
> >      http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=36897
>
> I have a private theory on, why Trond's patch isn't included
> in the kernel:
>
> The kernel people claims that it is a glibc bug.
> The glibc people claims that it is a kernel bug.
> Everybody says it's an SGI bug.

That sums it up pretty well.

The XFS projects goals it to provide the  XFS  file system, not to
become an integration test bed. (some might argue that point since
we enabled devfs,  but that's a different issue ;-)

SGI has a team/project for doing integration/value add called LBS
Linux Base System formally know as ProPack.
I'm not sure if the nfs  dir patch is part of the BLT at this point
but I would be a good candidate.

this is a bit out of date but...
http://www.sgi.com/software/linux/propack/



> p
>
> :-)
>
> Mogens
> --
> Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
> Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
> Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
> Email: mk@crc.dk Homepage: http://www.crc.dk

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 10:19:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HJoK08989
	for linux-xfs-outgoing; Thu, 3 May 2001 10:19:50 -0700
Received: from femail4.rdc1.on.home.com (femail4.rdc1.on.home.com [24.2.9.91])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HJmF08983
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:19:48 -0700
Received: from cr598116-a.wlfdle1.on.wave.home.com ([24.112.74.120])
          by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010503172049.DJPE718.femail4.rdc1.on.home.com@cr598116-a.wlfdle1.on.wave.home.com>
          for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:20:49 -0700
From: Gerald Henriksen <ghenriks@home.com>
To: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
Date: Thu, 03 May 2001 13:20:42 -0400
Message-ID: <do33ft85udhii2r0phnkosa2upruvl4keh@4ax.com>
References: <988893685.6072.1.camel@adslgw> <17303.988894661@ocs3.ocs-net> <vfs2ft42cm5v49grp8gtt5ksorj2tdu64h@4ax.com> <3AF179A8.6B772999@compro.net>
In-Reply-To: <3AF179A8.6B772999@compro.net>
X-Mailer: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f43HJmF08984
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 03 May 2001 11:30:49 -0400, you wrote:

>See http://www.gnu.org/software/gcc/gcc-2.96.html. So why would ANYBODY
>use 2.96?

That statement is merely warning people that the official gcc people
don't support 2.96, nothing more.

Simply, you use 2.96 if you want:

 - the best ISO C and ISO C++ standards conformance currently
available on Linux from the gcc family

 - the advantages of all the improvements in code generation that have
happened since egcs.  In particular, Intel paid for a new code
generation backend that first appeared in the 2.95 series.

 - it is a stable compiler.  A search through the Red Hat bugzilla
entries shows that most complaints about 2.96 are actually
non-standards compliant code.  Also, several distributions now ship
with either 2.95 or 2.96, with no problems.

 - far better non-IA32 support (one of the reasons Red Hat created
2.96 was so that they could use one version of the compiler on all the
platforms they support).

The bigger question is why would anyone with a 2.4 based kernel still
be using any of the egcs releases.

From owner-linux-xfs@oss.sgi.com Thu May  3 10:22:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HMht09267
	for linux-xfs-outgoing; Thu, 3 May 2001 10:22:43 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HMeF09261
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:22:40 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA04149
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:21:19 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA38904 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:26:14 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 5D44BCED7A
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 10:21:24 -0700 (PDT)
Subject: Re: NFS problems
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <3AF13971.C7E78689@crc.dk>
References: <3AF1325D.9B68F5C9@kscanners.com>  <3AF13971.C7E78689@crc.dk>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 10:21:24 -0700
Message-Id: <988910484.23682.3.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 03 May 2001 12:56:49 +0200, Mogens Kjaer wrote:
> 
> BTW[2], I couldn't do a graphical installation on an intel 815
> based machine, X won't start. Have some modules been taken
> out of the boot image (i.e. agpgart) in order to make room for xfs?

I didn't do a graphical install on i815, but a text one. Anyway, when it
came to probing X, it refused to work. So, it's the same problem.

I had to delay the X configuration, and do it after the system booted up
for the first time.

-- 
Florin Andrei

"Bloat is not about being big. Bloat is about being slow and stupid and not
realizing that it's because of design mistakes." - Linus Torvalds


From owner-linux-xfs@oss.sgi.com Thu May  3 10:32:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HWJT10083
	for linux-xfs-outgoing; Thu, 3 May 2001 10:32:19 -0700
Received: from gatekeeper.tripos.com (firewall-user@gatekeeper.tripos.com [192.160.145.62])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HWHF10078
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:32:18 -0700
Received: (from uucp@localhost) by tripos.com (8.8.8+Sun) id MAA09531 for <@firewall.tripos.com:linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:32:12 -0500 (CDT)
Received: from elara.tripos.com(172.20.5.15) by gatekeeper.tripos.com via smap (V5.5)
	id xma009470; Thu, 3 May 01 12:22:28 -0500
Received: from umbriel (umbriel [172.20.5.155]) by tripos.com (980919.SGI.STAND) via SMTP id MAA70238 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:22:27 -0500 (CDT)
From: "Jerry Wintrode" <wintrojr@tripos.com>
To: <linux-xfs@oss.sgi.com>
Subject: After installation X fails.
Date: Thu, 3 May 2001 12:22:27 -0500
Message-ID: <NEBBLOGEHMKPCBLKJNKMOEENCLAA.wintrojr@tripos.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


After installation X windows starts but will not clear screen, it just keeps
putting windows on top of old windows.

I have

Intel XEON Quad 500MHZ
1 Gig of ram
GD5480 video
MS intellimouse

I have already upgraded the Xconfig and mouseconfig rpms per RedHat bug
list.

Thanks

Jerry Wintrode
Tripos, Inc.



From owner-linux-xfs@oss.sgi.com Thu May  3 10:34:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HYXQ10180
	for linux-xfs-outgoing; Thu, 3 May 2001 10:34:33 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HYKF10168
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:34:20 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA765265
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 19:34:14 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA31347; Thu, 3 May 2001 12:32:58 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43HVuq10719;
	Thu, 3 May 2001 13:31:56 -0400
Message-ID: <3AF1960A.E3F927C6@thebarn.com>
Date: Thu, 03 May 2001 13:31:54 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: James Pearson <james-p@moving-picture.com>
CC: Jan Rekorajski <baggins@sith.mimuw.edu.pl>, linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
References: <3AF16D0A.2D12C344@moving-picture.com> <20010503170018.A31942@sith.mimuw.edu.pl> <3AF17D9A.D9B648A4@moving-picture.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I'n not quite spotting the problem either... could you send  the diff?

I'm not very familiar with the quota code...
Nathan  can you see a problem in the dquot.c stuff referenced below?


> Jan Rekorajski wrote:
> >
> > On Thu, 03 May 2001, James Pearson wrote:
> >
> > > I've just installed RedHat 7.1/XFS1.0 on a Athlon based system and I'm
> > > trying to get quotas working - so far without success.
> > >
> > > I've made a XFS file system and mounted it with -o quota and tried to
> > > follow the instructions in the quotaon man page and
> > > /usr/share/doc/xfsprogs/README.quota but get the following:
> > >
> > > # rpm -q quota
> > > quota-3.01-SGI_5
> > >
> > > # uname -r
> > > 2.4.2-SGI_XFS_1.0
> > >
> > > # mount | grep quota
> > > /dev/hda4 on /disk1 type xfs (rw,quota)
> > >
> > > # setquota james 600 800 15 20 /disk1
> > > Not all specified mountpoints are using quota.
> > >
> > > # repquota /disk1
> > > Not all specified mountpoints are using quota.
> > >
> > > # edquota james
> > > No filesystems with quota detected.
> > >
> > > I've also recompiled the kernel with CONFIG_QUOTA=y and
> > > CONFIG_XFS_QUOTA=y just in case the supplied kernel didn't have quotas
> > > enabled - but with the same results.
> > >
> > > Is there anything else I need to do?
> >
> > I had the same problem. It may be the effect of misplaced patch.
> >
> > Look in the fs/dquot.c file somewhere around line 1450,
> > and move the following after the if (special != NULL...) statement:
> >
> >         if (sb && sb->s_op && sb->s_op->quotactl) {
> >                 unlock_kernel();
> >                 return sb->s_op->quotactl(sb, cmds, type, id, addr);
> >         }
> >
> >         if (id & ~0xFFFF)
> >                 goto out;
> >
> > I don't know why, but it happened.
> >
>
> Not quite sure what needs to be moved where - there's nothing like that
> around line 1450, but at around line 2050 there is:
>
>         dev = NODEV;
>         if (special != NULL || (cmds != Q_SYNC && cmds != Q_GETSTATS)) {
>                 mode_t mode;
>                 struct nameidata nd;
>
>                 ret = user_path_walk(special, &nd);
>                 if (ret)
>                         goto out;
>
>                 dev = nd.dentry->d_inode->i_rdev;
>                 mode = nd.dentry->d_inode->i_mode;
>                 path_release(&nd);
>
>                 ret = -ENOTBLK;
>                 if (!S_ISBLK(mode))
>                         goto out;
>                 ret = -ENODEV;
>                 sb = get_super(dev);
>                 if (!sb)
>                         goto out;
>         }
>
>         if (sb && sb->s_op && sb->s_op->quotactl) {
>                 unlock_kernel();
>                 return sb->s_op->quotactl(sb, cmds, type, id, addr);
>         }
>
>         if (id & ~0xFFFF)
>                 goto out;
>
>         ret = -EINVAL;
>
> What needs to be changed?
>
> Thanks
>
> James Pearson

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 10:36:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HaCk10252
	for linux-xfs-outgoing; Thu, 3 May 2001 10:36:12 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43HaBF10249
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:36:11 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 3 May 2001 17:36:11 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001050311322022:149613 ;
          Thu, 3 May 2001 11:32:20 -0600 
Received: from amis.com ([172.16.17.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001050311355875:13984 ;
          Thu, 3 May 2001 11:35:58 -0600 
Message-ID: <3AF196E9.3235BBFD@amis.com>
Date: Thu, 03 May 2001 11:35:37 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: Mark Hounschell <dmarkh@cfl.rr.com>, utz lehmann <xfs@s2y4n2c.de>,
   linux-xfs@oss.sgi.com
Subject: Re: 2.4.4-xfs NFS testing
References: <3AF0468B.70E8B919@amis.com> <20010502195501.A13116@gruyere.muc.suse.de> <20010502203454.A9561@s2y4n2c.de> <3AF137CB.5DE970F6@cfl.rr.com> <20010503125844.C28596@gruyere.muc.suse.de>
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/03/2001
 11:35:58 AM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/03/2001
 11:36:00 AM,
	Serialize complete at 05/03/2001 11:36:00 AM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/03/2001
 11:32:20 AM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/03/2001
 11:32:26 AM,
	Serialize complete at 05/03/2001 11:32:26 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I tried:
2.4.4-xfs NFS 
kernel compiled with 2.95.3 

Results:
still had severe lockup under heavy nfs loading from solaris boxes.

I'll try to get more debug info -- as well as rule out some other
issues. I read about 2.4.4 problems -- maybe I should go back to
2.4.2-xfs?

eric


Andi Kleen wrote:
> 
> On Thu, May 03, 2001 at 06:49:47AM -0400, Mark Hounschell wrote:
> > I've heard rumors on the SuSE-e list that the lastest stable release
> > 2.95.3 works
> > ok woth XFS. Haven't tried it yet. Get SuSE's rpm and try it first.
> 
> The latest XFS tree has some workaround for known 2.95 long long bugs (mainly
> division) and they seem to work somehow; but nobody knows if that really
> catched all cases or if there isn't miscompilation in more obscure code
> paths left. XFS is full of long long computation (you wanted a "64bit
> filesystem", didn't you?). Using egcs 1.1 is definitely safer, with it
> XFS has been tested a lot more.  You could also use XFS on a 64bit
> architecture like an Alpha.
> 
> -Andi

-- 
__________________________________________________________________
Eric T. Whiting					AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Thu May  3 10:42:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43HgZM10591
	for linux-xfs-outgoing; Thu, 3 May 2001 10:42:35 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HgYF10587
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:42:34 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA07739
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:41:12 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA57010;
	Thu, 3 May 2001 10:41:16 -0700 (PDT)
Date: Thu, 3 May 2001 10:40:59 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Mogens Kjaer <mk@crc.dk>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: NFS problems
In-Reply-To: <3AF143AF.8D7C94C0@crc.dk>
Message-ID: <Pine.LNX.4.30.0105031039240.25517-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 3 May 2001, Mogens Kjaer wrote:

> The kernel people claims that it is a glibc bug.
> The glibc people claims that it is a kernel bug.
> Everybody says it's an SGI bug.

this is scheduled to be fixed in IRIX 6.5.13 (I think), but there are
going to be a lot of people out there with older versions of IRIX...

And as Russell pointed out, this is fixed in the integrated LBS kernel.

-tduffy


From owner-linux-xfs@oss.sgi.com Thu May  3 10:47:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Hlr011036
	for linux-xfs-outgoing; Thu, 3 May 2001 10:47:53 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43HlqF11033
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 10:47:52 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f43Hlq420621;
	Thu, 3 May 2001 12:47:52 -0500 (CDT)
Message-ID: <3AF19A22.4D39722E@sgi.com>
Date: Thu, 03 May 2001 12:49:22 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Walker <walkerbm@home.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs compile problem
References: <3AF18119.1030704@home.com> <3AF1870E.8F7CEC29@sgi.com> <3AF19720.7030905@home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Try installing the kgcc package, which is an alias for an older, but
more kernel-compatible gcc.  Then edit the Makefile to use kgcc
(comments in the Makefile explain how to do this).

"2.96" has some issues with our kernel - or maybe it's the other way
around...

We're moving towards better compiler-independence, but for now, use
kgcc.

-Eric


Brian Walker wrote:
> 
> Eric,
> 
> Thanks for the quick reply! I've got the redhat 7.1 default compiler
> which is gcc 2.96. Should I be using something different?
> 
> Brian
>
> Eric Sandeen wrote:
>
>  >What compiler are you using?

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 11:37:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Ibor13106
	for linux-xfs-outgoing; Thu, 3 May 2001 11:37:50 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43IboF13103
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:37:50 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA02580
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:37:46 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA06448 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:36:30 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43IZTq13310
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:35:29 -0400
Message-ID: <3AF1A4EF.EE82780F@thebarn.com>
Date: Thu, 03 May 2001 14:35:27 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
References: <Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm sure this compiler issue won't go away soon.

But just as an overview of what is working and what isn't

XFS Release 1.0:

     gcc 2.91.66  well tested know to work, use this for stability

    gcc 2.95.2/3/4 reported to work, not extensively tested, use as own risk

    gcc 2.96     does not work, gives compilation errors.

    gcc 2.95RH7.1    ditto.

    gcc 2.96Mandrake Not attempted yet.

XFS current:
    gcc 2.91.66    same as R 1.0

    gcc 2.95.2/3/4    same as R 1.0

    gcc 2.96        does not work, compilation errors

    gcc 2.96RH7.1    compiles, boots, and initial tests show it to be working

    gcc 2.96Mandrake    compiles, boots, and initial tests show it to be working

As always there is a big difference between what is "supported" and what "works".

We are saying R 1.0 is supported (in the loose sense of Open Source supported)

by compiling with gcc 2.91.66, everything else is "use at your own risk" at this

point.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 11:46:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Ik5V13311
	for linux-xfs-outgoing; Thu, 3 May 2001 11:46:05 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43IjxF13308
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:46:00 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA09737
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:45:58 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA72896; Thu, 3 May 2001 13:44:41 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43Iheq13352;
	Thu, 3 May 2001 14:43:40 -0400
Message-ID: <3AF1A6DC.67C1CA2F@thebarn.com>
Date: Thu, 03 May 2001 14:43:40 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chmouel Boudjnah <chmouel@mandrakesoft.com>
CC: Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
		<m3bspbwotj.fsf@giants.mandrakesoft.com>
		<3AF0A70D.C5CE4733@thebarn.com> <m37kzyrhj1.fsf@giants.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chmouel Boudjnah wrote:

> Russell Cattelan <cattelan@thebarn.com> writes:
>
> > Yes please.
>
> Ok they are ready :
>
> ftp://ftp.sunet.se/pub/Linux/distributions/mandrake-devel/contrib/RPMS/

If you don't mind, I'll will put this link in our "news" segment on our
web page?

>
> > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > yet but it does compile.
> > Anybody want help finish it.?
>
> Could you send me the patch, i had a lot of conflict and i did the
> kernel-xfs on a vanilla 2.4.4 generated patch from cvs.

ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch

this was a real quick attempt to get it to compile, area that are suspect
and may not be right :
dquot.c
and  param addition  to do_mount_nd
probably a better way to go about  getting the dir name to the dmapi
mount,
or even look at the code closer and move the dmapi stuff back into
do_mount.

>
> > If fact I would to encourage some savvy installer programmer to add
> > XFS support to the mandrake installer. I've looked at the code and
> > see reiserfs is already in there shouldn't be to much work to add
> > xfs.
>
> I already begin it, it should be fairly simple...

Great let us know if you have any questions, obviously we had to struggle
with a few problems  on anaconda.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 11:55:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43ItLi13587
	for linux-xfs-outgoing; Thu, 3 May 2001 11:55:21 -0700
Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43ItJF13584
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 11:55:19 -0700
Received: from apal-192.ii.uib.no (apal.ii.uib.no) [129.177.192.27] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 14vOG5-0000VH-00 ; Thu, 03 May 2001 20:55:25 +0200
Received: (from janfrode@localhost)
	by apal.ii.uib.no (8.9.3+Sun/8.9.3) id UAA01890;
	Thu, 3 May 2001 20:55:17 +0200 (MEST)
Date: Thu, 3 May 2001 20:55:16 +0200
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: Austin Gonyou <austin@coremetrics.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: devfsd-1.3.11-1
Message-ID: <20010503205516.A633@ii.uib.no>
References: <m17kzyjv7p.fsf@vador.mandrakesoft.com> <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0105031046420.19882-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Thu, May 03, 2001 at 10:47:37AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 03, 2001 at 10:47:37AM -0500, Austin Gonyou wrote:
> How easy would it be to just patch a 2.4.4 kernel and NOT use devfsd. 

[ Assuming you really meant devfsd and not devfs ]

No problem at all. Just remove / comment out the devfsd lines from
rc.sysinit or equivalent. Then you will get a clean /dev/ containing 
only the real devices, like this:

%  ls -l /dev
totalt 0
crw-------    1 janfrode root       5,   1 apr 24 19:08 console
drwxr-xr-x    1 root     root            0 jan  1  1970 cpu
drwxr-xr-x    1 root     root            0 jan  1  1970 cua
drwxr-xr-x    1 root     root            0 jan  1  1970 discs
drwxr-xr-x    1 root     root            0 apr 24 19:08 dri
crw-rw-rw-    1 root     root       1,   7 jan  1  1970 full
drwxr-xr-x    1 root     root            0 jan  1  1970 ide
prw-------    1 root     root            0 apr 24 21:05 initctl
crw-r-----    1 root     root       1,   2 jan  1  1970 kmem
srw-rw-rw-    0 root     root            0 apr 24 21:05 log
crw-r-----    1 root     root       1,   1 jan  1  1970 mem
drwxr-xr-x    1 root     root            0 jan  1  1970 misc
crw-rw-rw-    1 root     root       1,   3 jan  1  1970 null
crw-r-----    1 root     root       1,   4 jan  1  1970 port
crw-------    1 root     root     108,   0 jan  1  1970 ppp
drwxr-xr-x    1 root     root            0 jan  1  1970 printers
crw-rw-rw-    1 root     root       5,   2 mai  3 19:47 ptmx
drwxr-xr-x    1 root     root            0 jan  1  1970 pts
drwxr-xr-x    1 root     root            0 jan  1  1970 pty
crw-r--r--    1 root     root       1,   8 jan  1  1970 random
drwxr-xr-x    1 root     root            0 jan  1  1970 scsi
drwxrwxrwt    1 root     root            0 apr 24 19:08 shm
drwxr-xr-x    1 root     root            0 jan  1  1970 sound
drwxr-xr-x    1 root     root            0 jan  1  1970 tts
crw-rw-rw-    1 root     root       5,   0 mai  2 16:16 tty
crw-r--r--    1 root     root       1,   9 jan  1  1970 urandom
drwxr-xr-x    1 root     root            0 jan  1  1970 vc
drwxr-xr-x    1 root     root            0 jan  1  1970 vcc
crw-rw-rw-    1 root     root       1,   5 jan  1  1970 zero

I use devfs without devfsd, and manually create the few links (dsp, sg0)
I need for applications that don't understand the new naming.



  -jf

From owner-linux-xfs@oss.sgi.com Thu May  3 12:17:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JHcP14221
	for linux-xfs-outgoing; Thu, 3 May 2001 12:17:38 -0700
Received: from skif.spylog.net (skif.spylog.com [194.67.35.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JHbF14215
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:17:38 -0700
Received: from mail.spylog.com (www.local [192.168.0.205])
	by skif.spylog.net (Postfix) with ESMTP id 4053D47C4
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 23:17:36 +0400 (MSD)
Received: from an.local (an.local [192.168.4.50])
	by mail.spylog.com (Postfix) with ESMTP id 3AF0E70F01
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 23:17:36 +0400 (MSD)
Received: by an.local (Postfix, from userid 501)
	id 5168950B6B; Thu,  3 May 2001 23:17:35 +0400 (MSD)
Date: Thu, 3 May 2001 23:17:35 +0400
From: Andrey Nekrasov <andy@spylog.com>
To: linux-xfs@oss.sgi.com
Subject: repquota bug?
Message-ID: <20010503231735.A1917@an.local>
Mail-Followup-To: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Organization: SpyLOG ltd.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hello,

1. quota-3.01-SGI_5
   kernel 2.4.3 + xfs patch + core patch (from SGI)
   egcs 1.1.2 (kgcc)


2. /dev/hda3 on /home type xfs (rw,usrquota)

3. 

andy@an /opt/in $ quota andy
Disk quotas for user andy (uid 501): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit grace
      /dev/hda3   95684  400000       0            5196       0       0        
andy@an /opt/in $

OK!

4.

andy@an /opt/in $ repquota |less
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User             used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
andy      --   95684  400000       0           5196     0     0       
andy      --   95684  400000       0           5196     0     0       
andy      --   95684  400000       0           5196     0     0       
andy      --   95684  400000       0           5196     0     0       
andy      --   95684  400000       0           5196     0     0       
andy      --   95684  400000       0           5196     0     0       
....
andy      --   95684  400000       0           5196     0     0
...
...
...

Why?

bye.
Andrey Nekrasov, SpyLOG.
http://www.spylog.com/

From owner-linux-xfs@oss.sgi.com Thu May  3 12:33:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JXVG14641
	for linux-xfs-outgoing; Thu, 3 May 2001 12:33:31 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JXTF14638
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:33:30 -0700
Received: from [195.20.224.208] (helo=mrvdom01.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14vOqu-0007Vr-00; Thu, 3 May 2001 21:33:28 +0200
Received: from pd901e31c.dip.t-dialin.net ([217.1.227.28] helo=kernelpanix.aura.of.mankind)
	by mrvdom01.schlund.de with esmtp (Exim 2.12 #2)
	id 14vOqm-0007pS-00; Thu, 3 May 2001 21:33:21 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f43Ir8G23268;
	Thu, 3 May 2001 20:53:08 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Thu, 3 May 2001 20:53:08 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: "redhat.angus" <redhat.angus@wanadoo.fr>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: strange files, XFS bug?
Message-ID: <20010503205308.A23197@s2y4n2c.de>
References: <20010503120435.A13673@ii.uib.no> <988889956.4975.0.camel@adslgw> <20010503140956.A14103@ii.uib.no> <20010503141440.C23836@tecosim.de> <988893685.6072.1.camel@adslgw>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <988893685.6072.1.camel@adslgw>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

redhat.angus [redhat.angus@wanadoo.fr] wrote:
> Le 03 May 2001 14:14:41 +0200, Utz Lehmann a écrit :
> > i had this using a bad compiler (gcc 2.96).
> > 
> > egcs-2.91.66 (= kgcc) is recomended. see the linux-xfs makefile.
> 
> Can somebody of SGI confirm ? That I do not use any more gcc-2.96RH to
> compile kernel-2.4-xfs.

here my own experience:

i had tried the redhat gcc-2.96-81 on redhat 7.0 a few days before.
the result was a crashing kernel and errors like yours. i went back to kgcc
everythings works without any problem.

even with non xfs 2.4.x kernel a had problems with the suse gcc 2.95.2.
using the redhat kgcc solved it.

egcs-2.91.66 (= kgcc) is rock solid for kernel compilation.

btw: i dont trust gcc 2.95.2 any more. on hp-ux sometimes it used the same
address for differnet variables. very hard to find the bug.


utz

From owner-linux-xfs@oss.sgi.com Thu May  3 12:33:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JXl014652
	for linux-xfs-outgoing; Thu, 3 May 2001 12:33:47 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JXkF14649
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:33:46 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14vOqu-0005kF-00; Fri, 04 May 2001 07:33:28 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Keith Owens" <kaos@melbourne.sgi.com>,
   "redhat.angus" <redhat.angus@wanadoo.fr>
Cc: "linux-xfs" <linux-xfs@oss.sgi.com>
Subject: RE: strange files, XFS bug? 
Date: Fri, 4 May 2001 07:32:57 +1200
Message-ID: <KPECIILENDDLPCNIMLOFIEGOCDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <17303.988894661@ocs3.ocs-net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: gcc 2.96 is not an official release, it is a RedHat special.  2.96 does
:: not correctly compile the kernel, even without XFS.

It has compiled the 2.4.x kernels just fine for me...

-- Juha

From owner-linux-xfs@oss.sgi.com Thu May  3 12:40:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JefZ14901
	for linux-xfs-outgoing; Thu, 3 May 2001 12:40:41 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JeeF14898
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:40:41 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43JbW529015;
	Thu, 3 May 2001 14:37:32 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 14:37:32 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Jan-Frode Myklebust <janfrode@parallab.uib.no>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: devfsd-1.3.11-1
In-Reply-To: <20010503205516.A633@ii.uib.no>
Message-ID: <Pine.LNX.4.33.0105031434570.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I should've been more specific. I was under the assumption that you
couldn't really use devfsd if devfs was not compiled into the kernel.
Sorry for the confusion. What I really want to do is patch a 2.4.4 kernel
to use XFS without using devfs. That part I don't think would be an issue,
and I understand all that's involved here. One thing I'd like to be able
to do though is to know how to properly patch a 2.4.4 kernel upto xfs.
Should I get a 2.4.2 kernel, patch it with xfs, then patch it up to 2.4.4?
Ideas?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Thu May  3 12:43:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Jhqj14982
	for linux-xfs-outgoing; Thu, 3 May 2001 12:43:52 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JhoF14979
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:43:50 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14vP0R-0005kq-00; Fri, 04 May 2001 07:43:19 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: <markh@compro.net>, "Gerald Henriksen" <ghenriks@home.com>
Cc: "Keith Owens" <kaos@melbourne.sgi.com>, <linux-xfs@oss.sgi.com>
Subject: RE: strange files, XFS bug?
Date: Fri, 4 May 2001 07:42:48 +1200
Message-ID: <KPECIILENDDLPCNIMLOFAEHACDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3AF179A8.6B772999@compro.net>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: See http://www.gnu.org/software/gcc/gcc-2.96.html. So why would ANYBODY
:: use 2.96?

You'll probably find that Red Hat's GCC 2.96 isn't the pukka GNU GCC 2.96. 

-- Juha

From owner-linux-xfs@oss.sgi.com Thu May  3 12:45:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JjuO15042
	for linux-xfs-outgoing; Thu, 3 May 2001 12:45:56 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JjtF15039
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:45:55 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43Jioh29066
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:44:51 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 14:44:50 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: New thread: Manually creating the 2.4.4 XFS tree
Message-ID: <Pine.LNX.4.33.0105031444100.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I should've been more specific. I was under the assumption that you
couldn't really use devfsd if devfs was not compiled into the kernel.
Sorry for the confusion. What I really want to do is patch a 2.4.4 kernel
to use XFS without using devfs. That part I don't think would be an issue,
and I understand all that's involved here. One thing I'd like to be able
to do though is to know how to properly patch a 2.4.4 kernel upto xfs.
Should I get a 2.4.2 kernel, patch it with xfs, then patch it up to 2.4.4?
Ideas?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Thu May  3 12:52:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Jqbj15172
	for linux-xfs-outgoing; Thu, 3 May 2001 12:52:37 -0700
Received: from marvin.linux-dude.com (c-cd8a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.205])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JqYF15169
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:52:35 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f43JqXm05026
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 21:52:33 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: linux-xfs@oss.sgi.com
Date: Thu, 3 May 2001 21:52:33 +0200
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01050321241200.04916@marvin>
Content-Transfer-Encoding: 8bit
Subject: Will xfs scale to > 1GB/s on any hardware?
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've seen that people repport 100 MB/s (sustained I hope) with
as few as 8 disks. Would XFS scale to > 1GB/s sustained and
is it known what could be the largest integrated deviation from
that streaming speed (to get the feeling for the size of buffer needed
to pick up the slack). Also, would I get this performance over
1-2 TB.
The application, as it is, allready uses several channels to get a
combined 1GB/s performance (roughly 10 channels) so esoteric
hardware is quite feasible in this case.
I know that we are talking about 100 disks here and maybe the
reliability of that system may not to high but so far I'm just
exploring the possibilities of alternative implementations.

Greetings,
Jarek

From owner-linux-xfs@oss.sgi.com Thu May  3 12:55:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JttD15279
	for linux-xfs-outgoing; Thu, 3 May 2001 12:55:55 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43JtrF15275
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:55:54 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43Jn4J29134;
	Thu, 3 May 2001 14:49:04 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 14:49:04 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Juha Saarinen <juha@saarinen.org>
cc: <markh@compro.net>, Gerald Henriksen <ghenriks@home.com>,
   Keith Owens <kaos@melbourne.sgi.com>, <linux-xfs@oss.sgi.com>
Subject: RE: strange files, XFS bug?
In-Reply-To: <KPECIILENDDLPCNIMLOFAEHACDAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.33.0105031448210.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

the newest gcc they have seems to be ok. I've been using RH7.0 since the
DAY it was released, and had plenty of headache, until they updated their
packages to 2.96. Ever since then, things have been good.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 4 May 2001, Juha Saarinen wrote:

> :: See http://www.gnu.org/software/gcc/gcc-2.96.html. So why would ANYBODY
> :: use 2.96?
>
> You'll probably find that Red Hat's GCC 2.96 isn't the pukka GNU GCC 2.96.
>
> -- Juha
>


From owner-linux-xfs@oss.sgi.com Thu May  3 12:58:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43JwAa15362
	for linux-xfs-outgoing; Thu, 3 May 2001 12:58:10 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Jw7F15356
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 12:58:08 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43Jvs129198;
	Thu, 3 May 2001 14:57:54 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 14:57:52 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Jarek Luberek <jarek@swipnet.se>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Will xfs scale to > 1GB/s on any hardware?
In-Reply-To: <01050321241200.04916@marvin>
Message-ID: <Pine.LNX.4.33.0105031455460.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>From what I've read is that you can get 1GB/s out of xfs, and possibly
greater. If this is true, then I'd suspect that it would be a good fibre
setup or possibly a LOT of scsi controllers and disks. Say 4-6 UW160
controllers  2 channels each and say 4-6 disks per channel. (Pure scsi) If
fibre, then you should be able to use say 4 Single port Fibre cards
attatched to enough disks, say 16 or so, to get a reasonable throughput
like you speak of.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 3 May 2001, Jarek Luberek wrote:

> Hi,
>
> I've seen that people repport 100 MB/s (sustained I hope) with
> as few as 8 disks. Would XFS scale to > 1GB/s sustained and
> is it known what could be the largest integrated deviation from
> that streaming speed (to get the feeling for the size of buffer needed
> to pick up the slack). Also, would I get this performance over
> 1-2 TB.
> The application, as it is, allready uses several channels to get a
> combined 1GB/s performance (roughly 10 channels) so esoteric
> hardware is quite feasible in this case.
> I know that we are talking about 100 disks here and maybe the
> reliability of that system may not to high but so far I'm just
> exploring the possibilities of alternative implementations.
>
> Greetings,
> Jarek
>


From owner-linux-xfs@oss.sgi.com Thu May  3 13:09:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43K9Zt15599
	for linux-xfs-outgoing; Thu, 3 May 2001 13:09:35 -0700
Received: from ns1.penguincomputing.com (server6.penguincomputing.com [209.24.233.110])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43K9YF15596
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:09:34 -0700
Received: from localhost (cregentin@localhost)
	by ns1.penguincomputing.com (8.9.3/8.9.3) with ESMTP id NAA00818
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:09:33 -0700
Date: Thu, 3 May 2001 13:09:33 -0700 (PDT)
From: Curtis Regentin <cregentin@penguincomputing.com>
To: <linux-xfs@oss.sgi.com>
Subject: Documentation suggestion
Message-ID: <Pine.LNX.4.30.0105031306250.31712-100000@ns1.penguincomputing.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

It might be worth mentioning LILO, and the boot partition somewhere in
the context of the filesystem reorganizer.  I haven't tried it, but I
can't imagine that it won't make the system unbootable due to LILO's block
mapping being wrong.

 - Curtis


From owner-linux-xfs@oss.sgi.com Thu May  3 13:12:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KCiL15637
	for linux-xfs-outgoing; Thu, 3 May 2001 13:12:44 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KChF15634
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:12:43 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f43KCWq11776;
	Thu, 3 May 2001 15:12:32 -0500
Message-Id: <4.2.0.58.20010503150531.015376f8@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 15:12:37 -0500
To: Jarek Luberek <jarek@swipnet.se>, linux-xfs@oss.sgi.com
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: Re: Will xfs scale to > 1GB/s on any hardware?
In-Reply-To: <01050321241200.04916@marvin>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 09:52 PM 5/3/2001 +0200, Jarek Luberek wrote:
>I've seen that people repport 100 MB/s (sustained I hope) with
>as few as 8 disks. Would XFS scale to > 1GB/s sustained and

If your talking about a PC then it will take a while before PC are fast enough
to do this.

Most PC can only do about 200MB/sec on a memory copy.  With the
newer memories 400MB/sec.  Memory is one bottle neck.

You also have a bottle on the PC buses that would limit the Maxim aerate
throw put.  The PC buses need to get faster.

100 MB/s is doable 200MB/s is possible.  It depends on how much money
you want to spend and how specialized  you want to get.


Bill Jones



From owner-linux-xfs@oss.sgi.com Thu May  3 13:23:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KNxl15838
	for linux-xfs-outgoing; Thu, 3 May 2001 13:23:59 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KNwF15835
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:23:58 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f43KNjS10635;
	Thu, 3 May 2001 15:23:45 -0500 (CDT)
Message-ID: <3AF1BEAF.55C7B9A8@sgi.com>
Date: Thu, 03 May 2001 15:25:19 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Curtis Regentin <cregentin@penguincomputing.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Documentation suggestion
References: <Pine.LNX.4.30.0105031306250.31712-100000@ns1.penguincomputing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sort of like this?

http://linux-xfs.sgi.com/projects/xfs/1.0_caveats.html
------------
The fsr utility and system partitions 

In general we do not foresee the need to run fsr on system partitions
such as /, /boot and /usr as these will in general not suffer from
fragmentation. There are also issues with defragmenting the files lilo
uses to boot your system. Should these files be moved by fsr then you
must rerun lilo before you reboot or you may have an unbootable system. 
------------

Might be worth putting in the man page, or somewhere else as well,
though.

-Eric

Curtis Regentin wrote:
> 
> Hi,
> 
> It might be worth mentioning LILO, and the boot partition somewhere in
> the context of the filesystem reorganizer.  I haven't tried it, but I
> can't imagine that it won't make the system unbootable due to LILO's block
> mapping being wrong.
> 
>  - Curtis

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 13:39:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Kdcl16156
	for linux-xfs-outgoing; Thu, 3 May 2001 13:39:38 -0700
Received: from daffy.thegoop.com (root@[206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KdWF16153
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:39:36 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f43Kba125674;
	Thu, 3 May 2001 13:37:36 -0700
Date: Thu, 3 May 2001 13:37:35 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: Russell Cattelan <cattelan@thebarn.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
In-Reply-To: <3AF1A4EF.EE82780F@thebarn.com>
Message-ID: <Pine.LNX.4.21.0105031334070.25302-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Just an FYI...I'm using Debian Woody with the CVS XFS kernel...the woody
gcc version is 2.95.4, and it "works". I have not done extensive testing
though...

Dana


On Thu, 3 May 2001, Russell Cattelan wrote:

> I'm sure this compiler issue won't go away soon.
> 
> But just as an overview of what is working and what isn't
> 
> XFS Release 1.0:
> 
>      gcc 2.91.66  well tested know to work, use this for stability
> 
>     gcc 2.95.2/3/4 reported to work, not extensively tested, use as own risk
> 
>     gcc 2.96     does not work, gives compilation errors.
> 
>     gcc 2.95RH7.1    ditto.
> 
>     gcc 2.96Mandrake Not attempted yet.
> 
> XFS current:
>     gcc 2.91.66    same as R 1.0
> 
>     gcc 2.95.2/3/4    same as R 1.0
> 
>     gcc 2.96        does not work, compilation errors
> 
>     gcc 2.96RH7.1    compiles, boots, and initial tests show it to be working
> 
>     gcc 2.96Mandrake    compiles, boots, and initial tests show it to be working
> 
> As always there is a big difference between what is "supported" and what "works".
> 
> We are saying R 1.0 is supported (in the loose sense of Open Source supported)
> 
> by compiling with gcc 2.91.66, everything else is "use at your own risk" at this
> 
> point.
> 
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Thu May  3 13:40:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KepQ16190
	for linux-xfs-outgoing; Thu, 3 May 2001 13:40:51 -0700
Received: from digitaltux.com (cr56996-a.mtnk1.on.wave.home.com [24.65.38.194])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KepF16187
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:40:51 -0700
Received: from zoltan by digitaltux.com with local (Exim 3.22 #1 (Debian))
	id 14vPu2-0006TL-00
	for <linux-xfs@oss.sgi.com>; Thu, 03 May 2001 16:40:46 -0400
Date: Thu, 3 May 2001 16:40:45 -0400
To: linux-xfs@oss.sgi.com
Subject: Debian XFS
Message-ID: <20010503164045.A24838@digitaltux.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: zoltan@debian.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Well, it seems that the pcmcia-cs package isn't buildable at the moment, so I will have to postpone the disks till it is. The kernel is 2.4.4 taken from yesterday's cvs. If you want, I'll send the kernel-config for all you to look at, and comment on.

From owner-linux-xfs@oss.sgi.com Thu May  3 13:44:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KicL16253
	for linux-xfs-outgoing; Thu, 3 May 2001 13:44:38 -0700
Received: from smtp4.xs4all.nl (smtp4.xs4all.nl [194.109.6.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KibF16250
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:44:37 -0700
Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44])
	by smtp4.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA13344;
	Thu, 3 May 2001 22:44:35 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA14014;
	Thu, 3 May 2001 22:44:34 +0200 (CEST)
Date: Thu, 3 May 2001 22:44:34 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: Austin Gonyou <austin@coremetrics.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: New thread: Manually creating the 2.4.4 XFS tree
In-Reply-To: <Pine.LNX.4.33.0105031444100.27430-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.BSI.4.33L2.0105032238430.7264-100000@xs3.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 3 May 2001, Austin Gonyou wrote:

> I should've been more specific. I was under the assumption that you
> couldn't really use devfsd if devfs was not compiled into the kernel.
> Sorry for the confusion. What I really want to do is patch a 2.4.4 kernel
> to use XFS without using devfs. That part I don't think would be an issue,
> and I understand all that's involved here. One thing I'd like to be able
> to do though is to know how to properly patch a 2.4.4 kernel upto xfs.
> Should I get a 2.4.2 kernel, patch it with xfs, then patch it up to 2.4.4?
> Ideas?

Just check out the linux-2.4-xfs tree from CVS. This one is currently
based on 2.4.4. See the Getting XFS from CVS page. Patching 2.4.2 with
XFS would be no problem, but patching this from 2.4.2 to 2.4.4 would be a
serious issue. XFS and other journaling fs are dependent on VM behaviour
and are thus very closely intergrated.

If you know how to build kernels this shoudl not be a problem after
getting the tree fom CVS. If not, it's not that difficult.
Linuxdoc.org has al the neccesary kernel building howto's if neccesary.

Good luck
Seth


From owner-linux-xfs@oss.sgi.com Thu May  3 13:49:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KnD816365
	for linux-xfs-outgoing; Thu, 3 May 2001 13:49:13 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KnBF16362
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:49:11 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43KmHU05817;
	Thu, 3 May 2001 15:48:18 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 15:48:15 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "William L. Jones" <jones@hpc.utexas.edu>
cc: Jarek Luberek <jarek@swipnet.se>, <linux-xfs@oss.sgi.com>
Subject: Re: Will xfs scale to > 1GB/s on any hardware?
In-Reply-To: <4.2.0.58.20010503150531.015376f8@127.0.0.1>
Message-ID: <Pine.LNX.4.33.0105031547520.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That's why I mentioned what I did. You aren't going to use that kind of
hardware on a PC. Servers baby servers! :)

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 3 May 2001, William L. Jones wrote:

> At 09:52 PM 5/3/2001 +0200, Jarek Luberek wrote:
> >I've seen that people repport 100 MB/s (sustained I hope) with
> >as few as 8 disks. Would XFS scale to > 1GB/s sustained and
>
> If your talking about a PC then it will take a while before PC are fast enough
> to do this.
>
> Most PC can only do about 200MB/sec on a memory copy.  With the
> newer memories 400MB/sec.  Memory is one bottle neck.
>
> You also have a bottle on the PC buses that would limit the Maxim aerate
> throw put.  The PC buses need to get faster.
>
> 100 MB/s is doable 200MB/s is possible.  It depends on how much money
> you want to spend and how specialized  you want to get.
>
>
> Bill Jones
>


From owner-linux-xfs@oss.sgi.com Thu May  3 13:50:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KoQs16396
	for linux-xfs-outgoing; Thu, 3 May 2001 13:50:26 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KoPF16393
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:50:25 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43Knuv07146;
	Thu, 3 May 2001 15:49:56 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 15:49:54 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Seth Mos <knuffie@xs4all.nl>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: New thread: Manually creating the 2.4.4 XFS tree
In-Reply-To: <Pine.BSI.4.33L2.0105032238430.7264-100000@xs3.xs4all.nl>
Message-ID: <Pine.LNX.4.33.0105031549100.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yeah..I finally just figured well, I've seen posts saying that the
linux-2.4-xfs was the devel, and the devel was upped to 2.4.4, so, that
makes sense... I've gonethrough configuring, and I'll build soon.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 3 May 2001, Seth Mos wrote:

> On Thu, 3 May 2001, Austin Gonyou wrote:
>
> > I should've been more specific. I was under the assumption that you
> > couldn't really use devfsd if devfs was not compiled into the kernel.
> > Sorry for the confusion. What I really want to do is patch a 2.4.4 kernel
> > to use XFS without using devfs. That part I don't think would be an issue,
> > and I understand all that's involved here. One thing I'd like to be able
> > to do though is to know how to properly patch a 2.4.4 kernel upto xfs.
> > Should I get a 2.4.2 kernel, patch it with xfs, then patch it up to 2.4.4?
> > Ideas?
>
> Just check out the linux-2.4-xfs tree from CVS. This one is currently
> based on 2.4.4. See the Getting XFS from CVS page. Patching 2.4.2 with
> XFS would be no problem, but patching this from 2.4.2 to 2.4.4 would be a
> serious issue. XFS and other journaling fs are dependent on VM behaviour
> and are thus very closely intergrated.
>
> If you know how to build kernels this shoudl not be a problem after
> getting the tree fom CVS. If not, it's not that difficult.
> Linuxdoc.org has al the neccesary kernel building howto's if neccesary.
>
> Good luck
> Seth
>


From owner-linux-xfs@oss.sgi.com Thu May  3 13:52:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Kqfg16446
	for linux-xfs-outgoing; Thu, 3 May 2001 13:52:41 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KqeF16442
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:52:40 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14vQ5T-0005p7-00; Fri, 04 May 2001 08:52:35 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "William L. Jones" <jones@hpc.utexas.edu>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
Date: Fri, 4 May 2001 08:52:05 +1200
Message-ID: <KPECIILENDDLPCNIMLOFOEHECDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.33.0105031547520.27430-100000@UberGeek.coremetrics.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


:: On Thu, 3 May 2001, William L. Jones wrote:
::
:: > Most PC can only do about 200MB/sec on a memory copy.  With the
:: > newer memories 400MB/sec.  Memory is one bottle neck.

I was under the impression that you could actually wring out about 1.5GBps
out the theoretical 3.2GBps max of a dual-channel PC800 RDRAM set-up. Not
sure if this applies for both writes and reads though.

-- Juha


From owner-linux-xfs@oss.sgi.com Thu May  3 13:52:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43KqsR16461
	for linux-xfs-outgoing; Thu, 3 May 2001 13:52:54 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43KqrF16458
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 13:52:53 -0700
Received: from [195.20.224.208] (helo=mrvdom01.schlund.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14vQ5f-0002BS-00; Thu, 3 May 2001 22:52:47 +0200
Received: from pd901e331.dip.t-dialin.net ([217.1.227.49] helo=kernelpanix.aura.of.mankind)
	by mrvdom01.schlund.de with esmtp (Exim 2.12 #2)
	id 14vQ5c-00013y-00; Thu, 3 May 2001 22:52:45 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f43KCTf23944;
	Thu, 3 May 2001 22:12:29 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Thu, 3 May 2001 22:12:28 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Eric Sandeen <sandeen@sgi.com>
Cc: Curtis Regentin <cregentin@penguincomputing.com>, linux-xfs@oss.sgi.com
Subject: Re: Documentation suggestion
Message-ID: <20010503221228.A23929@s2y4n2c.de>
References: <Pine.LNX.4.30.0105031306250.31712-100000@ns1.penguincomputing.com> <3AF1BEAF.55C7B9A8@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF1BEAF.55C7B9A8@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen [sandeen@sgi.com] wrote:
> Sort of like this?
> 
> http://linux-xfs.sgi.com/projects/xfs/1.0_caveats.html
> ------------
> The fsr utility and system partitions 
> 
> In general we do not foresee the need to run fsr on system partitions
> such as /, /boot and /usr as these will in general not suffer from
> fragmentation. There are also issues with defragmenting the files lilo
> uses to boot your system. Should these files be moved by fsr then you
> must rerun lilo before you reboot or you may have an unbootable system. 
> ------------
> 
> Might be worth putting in the man page, or somewhere else as well,
> though.

yes, put it in the man page. man pages are the first place information
source for a lot of people.


utz

From owner-linux-xfs@oss.sgi.com Thu May  3 14:02:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43L27G16606
	for linux-xfs-outgoing; Thu, 3 May 2001 14:02:07 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43L26F16603
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:02:06 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f43L0T009011;
	Thu, 3 May 2001 16:00:30 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 3 May 2001 16:00:29 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Juha Saarinen <juha@saarinen.org>
cc: "William L. Jones" <jones@hpc.utexas.edu>, <linux-xfs@oss.sgi.com>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
In-Reply-To: <KPECIILENDDLPCNIMLOFOEHECDAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.33.0105031559050.27430-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

If you head down that road you're about correct. Alot of docs out there
support your claim, but I think that might ONLY be the memory bandwidth.
If you're just using IDE, now way in hell, if you're using UW160 SCSI,
with many drives on caching controller, you could very possibly hit that.
Fibre channel would be about the only way to hit that limit with the least
drives.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 4 May 2001, Juha Saarinen wrote:

>
> :: On Thu, 3 May 2001, William L. Jones wrote:
> ::
> :: > Most PC can only do about 200MB/sec on a memory copy.  With the
> :: > newer memories 400MB/sec.  Memory is one bottle neck.
>
> I was under the impression that you could actually wring out about 1.5GBps
> out the theoretical 3.2GBps max of a dual-channel PC800 RDRAM set-up. Not
> sure if this applies for both writes and reads though.
>
> -- Juha
>


From owner-linux-xfs@oss.sgi.com Thu May  3 14:13:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43LD9P16945
	for linux-xfs-outgoing; Thu, 3 May 2001 14:13:09 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LD7F16941
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:13:07 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA10030
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:11:45 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA41167; Thu, 3 May 2001 16:11:50 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43LAoq13793;
	Thu, 3 May 2001 17:10:50 -0400
Message-ID: <3AF1C959.8524363F@thebarn.com>
Date: Thu, 03 May 2001 17:10:49 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: Seth Mos <knuffie@xs4all.nl>, linux-xfs@oss.sgi.com
Subject: Re: New thread: Manually creating the 2.4.4 XFS tree
References: <Pine.LNX.4.33.0105031549100.27430-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:

> Yeah..I finally just figured well, I've seen posts saying that the
> linux-2.4-xfs was the devel, and the devel was upped to 2.4.4, so, that
> makes sense... I've gonethrough configuring, and I'll build soon.

this seem like a lot of work  just to disable devfs
where as
% vi lilo.conf
append="devfs=nomount"
% lilo -v
% reboot
is quite simple.



>
>
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
>
> On Thu, 3 May 2001, Seth Mos wrote:
>
> > On Thu, 3 May 2001, Austin Gonyou wrote:
> >
> > > I should've been more specific. I was under the assumption that you
> > > couldn't really use devfsd if devfs was not compiled into the kernel.
> > > Sorry for the confusion. What I really want to do is patch a 2.4.4 kernel
> > > to use XFS without using devfs. That part I don't think would be an issue,
> > > and I understand all that's involved here. One thing I'd like to be able
> > > to do though is to know how to properly patch a 2.4.4 kernel upto xfs.
> > > Should I get a 2.4.2 kernel, patch it with xfs, then patch it up to 2.4.4?
> > > Ideas?
> >
> > Just check out the linux-2.4-xfs tree from CVS. This one is currently
> > based on 2.4.4. See the Getting XFS from CVS page. Patching 2.4.2 with
> > XFS would be no problem, but patching this from 2.4.2 to 2.4.4 would be a
> > serious issue. XFS and other journaling fs are dependent on VM behaviour
> > and are thus very closely intergrated.
> >
> > If you know how to build kernels this shoudl not be a problem after
> > getting the tree fom CVS. If not, it's not that difficult.
> > Linuxdoc.org has al the neccesary kernel building howto's if neccesary.
> >
> > Good luck
> > Seth
> >

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 14:14:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43LENe16995
	for linux-xfs-outgoing; Thu, 3 May 2001 14:14:23 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LEMF16991
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:14:22 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14vQGi-0005r5-00; Fri, 04 May 2001 09:04:12 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Austin Gonyou" <austin@coremetrics.com>
Cc: "William L. Jones" <jones@hpc.utexas.edu>, <linux-xfs@oss.sgi.com>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
Date: Fri, 4 May 2001 09:03:42 +1200
Message-ID: <KPECIILENDDLPCNIMLOFGEHFCDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.33.0105031559050.27430-100000@UberGeek.coremetrics.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yes, it's only memory bandwidth, not system bandwidth.

I know how to do it... build a huge solid-state RDRAM disk array. ;-)

-- Juha

:: -----Original Message-----
:: From: Austin Gonyou [mailto:austin@coremetrics.com]
:: Sent: Friday, 4 May 2001 09:00
:: To: Juha Saarinen
:: Cc: William L. Jones; linux-xfs@oss.sgi.com
:: Subject: RE: Will xfs scale to > 1GB/s on any hardware?
::
::
:: If you head down that road you're about correct. Alot of docs out there
:: support your claim, but I think that might ONLY be the memory bandwidth.
:: If you're just using IDE, now way in hell, if you're using UW160 SCSI,
:: with many drives on caching controller, you could very possibly hit that.
:: Fibre channel would be about the only way to hit that limit with
:: the least
:: drives.
::


From owner-linux-xfs@oss.sgi.com Thu May  3 14:26:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43LQOp17242
	for linux-xfs-outgoing; Thu, 3 May 2001 14:26:24 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LQMF17239
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:26:22 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f43LQHq12461;
	Thu, 3 May 2001 16:26:17 -0500
Message-Id: <4.2.0.58.20010503162336.01506ab0@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 16:26:23 -0500
To: "Juha Saarinen" <juha@saarinen.org>,
   "William L. Jones" <jones@hpc.utexas.edu>
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
Cc: <linux-xfs@oss.sgi.com>
In-Reply-To: <KPECIILENDDLPCNIMLOFOEHECDAA.juha@saarinen.org>
References: <Pine.LNX.4.33.0105031547520.27430-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

1.5GBps is 187Mbytes/sec.  Which sounds low.  I know can ring out 
300MBytes/sec or
2.4GBps on one of our RAMBUS systems.

Bill Jones

At 08:52 AM 5/4/2001 +1200, Juha Saarinen wrote:

>:: On Thu, 3 May 2001, William L. Jones wrote:
>::
>:: > Most PC can only do about 200MB/sec on a memory copy.  With the
>:: > newer memories 400MB/sec.  Memory is one bottle neck.
>
>I was under the impression that you could actually wring out about 1.5GBps
>out the theoretical 3.2GBps max of a dual-channel PC800 RDRAM set-up. Not
>sure if this applies for both writes and reads though.
>
>-- Juha


From owner-linux-xfs@oss.sgi.com Thu May  3 14:29:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43LTtT17293
	for linux-xfs-outgoing; Thu, 3 May 2001 14:29:55 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LTsF17290
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:29:54 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14vQfW-0005s8-00; Fri, 04 May 2001 09:29:50 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "William L. Jones" <jones@hpc.utexas.edu>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
Date: Fri, 4 May 2001 09:29:20 +1200
Message-ID: <KPECIILENDDLPCNIMLOFOEHFCDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <4.2.0.58.20010503162336.01506ab0@127.0.0.1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

No, no, giga bytes per second, not giga bit.



:: -----Original Message-----
:: From: William L. Jones [mailto:jones@hpc.utexas.edu]
:: Sent: Friday, 4 May 2001 09:26
:: To: Juha Saarinen; William L. Jones
:: Cc: linux-xfs@oss.sgi.com
:: Subject: RE: Will xfs scale to > 1GB/s on any hardware?
:: 
:: 
:: 1.5GBps is 187Mbytes/sec.  Which sounds low.  I know can ring out 
:: 300MBytes/sec or
:: 2.4GBps on one of our RAMBUS systems.
:: 
:: Bill Jones
:: 
:: At 08:52 AM 5/4/2001 +1200, Juha Saarinen wrote:
:: 
:: >:: On Thu, 3 May 2001, William L. Jones wrote:
:: >::
:: >:: > Most PC can only do about 200MB/sec on a memory copy.  With the
:: >:: > newer memories 400MB/sec.  Memory is one bottle neck.
:: >
:: >I was under the impression that you could actually wring out 
:: about 1.5GBps
:: >out the theoretical 3.2GBps max of a dual-channel PC800 RDRAM 
:: set-up. Not
:: >sure if this applies for both writes and reads though.
:: >
:: >-- Juha
:: 
:: 
:: 

From owner-linux-xfs@oss.sgi.com Thu May  3 14:30:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43LUER17309
	for linux-xfs-outgoing; Thu, 3 May 2001 14:30:14 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LUEF17306
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:30:14 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f43LUAq12493;
	Thu, 3 May 2001 16:30:10 -0500
Message-Id: <4.2.0.58.20010503162859.015a4120@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 16:30:16 -0500
To: "Juha Saarinen" <juha@saarinen.org>,
   "Austin Gonyou" <austin@coremetrics.com>
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: RE: Will xfs scale to > 1GB/s on any hardware?
Cc: "William L. Jones" <jones@hpc.utexas.edu>, <linux-xfs@oss.sgi.com>
In-Reply-To: <KPECIILENDDLPCNIMLOFGEHFCDAA.juha@saarinen.org>
References: <Pine.LNX.4.33.0105031559050.27430-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

If your running linux you are hitting MEMROY which make it hard to do 
better then
the memory system.

At 09:03 AM 5/4/2001 +1200, Juha Saarinen wrote:
>Yes, it's only memory bandwidth, not system bandwidth.
>
>I know how to do it... build a huge solid-state RDRAM disk array. ;-)
>
>-- Juha


From owner-linux-xfs@oss.sgi.com Thu May  3 14:38:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Lc6G17396
	for linux-xfs-outgoing; Thu, 3 May 2001 14:38:06 -0700
Received: from mail.crc.dk (mail.crc.dk [130.226.184.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Lc0F17393
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:38:01 -0700
Received: from crc.dk (isdn1b.crc.dk [130.226.184.50])
	by mail.crc.dk (8.9.3/8.9.3) with ESMTP id XAA19453;
	Thu, 3 May 2001 23:37:55 +0200
Message-ID: <3AF1CF50.E795AB50@crc.dk>
Date: Thu, 03 May 2001 23:36:16 +0200
From: Mogens Kjaer <mk@crc.dk>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: da, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: NFS problems
References: <Pine.LNX.4.30.0105031039240.25517-100000@dbear.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Duffy wrote:
> 
> On Thu, 3 May 2001, Mogens Kjaer wrote:
> 
> > The kernel people claims that it is a glibc bug.
> > The glibc people claims that it is a kernel bug.
> > Everybody says it's an SGI bug.
> 
> this is scheduled to be fixed in IRIX 6.5.13 (I think), but there are
> going to be a lot of people out there with older versions of IRIX...
> 
> And as Russell pointed out, this is fixed in the integrated LBS kernel.

Are you referring to the second last Q on
http://nfs.sourceforge.net ?

This is the other way around; having problems with a Linux NFS
server and an IRIX NFS client, this is not what Trond's patch
is referring to.

Anyway, if the problem is solved both in the Linux kernel,
glibc, and in IRIX then everybody would be happy.

Mogens
-- 
Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

From owner-linux-xfs@oss.sgi.com Thu May  3 14:44:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Lila17479
	for linux-xfs-outgoing; Thu, 3 May 2001 14:44:47 -0700
Received: from marvin.linux-dude.com (c-cd8a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.205])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LikF17476
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:44:46 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f43Liem25725;
	Thu, 3 May 2001 23:44:40 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: "William L. Jones" <jones@hpc.utexas.edu>, linux-xfs@oss.sgi.com
Subject: Re: Will xfs scale to > 1GB/s on any hardware?
Date: Thu, 3 May 2001 23:44:40 +0200
X-Mailer: KMail [version 1.2]
References: <4.2.0.58.20010503150531.015376f8@127.0.0.1>
In-Reply-To: <4.2.0.58.20010503150531.015376f8@127.0.0.1>
MIME-Version: 1.0
Message-Id: <01050323444002.04916@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thursday 03 May 2001 22:12, you wrote:
> At 09:52 PM 5/3/2001 +0200, Jarek Luberek wrote:
> >I've seen that people repport 100 MB/s (sustained I hope) with
> >as few as 8 disks. Would XFS scale to > 1GB/s sustained and
>
> If your talking about a PC then it will take a while before PC are fast
> enough to do this.
>
> Most PC can only do about 200MB/sec on a memory copy.  With the
> newer memories 400MB/sec.  Memory is one bottle neck.
>
> You also have a bottle on the PC buses that would limit the Maxim aerate
> throw put.  The PC buses need to get faster.
>
> 100 MB/s is doable 200MB/s is possible.  It depends on how much money
> you want to spend and how specialized  you want to get.
I'm really liberal about the hardware. Since we are talking XFS, it seems 
to me the choice is linux-on-sgi-hardware or irix. I also need quite a
lot of specINT and specFP and we can get resonably specialized although
the whole point is to use as much standard hardware as possible.

Thanks for the input, all of ya.

/jarek

From owner-linux-xfs@oss.sgi.com Thu May  3 14:50:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Loq417590
	for linux-xfs-outgoing; Thu, 3 May 2001 14:50:52 -0700
Received: from deepthought.granfalloon.com (roc-24-161-81-88.rochester.rr.com [24.161.81.88])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43LopF17586
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 14:50:51 -0700
Received: from helga.granfalloon.com (helga.granfalloon.com [192.168.0.2])
	by deepthought.granfalloon.com (8.9.3/8.8.7) with ESMTP id RAA17978
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 17:50:39 -0400
Subject: Concerning RH 7.1, chkconfig and services
From: Caleb "J." Land <bokonon@rochester.rr.com>
To: Linux XFS List <linux-xfs@oss.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 17:48:05 -0400
Message-Id: <988926486.19228.1.camel@helga.granfalloon.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,
    I installed SGI RH 7.1 test 2 some while ago, and noticed that
    several (~ 19) scripts in /etc/init.d have the line:

    chkconfig: - <some numbers> <some numbers>

    which means that if one does a chkconfig --add <service> the service
    gets disabled in all runlevels.  I would like to run amd and smb, so
    I manually changed the startup runlevels, but would like to know why
    the others are disabled in this manner?

    I asked someone on IRC who is running RH 7.1 stock, and he didn't
    seem to have this problem, so my next guess is that it's either my
    fault (most likely), an sgi rh 7.1 (test2 or other) thing, OR it's
    supposed to be like that, and there is another way of making the
    services start up at boot time.

    I'm going to install RH 7.1 XFS 1.0 on my home file server, so it's
    more of an issue there where I run more server processes.

    Just wondering

-- 
Sincerely,
Caleb Land

---
A prayer:
        Lord, protect me from knowing what I don't need to know.
Protect me from even knowing that there are things to know that I
don't know.  Protect me from knowing that I decided not to know about
the things that I decided not to know about.  Amen.
        --Mostly Harmless, Douglas Adams

Email: bokonon@rochester.rr.com

Jabber: caleb@jabber.granfalloon.com
AIM:   RedHatDude
ICQ:   8358400

GnuPG/PGP Public Key: finger me at "caleb@deepthought.granfalloon.com"
                      and read my .plan.
---



From owner-linux-xfs@oss.sgi.com Thu May  3 15:03:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43M37h17933
	for linux-xfs-outgoing; Thu, 3 May 2001 15:03:07 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43M36F17930
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:03:06 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f43M33S18417;
	Thu, 3 May 2001 17:03:03 -0500 (CDT)
Message-ID: <3AF1D5F5.9F7C6EC9@sgi.com>
Date: Thu, 03 May 2001 17:04:37 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Caleb J. Land" <bokonon@rochester.rr.com>
CC: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: Concerning RH 7.1, chkconfig and services
References: <988926486.19228.1.camel@helga.granfalloon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Caleb - 

It's highly unlikely that this has anything to do with XFS or our
installer... this stuff should have come straight out of original Red
Hat RPMs.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 15:16:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43MGWu18210
	for linux-xfs-outgoing; Thu, 3 May 2001 15:16:32 -0700
Received: from sith.mimuw.edu.pl (qmailr@sith.mimuw.edu.pl [193.0.97.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f43MGTF18204
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:16:30 -0700
Received: (qmail 13263 invoked by uid 1645); 3 May 2001 22:22:02 -0000
Date: Fri, 4 May 2001 00:22:02 +0200
From: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: James Pearson <james-p@moving-picture.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
Message-ID: <20010504002202.D12796@sith.mimuw.edu.pl>
References: <3AF16D0A.2D12C344@moving-picture.com> <20010503170018.A31942@sith.mimuw.edu.pl> <3AF17D9A.D9B648A4@moving-picture.com> <3AF1960A.E3F927C6@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AF1960A.E3F927C6@thebarn.com>; from cattelan@thebarn.com on Thu, May 03, 2001 at 01:31:54PM -0400
X-Operating-System: Linux 2.4.2 i686
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 03 May 2001, Russell Cattelan wrote:

> 
> I'n not quite spotting the problem either... could you send  the diff?
> 
> I'm not very familiar with the quota code...
> Nathan  can you see a problem in the dquot.c stuff referenced below?

Hmm, I'm sorry for all this confusion, it must have been specific to
my heavyly patched source. I have some quota fixes that still didn't make
it to 2.4 proper and this might caused patch misplacement for me.

James, as far as I can see your problem is somewhere else.

Jan
-- 
Jan Rêkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio

From owner-linux-xfs@oss.sgi.com Thu May  3 15:25:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43MPoB18446
	for linux-xfs-outgoing; Thu, 3 May 2001 15:25:50 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43MPnF18442
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:25:49 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id PAA03571
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:36:31 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA26990; Fri, 4 May 2001 08:24:29 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA50312;
	Fri, 4 May 2001 08:24:28 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105040824.ZM55920@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 08:24:27 -0500
In-Reply-To: James Pearson <james-p@moving-picture.com>
        "Problem setting up quotas ..." (May  3,  3:36pm)
References: <3AF16D0A.2D12C344@moving-picture.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: James Pearson <james-p@moving-picture.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi James,

On May 3,  3:36pm, James Pearson wrote:
> Subject: Problem setting up quotas ...
> I've just installed RedHat 7.1/XFS1.0 on a Athlon based system and I'm
> trying to get quotas working - so far without success.
> 
> I've made a XFS file system and mounted it with -o quota and tried to
> follow the instructions in the quotaon man page and
> /usr/share/doc/xfsprogs/README.quota but get the following:
> 
> ...
> # edquota james
> No filesystems with quota detected.
> 
> I've also recompiled the kernel with CONFIG_QUOTA=y and
> CONFIG_XFS_QUOTA=y just in case the supplied kernel didn't have quotas
> enabled - but with the same results.
> 

yup, that would have been my first guess too (you definately
rebooted after recompiling?).  can you send the output from:

	# repquota -v /dev/hda4

this will tell for sure whether quota are enabled.  when you
mount with quota for the first time, you should see a console
message - "XFS doing a quotacheck", or something along those
lines.

Alternatively, if you unmount the filesystem, then run:

	# xfs_db -r -c sb -c p /dev/hda4 | grep qflags

you'll see a non-zero hex number if quota are enabled -
if you get zero, somethings wrong (running kernel doesn't
support XFS quota would be the most likely).

> 
> Incidentally, the examples in /usr/share/doc/xfsprogs/README.quota and
> the quotaon man page don't agree with the actual commands e.g.
> 
> in README.quota the syntax to the setquota example is incorrect.
> 
> in quotaon(8), the examples talk about a -s option to repquota and a -o
> option to quotaoff which don't seem to exist ...
> 

yes, the problem here is that the XFS 1.0 tree was
frozen to changes (bug fixes only) several weeks
ago ... and a couple of new releases of the quota
tools have happened since then, changing output,
args, etc.

you'll find the current development cvs tree README
closer to reality here, but having just read it, I
see it needs to be updated a little again for the
latest quota tools... will put an updated version
in shortly.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 15:28:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43MS7818525
	for linux-xfs-outgoing; Thu, 3 May 2001 15:28:07 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43MS7F18522
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:28:07 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07058
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:38:50 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA75219
	for linux-xfs@oss.sgi.com; Fri, 4 May 2001 08:26:48 +1000 (EST)
Date: Fri, 4 May 2001 08:26:48 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105032226.IAA75219@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - fsr doc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May  3 14:19:45 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:93997a
cmd/xfsdump/man/man8/xfs_fsr.8 - 1.2
	- add section about lilo from the 1.0 caveats page.


Date:  Thu May  3 14:57:52 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94005a
cmd/xfsdump/librmt/rmtopen.c - 1.2
	- fix parentheses related compiler warning.

cmd/xfsdump/fsr/xfs_fsr.c - 1.5
	- fix some 64bit-related compiler warnings.



From owner-linux-xfs@oss.sgi.com Thu May  3 15:30:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43MUFo18570
	for linux-xfs-outgoing; Thu, 3 May 2001 15:30:15 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43MUCF18567
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:30:12 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id AAA779586
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 00:30:09 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA27020; Fri, 4 May 2001 08:28:36 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA55745;
	Fri, 4 May 2001 08:28:35 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105040828.ZM55812@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 08:28:34 -0500
In-Reply-To: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
        "Re: Problem setting up quotas ..." (May  4, 12:22am)
References: <3AF16D0A.2D12C344@moving-picture.com> 
	<20010503170018.A31942@sith.mimuw.edu.pl> 
	<3AF17D9A.D9B648A4@moving-picture.com> 
	<3AF1960A.E3F927C6@thebarn.com> 
	<20010504002202.D12796@sith.mimuw.edu.pl>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Jan Rekorajski <baggins@sith.mimuw.edu.pl>,
   Russell Cattelan <cattelan@thebarn.com>
Subject: Re: Problem setting up quotas ...
Cc: James Pearson <james-p@moving-picture.com>, linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 4, 12:22am, Jan Rekorajski wrote:
> Subject: Re: Problem setting up quotas ...
> On Thu, 03 May 2001, Russell Cattelan wrote:
> 
> > 
> > I'n not quite spotting the problem either... could you send  the diff?
> > 
> > I'm not very familiar with the quota code...
> > Nathan  can you see a problem in the dquot.c stuff referenced below?
> 
> Hmm, I'm sorry for all this confusion, it must have been specific to
> my heavyly patched source. I have some quota fixes that still didn't make
> it to 2.4 proper and this might caused patch misplacement for me.
> 
> James, as far as I can see your problem is somewhere else.
> 

yes, afaict, there's nothing broken with the XFS quotactl code
(works for me, TM).

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 15:47:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Ml8A19230
	for linux-xfs-outgoing; Thu, 3 May 2001 15:47:08 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Ml7F19227
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:47:07 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id PAA07024
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:47:05 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA27176; Fri, 4 May 2001 08:45:47 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA56066;
	Fri, 4 May 2001 08:45:45 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105040845.ZM55988@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 08:45:44 -0500
In-Reply-To: Andrey Nekrasov <andy@spylog.com>
        "repquota bug?" (May  3, 11:17pm)
References: <20010503231735.A1917@an.local>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Andrey Nekrasov <andy@spylog.com>, linux-xfs@oss.sgi.com
Subject: Re: repquota bug?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi Andrey,

On May 3, 11:17pm, Andrey Nekrasov wrote:
> Subject: repquota bug?
> 
> Hello,
> ...
> andy@an /opt/in $ repquota |less
> *** Report for user quotas on device /dev/hda3
> Block grace time: 7days; Inode grace time: 7days
>                         Block limits                File limits
> User             used    soft    hard  grace    used  soft  hard  grace
> ----------------------------------------------------------------------
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> ....
> andy      --   95684  400000       0           5196     0     0
> ...
> ...
> ...
> 
> Why?
> 

Hmm, I've never seen this one before... I guess repquota just
wants to make absolutely sure you know what Andy's usage is!

[digging through code]... do you have an /etc/passwd with
multiple entries with the same uid (501) by any chance?

Where you have "..." above, is it going into an infinite loop,
or does it stop after some number of "andy" iterations?

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 15:58:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43MwVJ19378
	for linux-xfs-outgoing; Thu, 3 May 2001 15:58:31 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43MwUF19375
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 15:58:30 -0700
Received: from sguk.reading.sgi.com (sguk.reading.sgi.com [144.253.64.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA08234
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 16:09:13 -0700 (PDT)
	mail_from (markj@reading.sgi.com)
Received: from reading.sgi.com (sgigate.sgi.com [198.29.75.75]) by sguk.reading.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF.hoststrip-1.1) via ESMTP id XAA35529 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 23:57:11 +0100 (BST)
Message-ID: <3AF1A8F5.A1220207@reading.sgi.com>
Date: Thu, 03 May 2001 19:52:38 +0100
From: Mark Jeffery <markj@reading.sgi.com>
Organization: Silicon Graphics
X-Mailer: Mozilla 4.75C-SGI [en] (X11; I; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: problem with mount root file system
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've just installed a completely fresh copy of Linux with XFS 1.0 using
the boot loader.

This is going onto an old Dell machine with AIC7XXX SCSI internal system
disk (and CDROM and CDRW), with 2 qla1280 controllers talking to arrays
of disks (hence the XFS requirement).

I can boot the system if the arrays of disks are turned off. When I turn
the disks on, I cannot boot the system.

It seems that devfs maps the arrays of disks to /dev/sda,b,c and d
leaving the system disk /dev/sde!

I have tried the scsihosts kernel parameter, setting it to
aic7xxx:qla1280:qla1280, but that doesn't seem to help.

Any ideas?
--
Mark Jeffery                Tel: +44 118 925 7666
Business Development Mgr    Mob: +44 7710 579828
Business Intelligence, SGI  Fax: +44 118 925 7699
Email: markj@sgi.com        http://www.sgi.com


From owner-linux-xfs@oss.sgi.com Thu May  3 16:01:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43N1vB19481
	for linux-xfs-outgoing; Thu, 3 May 2001 16:01:57 -0700
Received: from moe.rice.edu (moe.rice.edu [128.42.5.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43N1fF19472
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 16:01:41 -0700
Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116])
	by moe.rice.edu (8.9.0/8.9.0) with ESMTP id SAA03664
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 18:01:40 -0500 (CDT)
Received: from photino.sid.rice.edu (rjain@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f43N1eee008350
        for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 18:01:40 -0500
Received: (from rjain@localhost)
        by photino.sid.rice.edu (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f43N1dnf008348
        for linux-xfs@oss.sgi.com; Thu, 3 May 2001 18:01:39 -0500
Date: Thu, 3 May 2001 18:01:39 -0500
From: Rahul Jain <rahul@rice.edu>
To: linux-xfs@oss.sgi.com
Subject: Re: Will xfs scale to > 1GB/s on any hardware?
Message-ID: <20010503180139.A8157@photino.sid.rice.edu>
Reply-To: Rahul Jain <rahul@rice.edu>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <01050321241200.04916@marvin> <Pine.LNX.4.33.0105031455460.27430-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <Pine.LNX.4.33.0105031455460.27430-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Thu, May 03, 2001 at 02:57:52PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 03, 2001 at 02:57:52PM -0500, Austin Gonyou wrote:
> >From what I've read is that you can get 1GB/s out of xfs, and possibly
> greater. If this is true, then I'd suspect that it would be a good fibre
> setup or possibly a LOT of scsi controllers and disks. Say 4-6 UW160
> controllers  2 channels each and say 4-6 disks per channel. (Pure scsi) If
> fibre, then you should be able to use say 4 Single port Fibre cards
> attatched to enough disks, say 16 or so, to get a reasonable throughput
> like you speak of.

hmm... if you're talking 2 Gbps scsi, that's a total of 8 Gbps or 1GB/s
available bandwidth, and the packet switching in the protocol will definitely
make you lose some of that to overhead. I think he'd need a bit more if he
wanted to actually get 1GB/s from the disks to the system. He'd probably also
need to use a very high-performance bus architecture (is there even one that
fast supported by linux?).

-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

From owner-linux-xfs@oss.sgi.com Thu May  3 16:44:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Ni9c20652
	for linux-xfs-outgoing; Thu, 3 May 2001 16:44:09 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Ni8F20649
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 16:44:08 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA06836
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 16:54:51 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA25840; Thu, 3 May 2001 18:42:51 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f43Nfpq14311;
	Thu, 3 May 2001 19:41:51 -0400
Message-ID: <3AF1ECBF.357F10AE@thebarn.com>
Date: Thu, 03 May 2001 19:41:51 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Jeffery <markj@reading.sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: problem with mount root file system
References: <3AF1A8F5.A1220207@reading.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mark Jeffery wrote:

> Hi,
>
> I've just installed a completely fresh copy of Linux with XFS 1.0 using
> the boot loader.
>
> This is going onto an old Dell machine with AIC7XXX SCSI internal system
> disk (and CDROM and CDRW), with 2 qla1280 controllers talking to arrays
> of disks (hence the XFS requirement).
>
> I can boot the system if the arrays of disks are turned off. When I turn
> the disks on, I cannot boot the system.
>
> It seems that devfs maps the arrays of disks to /dev/sda,b,c and d
> leaving the system disk /dev/sde!

This is exactly on of the problems devfs is designed to fix.
Change your fstab to reference the devfs device and not the compatibility
device
eg
/devfs/scsi/host0/bus0/target2/lun0/part1

>
>
> I have tried the scsihosts kernel parameter, setting it to
> aic7xxx:qla1280:qla1280, but that doesn't seem to help.

The issue probably the controller order although that can be a problem.
putting all your scsi controllers in initrd in the correct order will fix
this problem also.


>
>
> Any ideas?
> --
> Mark Jeffery                Tel: +44 118 925 7666
> Business Development Mgr    Mob: +44 7710 579828
> Business Intelligence, SGI  Fax: +44 118 925 7699
> Email: markj@sgi.com        http://www.sgi.com

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May  3 16:55:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f43Nt8H20888
	for linux-xfs-outgoing; Thu, 3 May 2001 16:55:08 -0700
Received: from www.quasihorse.com (cs666825-182.austin.rr.com [66.68.25.182])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f43Nt6F20885
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 16:55:07 -0700
Received: by www.quasihorse.com (Postfix, from userid 500)
	id 0DE3A11A; Thu,  3 May 2001 19:00:31 -0500 (CDT)
Date: Thu, 3 May 2001 19:00:30 -0500
From: pac@fortuitous.com
To: linux-xfs@oss.sgi.com
Subject: vmware broken again:
Message-ID: <20010503190030.A1752@bistro.marx>
Reply-To: pac@fortuitous.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  
  I just fixed the vmware modules two work with 2.4.X kernels,
  now it looks like you have returned the code to its original state.
  I used the old modules from vmware, but now the system locks up tight
  (the whole, system, no consoles, cant ssh/telnet in).

 Using 2.4.3-xfs kernel tree, on Duron system. 
Linux bistro 2.4.3-xfs #1 Thu May 3 11:52:51 CDT 2001 i686 unknown

>make: Entering directory `/root/tmp/vmware-config1/vmnet-only'
>bridge.c: In function `VNetBridgeReceiveFromDev':
>bridge.c:788: warning: implicit declaration of function `skb_shinfo'
>make: Leaving directory `/root/tmp/vmware-config1/vmnet-only'
>Unable to make a vmnet module that can be loaded in the running kernel:
>/root/tmp/vmware-config1/vmnet.o: unresolved symbol skb_shinfo
>There is probably a light difference of kernel configuration between the set of 
>C header files you specified and your running kernel. You may want to rebuild a 
>kernel based on that directory, or specify another directory.
>
>For more information on how to troubleshoot module-related problems, please have
>a look at "http://www.vmware.com/download/modules/modules.html".
-- 

 Here is the info I used to "fix" the problem in the first place
 for 2.4.2 and above kernels (no XFS)
 (its not fixed in the xfs kernels ):

>> : patch -p0 < patch-skb
>> patching file vmnet-only/vnetInt.h
>> Hunk #1 FAILED at 16.
>> 1 out of 1 hunk FAILED -- saving rejects to file vmnet-only/vnetInt.h.rej
>>
>>  Im not patch expert, so Im sorta lost.. i attached the file just in
>>   case you can illuminate the problem.
>
>Maybe you need to remove '\r' from my patch, if your news browser did
>not do it: tr -d "\r" < patch-skb > patch-skb-ok; patch -p0 < patch-skb-ok
                                                >
>'patch' program just removes lines marked with '- ' and adds lines
>marked with '+ ' into file, checking that '  ' marked lines are really
>in file to verify that it patches correct file at correct position.
>
>If it will not help, just replace
>
>skb_datarefp(clone) == skb_datarefp(skb)
>
>with
>
>skb_shinfo(clone) == skb_shinfo(clone)
>
>In old kernels there was only reference counter at the end of SKB, so
>function was named skb_datarefp(). Now there is more info stored here,
>so function was renamed to skb_shinfo() (from SHared INFOrmation)...
                                 >

  -Phil C.
.---------------------------------------------------------
| P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
| Fortuitous Technologies Inc. |  http://fortuitous.com   |
| Linux Training Services      |  Tel : 1-512 467-2154    |
| Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
 ---------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Thu May  3 17:48:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f440mn823712
	for linux-xfs-outgoing; Thu, 3 May 2001 17:48:49 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440mlF23708
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 17:48:47 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA775181
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 02:48:45 +0200 (CEST)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA63413 for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 17:52:18 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 832F4CED7A
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 17:47:28 -0700 (PDT)
Subject: Re: TAKE - DAC driver
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <3AF0C118.90109F1B@thebarn.com>
References: <yq1ae4vkzid.fsf@jcb.mkp.net>  <3AF0C118.90109F1B@thebarn.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 17:47:28 -0700
Message-Id: <988937248.26915.1.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 02 May 2001 21:23:21 -0500, Russell Cattelan wrote:
> "Martin K. Petersen" wrote:
> 
> > Modid:  2.4.x-xfs:slinx:93919a
> > linux/drivers/block/DAC960.c - 1.25
> 
> Good.
> Now how do fix Florin's problem.
> I suppose we could send him a patch for the 1.0 tree
> and have him rebuild the kernel?

Yes, please.

-- 
Florin Andrei

"Bloat is not about being big. Bloat is about being slow and stupid and not
realizing that it's because of design mistakes." - Linus Torvalds


From owner-linux-xfs@oss.sgi.com Thu May  3 17:53:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f440rSu23791
	for linux-xfs-outgoing; Thu, 3 May 2001 17:53:28 -0700
Received: from deepthought.granfalloon.com (roc-24-161-81-88.rochester.rr.com [24.161.81.88])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440rQF23788
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 17:53:27 -0700
Received: from helga.granfalloon.com (helga.granfalloon.com [192.168.0.2])
	by deepthought.granfalloon.com (8.9.3/8.8.7) with ESMTP id UAA18970
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 20:53:25 -0400
Subject: Re: Concerning RH 7.1, chkconfig and services
From: Caleb "J." Land <bokonon@rochester.rr.com>
To: Linux XFS List <linux-xfs@oss.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 03 May 2001 20:50:50 -0400
Message-Id: <988937450.24114.0.camel@helga.granfalloon.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Whoops, forgot to send it to the list...

On 03 May 2001 17:04:37 -0500, Eric Sandeen wrote:
> It's highly unlikely that this has anything to do with XFS or our
> installer... this stuff should have come straight out of original Red
> Hat RPMs.

Thanks for the reply,
    That's what I thought, but wanted to know for sure.  If anyone has
    the information I would appreciate it even though it isn't XFS
    related (or is there a redhat mailing list somewhere... I'll have to
    look for one)
-- 
Sincerely,
Caleb Land

---
A prayer:
        Lord, protect me from knowing what I don't need to know.
Protect me from even knowing that there are things to know that I
don't know.  Protect me from knowing that I decided not to know about
the things that I decided not to know about.  Amen.
        --Mostly Harmless, Douglas Adams

Email: bokonon@rochester.rr.com

Jabber: caleb@jabber.granfalloon.com
AIM:   RedHatDude
ICQ:   8358400

GnuPG/PGP Public Key: finger me at "caleb@deepthought.granfalloon.com"
                      and read my .plan.
---


-- 
Sincerely,
Caleb Land

---
A prayer:
        Lord, protect me from knowing what I don't need to know.
Protect me from even knowing that there are things to know that I
don't know.  Protect me from knowing that I decided not to know about
the things that I decided not to know about.  Amen.
        --Mostly Harmless, Douglas Adams

Email: bokonon@rochester.rr.com

Jabber: caleb@jabber.granfalloon.com
AIM:   RedHatDude
ICQ:   8358400

GnuPG/PGP Public Key: finger me at "caleb@deepthought.granfalloon.com"
                      and read my .plan.
---



From owner-linux-xfs@oss.sgi.com Thu May  3 17:55:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f440twc23853
	for linux-xfs-outgoing; Thu, 3 May 2001 17:55:58 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f440tvF23850
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 17:55:57 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f440tuA14464;
	Thu, 3 May 2001 19:55:56 -0500 (CDT)
Message-ID: <3AF1FE7A.1CCC8218@sgi.com>
Date: Thu, 03 May 2001 19:57:30 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Florin Andrei <florin@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: TAKE - DAC driver
References: <yq1ae4vkzid.fsf@jcb.mkp.net>  <3AF0C118.90109F1B@thebarn.com> <988937248.26915.1.camel@stantz.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Florin Andrei wrote:
> 
> On 02 May 2001 21:23:21 -0500, Russell Cattelan wrote:
>
> > Now how do fix Florin's problem.
> > I suppose we could send him a patch for the 1.0 tree
> > and have him rebuild the kernel?
> 
> Yes, please.

--- /usr/tmp/TmpDir.14586-0/linux/drivers/block/DAC960.c_1.24	Thu May  3
20:55:14 2001
+++ /usr/tmp/TmpDir.14586-0/linux/drivers/block/DAC960.c_1.25	Thu May  3
20:55:14 2001
@@ -5104,6 +5104,9 @@
       return
put_user(Controller->GenericDiskInfo.part[MINOR(Inode->i_rdev)]
 						 .nr_sects,
 		      (long *) Argument);
+    case BLKBSZSET:
+      /* Set block size. */
+      return blk_ioctl (Inode->i_rdev, Request, Argument);
     case BLKRAGET:
       /* Get Read-Ahead. */
       if ((long *) Argument == NULL) return -EINVAL;

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 18:17:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f441H4C24464
	for linux-xfs-outgoing; Thu, 3 May 2001 18:17:04 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f441H3F24453
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 18:17:03 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA775243
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 03:17:00 +0200 (CEST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA56316
	for linux-xfs@oss.sgi.com; Fri, 4 May 2001 11:15:42 +1000 (EST)
Date: Fri, 4 May 2001 11:15:42 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105040115.LAA56316@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - doc
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May  3 18:15:24 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94022a
cmd/xfsprogs/doc/README.quota - 1.4
	- update readme text to match current quota commands output.



From owner-linux-xfs@oss.sgi.com Thu May  3 19:11:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f442BhM25437
	for linux-xfs-outgoing; Thu, 3 May 2001 19:11:43 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f442BhF25434
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 19:11:43 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA08178
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 19:22:26 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA28691; Fri, 4 May 2001 12:10:21 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Brian Walker <walkerbm@home.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs compile problem 
In-reply-to: Your message of "Thu, 03 May 2001 12:02:33 -0400."
             <3AF18119.1030704@home.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 04 May 2001 12:10:21 +1000
Message-ID: <25400.988942221@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 03 May 2001 12:02:33 -0400, 
Brian Walker <walkerbm@home.com> wrote:
>I'm running Redhat 7.1 and I wanted to recompile my kernel. I'm using 
>the stock 2.4.2 kernel with XFS support installed by the XFS iso image 
>and the redhat 7.1 iso images. I am getting the following when doing a 
>make bzImage:
>
>ld -m elf_i386 -Ttext 0x0 -s --oformat binary -e begtext -o bsetup bsetup.o
>bsetup.o: In function `start_of_setup':
>bsetup.o(.text+0x43e): undefined reference to `SIG1'

All the failing symbols are #defines which should have been converted
to numbers by cpp.  If switching to kgcc does not fix the problem, tar
these files and send to kaos@melbourne.sgi.com, not to the list.

  arch/i386/boot/Makefile
  arch/i386/boot/setup.S
  arch/i386/boot/bsetup.s
  arch/i386/boot/bsetup.o

Also try rm arch/i386/boot/bsetup.s followed by make bzImage, it might
be a transient error.  Include the compile log from

  cpp ... -D__BIG_KERNEL__ -traditional ... setup.S -o bsetup.s

onwards.


From owner-linux-xfs@oss.sgi.com Thu May  3 20:26:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f443QoO26394
	for linux-xfs-outgoing; Thu, 3 May 2001 20:26:50 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f443QnF26391
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 20:26:49 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f443Qmq15159
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:26:48 -0500
Message-Id: <4.2.0.58.20010503222326.015069b8@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 03 May 2001 22:26:53 -0500
To: linux-xfs@oss.sgi.com
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: mkinitrd hang
In-Reply-To: <4.2.0.58.20010503150531.015376f8@127.0.0.1>
References: <01050321241200.04916@marvin>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


mkinitrd is hanging on a mkfs on the loop back device.
Has any one seen this problem.

I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running Redhat 7.1.

Bil Jones



From owner-linux-xfs@oss.sgi.com Thu May  3 20:37:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f443bYQ26559
	for linux-xfs-outgoing; Thu, 3 May 2001 20:37:34 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f443bWF26556
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 20:37:32 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f443bXA24769;
	Thu, 3 May 2001 22:37:33 -0500 (CDT)
Message-ID: <3AF2245A.36FFD7B2@sgi.com>
Date: Thu, 03 May 2001 22:39:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "William L. Jones" <jones@hpc.utexas.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: mkinitrd hang
References: <01050321241200.04916@marvin> <4.2.0.58.20010503222326.015069b8@127.0.0.1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"William L. Jones" wrote:
> 
> mkinitrd is hanging on a mkfs on the loop back device.
> Has any one seen this problem.
> 
> I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running Redhat 7.1.

Was this installed from our RPMs, or did you patch a vanilla kernel
yourself, or do a cvs checkout?

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 20:44:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f443iOF26675
	for linux-xfs-outgoing; Thu, 3 May 2001 20:44:24 -0700
Received: from walt400.holman.net (sttldslgw6poold155.sttl.uswest.net [63.226.211.155])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f443iNF26671
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 20:44:23 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP id 8CF4F426985
	for <linux-xfs@oss.sgi.com>; Thu,  3 May 2001 20:52:23 -0700 (PDT)
Message-ID: <3AF22777.9010300@uswest.net>
Date: Thu, 03 May 2001 20:52:23 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.9) Gecko/20010503
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: mkinitrd hang
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Oops. Looks like you got bit by the infamout loop fs bug. It didn't get 
fixed until 2.4.3.  If you can, boot into a different kernel version and 
run mkinitrd. Also, if I recall correctly, there was a link to a patch 
which corrected it on < 2.4.3 kernels - sorry I don't have the link 
handy. I had the same problem here, but I have both devel and stable 
branches built concurrently and used the devel branch to run mkinitrd.

-Walt


William L. Jones wrote:

>
> mkinitrd is hanging on a mkfs on the loop back device.
> Has any one seen this problem.
>
> I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running Redhat 
> 7.1.
>
> Bil Jones
>
>
>




From owner-linux-xfs@oss.sgi.com Thu May  3 20:46:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f443kuB26719
	for linux-xfs-outgoing; Thu, 3 May 2001 20:46:56 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f443kuF26716
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 20:46:56 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f443kvA29622;
	Thu, 3 May 2001 22:46:57 -0500 (CDT)
Message-ID: <3AF2268F.65DBAC08@sgi.com>
Date: Thu, 03 May 2001 22:48:31 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "William L. Jones" <jones@hpc.utexas.edu>, linux-xfs@oss.sgi.com
Subject: Re: mkinitrd hang
References: <01050321241200.04916@marvin> <4.2.0.58.20010503222326.015069b8@127.0.0.1> <3AF2245A.36FFD7B2@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:
> 
> "William L. Jones" wrote:
> >
> > mkinitrd is hanging on a mkfs on the loop back device.
> > Has any one seen this problem.
> >
> > I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running Redhat 7.1.
> 
> Was this installed from our RPMs, or did you patch a vanilla kernel
> yourself, or do a cvs checkout?

Sorry, I should complete that thought.  :)

If you patched your own kernel, and especially if you did a cvs
checkout, the loop device is probably broken (it was broken in Linus'
tree at least through 2.4.2...)

The loop patches in
ftp://linux-xfs.sgi.com/projects/xfs/download/archive/Release-1.0-test2/patches/
will *probably* apply cleanly for you if you have a vanilla 2.4.2 kernel
+ XFS.

But if you're on Red Hat, I'd suggest using the kernel-source RPM we
packaged, as it has many other fixes, as well, thanks to Red Hat.

If you're already using our RPM, then I'm not sure what the solution
will be.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May  3 22:23:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f445Npw28213
	for linux-xfs-outgoing; Thu, 3 May 2001 22:23:51 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f445NnF28210
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:23:49 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id WAA03675
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:23:47 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA29868; Fri, 4 May 2001 15:22:30 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA56972;
	Fri, 4 May 2001 15:22:29 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105041522.ZM56847@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 15:22:27 -0500
In-Reply-To: James Pearson <james-p@moving-picture.com>
        "Problem setting up quotas ..." (May  3,  3:36pm)
References: <3AF16D0A.2D12C344@moving-picture.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: James Pearson <james-p@moving-picture.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi James,

On May 3,  3:36pm, James Pearson wrote:
> Subject: Problem setting up quotas ...
> ...
> # edquota james
> No filesystems with quota detected.
> 

OK, this is a bug in the way the Redhat 7.1 kernel rpms
were integrated with the XFS code.  Here is a patch which
will fix it - Eric has tested this for me & it works.

It _only_ affects the kernel rpms with Redhat 7.1 changes
- the base 2.4.2 patches, cvs trees, etc. are not affected
and _do not_ need the patch..

--- fs/dquot.c.orig	Fri May  4 10:17:40 2001
+++ fs/dquot.c	Fri May  4 11:02:13 2001
@@ -2001,7 +2001,7 @@
 	type = cmd & SUBCMDMASK;
 
 
-	if ((uint) type >= MAXQUOTAS || cmds > 0x0F00 || cmds < 0x100 || cmds == 0x0300 ||
+	if ((uint) type >= MAXQUOTAS || cmds < 0x100 || cmds == 0x0300 ||
 	    cmds == 0x0400 || cmds == 0x0500)
 		goto out;
 
@@ -2049,9 +2049,6 @@
 		unlock_kernel();
 		return sb->s_op->quotactl(sb, cmds, type, id, addr);
 	}
-
-	if (id & ~0xFFFF)
-		goto out;
 
 	ret = -EINVAL;
 	switch (cmds) {



> ...
> Incidentally, the examples in /usr/share/doc/xfsprogs/README.quota and
> the quotaon man page don't agree with the actual commands e.g.
> 
> in README.quota the syntax to the setquota example is incorrect.
> 
> in quotaon(8), the examples talk about a -s option to repquota and a -o
> option to quotaoff which don't seem to exist ...
> 

That's been updated in the development tree now -- thanks.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 22:24:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f445OHv28236
	for linux-xfs-outgoing; Thu, 3 May 2001 22:24:17 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f445OGF28233
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:24:17 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA01975
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:22:54 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA29874; Fri, 4 May 2001 15:22:58 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA54171;
	Fri, 4 May 2001 15:22:57 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105041522.ZM56355@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 15:22:56 -0500
In-Reply-To: Andrey Nekrasov <andy@spylog.com>
        "repquota bug?" (May  3, 11:17pm)
References: <20010503231735.A1917@an.local>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Andrey Nekrasov <andy@spylog.com>, linux-xfs@oss.sgi.com
Subject: Re: repquota bug?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi Andrey,

Eric managed to reproduce this internally, and I am coding
a fix for it now.  The bug is to do with the way the quota
tools interact with very specific versions of libc (eg. the
version in Redhat 7.1).

I'll send a note once a new version of the tools has been
produced.

thanks.

On May 3, 11:17pm, Andrey Nekrasov wrote:
> Subject: repquota bug?
> 
> Hello,
> 
> 1. quota-3.01-SGI_5
>    kernel 2.4.3 + xfs patch + core patch (from SGI)
>    egcs 1.1.2 (kgcc)
> 
> 
> 2. /dev/hda3 on /home type xfs (rw,usrquota)
> 
> 3. 
> 
> andy@an /opt/in $ quota andy
> Disk quotas for user andy (uid 501): 
>      Filesystem  blocks   quota   limit   grace   files   quota   limit grace
>       /dev/hda3   95684  400000       0            5196       0       0        
> andy@an /opt/in $
> 
> OK!
> 
> 4.
> 
> andy@an /opt/in $ repquota |less
> *** Report for user quotas on device /dev/hda3
> Block grace time: 7days; Inode grace time: 7days
>                         Block limits                File limits
> User             used    soft    hard  grace    used  soft  hard  grace
> ----------------------------------------------------------------------
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> andy      --   95684  400000       0           5196     0     0       
> ....
> andy      --   95684  400000       0           5196     0     0
> ...
> ...
> ...
> 
> Why?
> 
> bye.
> Andrey Nekrasov, SpyLOG.
> http://www.spylog.com/
>-- End of excerpt from Andrey Nekrasov



-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May  3 22:33:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f445XBk28413
	for linux-xfs-outgoing; Thu, 3 May 2001 22:33:11 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f445XAF28410
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:33:10 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA02794
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:31:48 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA82482
	for linux-xfs@oss.sgi.com; Fri, 4 May 2001 15:31:52 +1000 (EST)
Date: Fri, 4 May 2001 15:31:52 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105040531.PAA82482@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - acls
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Incorporating some suggestions from John Trostel 
(and Andreas G.).

--Tim

Date:  Thu May  3 22:27:54 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94034a
linux/fs/posix_acl.c - 1.5
	- Don't update ATIME for ACLs.
	  If i_op's are not set then return EOPNOTSUPP (=ENOTSUP) instead
	  of EINVAL.

linux/fs/ext_attr.c - 1.3
	- Don't update ATIME for EAs.



From owner-linux-xfs@oss.sgi.com Thu May  3 22:38:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f445cUG28538
	for linux-xfs-outgoing; Thu, 3 May 2001 22:38:30 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f445cTF28535
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:38:29 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA03146
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 22:37:08 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id WAA52713;
	Thu, 3 May 2001 22:37:12 -0700 (PDT)
Date: Thu, 3 May 2001 22:36:53 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Mogens Kjaer <mk@crc.dk>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: NFS problems
In-Reply-To: <3AF1CF50.E795AB50@crc.dk>
Message-ID: <Pine.LNX.4.30.0105032234500.25517-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Are you referring to the second last Q on
> http://nfs.sourceforge.net ?

yes, you are right.  this is the bug I was thinking of...

> This is the other way around; having problems with a Linux NFS
> server and an IRIX NFS client, this is not what Trond's patch
> is referring to.
>
> Anyway, if the problem is solved both in the Linux kernel,
> glibc, and in IRIX then everybody would be happy.

oh, ok, did not know there was another bug...what is the correct fix in
IRIX cause I will post a bug and push it back to the folks here who can
deal with it...

-tduffy


From owner-linux-xfs@oss.sgi.com Thu May  3 23:08:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4468p729115
	for linux-xfs-outgoing; Thu, 3 May 2001 23:08:51 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4468pF29112
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 23:08:51 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id XAA05568
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 23:07:28 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA90234
	for linux-xfs@oss.sgi.com; Fri, 4 May 2001 16:07:30 +1000 (EST)
Date: Fri, 4 May 2001 16:07:30 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105040607.QAA90234@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - EA
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May  3 23:06:47 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94037a
linux/fs/ext_attr.c - 1.4
	- Like ACLs if no i_op then return EOPNOTSUPP instead of EINVAL.



From owner-linux-xfs@oss.sgi.com Thu May  3 23:42:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f446gnc30479
	for linux-xfs-outgoing; Thu, 3 May 2001 23:42:49 -0700
Received: from skif.spylog.net (skif.spylog.com [194.67.35.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f446gmF30476
	for <linux-xfs@oss.sgi.com>; Thu, 3 May 2001 23:42:48 -0700
Received: from mail.spylog.com (www.local [192.168.0.205])
	by skif.spylog.net (Postfix) with ESMTP id 6668F49C
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 10:42:47 +0400 (MSD)
Received: from an.local (an.local [192.168.4.50])
	by mail.spylog.com (Postfix) with ESMTP id 5C21C70F01
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 10:42:47 +0400 (MSD)
Received: by an.local (Postfix, from userid 501)
	id D923250B6B; Fri,  4 May 2001 10:42:45 +0400 (MSD)
Date: Fri, 4 May 2001 10:42:45 +0400
From: Andrey Nekrasov <andy@spylog.com>
To: linux-xfs@oss.sgi.com
Subject: Re: repquota bug?
Message-ID: <20010504104245.A3512@an.local>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <20010503231735.A1917@an.local> <andy@spylog.com> <10105040845.ZM55988@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <10105040845.ZM55988@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Fri, May 04, 2001 at 08:45:44AM -0500
Organization: SpyLOG ltd.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello Nathan Scott,

> > *** Report for user quotas on device /dev/hda3
> > Block grace time: 7days; Inode grace time: 7days
> >                         Block limits                File limits
> > User             used    soft    hard  grace    used  soft  hard  grace
> > ----------------------------------------------------------------------
> > andy      --   95684  400000       0           5196     0     0       
> > andy      --   95684  400000       0           5196     0     0       
> > andy      --   95684  400000       0           5196     0     0       
> > andy      --   95684  400000       0           5196     0     0       
> > andy      --   95684  400000       0           5196     0     0       
> > andy      --   95684  400000       0           5196     0     0       
> > ....
> > andy      --   95684  400000       0           5196     0     0
> > ...
> > ...
> > ...
> > 
> > Why?
> > 
> 
> Hmm, I've never seen this one before... I guess repquota just
> wants to make absolutely sure you know what Andy's usage is!
> 
> [digging through code]... do you have an /etc/passwd with
> multiple entries with the same uid (501) by any chance?

 No. Only one with uid 501:

andy@an /opt/in $ cat /etc/passwd|grep 501
andy:x:501:501:Andrey Nekrasov:/home/andy:/bin/zsh
andy@an /opt/in $

> Where you have "..." above, is it going into an infinite loop,
> or does it stop after some number of "andy" iterations?

 infinite loop
 
bye.
Andrey Nekrasov, SpyLOG.
http://www.spylog.com/

From owner-linux-xfs@oss.sgi.com Fri May  4 00:17:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f447HvC31145
	for linux-xfs-outgoing; Fri, 4 May 2001 00:17:57 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f447HsF31141
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 00:17:54 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id AAA01172
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 00:28:36 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA00572; Fri, 4 May 2001 17:16:35 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA57205;
	Fri, 4 May 2001 17:16:34 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105041716.ZM57219@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 17:16:32 -0500
In-Reply-To: Andrey Nekrasov <andy@spylog.com>
        "Re: repquota bug?" (May  4, 10:42am)
References: <20010503231735.A1917@an.local>  <andy@spylog.com> 
	<10105040845.ZM55988@wobbly.melbourne.sgi.com> 
	<20010504104245.A3512@an.local>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Andrey Nekrasov <andy@spylog.com>, linux-xfs@oss.sgi.com
Subject: Re: repquota bug?
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.110105041716.ZM57219.melbourne.sgi.com"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

--
--PART-BOUNDARY=.110105041716.ZM57219.melbourne.sgi.com
Content-Type: text/plain; charset=us-ascii

hi Andrey,

Could you try the attached patch to the quota-3.01-pre5
user tools & ensure it fixes the problem?  I've forwarded
it onto the other quota maintainers to get their feedback
too (bug explanation follows if you're interested).

thanks.


--- Forwarded mail from <nathans@wobbly.melbourne.sgi.com> ("Nathan Scott")

From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 17:04:15 -0500
To: Jan Kara <jack@ucw.cz>, Marco van Wieringen <mvw@planets.elm.net>
Subject: repquota bug

...[snip]...
The problem was basically that repquota can get into an
infinite loop on Redhat 7.1.  After some soul searching, it
turned out that the problem is to do with the implementation
of getpwent and getpwuid in the version of libc which ships
with that version of Redhat (which was why I had not seen it
before now myself).

I use getpwent in the xfs_scan_dquots, to find the users who
have quota information.  The problem is the "process_dquot"
callback routine makes a call to getpwuid, which resets (!)
the password entry state for subsequent getpwent calls, in
this particular libc version only it seems.  This reset
causes repquota to continually refetch the first passwd file
entry, instead of moving onto the next.

So, I've changed the code to pass the name associated with
the dquot id into the callback, so this reentrancy problem
no longer occurs.  For the other two quota formats, this
just means moving the id2name call out of repquota's "print"
callback and into the quotaio_v?.c files, and for XFS it
means there is no additional getpwuid() call since it has
already got the user/group name via getpwent/getgrent.
...[snip]...

---End of forwarded mail from <nathans@wobbly.melbourne.sgi.com> ("Nathan Scott")


-- 
Nathan

--PART-BOUNDARY=.110105041716.ZM57219.melbourne.sgi.com
X-Zm-Content-Name: infinite.patch
Content-Description: Text
Content-Type: text/plain ; name="infinite.patch" ; charset=us-ascii

diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/convertquota.c cvs/quota-tools/convertquota.c
--- pre5/quota-tools/convertquota.c	Wed May  2 02:35:34 2001
+++ cvs/quota-tools/convertquota.c	Fri May  4 16:51:09 2001
@@ -72,7 +72,7 @@
 	mntpoint = argstr[optind];
 }
 
-int convert_dquot(struct dquot *dquot)
+int convert_dquot(struct dquot *dquot, char *name)
 {
 	struct dquot newdquot;
 
@@ -88,8 +88,8 @@
 	newdquot.dq_dqb.dqb_btime = dquot->dq_dqb.dqb_btime;
 	newdquot.dq_dqb.dqb_itime = dquot->dq_dqb.dqb_itime;
 	if (qn->qh_ops->commit_dquot(&newdquot) < 0) {
-		errstr(_("Can't commit dquot for id %u: %s\n"),
-			(uint)dquot->dq_id, strerror(errno));
+		errstr(_("Can't commit dquot for id %u (%s): %s\n"),
+			(uint)dquot->dq_id, name, strerror(errno));
 		return -1;
 	}
 	return 0;
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio.h cvs/quota-tools/quotaio.h
--- pre5/quota-tools/quotaio.h	Wed May  2 03:19:18 2001
+++ cvs/quota-tools/quotaio.h	Fri May  4 15:57:40 2001
@@ -122,7 +122,7 @@
 	int (*write_info) (struct quota_handle * h);	/* Write info about quotafile */
 	struct dquot *(*read_dquot) (struct quota_handle * h, qid_t id);	/* Read dquot into memory */
 	int (*commit_dquot) (struct dquot * dquot);	/* Write given dquot to disk */
-	int (*scan_dquots) (struct quota_handle * h, int (*process_dquot) (struct dquot * dquot));	/* Scan quotafile and call callback on every structure */
+	int (*scan_dquots) (struct quota_handle * h, int (*process_dquot) (struct dquot * dquot, char * dqname));	/* Scan quotafile and call callback on every structure */
 	int (*report) (struct quota_handle * h, int verbose);	/* Function called after 'repquota' to print format specific file information */
 };
 
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_v1.c cvs/quota-tools/quotaio_v1.c
--- pre5/quota-tools/quotaio_v1.c	Wed May  2 19:32:22 2001
+++ cvs/quota-tools/quotaio_v1.c	Fri May  4 15:59:43 2001
@@ -46,13 +46,14 @@
 #include "quotaio_v1.h"
 #include "dqblk_v1.h"
 #include "quotaio.h"
+#include "quotasys.h"
 
 static int v1_init_io(struct quota_handle *h);
 static int v1_new_io(struct quota_handle *h);
 static int v1_write_info(struct quota_handle *h);
 static struct dquot *v1_read_dquot(struct quota_handle *h, qid_t id);
 static int v1_commit_dquot(struct dquot *dquot);
-static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 
 struct quotafile_ops quotafile_ops_1 = {
 init_io:	v1_init_io,
@@ -281,9 +282,10 @@
 /*
  *	Scan all dquots in file and call callback on each
  */
-static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *, char *))
 {
 	int rd;
+	char name[MAXNAMELEN];
 	struct v1_disk_dqblk ddqblk;
 	struct dquot *dquot = get_empty_dquot();
 	qid_t id = 0;
@@ -303,7 +305,8 @@
 			continue;
 		v1_disk2memdqblk(&dquot->dq_dqb, &ddqblk);
 		dquot->dq_id = id;
-		if ((rd = process_dquot(dquot)) < 0) {
+		id2name(dquot->dq_id, h->qh_type, name);
+		if ((rd = process_dquot(dquot, name)) < 0) {
 			free(dquot);
 			return rd;
 		}
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_v2.c cvs/quota-tools/quotaio_v2.c
--- pre5/quota-tools/quotaio_v2.c	Wed May  2 20:00:57 2001
+++ cvs/quota-tools/quotaio_v2.c	Fri May  4 15:59:20 2001
@@ -17,6 +17,7 @@
 #include "quotaio_v2.h"
 #include "dqblk_v2.h"
 #include "quotaio.h"
+#include "quotasys.h"
 
 typedef char *dqbuf_t;
 
@@ -25,7 +26,7 @@
 static int v2_write_info(struct quota_handle *h);
 static struct dquot *v2_read_dquot(struct quota_handle *h, qid_t id);
 static int v2_commit_dquot(struct dquot *dquot);
-static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 static int v2_report(struct quota_handle *h, int verbose);
 
 struct quotafile_ops quotafile_ops_2 = {
@@ -656,11 +657,12 @@
 #define get_bit(bmp, ind) ((bmp)[(ind) >> 3] & (1 << ((ind) & 7)))
 
 static int report_block(struct dquot *dquot, uint blk, char *bitmap,
-			int (*process_dquot) (struct dquot *))
+			int (*process_dquot) (struct dquot *, char *))
 {
 	dqbuf_t buf = getdqbuf();
 	struct v2_disk_dqdbheader *dh;
 	struct v2_disk_dqblk *ddata;
+	char name[MAXNAMELEN];
 	int entries, i;
 
 	set_bit(bitmap, blk);
@@ -672,7 +674,8 @@
 		if (!empty_dquot(ddata + i)) {
 			v2_disk2memdqblk(&dquot->dq_dqb, ddata + i);
 			dquot->dq_id = __le32_to_cpu(ddata[i].dqb_id);
-			if (process_dquot(dquot) < 0)
+			id2name(dquot->dq_id, dquot->dq_h->qh_type, name);
+			if (process_dquot(dquot, name) < 0)
 				break;
 		}
 	freedqbuf(buf);
@@ -680,7 +683,7 @@
 }
 
 static int report_tree(struct dquot *dquot, uint blk, int depth, char *bitmap,
-		       int (*process_dquot) (struct dquot *))
+		       int (*process_dquot) (struct dquot *, char *))
 {
 	int entries = 0, i;
 	dqbuf_t buf = getdqbuf();
@@ -714,7 +717,7 @@
 	return used;
 }
 
-static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *, char *))
 {
 	char *bitmap;
 	struct v2_mem_dqinfo *info = &h->qh_info.u.v2_mdqi;
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_xfs.c cvs/quota-tools/quotaio_xfs.c
--- pre5/quota-tools/quotaio_xfs.c	Wed Apr 11 20:06:06 2001
+++ cvs/quota-tools/quotaio_xfs.c	Fri May  4 15:38:40 2001
@@ -28,7 +28,7 @@
 static int xfs_write_info(struct quota_handle *h);
 static struct dquot *xfs_read_dquot(struct quota_handle *h, qid_t id);
 static int xfs_commit_dquot(struct dquot *dquot);
-static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 static int xfs_report(struct quota_handle *h, int verbose);
 
 struct quotafile_ops quotafile_ops_xfs = {
@@ -166,7 +166,8 @@
  */
 static int xfs_scan_dquot(struct quota_handle *h,
 			  struct xfs_kern_dqblk *d,
-			  struct dquot *dq, int (*process_dquot) (struct dquot * dquot))
+			  char *name, struct dquot *dq,
+			  int (*process_dquot) (struct dquot *dquot, char *dqname))
 {
 	int qcmd = QCMD(Q_XFS_GETQUOTA, h->qh_type);
 
@@ -180,13 +181,13 @@
 	    d->d_ino_hardlimit == 0 &&
 	    d->d_ino_softlimit == 0 && d->d_bcount == 0 && d->d_icount == 0) return 0;
 	xfs_kern2utildqblk(&dq->dq_dqb, d);
-	return process_dquot(dq);
+	return process_dquot(dq, name);
 }
 
 /*
  *	Scan all known dquots and call callback on each
  */
-static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname))
 {
 	struct dquot *dq;
 	struct xfs_kern_dqblk d;
@@ -203,7 +204,8 @@
 		setpwent();
 		while ((usr = getpwent()) != NULL) {
 			dq->dq_id = usr->pw_uid;
-			if ((rd = xfs_scan_dquot(h, &d, dq, process_dquot)) < 0)
+			rd = xfs_scan_dquot(h, &d, usr->pw_name, dq, process_dquot);
+			if (rd < 0)
 				break;
 		}
 		endpwent();
@@ -214,7 +216,8 @@
 		setgrent();
 		while ((grp = getgrent()) != NULL) {
 			dq->dq_id = grp->gr_gid;
-			if ((rd = xfs_scan_dquot(h, &d, dq, process_dquot)) < 0)
+			rd = xfs_scan_dquot(h, &d, grp->gr_name, dq, process_dquot);
+			if (rd < 0)
 				break;
 		}
 		endgrent();
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/repquota.c cvs/quota-tools/repquota.c
--- pre5/quota-tools/repquota.c	Wed May  2 03:16:07 2001
+++ cvs/quota-tools/repquota.c	Fri May  4 15:48:50 2001
@@ -97,15 +97,13 @@
 	return '-';
 }
 
-static int print(struct dquot *dquot)
+static int print(struct dquot *dquot, char *name)
 {
-	char name[MAXNAMELEN];
 	char time[MAXTIMELEN];
 	struct util_dqblk *entry = &dquot->dq_dqb;
 
 	if (!entry->dqb_curspace && !entry->dqb_curinodes && !(flags & FL_VERBOSE))
 		return 0;
-	id2name(dquot->dq_id, dquot->dq_h->qh_type, name);
 	difftime2str(entry->dqb_btime, time);
 	printf("%-10s%c%c%8Lu%8Lu%8Lu%7s", name,
 	       overlim(qb2kb(toqb(entry->dqb_curspace)), qb2kb(entry->dqb_bsoftlimit),
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/warnquota.c cvs/quota-tools/warnquota.c
--- pre5/quota-tools/warnquota.c	Wed May  2 19:32:22 2001
+++ cvs/quota-tools/warnquota.c	Fri May  4 16:56:14 2001
@@ -25,7 +25,6 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
-#include <pwd.h>
 
 #include "mntopt.h"
 #include "pot.h"
@@ -92,26 +91,22 @@
  */
 static struct offenderlist *offenders = (struct offenderlist *)0;
 
-struct offenderlist *add_offender(int id)
+struct offenderlist *add_offender(int id, char *name)
 {
-	struct passwd *pwd;
 	struct offenderlist *offender;
 
-	if ((pwd = getpwuid(id)) == (struct passwd *)0)
-		return ((struct offenderlist *)0);
-
 	offender = (struct offenderlist *)smalloc(sizeof(struct offenderlist));
 
 	offender->offender_id = id;
-	offender->offender_name = (char *)smalloc(strlen(pwd->pw_name) + 1);
+	offender->offender_name = (char *)smalloc(strlen(name) + 1);
 	offender->usage = (struct usage *)NULL;
-	strcpy(offender->offender_name, pwd->pw_name);
+	strcpy(offender->offender_name, name);
 	offender->next = offenders;
 	offenders = offender;
 	return offender;
 }
 
-void add_offence(struct dquot *dquot)
+void add_offence(struct dquot *dquot, char *name)
 {
 	struct offenderlist *lptr;
 	struct usage *usage;
@@ -121,7 +116,7 @@
 			break;
 
 	if (!lptr)
-		if (!(lptr = add_offender(dquot->dq_id)))
+		if (!(lptr = add_offender(dquot->dq_id, name)))
 			return;
 
 	usage = (struct usage *)smalloc(sizeof(struct usage));
@@ -135,13 +130,13 @@
 	lptr->usage = usage;
 }
 
-int check_offence(struct dquot *dquot)
+int check_offence(struct dquot *dquot, char *name)
 {
 	if (
 	    (dquot->dq_dqb.dqb_bsoftlimit
 	     && toqb(dquot->dq_dqb.dqb_curspace) >= dquot->dq_dqb.dqb_bsoftlimit)
 	    || (dquot->dq_dqb.dqb_isoftlimit
-		&& dquot->dq_dqb.dqb_curinodes >= dquot->dq_dqb.dqb_isoftlimit)) add_offence(dquot);
+		&& dquot->dq_dqb.dqb_curinodes >= dquot->dq_dqb.dqb_isoftlimit)) add_offence(dquot, name);
 	return 0;
 }
 

--PART-BOUNDARY=.110105041716.ZM57219.melbourne.sgi.com--


From owner-linux-xfs@oss.sgi.com Fri May  4 00:50:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f447oDe32039
	for linux-xfs-outgoing; Fri, 4 May 2001 00:50:13 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f447o8F32036
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 00:50:10 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id JAA799034
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:50:04 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA00728; Fri, 4 May 2001 17:48:30 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA48689;
	Fri, 4 May 2001 17:48:29 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105041748.ZM57041@wobbly.melbourne.sgi.com>
Date: Fri, 4 May 2001 17:48:27 -0500
In-Reply-To: Russell Cattelan <cattelan@thebarn.com>
        "Re: Mandrake RPM's" (May  3,  2:43pm)
References: <3AF049D9.4090201@runbox.com> 
	<m3bspbwotj.fsf@giants.mandrakesoft.com> 
	<3AF0A70D.C5CE4733@thebarn.com> 
	<m37kzyrhj1.fsf@giants.mandrakesoft.com> 
	<3AF1A6DC.67C1CA2F@thebarn.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Russell Cattelan <cattelan@thebarn.com>,
   Chmouel Boudjnah <chmouel@mandrakesoft.com>
Subject: Re: Mandrake RPM's
Cc: Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 3,  2:43pm, Russell Cattelan wrote:
> Subject: Re: Mandrake RPM's
> > > Anybody want help finish it.?
> >
> > Could you send me the patch, i had a lot of conflict and i did the
> > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> 
> ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> 
> this was a real quick attempt to get it to compile, area that are suspect
> and may not be right :
> dquot.c

In addition to the stuff you've done already, you also
need that little dquot.c patch I sent out earlier here,
else we wont get the XFS quotactl commands being handed
off to XFS.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Fri May  4 00:59:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f447xpE32443
	for linux-xfs-outgoing; Fri, 4 May 2001 00:59:51 -0700
Received: from emma1.emma.line.org (postfix@p3EE3CC81.dip.t-dialin.net [62.227.204.129])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f447xnF32440
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 00:59:50 -0700
Received: by emma1.emma.line.org (Postfix, from userid 500)
	id 097BBA2001; Fri,  4 May 2001 09:59:44 +0200 (CEST)
Date: Fri, 4 May 2001 09:59:44 +0200
From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
To: linux-xfs@oss.sgi.com
Subject: Is an XFS core patch in the works for Linux 2.4.4?
Message-ID: <20010504095943.A5171@emma1.emma.line.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

See subject.

Thanks in advance.

From owner-linux-xfs@oss.sgi.com Fri May  4 01:40:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f448ejI00774
	for linux-xfs-outgoing; Fri, 4 May 2001 01:40:45 -0700
Received: from skif.spylog.net (skif.spylog.com [194.67.35.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f448eiF00771
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 01:40:44 -0700
Received: from mail.spylog.com (www.local [192.168.0.205])
	by skif.spylog.net (Postfix) with ESMTP id 452134BC
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 12:40:43 +0400 (MSD)
Received: from an.local (an.local [192.168.4.50])
	by mail.spylog.com (Postfix) with ESMTP id 3B91070F01
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 12:40:43 +0400 (MSD)
Received: by an.local (Postfix, from userid 501)
	id 1E4D750B6B; Fri,  4 May 2001 12:40:43 +0400 (MSD)
Date: Fri, 4 May 2001 12:40:43 +0400
From: Andrey Nekrasov <andy@spylog.com>
To: linux-xfs@oss.sgi.com
Subject: Re: repquota bug?
Message-ID: <20010504124043.C4117@an.local>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <20010503231735.A1917@an.local> <andy@spylog.com> <10105040845.ZM55988@wobbly.melbourne.sgi.com> <20010504104245.A3512@an.local> <andy@spylog.com> <10105041716.ZM57219@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <10105041716.ZM57219@wobbly.melbourne.sgi.com>; from nathans@wobbly.melbourne.sgi.com on Fri, May 04, 2001 at 05:16:32PM -0500
Organization: SpyLOG ltd.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello Nathan Scott,

Once you wrote about "Re: repquota bug?":
> hi Andrey,
> 
> Could you try the attached patch to the quota-3.01-pre5
> user tools & ensure it fixes the problem?  I've forwarded
> it onto the other quota maintainers to get their feedback
> too (bug explanation follows if you're interested).

OK!

(1)

root@an /opt/in/quota-tools # ./repquota -a
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
root      --       0       0       0              3     0     0       
andy      --   96164  400000       0           5310     0     0       


root@an /opt/in/quota-tools #


(2)

andy@an /opt/in/quota-tools $ ./repquota /dev/hda3
*** Report for user quotas on device /dev/hda3
Block grace time: 7days; Inode grace time: 7days
                        Block limits                File limits
User            used    soft    hard  grace    used  soft  hard  grace
----------------------------------------------------------------------
andy      --   96160  400000       0           5309     0     0       


andy@an /opt/in/quota-tools $


(3)

andy@an /opt/in/quota-tools $ rpm -q glibc
glibc-2.2.2-4mdk

thanks.

Andrey Nekrasov, SpyLOG.
http://www.spylog.com/

From owner-linux-xfs@oss.sgi.com Fri May  4 02:07:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4497K601564
	for linux-xfs-outgoing; Fri, 4 May 2001 02:07:20 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4497JF01561
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 02:07:20 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 0D821CCAE; Fri,  4 May 2001 11:05:13 +0100 (BST)
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Sven Herzberg <herzi@runbox.com>, linux-xfs@oss.sgi.com,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
	<m3bspbwotj.fsf@giants.mandrakesoft.com>
	<3AF0A70D.C5CE4733@thebarn.com>
	<m37kzyrhj1.fsf@giants.mandrakesoft.com>
	<3AF1A6DC.67C1CA2F@thebarn.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 04 May 2001 11:05:13 +0100
In-Reply-To: <3AF1A6DC.67C1CA2F@thebarn.com> (Russell Cattelan's message of "Thu, 03 May 2001 14:43:40 -0400")
Message-ID: <m3bsp9xwdi.fsf@giants.mandrakesoft.com>
Lines: 33
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

> If you don't mind, I'll will put this link in our "news" segment on our
> web page?

Sure.

> > > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > > yet but it does compile.
> > > Anybody want help finish it.?
> > Could you send me the patch, i had a lot of conflict and i did the
> > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> this was a real quick attempt to get it to compile, area that are suspect
> and may not be right :
> dquot.c
> and  param addition  to do_mount_nd
> probably a better way to go about  getting the dir name to the dmapi
> mount,
> or even look at the code closer and move the dmapi stuff back into
> do_mount.

ok i'll look at that...

> > > If fact I would to encourage some savvy installer programmer to add
> > > XFS support to the mandrake installer. I've looked at the code and
> > > see reiserfs is already in there shouldn't be to much work to add
> > > xfs.
> > I already begin it, it should be fairly simple...
> Great let us know if you have any questions, obviously we had to struggle
> with a few problems  on anaconda.

ok..

From owner-linux-xfs@oss.sgi.com Fri May  4 02:08:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4498JC01615
	for linux-xfs-outgoing; Fri, 4 May 2001 02:08:19 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4498IF01610
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 02:08:18 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 0BE65CCAE; Fri,  4 May 2001 11:06:23 +0100 (BST)
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
References: <Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
	<3AF1A4EF.EE82780F@thebarn.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 04 May 2001 11:06:23 +0100
In-Reply-To: <3AF1A4EF.EE82780F@thebarn.com> (Russell Cattelan's message of "Thu, 03 May 2001 14:35:27 -0400")
Message-ID: <m37kzxxwbk.fsf@giants.mandrakesoft.com>
Lines: 9
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

>     gcc 2.95RH7.1    ditto.

humm i haven't see a 2.95 for rh.

>     gcc 2.96Mandrake Not attempted yet.

ditto of 2.96RH

From owner-linux-xfs@oss.sgi.com Fri May  4 02:55:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f449tGl02666
	for linux-xfs-outgoing; Fri, 4 May 2001 02:55:16 -0700
Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f449tFF02663
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 02:55:15 -0700
Received: from sid.mpc.local ([172.16.20.7] helo=moving-picture.com)
	by moving-picture.com with esmtp (Exim 3.16 #1)
	id 14vcId-0000zM-00; Fri, 04 May 2001 10:54:59 +0100
Message-ID: <3AF27C73.45A23A7D@moving-picture.com>
Date: Fri, 04 May 2001 10:54:59 +0100
From: James Pearson <james-p@moving-picture.com>
Organization: Moving Picture Company
X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22)
X-Accept-Language: en
MIME-Version: 1.0
To: Nathan Scott <nathans@wobbly.melbourne.sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
References: <3AF16D0A.2D12C344@moving-picture.com> <10105041522.ZM56847@wobbly.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks - that seems to have fixed it - although I've now hit a problem
with  repquota endlessly looping - but I notice that this has already
been reported.

James Pearson

Nathan Scott wrote:
> 
> hi James,
> 
> On May 3,  3:36pm, James Pearson wrote:
> > Subject: Problem setting up quotas ...
> > ...
> > # edquota james
> > No filesystems with quota detected.
> >
> 
> OK, this is a bug in the way the Redhat 7.1 kernel rpms
> were integrated with the XFS code.  Here is a patch which
> will fix it - Eric has tested this for me & it works.
> 
> It _only_ affects the kernel rpms with Redhat 7.1 changes
> - the base 2.4.2 patches, cvs trees, etc. are not affected
> and _do not_ need the patch..
> 
> --- fs/dquot.c.orig     Fri May  4 10:17:40 2001
> +++ fs/dquot.c  Fri May  4 11:02:13 2001
> @@ -2001,7 +2001,7 @@
>         type = cmd & SUBCMDMASK;
> 
> 
> -       if ((uint) type >= MAXQUOTAS || cmds > 0x0F00 || cmds < 0x100 || cmds == 0x0300 ||
> +       if ((uint) type >= MAXQUOTAS || cmds < 0x100 || cmds == 0x0300 ||
>             cmds == 0x0400 || cmds == 0x0500)
>                 goto out;
> 
> @@ -2049,9 +2049,6 @@
>                 unlock_kernel();
>                 return sb->s_op->quotactl(sb, cmds, type, id, addr);
>         }
> -
> -       if (id & ~0xFFFF)
> -               goto out;
> 
>         ret = -EINVAL;
>         switch (cmds) {
> 
> > ...
> > Incidentally, the examples in /usr/share/doc/xfsprogs/README.quota and
> > the quotaon man page don't agree with the actual commands e.g.
> >
> > in README.quota the syntax to the setquota example is incorrect.
> >
> > in quotaon(8), the examples talk about a -s option to repquota and a -o
> > option to quotaoff which don't seem to exist ...
> >
> 
> That's been updated in the development tree now -- thanks.
> 
> cheers.
> 
> --
> Nathan

From owner-linux-xfs@oss.sgi.com Fri May  4 03:00:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44A0EY02771
	for linux-xfs-outgoing; Fri, 4 May 2001 03:00:14 -0700
Received: from berlin.sharemedia.com ([151.200.228.42])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44A0DF02768
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 03:00:13 -0700
Received: from berlin.sharemedia.com (berlin.sharemedia.com [127.0.0.1])
	by berlin.sharemedia.com (8.9.3/8.9.3) with ESMTP id GAA22859
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 06:00:13 -0400
Date: Fri, 4 May 2001 06:00:13 -0400
Message-ID: <3141749.988970413359.JavaMail.sharemail@berlin.sharemedia.com>
From: Dave Strout <dstrout@sharemedia.com>
To: linux-xfs@oss.sgi.com
Subject: xfs root filesystem on SGI 1450?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Does anybody have any idea why the kernel that's on the RH7.1 
ISO image locks up on an SGI 1450?  The regular RH 7.1 CD works 
just fine, but the XFS iso locks while probing for hda.

My config is:
SGI 1450, 1GB ram, 5x32GB SCSI HD on DAC960 raid controller, 
2xPIII xeon @700MHz

One other sympton I noticed is that if I use 'expert' or 'linux 
dd', I get into the text-mode anaconda, but it's _really_ 
slow.  /sbin/loader takes several minutes to get me to the "do 
you have a driver disk" prompt, then locks up.

Floppies made from the iso produce the same results.....

Any ideas welcome.....

thanks,
dave.

-- 

"I have a malformed public duty gland and a natural deficiency in moral fiber and am therefore excused from saving universes." 


From owner-linux-xfs@oss.sgi.com Fri May  4 03:01:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44A1XO02801
	for linux-xfs-outgoing; Fri, 4 May 2001 03:01:33 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44A1WF02798
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 03:01:32 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id DAA00087
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 03:01:29 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01201; Fri, 4 May 2001 19:59:45 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA51968;
	Fri, 4 May 2001 19:59:45 +1000 (EST)
Date: Fri, 4 May 2001 19:59:44 +1000
From: Nathan Scott <nathans@sgi.com>
To: James Pearson <james-p@moving-picture.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Problem setting up quotas ...
Message-ID: <20010504195944.A36169@wobbly.melbourne.sgi.com>
References: <3AF16D0A.2D12C344@moving-picture.com> <10105041522.ZM56847@wobbly.melbourne.sgi.com> <3AF27C73.45A23A7D@moving-picture.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <3AF27C73.45A23A7D@moving-picture.com>; from james-p@moving-picture.com on Fri, May 04, 2001 at 10:54:59AM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On Fri, May 04, 2001 at 10:54:59AM +0100, James Pearson wrote:
> Thanks - that seems to have fixed it - although I've now hit a problem
> with  repquota endlessly looping - but I notice that this has already
> been reported.
> 

and fixed - Jan has now checked the fix into the quota CVS
tree (see http://sourceforge.net/projects/linuxquota/), so
the fix will be in the next 3.01-pre release.

cheers.

From owner-linux-xfs@oss.sgi.com Fri May  4 07:00:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44E0J110695
	for linux-xfs-outgoing; Fri, 4 May 2001 07:00:19 -0700
Received: from flowers.house.larsshack.org (lars@h00059aa0e40d.ne.mediaone.net [66.31.89.164])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44E0IF10684
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:00:18 -0700
Received: from localhost (lars@localhost)
	by flowers.house.larsshack.org (8.11.0/8.11.0) with ESMTP id f44E0CF00858
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:00:12 -0400
X-Authentication-Warning: flowers.house.larsshack.org: lars owned process doing -bs
Date: Fri, 4 May 2001 10:00:12 -0400 (EDT)
From: Lars Kellogg-Stedman <lars@larsshack.org>
X-X-Sender:  <lars@flowers.house.larsshack.org>
To: <linux-xfs@oss.sgi.com>
Subject: 2.4.5pre patches and XFS cvs...
Message-ID: <Pine.LNX.4.33.0105040958260.1786-100000@flowers.house.larsshack.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Howdy,

The discussion on linux-kernel and elsewhere makes it sound like some of
the patches that made it into 2.4.4 have been quickly ripped out (such as
the fork patch).

Will these changes make it into the XFS development CVS tree, or will
folks wait for 2.4.5 before synchronizing?

Thanks,

-- Lars

-- 
Lars Kellogg-Stedman <lars@larsshack.org>


From owner-linux-xfs@oss.sgi.com Fri May  4 07:19:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EJ1J11204
	for linux-xfs-outgoing; Fri, 4 May 2001 07:19:01 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EIxF11200
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:18:59 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f44EIvwH058345;
	Fri, 4 May 2001 09:18:57 -0500 (CDT)
Message-ID: <3AF2BA4B.AFA4793F@thebarn.com>
Date: Fri, 04 May 2001 09:18:52 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Chmouel Boudjnah <chmouel@mandrakesoft.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
References: <Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
		<3AF1A4EF.EE82780F@thebarn.com> <m37kzxxwbk.fsf@giants.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chmouel Boudjnah wrote:

> Russell Cattelan <cattelan@thebarn.com> writes:
>
> >     gcc 2.95RH7.1    ditto.
>
> humm i haven't see a 2.95 for rh.

Opps typo.  That should have been gcc2.96RH7.1

>
>
> >     gcc 2.96Mandrake Not attempted yet.
>
> ditto of 2.96RH

gibble[2:02am]-=>gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)

I assume this is the compiler 8.0 is defaulting to for the kernel
compile?


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri May  4 07:20:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EKid11268
	for linux-xfs-outgoing; Fri, 4 May 2001 07:20:44 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EKhF11265
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:20:43 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f44EKdq20010;
	Fri, 4 May 2001 09:20:39 -0500
Message-Id: <4.2.0.58.20010504092022.01608f00@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 04 May 2001 09:20:46 -0500
To: Eric Sandeen <sandeen@sgi.com>, "William L. Jones" <jones@hpc.utexas.edu>
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: Re: mkinitrd hang
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3AF2245A.36FFD7B2@sgi.com>
References: <01050321241200.04916@marvin>
 <4.2.0.58.20010503222326.015069b8@127.0.0.1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


The cvs check out.


At 10:39 PM 5/3/2001 -0500, Eric Sandeen wrote:
>"William L. Jones" wrote:
> >
> > mkinitrd is hanging on a mkfs on the loop back device.
> > Has any one seen this problem.
> >
> > I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running Redhat 7.1.
>
>Was this installed from our RPMs, or did you patch a vanilla kernel
>yourself, or do a cvs checkout?
>
>-Eric
>
>--
>Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
>sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Fri May  4 07:25:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EPqx11491
	for linux-xfs-outgoing; Fri, 4 May 2001 07:25:52 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EPpF11488
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:25:51 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f44EPlwH058393;
	Fri, 4 May 2001 09:25:47 -0500 (CDT)
Message-ID: <3AF2BBE5.C675CD7D@thebarn.com>
Date: Fri, 04 May 2001 09:25:41 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthias Andree <ma@dt.e-technik.uni-dortmund.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: Is an XFS core patch in the works for Linux 2.4.4?
References: <20010504095943.A5171@emma1.emma.line.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Matthias Andree wrote:

> See subject.
>
> Thanks in advance.

Yes but XFS and 2.4.4 have a few problems.
One of our stress testing is causing a panic.


Another report has nfs hanging under load... although

this has yet been linked to XFS.

If you really want to run 2.4.4 grab the devel tree for the moment.

Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri May  4 07:27:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44ERVf11537
	for linux-xfs-outgoing; Fri, 4 May 2001 07:27:31 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44ERUF11534
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:27:30 -0700
Received: from harrar (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f44ERTq20108;
	Fri, 4 May 2001 09:27:29 -0500
Message-Id: <4.2.0.58.20010504092712.015a3db0@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 04 May 2001 09:27:36 -0500
To: Eric Sandeen <sandeen@sgi.com>, "William L. Jones" <jones@hpc.utexas.edu>,
   linux-xfs@oss.sgi.com
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: Re: mkinitrd hang
In-Reply-To: <3AF2268F.65DBAC08@sgi.com>
References: <01050321241200.04916@marvin>
 <4.2.0.58.20010503222326.015069b8@127.0.0.1>
 <3AF2245A.36FFD7B2@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hmm,

I should have read the instruction more carefully. Thanks!


At 10:48 PM 5/3/2001 -0500, Eric Sandeen wrote:
>Eric Sandeen wrote:
> >
> > "William L. Jones" wrote:
> > >
> > > mkinitrd is hanging on a mkfs on the loop back device.
> > > Has any one seen this problem.
> > >
> > > I am runing linux-2.4-xfs-r1.0  build with kcc on a amd running 
> Redhat 7.1.
> >
> > Was this installed from our RPMs, or did you patch a vanilla kernel
> > yourself, or do a cvs checkout?
>
>Sorry, I should complete that thought.  :)
>
>If you patched your own kernel, and especially if you did a cvs
>checkout, the loop device is probably broken (it was broken in Linus'
>tree at least through 2.4.2...)
>
>The loop patches in
>ftp://linux-xfs.sgi.com/projects/xfs/download/archive/Release-1.0-test2/pat 
>ches/
>will *probably* apply cleanly for you if you have a vanilla 2.4.2 kernel
>+ XFS.
>
>But if you're on Red Hat, I'd suggest using the kernel-source RPM we
>packaged, as it has many other fixes, as well, thanks to Red Hat.
>
>If you're already using our RPM, then I'm not sure what the solution
>will be.
>
>-Eric
>
>--
>Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
>sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Fri May  4 07:31:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EV4x11629
	for linux-xfs-outgoing; Fri, 4 May 2001 07:31:04 -0700
Received: from mout1.freenet.de (exim@mout1.freenet.de [194.97.50.132])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EV2F11625
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:31:03 -0700
Received: from [194.97.50.135] (helo=mx2.freenet.de)
	by mout1.freenet.de with esmtp (Exim 3.22 #1)
	id 14vgbm-0005PI-00
	for linux-xfs@oss.sgi.com; Fri, 04 May 2001 16:31:02 +0200
Received: from add0b.pppool.de ([213.6.221.11] helo=freakmail.de)
	by mx2.freenet.de with asmtp (ID thh@freakmail.de) (Exim 3.22 #1)
	id 14vgbl-0006qk-00
	for linux-xfs@oss.sgi.com; Fri, 04 May 2001 16:31:01 +0200
Message-ID: <3AF2BD35.46EC15B8@freakmail.de>
Date: Fri, 04 May 2001 16:31:17 +0200
From: ThH <thh@freakmail.de>
X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.2xfs i586)
X-Accept-Language: de
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: XFS 1.0 on AlphaLinux LVM
Content-Type: multipart/mixed;
 boundary="------------B1F76AC82E39A067D90D02E2"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------B1F76AC82E39A067D90D02E2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

like with 0.10.3, the Release 1.0 doesn't work with my
LinuxAlphastation. This time I've added a part of the /var/log/messages
file. These error occurse when I try to mount the logical volume
formated with xfs. I can not mount or umount anything after this
happened, and have to do a reset.
It may be that this will help to find the bug.
I've used the source tree from kernel-2.4.2-SGI_XFS-1.0.src.rpm after
doing the prep state.

ThH
--------------B1F76AC82E39A067D90D02E2
Content-Type: text/plain; charset=us-ascii;
 name="xfs1.0onlvmonalpha.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="xfs1.0onlvmonalpha.log"

May  4 15:55:56 alpha kernel: mount(753): Kernel Bug 1
May  4 15:55:56 alpha kernel: pc = [<fffffc0000454250>]  ra = [<fffffc0000454d4c>]  ps = 0000
May  4 15:55:56 alpha kernel: v0 = fffffc0005fe94b0  t0 = 0000000000000200  t1 = 0000000000000000
May  4 15:55:56 alpha kernel: t2 = fffffc0005fef000  t3 = 0000000000000800  t4 = ffffffff00000000
May  4 15:55:56 alpha kernel: t5 = 0000000000000001  t6 = 00000000001f4b1c  t7 = fffffc000199c000
May  4 15:55:56 alpha kernel: a0 = fffffc0005fe94b0  a1 = fffffc0003c75520  a2 = fffffc0003c74c20
May  4 15:55:56 alpha kernel: a3 = 0000000000003a01  a4 = fffffc000066b988  a5 = 0000000000000001
May  4 15:55:56 alpha kernel: t8 = 0000000000000004  t9 = fffffc0000518b08  t10= 00000000002bfff0
May  4 15:55:56 alpha kernel: t11= 0000000000002000  pv = fffffc00004541c0  at = 0000000000000001
May  4 15:55:56 alpha kernel: gp = fffffc000063ae20  sp = fffffc000199f5f8
May  4 15:55:56 alpha kernel: Code: a02c0058  ldl t0,88(s3)
May  4 15:55:56 alpha kernel:  e5600001  blt s2,.+8
May  4 15:55:56 alpha kernel:  a02d0004  ldl t0,4(s4)
May  4 15:55:56 alpha kernel:  b43e0070  stq t0,112(sp)
May  4 15:55:56 alpha kernel:  c3e00002  br .+12
May  4 15:55:56 alpha kernel:  00000081  call_pal 129
May  4 15:55:56 alpha kernel: *c3e0024f  br .+2368
May  4 15:55:57 alpha kernel:  a42a0020  ldq t0,32(s1)
May  4 15:55:57 alpha kernel: 
May  4 15:55:57 alpha kernel: Trace:454d4c 518fe0 3c3d38 454d64 3c3eb8 3c41c4 3c4790 3c4320 3c3fe0 3c367c 3c2d64
May  4 15:55:57 alpha kernel: 43d970 428560 4324c0 427bb8 4323a8 4328bc 432934 4473e0 34fda4 3658a8 353444
May  4 15:55:57 alpha kernel: 35012c 34fb9c 34fca8 350190 351514 351830 351810 310aa0 3109f8 

--------------B1F76AC82E39A067D90D02E2
Content-Type: text/x-vcard; charset=us-ascii;
 name="thh.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Visitenkarte für ThH
Content-Disposition: attachment;
 filename="thh.vcf"

begin:vcard 
n:Heinemann;Thomas
tel;cell:(0177) 74 33 93 7
tel;home:(03928) 84 62 31
x-mozilla-html:FALSE
adr:;;Berliner Str. 1;Schönebeck;Sachsen-Anhalt;39218;Deutschland
version:2.1
email;internet:thh@freakmail.de
x-mozilla-cpt:;640
fn:Heinemann, Thomas
end:vcard

--------------B1F76AC82E39A067D90D02E2--


From owner-linux-xfs@oss.sgi.com Fri May  4 07:32:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EWca11715
	for linux-xfs-outgoing; Fri, 4 May 2001 07:32:38 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EWbF11701
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:32:37 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f44EWZwH058416;
	Fri, 4 May 2001 09:32:36 -0500 (CDT)
Message-ID: <3AF2BD7E.1F2CFE15@thebarn.com>
Date: Fri, 04 May 2001 09:32:30 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Lars Kellogg-Stedman <lars@larsshack.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: 2.4.5pre patches and XFS cvs...
References: <Pine.LNX.4.33.0105040958260.1786-100000@flowers.house.larsshack.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Lars Kellogg-Stedman wrote:

> Howdy,
>
> The discussion on linux-kernel and elsewhere makes it sound like some of
> the patches that made it into 2.4.4 have been quickly ripped out (such as
> the fork patch).
>
> Will these changes make it into the XFS development CVS tree, or will
> folks wait for 2.4.5 before synchronizing?

Generally we resist tossing every 2.4.x-prex version of the linux tree into
ours
simply  because we don't want to spend all of our time merging code and
we need some stability.
But if thing in 2.4.4 prove to be horribly broken we may consider moving
up.

>
>
> Thanks,
>
> -- Lars
>
> --
> Lars Kellogg-Stedman <lars@larsshack.org>

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri May  4 07:40:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EeUQ11939
	for linux-xfs-outgoing; Fri, 4 May 2001 07:40:30 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EeTF11936
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:40:29 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f44EeRwH058629;
	Fri, 4 May 2001 09:40:27 -0500 (CDT)
Message-ID: <3AF2BF56.847EB08C@thebarn.com>
Date: Fri, 04 May 2001 09:40:22 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Strout <dstrout@sharemedia.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs root filesystem on SGI 1450?
References: <3141749.988970413359.JavaMail.sharemail@berlin.sharemedia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dave Strout wrote:

> Does anybody have any idea why the kernel that's on the RH7.1
> ISO image locks up on an SGI 1450?  The regular RH 7.1 CD works
> just fine, but the XFS iso locks while probing for hda.
>
> My config is:
> SGI 1450, 1GB ram, 5x32GB SCSI HD on DAC960 raid controller,
> 2xPIII xeon @700MHz
>
> One other sympton I noticed is that if I use 'expert' or 'linux
> dd', I get into the text-mode anaconda, but it's _really_
> slow.  /sbin/loader takes several minutes to get me to the "do
> you have a driver disk" prompt, then locks up.
>
> Floppies made from the iso produce the same results.....
>
> Any ideas welcome.....

>

The only thing that changed with on  1.0 release CD was the
BOOT kernel has APIC enabled due to a bug in the 1200's.

The BOOT image on the Release-1.0-test3 did not have APIC enabled
you could try that one to see if it make a difference.

This would be a real pain if we fix one machine and break the other...
argghh.



>
> --
>
> "I have a malformed public duty gland and a natural deficiency in moral fiber and am therefore excused from saving universes."

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Fri May  4 07:51:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EplV12613
	for linux-xfs-outgoing; Fri, 4 May 2001 07:51:47 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EpkF12609
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:51:46 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id C15C8CC26; Fri,  4 May 2001 16:49:50 +0100 (BST)
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange files, XFS bug?
References: <Pine.LNX.4.33.0105031528580.10540-100000@vie-ac.office.ecetra.com>
	<3AF1A4EF.EE82780F@thebarn.com>
	<m37kzxxwbk.fsf@giants.mandrakesoft.com>
	<3AF2BA4B.AFA4793F@thebarn.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 04 May 2001 16:49:50 +0100
In-Reply-To: <3AF2BA4B.AFA4793F@thebarn.com> (Russell Cattelan's message of "Fri, 04 May 2001 09:18:52 -0500")
Message-ID: <m3k83x6rmp.fsf@giants.mandrakesoft.com>
Lines: 13
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

> gibble[2:02am]-=>gcc -v
> Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
> gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)

yup this one is based on on rh2.96-80

> I assume this is the compiler 8.0 is defaulting to for the kernel
> compile?

no, we use kgcc to compile kernel for safely (even this gcc should
works fine).

From owner-linux-xfs@oss.sgi.com Fri May  4 07:52:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44EqQI12643
	for linux-xfs-outgoing; Fri, 4 May 2001 07:52:26 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44EqPF12638
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 07:52:25 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f44EqGA23592;
	Fri, 4 May 2001 09:52:16 -0500 (CDT)
Message-ID: <3AF2C284.4E34597C@sgi.com>
Date: Fri, 04 May 2001 09:53:56 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Dave Strout <dstrout@sharemedia.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs root filesystem on SGI 1450?
References: <3141749.988970413359.JavaMail.sharemail@berlin.sharemedia.com> <3AF2BF56.847EB08C@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Try booting with "noapic" as one of the boot parameters at the boot
prompt.


   noapic     [SMP,APIC] Tells the kernel not to make use of any
              APIC that may be present on the system.

-Eric

Russell Cattelan wrote:

> The only thing that changed with on  1.0 release CD was the
> BOOT kernel has APIC enabled due to a bug in the 1200's.
> 
> The BOOT image on the Release-1.0-test3 did not have APIC enabled
> you could try that one to see if it make a difference.
> 
> This would be a real pain if we fix one machine and break the other...
> argghh.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 08:04:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44F45613009
	for linux-xfs-outgoing; Fri, 4 May 2001 08:04:05 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44F43F13005
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 08:04:03 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f44F40S07357;
	Fri, 4 May 2001 10:04:00 -0500 (CDT)
Message-ID: <3AF2C545.7C08D0BC@sgi.com>
Date: Fri, 04 May 2001 10:05:41 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Strout <dstrout@sharemedia.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs root filesystem on SGI 1450?
References: <3141749.988970413359.JavaMail.sharemail@berlin.sharemedia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dave Strout wrote:
> 
> Does anybody have any idea why the kernel that's on the RH7.1
> ISO image locks up on an SGI 1450?  The regular RH 7.1 CD works
> just fine, but the XFS iso locks while probing for hda.

Ah, there was a similar discussion on the seawolf list.

see:
https://listman.redhat.com/pipermail/seawolf-list/2001-April/001097.html

This was a 1200, not a 1450, but having similar problems with the
DAC960, so you might try Red Hat's suggestion in that thread.

See also the "dac960" thread earlier in this list.

Sounds like it may be related...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 08:10:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44FAdb13259
	for linux-xfs-outgoing; Fri, 4 May 2001 08:10:39 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44FAaF13255
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 08:10:37 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GCT006HBGTCFR@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Fri,
 04 May 2001 10:10:25 -0500 (CDT)
Date: Fri, 04 May 2001 11:09:35 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: vmware broken again:
In-reply-to: <20010503190030.A1752@bistro.marx>
To: pac@fortuitous.com
Cc: linux-xfs@oss.sgi.com
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010504110935.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Look at /usr/lib/vmware/modules/source/vmnet.tar (from vmware build 799)

Inside this tar should be a file vmnet-only/vnetInt.h

This file needs to be patched as follows:

after

 #define DEV_KFREE_SKB(skb, type) dev_kfree_skb(skb)
 #define SKB_INCREF(skb) atomic_inc(&(skb)->users)

add the following

 #ifdef KERNEL_2_4_0
 #define SKB_IS_CLONE_OF(clone, skb) ( \
  skb_cloned(clone) \
  )
 #else

then, skip over the following original lines

 # define SKB_IS_CLONE_OF(clone, skb) ( \
 skb_datarefp(clone) == skb_datarefp(skb) \
 )

and after these lines add this final endif

# endif

---------------------

This made my vmware work again... YMMV 

On 04-May-2001 pac@fortuitous.com wrote:
>   
>   I just fixed the vmware modules two work with 2.4.X kernels,
>   now it looks like you have returned the code to its original state.
>   I used the old modules from vmware, but now the system locks up tight
>   (the whole, system, no consoles, cant ssh/telnet in).
> 
>  Using 2.4.3-xfs kernel tree, on Duron system. 
> Linux bistro 2.4.3-xfs #1 Thu May 3 11:52:51 CDT 2001 i686 unknown
> 
>>make: Entering directory `/root/tmp/vmware-config1/vmnet-only'
>>bridge.c: In function `VNetBridgeReceiveFromDev':
>>bridge.c:788: warning: implicit declaration of function `skb_shinfo'
>>make: Leaving directory `/root/tmp/vmware-config1/vmnet-only'
>>Unable to make a vmnet module that can be loaded in the running kernel:
>>/root/tmp/vmware-config1/vmnet.o: unresolved symbol skb_shinfo
>>There is probably a light difference of kernel configuration between the set
>>of 
>>C header files you specified and your running kernel. You may want to rebuild
>>a 
>>kernel based on that directory, or specify another directory.
>>
>>For more information on how to troubleshoot module-related problems, please
>>have
>>a look at "http://www.vmware.com/download/modules/modules.html".
> -- 
> 
>  Here is the info I used to "fix" the problem in the first place
>  for 2.4.2 and above kernels (no XFS)
>  (its not fixed in the xfs kernels ):
> 
>>> : patch -p0 < patch-skb
>>> patching file vmnet-only/vnetInt.h
>>> Hunk #1 FAILED at 16.
>>> 1 out of 1 hunk FAILED -- saving rejects to file vmnet-only/vnetInt.h.rej
>>>
>>>  Im not patch expert, so Im sorta lost.. i attached the file just in
>>>   case you can illuminate the problem.
>>
>>Maybe you need to remove '\r' from my patch, if your news browser did
>>not do it: tr -d "\r" < patch-skb > patch-skb-ok; patch -p0 < patch-skb-ok
>                                                 >
>>'patch' program just removes lines marked with '- ' and adds lines
>>marked with '+ ' into file, checking that '  ' marked lines are really
>>in file to verify that it patches correct file at correct position.
>>
>>If it will not help, just replace
>>
>>skb_datarefp(clone) == skb_datarefp(skb)
>>
>>with
>>
>>skb_shinfo(clone) == skb_shinfo(clone)
>>
>>In old kernels there was only reference counter at the end of SKB, so
>>function was named skb_datarefp(). Now there is more info stored here,
>>so function was renamed to skb_shinfo() (from SHared INFOrmation)...
>                                  >
> 
>   -Phil C.
> .---------------------------------------------------------
>| P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
>| Fortuitous Technologies Inc. |  http://fortuitous.com   |
>| Linux Training Services      |  Tel : 1-512 467-2154    |
>| Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
>  ---------------------------------------------------------

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Fri May  4 08:37:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44FbMb14521
	for linux-xfs-outgoing; Fri, 4 May 2001 08:37:22 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44FbLF14518
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 08:37:21 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <JCFDD1NN>; Fri, 4 May 2001 11:37:09 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C8889@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "Linux XFS (E-mail)" <linux-xfs@oss.sgi.com>
Subject: chacl usage
Date: Fri, 4 May 2001 11:37:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Am I missing something to get acls to work on XFS?  I'm on a frsh RedHat 7.1 install, built a kernel from the 1.0 XFS release.  I installed the SGI acl-1.0.1-0.  Built an XFS filesystem:

[root@betanas1 pkgs]# chacl u::rwx,g::rwx,o::rwx foo
chacl: error setting access acl on "foo": Function not implemented

From owner-linux-xfs@oss.sgi.com Fri May  4 08:38:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Fcki14595
	for linux-xfs-outgoing; Fri, 4 May 2001 08:38:46 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44FckF14592
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 08:38:46 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <JCFDD1NW>; Fri, 4 May 2001 11:38:39 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C888A@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "Christian, Chip" <chip.christian@storageapps.com>,
   "'Linux XFS (E-mail)'" <linux-xfs@oss.sgi.com>
Subject: RE: chacl usage
Date: Fri, 4 May 2001 11:38:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Oh, and I specified
	CONFIG_FS_POSIX_ACL=y
when building the kernel.

>  -----Original Message-----
> From: 	Christian, Chip  
> Sent:	Friday, May 04, 2001 11:37
> To:	Linux XFS (E-mail)
> Subject:	chacl usage
> 
> Am I missing something to get acls to work on XFS?  I'm on a frsh RedHat 7.1 install, built a kernel from the 1.0 XFS release.  I installed the SGI acl-1.0.1-0.  Built an XFS filesystem:
> 
> [root@betanas1 pkgs]# chacl u::rwx,g::rwx,o::rwx foo
> chacl: error setting access acl on "foo": Function not implemented

From owner-linux-xfs@oss.sgi.com Fri May  4 09:17:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44GHxa16023
	for linux-xfs-outgoing; Fri, 4 May 2001 09:17:59 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44GHwF16020
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:17:58 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA18587
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:17:56 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA12585
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:17:54 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Fri, 4 May 2001 09:17:47 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id JAA37730;
	Fri, 4 May 2001 09:17:46 -0700
Message-Id: <3AF2D62A.775AEFF2@pipcws.ca.boeing.com>
Date: Fri, 04 May 2001 09:17:46 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com, Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
		<m3bspbwotj.fsf@giants.mandrakesoft.com>
		<3AF0A70D.C5CE4733@thebarn.com>
		<m37kzyrhj1.fsf@giants.mandrakesoft.com>
		<3AF1A6DC.67C1CA2F@thebarn.com> <m3bsp9xwdi.fsf@giants.mandrakesoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chmouel Boudjnah wrote:
> 
> Russell Cattelan <cattelan@thebarn.com> writes:
> 
> > If you don't mind, I'll will put this link in our "news" segment on our
> > web page?
> 
> Sure.
> 
> > > > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > > > yet but it does compile.
> > > > Anybody want help finish it.?
> > > Could you send me the patch, i had a lot of conflict and i did the
> > > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> > ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> > this was a real quick attempt to get it to compile, area that are suspect
> > and may not be right :
> > dquot.c

To anyone that's interested. I applied this patch to a clean Mandrake 2.4.3
kernel last night.
It applied cleanly, and the resulting code compiled without error. The system
booted normally, and all "looked" well. BUT: I have not done any testing! It was
late when the build finished. I will be doing more with it over the week-end.

But the preliminary view of it is: It works.

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Fri May  4 09:23:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44GNn416137
	for linux-xfs-outgoing; Fri, 4 May 2001 09:23:49 -0700
Received: from hotmail.com (f116.law7.hotmail.com [216.33.237.116])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44GNnF16134
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:23:49 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Fri, 4 May 2001 09:23:44 -0700
Received: from 149.136.226.49 by lw7fd.law7.hotmail.msn.com with HTTP;	Fri, 04 May 2001 16:23:44 GMT
X-Originating-IP: [149.136.226.49]
From: "Mr Lancealot" <mrlancealot@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: Anyone got XFS working with DAC960?
Date: Fri, 04 May 2001 09:23:44 -0700
Mime-Version: 1.0
Content-Type: text/html
Message-ID: <F116GE5nCz0b4djKMQz00002029@hotmail.com>
X-OriginalArrivalTime: 04 May 2001 16:23:44.0308 (UTC) FILETIME=[96A7A740:01C0D4B6]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

<html>Has anyone got a XFS SCSI RAID setup working with the DAC960 module?&nbsp; I go through the Redhat 7.1 XFS install disk, and everything seems to work fine.&nbsp; When I boot the system up it can not mount the RAID device.&nbsp; I get "mount: special device /dev/rd/c0d0p1 does not exist" anytime I try to mount the XFS raid device.&nbsp; I have no trouble getting this setup working with EXT2.&nbsp; Any ideas?&nbsp; Thanks.
<DIV></DIV><br clear=all><hr>Get your FREE download of MSN Explorer at <a href="http://explorer.msn.com">http://explorer.msn.com</a><br></p></html>

From owner-linux-xfs@oss.sgi.com Fri May  4 09:35:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44GZgK16376
	for linux-xfs-outgoing; Fri, 4 May 2001 09:35:42 -0700
Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44GZfF16373
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:35:41 -0700
Received: (qmail 13198 invoked from network); 4 May 2001 16:35:40 -0000
Received: from zaurak.cedar.buffalo.edu (128.205.33.110)
  by antares.cedar.buffalo.edu with SMTP; 4 May 2001 16:35:40 -0000
Received: (from ajay@localhost)
	by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id MAA04160;
	Fri, 4 May 2001 12:35:39 -0400 (EDT)
Date: Fri, 4 May 2001 12:35:39 -0400
From: Ajay Shekhawat <ajay@cedar.Buffalo.EDU>
To: Mr Lancealot <mrlancealot@hotmail.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Anyone got XFS working with DAC960?
Message-ID: <20010504123539.K3700@zaurak.cedar.buffalo.edu>
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F116GE5nCz0b4djKMQz00002029@hotmail.com>; from mrlancealot@hotmail.com on Fri, May 04, 2001 at 09:23:44AM -0700
Organization: Center for Document Analysis and Recognition
X-OfficePhone: +1 (716)-645-6164 ext. 101
X-Fax-Number: +1 (716)-645-6176
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Couldn't read your HTML message, but the answer is yes, I have created
an XFS filesystem on a Mylex eXtremeRAID 2000 controller with 10+ SCSI
disks. Worked fine for me. 

Ajay


From owner-linux-xfs@oss.sgi.com Fri May  4 09:42:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Gg5W16565
	for linux-xfs-outgoing; Fri, 4 May 2001 09:42:05 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44Gg3F16561
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 09:42:04 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14vieX-0003Wr-00; Fri, 04 May 2001 18:42:01 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f44GfJt05398;
	Fri, 4 May 2001 12:41:19 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: "Mr Lancealot" <mrlancealot@hotmail.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Anyone got XFS working with DAC960?
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 04 May 2001 12:41:19 -0400
In-Reply-To: <F116GE5nCz0b4djKMQz00002029@hotmail.com>
Message-ID: <yq1hez1dq34.fsf@jcb.mkp.net>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> Has anyone got a XFS SCSI RAID setup working with the DAC960
> module?  I go through the Redhat 7.1 XFS install disk, and
> everything seems to work fine.  When I boot the system up it can not
> mount the RAID device.  I get "mount: special device /dev/rd/c0d0p1
> does not exist" anytime I try to mount the XFS raid device.  I have
> no trouble getting this setup working with EXT2.

I committed a patch to the development tree fixing this a couple of
days ago.  Unfortunately, there seem to be a few other issues with
2.4.4 and the tree is not quite stable yet.

So right now I'd recommend you hold off a bit until we do a respin of
the images.


PS. Please fix your mail program so it doesn't send out HTML mails to
the list.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Fri May  4 10:06:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44H6eb17240
	for linux-xfs-outgoing; Fri, 4 May 2001 10:06:40 -0700
Received: from umcdev1.sharemedia.com ([151.200.228.52])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44H6dF17231
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:06:39 -0700
Received: from sharemedia.com (das [127.0.0.1])
	by umcdev1.sharemedia.com (8.9.3/8.9.3) with ESMTP id NAA09363;
	Fri, 4 May 2001 13:06:37 -0400
Message-ID: <3AF2E19D.38D64AFC@sharemedia.com>
Date: Fri, 04 May 2001 13:06:37 -0400
From: Dave Strout <dstrout@sharemedia.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mr Lancealot <mrlancealot@hotmail.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Anyone got XFS working with DAC960?
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just had the same problem -- you can mount them the hard way by hand
by doing:
mount /dev/rd/disc0/part1 /wherever_it_goes

etc., then edit the /etc/fstab  to use the long device paths -- that'll
make them mount on boot, but I still haven't figured out why that
happened.

dave.


Mr Lancealot wrote:

> Has anyone got a XFS SCSI RAID setup working with the DAC960 module?
> I go through the Redhat 7.1 XFS install disk, and everything seems to
> work fine.  When I boot the system up it can not mount the RAID
> device.  I get "mount: special device /dev/rd/c0d0p1 does not exist"
> anytime I try to mount the XFS raid device.  I have no trouble getting
> this setup working with EXT2.  Any ideas?  Thanks.
>
> -----------------------------------------------------------------------
> Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-linux-xfs@oss.sgi.com Fri May  4 10:17:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44HHfU17498
	for linux-xfs-outgoing; Fri, 4 May 2001 10:17:41 -0700
Received: from umcdev1.sharemedia.com ([151.200.228.52])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44HHdF17494
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:17:39 -0700
Received: from sharemedia.com (das [127.0.0.1])
	by umcdev1.sharemedia.com (8.9.3/8.9.3) with ESMTP id NAA09370;
	Fri, 4 May 2001 13:17:19 -0400
Message-ID: <3AF2E41F.B4A55999@sharemedia.com>
Date: Fri, 04 May 2001 13:17:19 -0400
From: Dave Strout <dstrout@sharemedia.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: xfs root filesystem on SGI 1450?
References: <3141749.988970413359.JavaMail.sharemail@berlin.sharemedia.com>
	    <3AF2BF56.847EB08C@thebarn.com> <3AF2C284.4E34597C@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yup, 'noapic' worked -- thanks!

dave.


Eric Sandeen wrote:

> Try booting with "noapic" as one of the boot parameters at the boot
> prompt.
>
>    noapic     [SMP,APIC] Tells the kernel not to make use of any
>               APIC that may be present on the system.
>
> -Eric
>
> Russell Cattelan wrote:
>
> > The only thing that changed with on  1.0 release CD was the
> > BOOT kernel has APIC enabled due to a bug in the 1200's.
> >
> > The BOOT image on the Release-1.0-test3 did not have APIC enabled
> > you could try that one to see if it make a difference.
> >
> > This would be a real pain if we fix one machine and break the other...
> > argghh.
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Fri May  4 10:28:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44HS8v18185
	for linux-xfs-outgoing; Fri, 4 May 2001 10:28:08 -0700
Received: from kamov.deltanet.ro (as.deltanet.ro [193.226.175.59])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44HS7F18181
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:28:07 -0700
Received: from shiva.ppetru.net (home.ppetru.net [193.230.129.57])
	by kamov.deltanet.ro (Postfix) with ESMTP id 43324F7B3
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 20:28:12 +0300 (EEST)
Received: by shiva.ppetru.net (Postfix, from userid 1000)
	id 3990D40AD7; Fri,  4 May 2001 20:27:34 +0300 (EEST)
Date: Fri, 4 May 2001 20:27:34 +0300
To: linux-xfs@oss.sgi.com
Subject: What does the ISO image include?
Message-ID: <20010504202734.E414@ppetru.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: ppetru@ppetru.net (Petru Paler)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

What does the RH7.1-SGI-XFS-1.0.iso image include?
I thought it's the exact copy of the first RH 7.1
ISO, with the XFS modifications, but there seems to
be an almost 300M size difference between the two (
the original seawolf image being bigger).

--
Petru Paler, mailto:ppetru@ppetru.net
http://www.ppetru.net - ICQ: 41817235

From owner-linux-xfs@oss.sgi.com Fri May  4 10:28:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44HSZD18201
	for linux-xfs-outgoing; Fri, 4 May 2001 10:28:35 -0700
Received: from cube.gelatinous.com (cube.gelatinous.com [207.82.194.150])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44HSVF18197
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:28:35 -0700
Received: (qmail 16464 invoked by uid 1000); 4 May 2001 17:28:30 -0000
Date: Fri, 4 May 2001 10:28:30 -0700
From: Aaron Smith <aaron-xfs@mutex.org>
To: linux-xfs@oss.sgi.com
Subject: user-mode linux & xfs
Message-ID: <20010504102830.B92452@gelatinous.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, has anyone had success getting xfs and the user-mode linux patches to
play nice? It blew up at compile; I'm thinking it probably just needs some
changes in arch/um that are in the xfs tree's arch?

Aaron

From owner-linux-xfs@oss.sgi.com Fri May  4 10:46:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Hk9m18623
	for linux-xfs-outgoing; Fri, 4 May 2001 10:46:09 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44Hk7F18620
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:46:08 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f44Hk1t24357;
	Fri, 4 May 2001 12:46:01 -0500 (CDT)
Message-ID: <3AF2EB2E.71A437D9@sgi.com>
Date: Fri, 04 May 2001 12:47:26 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Petru Paler <ppetru@ppetru.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: What does the ISO image include?
References: <20010504202734.E414@ppetru.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It has the complete installer, modified for XFS (which accounts for a
lot of the size)

It also has all of the modified RPMs necessary to support XFS, as well
as their SRPMS.

So, it works with RH disc 1 and disc 2 to install the system - we didn't
duplicate any unmodified RPMs from RH disc 1.

If you look in the download directory, there's a directory tree of the
iso so you can see exactly what's there.

-Eric

Petru Paler wrote:
> 
> Hi,
> 
> What does the RH7.1-SGI-XFS-1.0.iso image include?
> I thought it's the exact copy of the first RH 7.1
> ISO, with the XFS modifications, but there seems to
> be an almost 300M size difference between the two (
> the original seawolf image being bigger).

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 10:48:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44HmZv18682
	for linux-xfs-outgoing; Fri, 4 May 2001 10:48:35 -0700
Received: from kamov.deltanet.ro (as.deltanet.ro [193.226.175.59])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44HmYF18679
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:48:34 -0700
Received: from shiva.ppetru.net (home.ppetru.net [193.230.129.57])
	by kamov.deltanet.ro (Postfix) with ESMTP
	id 061E4F7BD; Fri,  4 May 2001 20:48:44 +0300 (EEST)
Received: by shiva.ppetru.net (Postfix, from userid 1000)
	id 6248840AD8; Fri,  4 May 2001 20:48:03 +0300 (EEST)
Date: Fri, 4 May 2001 20:48:03 +0300
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: What does the ISO image include?
Message-ID: <20010504204803.H414@ppetru.net>
References: <20010504202734.E414@ppetru.net> <3AF2EB2E.71A437D9@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AF2EB2E.71A437D9@sgi.com>; from sandeen@sgi.com on Fri, May 04, 2001 at 12:47:26PM -0500
From: ppetru@ppetru.net (Petru Paler)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 04, 2001 at 12:47:26PM -0500, Eric Sandeen wrote:
> It has the complete installer, modified for XFS (which accounts for a
> lot of the size)
> 
> It also has all of the modified RPMs necessary to support XFS, as well
> as their SRPMS.
> 
> So, it works with RH disc 1 and disc 2 to install the system - we didn't
> duplicate any unmodified RPMs from RH disc 1.

So when installing from your ISO image, one needs to also have the original
seawolf disc1 handy for when the installer asks for it, right?

--
Petru Paler, mailto:ppetru@ppetru.net
http://www.ppetru.net - ICQ: 41817235

From owner-linux-xfs@oss.sgi.com Fri May  4 10:51:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Hpev18731
	for linux-xfs-outgoing; Fri, 4 May 2001 10:51:40 -0700
Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44HpdF18726
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:51:39 -0700
Received: (qmail 14046 invoked from network); 4 May 2001 17:51:38 -0000
Received: from zaurak.cedar.buffalo.edu (128.205.33.110)
  by antares.cedar.buffalo.edu with SMTP; 4 May 2001 17:51:38 -0000
Received: (from ajay@localhost)
	by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id NAA04189;
	Fri, 4 May 2001 13:51:38 -0400 (EDT)
Date: Fri, 4 May 2001 13:51:38 -0400
From: Ajay Shekhawat <ajay@cedar.Buffalo.EDU>
To: Dave Strout <dstrout@sharemedia.com>
Cc: Mr Lancealot <mrlancealot@hotmail.com>, linux-xfs@oss.sgi.com
Subject: Re: Anyone got XFS working with DAC960?
Message-ID: <20010504135137.L3700@zaurak.cedar.buffalo.edu>
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com> <3AF2E19D.38D64AFC@sharemedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF2E19D.38D64AFC@sharemedia.com>; from dstrout@sharemedia.com on Fri, May 04, 2001 at 01:06:37PM -0400
Organization: Center for Document Analysis and Recognition
X-OfficePhone: +1 (716)-645-6164 ext. 101
X-Fax-Number: +1 (716)-645-6176
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Here's an entry from my fstab:

	/dev/rd/c0d0p1      /RAID1                  xfs     defaults        0 0

Here's a mount command to mount it
	mount -t xfs /dev/rd/c0d0p1 /RAID1

I think you need to specify "-t xfs" because XFS uses the default Linux
partition type (0x82?), and the system assumes it to be of type ext2.

Ajay

On Fri, May 04, 2001 at 01:06:37PM -0400, Dave Strout wrote:
> I just had the same problem -- you can mount them the hard way by hand
> by doing:
> mount /dev/rd/disc0/part1 /wherever_it_goes
> 
> etc., then edit the /etc/fstab  to use the long device paths -- that'll
> make them mount on boot, but I still haven't figured out why that
> happened.
> 
> dave.
> 
> 
> Mr Lancealot wrote:
> 
> > Has anyone got a XFS SCSI RAID setup working with the DAC960 module?
> > I go through the Redhat 7.1 XFS install disk, and everything seems to
> > work fine.  When I boot the system up it can not mount the RAID
> > device.  I get "mount: special device /dev/rd/c0d0p1 does not exist"
> > anytime I try to mount the XFS raid device.  I have no trouble getting
> > this setup working with EXT2.  Any ideas?  Thanks.
> >
> > -----------------------------------------------------------------------
> > Get your FREE download of MSN Explorer at http://explorer.msn.com

From owner-linux-xfs@oss.sgi.com Fri May  4 10:53:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44HrG218878
	for linux-xfs-outgoing; Fri, 4 May 2001 10:53:16 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44HrGF18875
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 10:53:16 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f44HrEi14946;
	Fri, 4 May 2001 12:53:14 -0500 (CDT)
Message-ID: <3AF2ECDB.73D69FAF@sgi.com>
Date: Fri, 04 May 2001 12:54:35 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Petru Paler <ppetru@ppetru.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: What does the ISO image include?
References: <20010504202734.E414@ppetru.net> <3AF2EB2E.71A437D9@sgi.com> <20010504204803.H414@ppetru.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Petru Paler wrote:
 
> So when installing from your ISO image, one needs to also have the original
> seawolf disc1 handy for when the installer asks for it, right?

Yes.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 12:05:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44J5Np20918
	for linux-xfs-outgoing; Fri, 4 May 2001 12:05:23 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44J5MF20915
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:05:22 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAB04830
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:05:19 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA16097 for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 14:04:04 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f44J34Y28397
	for linux-xfs@oss.sgi.com; Fri, 4 May 2001 15:03:04 -0400
Date: Fri, 4 May 2001 15:03:04 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105041903.f44J34Y28397@gibble.americas.sgi.com>
Subject: TAKE - merge Martins fixes for raid controllers
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Fri May  4 12:02:10 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0
Merged by:  cattelan
Merged mods:  2.4.x-xfs:slinx:93919a,2.4.x-xfs:slinx:93920a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0


Modid:  2.4.x-xfs-r1.0:slinx:94078a
linux/drivers/block/ps2esdi.c - 1.12
	- Merge of 2.4.x-xfs:slinx:93920a originally by nn100004 on 05/02/01
	  Well, ESDI hardly qualifies as a RAID controller, but...

linux/drivers/block/cpqarray.c - 1.21
	- Merge of 2.4.x-xfs:slinx:93920a originally by nn100004 on 05/02/01
	  Fix the other RAID controllers while I'm at it.

linux/drivers/block/DAC960.c - 1.25
	- Merge of 2.4.x-xfs:slinx:93919a originally by nn100004 on 05/02/01
	  Add BLKBSZSET ioctl

linux/drivers/block/cciss.c - 1.6
	- Merge of 2.4.x-xfs:slinx:93920a originally by nn100004 on 05/02/01
	  Fix the other RAID controllers while I'm at it.



From owner-linux-xfs@oss.sgi.com Fri May  4 12:08:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44J8eW21015
	for linux-xfs-outgoing; Fri, 4 May 2001 12:08:40 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44J8cF21012
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:08:38 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAA06360
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:08:37 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA12328; Fri, 4 May 2001 14:07:13 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f44J6Dq28402;
	Fri, 4 May 2001 15:06:13 -0400
Message-ID: <3AF2FDA4.DA0F4AAD@thebarn.com>
Date: Fri, 04 May 2001 15:06:12 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
CC: linux-xfs@oss.sgi.com, Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
			<m3bspbwotj.fsf@giants.mandrakesoft.com>
			<3AF0A70D.C5CE4733@thebarn.com>
			<m37kzyrhj1.fsf@giants.mandrakesoft.com>
			<3AF1A6DC.67C1CA2F@thebarn.com> <m3bsp9xwdi.fsf@giants.mandrakesoft.com> <3AF2D62A.775AEFF2@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts wrote:

> Chmouel Boudjnah wrote:
> >
> > Russell Cattelan <cattelan@thebarn.com> writes:
> >
> > > If you don't mind, I'll will put this link in our "news" segment on our
> > > web page?
> >
> > Sure.
> >
> > > > > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > > > > yet but it does compile.
> > > > > Anybody want help finish it.?
> > > > Could you send me the patch, i had a lot of conflict and i did the
> > > > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> > > ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> > > this was a real quick attempt to get it to compile, area that are suspect
> > > and may not be right :
> > > dquot.c
>
> To anyone that's interested. I applied this patch to a clean Mandrake 2.4.3
> kernel last night.
> It applied cleanly, and the resulting code compiled without error. The system
> booted normally, and all "looked" well. BUT: I have not done any testing! It was
> late when the build finished. I will be doing more with it over the week-end.
>

Note if you want quotas to work right grab the patch Nathan send out recently
it was for the RH build but the same error exists in the Mandrake build.

>
> But the preliminary view of it is: It works.

If your testing goes well I will spin a set of mandrake rpm and
put them up on the ftp site as "experimental"


>
>
> --
> __________________________________________________________
> Ric Tibbetts
> Boeing Shared Services Group
> UNIX System Administration
> Seattle Server Operations
> __________________________________________________________

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Fri May  4 12:17:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44JHVs22043
	for linux-xfs-outgoing; Fri, 4 May 2001 12:17:31 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JHUF22040
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:17:30 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA01068
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:16:09 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA34182 for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:21:04 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 03FC7CED7A
	for <linux-xfs@oss.sgi.com>; Fri,  4 May 2001 12:16:13 -0700 (PDT)
Subject: Re: Anyone got XFS working with DAC960?
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <yq1hez1dq34.fsf@jcb.mkp.net>
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com> 
	<yq1hez1dq34.fsf@jcb.mkp.net>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 04 May 2001 12:16:13 -0700
Message-Id: <989003774.32764.8.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 04 May 2001 12:41:19 -0400, Martin K. Petersen wrote:
> 
> So right now I'd recommend you hold off a bit until we do a respin of
> the images.

When will that be?

-- 
Florin Andrei

"Imagine working in a secure environment and finding the string _NSAKEY
in the OS binaries without a good explanation." - Alan Cox


From owner-linux-xfs@oss.sgi.com Fri May  4 12:18:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44JI4622116
	for linux-xfs-outgoing; Fri, 4 May 2001 12:18:04 -0700
Received: from exchange.concordia.ab.ca (exchange.concordia.ab.ca [199.185.120.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JI3F22111
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:18:04 -0700
Received: from strobe (strobe.concordia.ab.ca [199.185.121.61]) by exchange.concordia.ab.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id JYSAX1C8; Fri, 4 May 2001 13:21:46 -0600
Message-ID: <009a01c0d4cf$02a8a760$3d79b9c7@admin.concordia.ab.ca>
From: "Ed Boraas" <ed@boraas.ca>
To: <linux-xfs@oss.sgi.com>
Subject: Official Debian XFS kernel patch packages
Date: Fri, 4 May 2001 13:18:32 -0600
Organization: http://www.ed.boraas.ca
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello, all.

I'm pleased to say that, as of today, the XFS/Linux Release 1.0 patches are
now available in the Debian 'unstable' (Sid) distribution. I'd like to
encourage people to test these packages and report on any issues via the
Debian bug tracking system.

Barring any major issues, these packages should also be available in the
'testing' (Woody)distribution in a couple of weeks.

The packages contain the patches from XFS R1.0, with a couple minor
modifications (none of which affect the substance of the patch), as
documented in the changelog. They can be found as 'kernel-patch-xfs' and
'kernel-patch-xfs-core'.

In order to make effective use of these, of course, Nathan Scott's excellent
official XFS userspace packages should be installed as well.

Take care,
Ed Boraas, Debian XFS kernel patch maintainer


From owner-linux-xfs@oss.sgi.com Fri May  4 12:39:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44JdqC23050
	for linux-xfs-outgoing; Fri, 4 May 2001 12:39:52 -0700
Received: from bubba.NMSU.Edu (bubba.NMSU.Edu [128.123.3.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44JdqF23047
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 12:39:52 -0700
Received: from dns1.nmsu.edu (dns1.NMSU.Edu [128.123.3.5])
	by bubba.NMSU.Edu (8.9.3+Sun/8.9.0) with ESMTP id NAA07140
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:39:50 -0600 (MDT)
Received: from gauss.NMSU.Edu (IDENT:root@gauss.nmsu.edu [128.123.131.237])
	by dns1.nmsu.edu (8.9.3/8.9.0) with ESMTP id NAA35400
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:39:51 -0600 (MDT)
Received: from localhost (wsmith@localhost)
	by gauss.NMSU.Edu (8.9.3/8.9.0) with ESMTP id NAA20553
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:39:43 -0600
Date: Fri, 4 May 2001 13:39:43 -0600 (MDT)
From: Bill Smith <wsmith@NMSU.Edu>
To: <linux-xfs@oss.sgi.com>
Subject: Installed -- It's Great!
Message-ID: <Pine.LNX.4.30.0105041335120.20379-100000@gauss.NMSU.Edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello-

Just wanted you to know I now have our departmental Linux distribution
server up totally on XFS and it's working great! I took a chance and
powered the system down; it came back up in about the same time as if I
had restarted it in an orderly fashion. Users report the downloads seem to
be quicker as well.

We plan on migrating our other floor servers to this filesystem during the
summer.

Thanks, and keep it up!

Bill Smith

-- 

==============================
William Smith, CNA, WCNE
New Mexico State University
Klipsch School of Electrical &
Computer Engineering
Phone: 505-646-5390
FAX:   505-646-1435
Email: wsmith@nmsu.edu
==============================


From owner-linux-xfs@oss.sgi.com Fri May  4 13:03:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44K3Eg23534
	for linux-xfs-outgoing; Fri, 4 May 2001 13:03:14 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44K3DF23531
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:03:13 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA25676
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:03:12 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA04961
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:03:11 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Fri, 4 May 2001 13:03:03 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id NAA37684;
	Fri, 4 May 2001 13:03:03 -0700
Message-Id: <3AF30AF6.A76DD7A0@pipcws.ca.boeing.com>
Date: Fri, 04 May 2001 13:03:02 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
				<m3bspbwotj.fsf@giants.mandrakesoft.com>
				<3AF0A70D.C5CE4733@thebarn.com>
				<m37kzyrhj1.fsf@giants.mandrakesoft.com>
				<3AF1A6DC.67C1CA2F@thebarn.com> <m3bsp9xwdi.fsf@giants.mandrakesoft.com> <3AF2D62A.775AEFF2@pipcws.ca.boeing.com> <3AF2FDA4.DA0F4AAD@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Ric Tibbetts wrote:
> 
> > Chmouel Boudjnah wrote:
> > >
> > > Russell Cattelan <cattelan@thebarn.com> writes:
> > >
> > > > If you don't mind, I'll will put this link in our "news" segment on our
> > > > web page?
> > >
> > > Sure.
> > >
> > > > > > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > > > > > yet but it does compile.
> > > > > > Anybody want help finish it.?
> > > > > Could you send me the patch, i had a lot of conflict and i did the
> > > > > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> > > > ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> > > > this was a real quick attempt to get it to compile, area that are suspect
> > > > and may not be right :
> > > > dquot.c
> >
> > To anyone that's interested. I applied this patch to a clean Mandrake 2.4.3
> > kernel last night.
> > It applied cleanly, and the resulting code compiled without error. The system
> > booted normally, and all "looked" well. BUT: I have not done any testing! It was
> > late when the build finished. I will be doing more with it over the week-end.
> >
> 
> Note if you want quotas to work right grab the patch Nathan send out recently
> it was for the RH build but the same error exists in the Mandrake build.
> 
I wasn't planning on putting it in. I really don't use/need it on that system. I
may however put it in later, just for testing.

> >
> > But the preliminary view of it is: It works.
> 
> If your testing goes well I will spin a set of mandrake rpm and
> put them up on the ftp site as "experimental"

Thanks Russell
Give me a couple of days to beat it up ;) I'll throw some loads on it (both
local, and nfs), and see if it squeals.

I was impressed that it came up clean on the first try.
Also, as a bonus, this brought back my frame buffer! (This is as a result of
using the Mandrake kernel, which has some extra drivers). So there's been some
side benefit to this.

> 
> >
> >
> > --
> > __________________________________________________________
> > Ric Tibbetts
> > Boeing Shared Services Group
> > UNIX System Administration
> > Seattle Server Operations
> > __________________________________________________________
> 
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Fri May  4 13:18:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44KIVR23895
	for linux-xfs-outgoing; Fri, 4 May 2001 13:18:31 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44KIUF23892
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:18:30 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA05234
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 13:29:14 -0700 (PDT)
	mail_from (mann@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1703537; Fri, 4 May 2001 15:17:12 -0500 (CDT)
Received: from fsgi632.americas.sgi.com (fsgi632.americas.sgi.com [128.162.184.134]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA01773; Fri, 4 May 2001 15:17:12 -0500 (CDT)
From: Mark Nordstrand <mann@sgi.com>
Received: by fsgi632.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id PAA08352; Fri, 4 May 2001 15:17:12 -0500 (CDT)
Message-Id: <200105042017.PAA08352@fsgi632.americas.sgi.com>
Subject: Re: user-mode linux & xfs
To: aaron-xfs@mutex.org (Aaron Smith)
Date: Fri, 4 May 2001 15:17:11 -0500 (CDT)
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010504102830.B92452@gelatinous.com> from "Aaron Smith" at May 04, 2001 10:28:30 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> Hi, has anyone had success getting xfs and the user-mode linux patches to
> play nice? It blew up at compile; I'm thinking it probably just needs some
> changes in arch/um that are in the xfs tree's arch?
> 
> Aaron
> 

Moderate success.  I've only had success starting with 2.4.3, and appliing
-ac4 and then xfs patches.

I do hope to get back to 2.4.4 sometime next week.

Mark


From owner-linux-xfs@oss.sgi.com Fri May  4 14:37:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Lb1925652
	for linux-xfs-outgoing; Fri, 4 May 2001 14:37:01 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44Lb1F25649
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 14:37:01 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA08333
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 14:47:45 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA28545; Fri, 4 May 2001 16:35:44 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f44LYiq28887;
	Fri, 4 May 2001 17:34:44 -0400
Message-ID: <3AF32072.C905DA85@thebarn.com>
Date: Fri, 04 May 2001 17:34:43 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Florin Andrei <florin@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Anyone got XFS working with DAC960?
References: <F116GE5nCz0b4djKMQz00002029@hotmail.com> 
		<yq1hez1dq34.fsf@jcb.mkp.net> <989003774.32764.8.camel@stantz.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Florin Andrei wrote:

> On 04 May 2001 12:41:19 -0400, Martin K. Petersen wrote:
> >
> > So right now I'd recommend you hold off a bit until we do a respin of
> > the images.
>
> When will that be?

I might be able to build a boot floppy with the updated kernel.

but not right now...  bug me next week.


>
>
> --
> Florin Andrei
>
> "Imagine working in a secure environment and finding the string _NSAKEY
> in the OS binaries without a good explanation." - Alan Cox

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Fri May  4 15:18:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44MIx926819
	for linux-xfs-outgoing; Fri, 4 May 2001 15:18:59 -0700
Received: from dusnt051.satama.de (dusmail.owd.de [194.77.80.139])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44MIvF26816
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 15:18:58 -0700
Received: from 194.77.80.136 by dusnt051.satama.de (InterScan E-Mail VirusWall NT); Sat, 05 May 2001 00:18:51 +0200 (W. Europe Daylight Time)
Received: from bellapc.satama (dhcp-179.satama.de [194.77.80.179]) by dus010.satama.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D35JSJ9M; Sat, 5 May 2001 00:18:51 +0200
Date: Sat, 5 May 2001 00:14:35 +0200 (CEST)
From: Andriy.Bilous@satama.de
X-Sender: bella@bellapc.satama
To: linux-xfs@oss.sgi.com
Subject: cannot mount root-fs
Message-ID: <Pine.LNX.4.21.0105050009190.391-100000@bellapc.satama>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi!

It's sounds funny, but I cannot boot with patched kernel. I just recompile
new 2.4.3 kernel with xfs patches - linux-2.4-xfs-1.0.patch and
linux-2.4.3-core-xfs-1.0.patch. Any changes in fstab, ext2fs support in
kernel - OK. And now cannot booting... I use static /dev filesystem. May
be it's a problem?

-- 
E-mail: Andriy.Bilous@satama.de


From owner-linux-xfs@oss.sgi.com Fri May  4 15:58:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44Mw6M27402
	for linux-xfs-outgoing; Fri, 4 May 2001 15:58:06 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44Mw5F27397
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 15:58:05 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f44MvxU12102;
	Fri, 4 May 2001 17:57:59 -0500 (CDT)
Message-ID: <3AF3344D.1D933321@sgi.com>
Date: Fri, 04 May 2001 17:59:25 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andriy.Bilous@satama.de
CC: linux-xfs@oss.sgi.com
Subject: Re: cannot mount root-fs
References: <Pine.LNX.4.21.0105050009190.391-100000@bellapc.satama>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

When you say you cannot boot, when does it fail -  Lilo?  Kernel
startup?  Initscripts?

-Eric

Andriy.Bilous@satama.de wrote:
> 
> Hi!
> 
> It's sounds funny, but I cannot boot with patched kernel. I just recompile
> new 2.4.3 kernel with xfs patches - linux-2.4-xfs-1.0.patch and
> linux-2.4.3-core-xfs-1.0.patch. Any changes in fstab, ext2fs support in
> kernel - OK. And now cannot booting... I use static /dev filesystem. May
> be it's a problem?

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 16:26:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44NQFi28042
	for linux-xfs-outgoing; Fri, 4 May 2001 16:26:15 -0700
Received: from cube.gelatinous.com (cube.gelatinous.com [207.82.194.150])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f44NQEF28039
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 16:26:15 -0700
Received: (qmail 35099 invoked by uid 1000); 4 May 2001 23:26:14 -0000
Date: Fri, 4 May 2001 16:26:14 -0700
From: Aaron Smith <aaron-xfs@mutex.org>
To: linux-xfs@oss.sgi.com
Subject: loopback devices (is the FAQ entry out of date?)
Message-ID: <20010504162614.D92452@gelatinous.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The XFS FAQ says 2.4.2 needs a patch by Jens Axboes for loopback block
devices to work under XFS. Is this still true as of 2.4.4?

Thanks,
Aaron

From owner-linux-xfs@oss.sgi.com Fri May  4 16:29:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f44NTFB28096
	for linux-xfs-outgoing; Fri, 4 May 2001 16:29:15 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f44NTEF28093
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 16:29:14 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f44NT7U19322;
	Fri, 4 May 2001 18:29:07 -0500 (CDT)
Message-ID: <3AF33B98.368B47E9@sgi.com>
Date: Fri, 04 May 2001 18:30:32 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Aaron Smith <aaron-xfs@mutex.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: loopback devices (is the FAQ entry out of date?)
References: <20010504162614.D92452@gelatinous.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Aaron Smith wrote:
> 
> The XFS FAQ says 2.4.2 needs a patch by Jens Axboes for loopback block
> devices to work under XFS. Is this still true as of 2.4.4?

I'm fairly certain that loopback is working again under 2.4.4 - the
2.4.3 and 2.4.4 changelogs both reference loopback fixes.

Maybe Jens will chime in with a definitive answer... :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May  4 18:00:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4510aJ30863
	for linux-xfs-outgoing; Fri, 4 May 2001 18:00:36 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4510XF30859
	for <linux-xfs@oss.sgi.com>; Fri, 4 May 2001 18:00:34 -0700
Received: (qmail 31725 invoked from network); 5 May 2001 01:00:30 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 5 May 2001 01:00:30 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: ThH <thh@freakmail.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0 on AlphaLinux LVM 
In-reply-to: Your message of "Fri, 04 May 2001 16:31:17 +0200."
             <3AF2BD35.46EC15B8@freakmail.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 05 May 2001 11:00:29 +1000
Message-ID: <13043.989024429@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 04 May 2001 16:31:17 +0200, 
ThH <thh@freakmail.de> wrote:
>like with 0.10.3, the Release 1.0 doesn't work with my
>LinuxAlphastation. This time I've added a part of the /var/log/messages
>file.

The alpha oops log is badly designed, they strip off the high order
address bits to save space, they decode instructions themselves and
they put the trace after the code.  All of that messes up ksymoops so I
have reformatted your oops log to something that ksymoops should cope
with.  Please run this reformatted log through ksymoops on your alpha
using the System.map for the failing kernel and send the output to
linux-xfs.  Get the latest ksymoops from
ftp://ftp.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4 or a
ftp.de.kernel.org mirror.

May  4 15:55:56 alpha kernel: mount(753): Kernel Bug 1
May  4 15:55:56 alpha kernel: pc = [<fffffc0000454250>]  ra = [<fffffc0000454d4c>]  ps = 0000
May  4 15:55:56 alpha kernel: v0 = fffffc0005fe94b0  t0 = 0000000000000200  t1 = 0000000000000000
May  4 15:55:56 alpha kernel: t2 = fffffc0005fef000  t3 = 0000000000000800  t4 = ffffffff00000000
May  4 15:55:56 alpha kernel: t5 = 0000000000000001  t6 = 00000000001f4b1c  t7 = fffffc000199c000
May  4 15:55:56 alpha kernel: a0 = fffffc0005fe94b0  a1 = fffffc0003c75520  a2 = fffffc0003c74c20
May  4 15:55:56 alpha kernel: a3 = 0000000000003a01  a4 = fffffc000066b988  a5 = 0000000000000001
May  4 15:55:56 alpha kernel: t8 = 0000000000000004  t9 = fffffc0000518b08  t10= 00000000002bfff0
May  4 15:55:56 alpha kernel: t11= 0000000000002000  pv = fffffc00004541c0  at = 0000000000000001
May  4 15:55:56 alpha kernel: gp = fffffc000063ae20  sp = fffffc000199f5f8
May  4 15:55:57 alpha kernel: Trace:fffffc0000454d4c fffffc0000518fe0
fffffc00003c3d38 fffffc0000454d64 fffffc00003c3eb8 fffffc00003c41c4
fffffc00003c4790 fffffc00003c4320 fffffc00003c3fe0 fffffc00003c367c
fffffc00003c2d64 fffffc000043d970 fffffc0000428560 fffffc00004324c0
fffffc0000427bb8 fffffc00004323a8 fffffc00004328bc fffffc0000432934
fffffc00004473e0 fffffc000034fda4 fffffc00003658a8 fffffc0000353444
fffffc000035012c fffffc000034fb9c fffffc000034fca8 fffffc0000350190
fffffc0000351514 fffffc0000351830 fffffc0000351810 fffffc0000310aa0
fffffc00003109f8
May  4 15:55:56 alpha kernel: Code: a02c0058 e5600001 a02d0004 b43e0070 c3e00002 00000081 <c3e0024f> a42a0020


From owner-linux-xfs@oss.sgi.com Sat May  5 01:43:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f458hRR06206
	for linux-xfs-outgoing; Sat, 5 May 2001 01:43:27 -0700
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f458hOF06203
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 01:43:25 -0700
Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52])
	by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id OAA25669
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 14:21:40 GMT
Received: from wipro.tcpn.com ([172.31.41.11]) by
          sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with
          ESMTP id GCUTU000.S7U for <linux-xfs@oss.sgi.com>; Sat, 5 May
          2001 14:19:12 +0530 
Received: from pelican.wipro.tcpn.com (pelican.wipro.tcpn.com [172.31.42.201])
	by wipro.tcpn.com (8.9.3/8.9.3) with ESMTP id OAA22595;
	Sat, 5 May 2001 14:11:54 +0530 (IST)
Received: from wipro.co.in (isd246.wipro.tcpn.com [172.31.42.246])
	by pelican.wipro.tcpn.com (8.8.5/8.8.5) with ESMTP id OAA07854;
	Sat, 5 May 2001 14:10:55 +0530 (IST)
Message-ID: <3AF3BF07.5C0E03CB@wipro.co.in>
Date: Sat, 05 May 2001 14:21:20 +0530
From: Chandramouli <ssmouli@wipro.co.in>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
CC: Nithya <Nithya.Ganesan@wipro.com>
Subject: XFS on SuSE7.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi All,

    Could you please provide me some information on how to install XFS
on SuSE7.1 linux. Or if you know a place where this doc. already exists
please point me to that ......

Thanks in advance
Regds
Mouli




From owner-linux-xfs@oss.sgi.com Sat May  5 03:09:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45A9E007104
	for linux-xfs-outgoing; Sat, 5 May 2001 03:09:14 -0700
Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45A9BF07100
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 03:09:11 -0700
Received: from burns.home.kernel.dk ([192.168.0.2] ident=root)
	by virtualhost.dk with esmtp (Exim 3.22 #4)
	id 14vyzS-0001QI-00; Sat, 05 May 2001 12:08:42 +0200
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 14vyzL-0007Ij-00; Sat, 05 May 2001 12:08:35 +0200
Date: Sat, 5 May 2001 12:08:35 +0200
From: Jens Axboe <axboe@suse.de>
To: Eric Sandeen <sandeen@sgi.com>
Cc: Aaron Smith <aaron-xfs@mutex.org>, linux-xfs@oss.sgi.com
Subject: Re: loopback devices (is the FAQ entry out of date?)
Message-ID: <20010505120835.G24237@suse.de>
References: <20010504162614.D92452@gelatinous.com> <3AF33B98.368B47E9@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3AF33B98.368B47E9@sgi.com>; from sandeen@sgi.com on Fri, May 04, 2001 at 06:30:32PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 04 2001, Eric Sandeen wrote:
> Aaron Smith wrote:
> > 
> > The XFS FAQ says 2.4.2 needs a patch by Jens Axboes for loopback block
> > devices to work under XFS. Is this still true as of 2.4.4?
> 
> I'm fairly certain that loopback is working again under 2.4.4 - the
> 2.4.3 and 2.4.4 changelogs both reference loopback fixes.
> 
> Maybe Jens will chime in with a definitive answer... :)

2.4.4 should be fine, there are some minor buglets in there but nothing
that will prevent it from working.

-- 
Jens Axboe


From owner-linux-xfs@oss.sgi.com Sat May  5 04:22:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45BMKJ08090
	for linux-xfs-outgoing; Sat, 5 May 2001 04:22:20 -0700
Received: from legba.tvnet.hu (legba.tvnet.hu [195.38.96.20])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45BMIF08087
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 04:22:18 -0700
Received: from dumballah.tvnet.hu (zeus.city.tvnet.hu [195.38.100.182])
	by legba.tvnet.hu (8.9.3+Sun/8.9.3) with ESMTP id NAA20229
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 13:22:13 +0200 (MEST)
Message-ID: <3AF3E2A9.70603@dumballah.tvnet.hu>
Date: Sat, 05 May 2001 13:23:21 +0200
From: Sipos Ferenc <sferi@dumballah.tvnet.hu>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-ac2 i686; en-US; 0.8.1) Gecko/20010430
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: rh 7.1 installation question
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I don't have any redhat 7.1 cds, I used to choose the network 
installation method, because I have fast connection. I've tried the sgi 
installer's bootnet image, and it works. My question is: is it possible, 
that after the network installation of sgi's xfs install the redhat rpms 
in a network way like the original network installation method? I don't 
want to try it out, because it's a home machine, and if it won't work, 
than I have to reinstall everything. Please tell me, if anybody has such 
experience, because it it works, I will reinstall my system.

Thx

Paco


From owner-linux-xfs@oss.sgi.com Sat May  5 06:57:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45DvRk10768
	for linux-xfs-outgoing; Sat, 5 May 2001 06:57:27 -0700
Received: from marvin.linux-dude.com (c-e98a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.233])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45DvPF10765
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 06:57:26 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f45Dv2001165
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:57:04 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: linux-xfs@oss.sgi.com
Subject: Incredibly slow rebuild of small access_db on xfs partition
Date: Sat, 5 May 2001 15:57:01 +0200
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01050515570100.01078@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

The command (in /etc/mail),
# time make
Rebuilding /etc/mail/access.db.
makemap hash -f /etc/mail/access.db < /etc/mail/access
test -e /etc/mail/access.db && touch /etc/mail/access.db
 
real    1m55.378s
user    0m0.170s
sys     0m18.880s


takes almost two minutes to complete. The access_db has only

# wc access
    705    1428   15002 access

entries. I have to identical installations of suse 7.1 (on this dual PIII 
with  intel chipsets (all over it seems to me). One uses reiserfs and this 
one xfs. The disk is with the xfs partition is,

hda: IBM-DTTA-351010, ATA DISK drive
hda: 19807200 sectors (10141 MB) w/466KiB Cache, CHS=1232/255/63

and has performed reliably so far. On the reiserfs-partitions this command 
takes normal time (<< 1s).

The makemap command will eventually complete after accessing the
disk for the duration of the command. After completion, no error messages
are logged seen in dmesg or /var/log/messages. Also, the memory usage
is quite exessive. Im only running KDE right how and,

 > free
             total       used       free     shared    buffers     cached
Mem:        254684     249156       5528          0          4      69748
-/+ buffers/cache:     179404      75280
Swap:        72252       1496      70756

Any clues?

Greetings,
Jarek



From owner-linux-xfs@oss.sgi.com Sat May  5 07:12:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45ECUp11134
	for linux-xfs-outgoing; Sat, 5 May 2001 07:12:30 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45ECRF11131
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 07:12:27 -0700
Received: (qmail 4017 invoked from network); 5 May 2001 14:12:24 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 5 May 2001 14:12:24 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Jarek Luberek <jarek@swipnet.se>
cc: linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition 
In-reply-to: Your message of "Sat, 05 May 2001 15:57:01 +0200."
             <01050515570100.01078@marvin> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 May 2001 00:12:23 +1000
Message-ID: <17466.989071943@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, 5 May 2001 15:57:01 +0200, 
Jarek Luberek <jarek@swipnet.se> wrote:
>makemap hash -f /etc/mail/access.db < /etc/mail/access
>takes almost two minutes to complete. The access_db has only

strace -c makemap hash -f /etc/mail/access.db < /etc/mail/access

will give a summary of system calls and speed, as a first step in
working out where the delay is.


From owner-linux-xfs@oss.sgi.com Sat May  5 08:30:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45FUce13532
	for linux-xfs-outgoing; Sat, 5 May 2001 08:30:38 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45FUbF13529
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 08:30:37 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f45FSRA09605;
	Sat, 5 May 2001 10:28:27 -0500 (CDT)
Message-ID: <3AF41C77.D1A23AA9@sgi.com>
Date: Sat, 05 May 2001 10:29:59 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chandramouli <ssmouli@wipro.co.in>
CC: linux-xfs@oss.sgi.com, Nithya <Nithya.Ganesan@wipro.com>
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chandramouli wrote:
 
>     Could you please provide me some information on how to install XFS
> on SuSE7.1 linux. Or if you know a place where this doc. already exists
> please point me to that ......

Well, installing from the source will always work.  :)  Pay attention to
the compiler you use to build your kernel, we recommend 2.91.66, but
there have been reports of 2.95.x working.  If you have any problems
building or running XFS, please try 2.91.66 and see if that fixes it.

The userspace commands (you'll need at least xfsprogs) can be built from
the source as well, of course, but the existing RPMs might work ok on
your SuSE system.  It looks like one difference is that SuSE 7.1 puts
man pages in /usr/share/man, while our RPMs have them in /usr/man.

If you want to run your whole system on XFS, that's still tricky at this
point - you'll need to have enough extra partitions to copy over your
system from ext2 partitions to XFS partitions.  We have some general
information on this here: 
http://linux-xfs.sgi.com/projects/xfs/xfsroot.html

If anyone who is SuSE-savvy would like to build some SuSE packages, that
would be most welcome!  :)

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 10:04:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45H47F15517
	for linux-xfs-outgoing; Sat, 5 May 2001 10:04:07 -0700
Received: from infa.abo.fi (IDENT:root@infa.abo.fi [130.232.208.126])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45H45F15514
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:04:06 -0700
Received: (from jweeriks@localhost)
	by infa.abo.fi (8.9.3/8.9.3) id UAA16845
	for linux-xfs@oss.sgi.com; Sat, 5 May 2001 20:04:01 +0300
Date: Sat, 5 May 2001 20:04:01 +0300
From: Johannes Eriksson <jweeriks@infa.abo.fi>
To: linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
Message-ID: <20010505200401.A16626@infa.abo.fi>
Reply-To: Johannes Eriksson <joheriks@abo.fi>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <3AF3BF07.5C0E03CB@wipro.co.in> <3AF41C77.D1A23AA9@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.10i
In-Reply-To: <3AF41C77.D1A23AA9@sgi.com>; from sandeen@sgi.com on Sat, May 05, 2001 at 10:29:59AM -0500
X-Operating-System: Linux 2.2.19
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Eric Sandeen [Sat, May 05, 2001 at 10:29:59AM -0500]:
> 
> The userspace commands (you'll need at least xfsprogs) can be built from
> the source as well, of course, but the existing RPMs might work ok on
> your SuSE system.  It looks like one difference is that SuSE 7.1 puts
> man pages in /usr/share/man, while our RPMs have them in /usr/man.
> 

Why? Red Hat 7.x also puts man pages in /usr/share/man, which is where
they should be according to FHS 2.0.

-- 
Johannes Eriksson
<joherks@abo.fi>

From owner-linux-xfs@oss.sgi.com Sat May  5 10:23:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45HNnM16188
	for linux-xfs-outgoing; Sat, 5 May 2001 10:23:49 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45HNmF16185
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:23:48 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f45HNeA15755;
	Sat, 5 May 2001 12:23:41 -0500 (CDT)
Message-ID: <3AF43774.62270B72@sgi.com>
Date: Sat, 05 May 2001 12:25:08 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Johannes Eriksson <joheriks@abo.fi>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in> <3AF41C77.D1A23AA9@sgi.com> <20010505200401.A16626@infa.abo.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Johannes Eriksson wrote:

> Why? Red Hat 7.x also puts man pages in /usr/share/man, which is where
> they should be according to FHS 2.0.

Good question.  :)  Nathan did the RPM packages, I think - we can
probably fix that up next time around.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 10:31:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45HVP116351
	for linux-xfs-outgoing; Sat, 5 May 2001 10:31:25 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45HVOF16347
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:31:24 -0700
Received: (qmail 19188 invoked by uid 0); 5 May 2001 17:31:17 -0000
Received: from adsl-4-185.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.185)
  by mail.gmx.net (mp001-rz3) with SMTP; 5 May 2001 17:31:17 -0000
Message-ID: <200105051930130023.0064A46E@mail.gmx.de>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sat, 05 May 2001 19:30:13 +0200
From: "linux" <dahouet@gmx.net>
To: linux-xfs@oss.sgi.com
Subject: Problem compliling kernel
Mime-Version: 1.0
Content-Type: text/plain; charset="WINDOWS-1250"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f45HVOF16348
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

i have a mandrake 8.0 on an athlon proc.
i changed my kernel for an 2.4.3 for some network reasons
and now, i would like to have a journaling filesystem , so XFS...
i applied the two patches :
linux-2.4-xfs-1.0.patch
linux-2.4.3-core-xfs-1.0.patch 

but when i tried to compile xfs in the kernel :
and i have this last error :

xfs_bmap.c:2721: Unrecognizable insn:
(insn/i 137 3604 3598 (parallel[ 
            (set (reg:SI 0 eax)
                (asm_operands ("") ("=a") 0[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 287))
            (set (reg:SI 1 edx)
                (asm_operands ("") ("=d") 1[ 
                        (reg:DI 1 edx)
                    ] 
                    [ 
                        (asm_input:DI ("A"))
                    ]  ("linux/xfs_linux.h") 287))
            (clobber (reg:QI 19 dirflag))
            (clobber (reg:QI 18 fpsr))
            (clobber (reg:QI 17 flags))
        ] ) -1 (nil)
    (nil))
xfs_bmap.c:2721: confused by earlier errors, bailing out
make[3]: *** [xfs_bmap.o] Erreur 2
make[3]: Quitte le répertoire `/usr/src/linux-xfs/fs/xfs'
make[2]: *** [first_rule] Erreur 2
make[2]: Quitte le répertoire `/usr/src/linux-xfs/fs/xfs'
make[1]: *** [_subdir_xfs] Erreur 2
make[1]: Quitte le répertoire `/usr/src/linux-xfs/fs'
make: *** [_dir_fs] Erreur 2

i do not know what is wrong...
thanks
@++
nico


From owner-linux-xfs@oss.sgi.com Sat May  5 10:32:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45HWLE16377
	for linux-xfs-outgoing; Sat, 5 May 2001 10:32:21 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45HWLF16374
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:32:21 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f45HV4T21397
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 12:31:04 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sat, 5 May 2001 12:31:04 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Tuning XFS for peak performance.
Message-ID: <Pine.LNX.4.33.0105051227220.21300-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is there a document which has a configuration matrix of how XFS should be
setup to offer peak performance? Say, for a mail/news server format your
xfs partitions with these parameters, adjusting the journal size as needed
for x% of your drive. Or perhpaps more importantly, a drive of size X
needs a journal of x%, a drive of size XX needs a journal of x%, etc? Is
there anything which exists like this? Does anyone have any tips here? I'm
seeing less than stellar system performance. While stable, it doesn't do
me any good if I have to wait 5 mins for PINE to open when it's only
moving a few messages from inbox to other boxes. The same operation would
take 30 seconds with ReiserFS.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Sat May  5 10:43:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45HhXo16546
	for linux-xfs-outgoing; Sat, 5 May 2001 10:43:33 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45HhWF16543
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:43:32 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id C6222CC26; Sat,  5 May 2001 19:41:32 +0100 (BST)
To: "linux" <dahouet@gmx.net>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
References: <200105051930130023.0064A46E@mail.gmx.de>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 05 May 2001 19:41:32 +0100
In-Reply-To: <200105051930130023.0064A46E@mail.gmx.de> ("linux"'s message of "Sat, 05 May 2001 19:30:13 +0200")
Message-ID: <m3ae4rwsdf.fsf@giants.mandrakesoft.com>
Lines: 26
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"linux" <dahouet@gmx.net> writes:

> hi,
> 
> i have a mandrake 8.0 on an athlon proc.
> i changed my kernel for an 2.4.3 for some network reasons
> and now, i would like to have a journaling filesystem , so XFS...

use kgcc :

http://linux-xfs.sgi.com/projects/xfs/faq.html:

Q: Are there any known issues about gcc 2.95 for compiling the XFS kernel tree?

Yes. So far there were some problems reported with kernels built with
gcc 2.95 which were solved by compiling it with egcs 2.91.66. So for
now please use version gcc 2.91.66 (aka egcs 1.1.2) to build your XFS
kernel. If you are using a debian or SuSE based system this means that
you may have to find and install this egcs version. Please note that
the problems with gcc 2.95 seem to be restriced to the i386 platform -
on the ppc it works just fine with 2.95 for instance. All said for gcc
2.95 also applies to redhat's gcc 2.96. On the other hand the gcc
2.95.3 (20010125) from debian unstable seems to work.

kgcc on a Red Hat systems and are located in the compat-egcs package,
Linux-Mandrake systems it's located in the egcs package.

From owner-linux-xfs@oss.sgi.com Sat May  5 10:51:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45Hp8D16694
	for linux-xfs-outgoing; Sat, 5 May 2001 10:51:08 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45Hp7F16691
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 10:51:07 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 850F9CC26; Sat,  5 May 2001 19:49:08 +0100 (BST)
To: Eric Sandeen <sandeen@sgi.com>
Cc: Johannes Eriksson <joheriks@abo.fi>, linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in> <3AF41C77.D1A23AA9@sgi.com>
	<20010505200401.A16626@infa.abo.fi> <3AF43774.62270B72@sgi.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 05 May 2001 19:49:08 +0100
In-Reply-To: <3AF43774.62270B72@sgi.com> (Eric Sandeen's message of "Sat, 05 May 2001 12:25:08 -0500")
Message-ID: <m31yq3ws0r.fsf@giants.mandrakesoft.com>
Lines: 25
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen <sandeen@sgi.com> writes:

> Johannes Eriksson wrote:
> 
> > Why? Red Hat 7.x also puts man pages in /usr/share/man, which is where
> > they should be according to FHS 2.0.
> 
> Good question.  :)  Nathan did the RPM packages, I think - we can
> probably fix that up next time around.

well for the mdk package i did :

%install

[...]

mv %{buildroot}/usr/man %{buildroot}/%{_mandir}

[... filelist build ....]

perl -p -i -e 's|/usr/man|%{_mandir}|' files*rpm


> 
> -Eric

From owner-linux-xfs@oss.sgi.com Sat May  5 11:00:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45I02516996
	for linux-xfs-outgoing; Sat, 5 May 2001 11:00:02 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45I00F16975
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 11:00:00 -0700
Received: (qmail 18566 invoked by uid 0); 5 May 2001 17:59:53 -0000
Received: from adsl-4-185.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.185)
  by mail.gmx.net (mail07) with SMTP; 5 May 2001 17:59:53 -0000
Message-ID: <200105051958490712.007ED63E@mail.gmx.de>
In-Reply-To: <m3ae4rwsdf.fsf@giants.mandrakesoft.com>
References: <200105051930130023.0064A46E@mail.gmx.de>
 <m3ae4rwsdf.fsf@giants.mandrakesoft.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sat, 05 May 2001 19:58:49 +0200
From: "linux" <dahouet@gmx.net>
To: "Chmouel Boudjnah" <chmouel@mandrakesoft.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f45I01F16986
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi

thanks for your answer.
i red in the mailing list archive, that kgcc was not required

so i have installed egcs 1.1.2-44mdk
now when i try to compile
i've made a : make clean; make dep
i have this when i do a make bzImage : 
kgcc  -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
<command line>: warning: "cpu" re-asserted
<command line>: warning: "machine" re-asserted
In file included from /usr/src/linux-xfs/include/linux/kernel.h:10,
                 from /usr/src/linux-xfs/include/linux/wait.h:13,
                 from /usr/src/linux-xfs/include/linux/fs.h:12,
                 from /usr/src/linux-xfs/include/linux/capability.h:17,
                 from /usr/src/linux-xfs/include/linux/binfmts.h:5,
                 from /usr/src/linux-xfs/include/linux/sched.h:9,
                 from /usr/src/linux-xfs/include/linux/mm.h:4,
                 from /usr/src/linux-xfs/include/linux/slab.h:14,
                 from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: parse error before `__gnuc_va_list'
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: warning: data definition has no type or storage class
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: parse error before `va_list'
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: warning: data definition has no type or storage class
In file included from /usr/src/linux-xfs/include/linux/wait.h:13,
                 from /usr/src/linux-xfs/include/linux/fs.h:12,
                 from /usr/src/linux-xfs/include/linux/capability.h:17,
                 from /usr/src/linux-xfs/include/linux/binfmts.h:5,
                 from /usr/src/linux-xfs/include/linux/sched.h:9,
                 from /usr/src/linux-xfs/include/linux/mm.h:4,
                 from /usr/src/linux-xfs/include/linux/slab.h:14,
                 from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/src/linux-xfs/include/linux/kernel.h:62: parse error before `va_list'
/usr/src/linux-xfs/include/linux/kernel.h:62: warning: function declaration isn't a prototype
cpp: -lang-c: linker input file unused since linking not done
make: *** [init/main.o] Erreur 1


thanks
@++
Nico

Le 05/05/2001 à 19:41 Chmouel Boudjnah a écrit :

>"linux" <dahouet@gmx.net> writes:
>
>> hi,
>> 
>> i have a mandrake 8.0 on an athlon proc.
>> i changed my kernel for an 2.4.3 for some network reasons
>> and now, i would like to have a journaling filesystem , so XFS...
>
>use kgcc :



From owner-linux-xfs@oss.sgi.com Sat May  5 11:09:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45I96U17207
	for linux-xfs-outgoing; Sat, 5 May 2001 11:09:06 -0700
Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45I94F17203
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 11:09:04 -0700
Received: (qmail 10779 invoked by uid 8); 5 May 2001 18:09:02 -0000
From: thomas graichen <list-linux.sgi.xfs@spoiled.org>
Reply-To: thomas graichen <tgr@spoiled.org>
X-Newsgroups: spoiled.linux.sgi.xfs
Subject: suggestion: splitting the xfs list
Date: Sat, 5 May 2001 19:09:25 +0200
Organization: spoiled dot org
Lines: 19
Distribution: local
Message-ID: <news2mail-20010505170925.3A80EA93.NOFFLE@gray.example.com>
Reply-To: thomas graichen <tgr@spoiled.org>
X-Complaints-To: newsmaster@spoiled.org
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (Linux/2.4.3-XFS (i586))
To: linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

just an idea: now that most of the postings on this list are about
rpm's, devfs problems, congrats to the 1.0 release* - wouldn't it
be a good idea to split the list into a technical list - say
xfs-hackers and a user list (i think it's best to leave the old
list for this) so that people not having too much time can
still keep up with all the XFS technical efforts and people
trying and using XFS have a forum too ... as said - this is
just an idea ...

t

* i think this is not a problem as such, but i assume this movement
  of the contents in the list will get more and more into that
  direction as more as XFS gets an often used fs

-- 
thomas graichen <tgr@spoiled.org> ... perfection is reached, not
when there is no longer anything to add, but when there is no
longer anything to take away. --- antoine de saint-exupery

From owner-linux-xfs@oss.sgi.com Sat May  5 11:16:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45IGHi17372
	for linux-xfs-outgoing; Sat, 5 May 2001 11:16:17 -0700
Received: from fencepost.gnu.org (we-refuse-to-spy-on-our-users@fencepost.gnu.org [199.232.76.164])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45IGGF17369
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 11:16:16 -0700
Received: from buytenh by fencepost.gnu.org with local (Exim 3.16 #1 (Debian))
	id 14w6bE-0007uK-00; Sat, 05 May 2001 14:16:12 -0400
Date: Sat, 5 May 2001 14:16:12 -0400
From: Lennert Buytenhek <buytenh@gnu.org>
To: thomas graichen <tgr@spoiled.org>
Cc: linux-xfs@oss.sgi.com
Subject: Re: suggestion: splitting the xfs list
Message-ID: <20010505141612.A30232@gnu.org>
References: <news2mail-20010505170925.3A80EA93.NOFFLE@gray.example.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <news2mail-20010505170925.3A80EA93.NOFFLE@gray.example.com>; from list-linux.sgi.xfs@spoiled.org on Sat, May 05, 2001 at 07:09:25PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Sounds like a good plan. I would be most interested in a list with
just announcements, for example.


On Sat, May 05, 2001 at 07:09:25PM +0200, thomas graichen wrote:

> just an idea: now that most of the postings on this list are about
> rpm's, devfs problems, congrats to the 1.0 release* - wouldn't it
> be a good idea to split the list into a technical list - say
> xfs-hackers and a user list (i think it's best to leave the old
> list for this) so that people not having too much time can
> still keep up with all the XFS technical efforts and people
> trying and using XFS have a forum too ... as said - this is
> just an idea ...
> 
> t
> 
> * i think this is not a problem as such, but i assume this movement
>   of the contents in the list will get more and more into that
>   direction as more as XFS gets an often used fs
> 
> -- 
> thomas graichen <tgr@spoiled.org> ... perfection is reached, not
> when there is no longer anything to add, but when there is no
> longer anything to take away. --- antoine de saint-exupery

From owner-linux-xfs@oss.sgi.com Sat May  5 11:50:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45Ioev17913
	for linux-xfs-outgoing; Sat, 5 May 2001 11:50:40 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45IodF17910
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 11:50:39 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f45IoaA03904;
	Sat, 5 May 2001 13:50:36 -0500 (CDT)
Message-ID: <3AF44BD9.DAFEE24@sgi.com>
Date: Sat, 05 May 2001 13:52:09 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lennert Buytenhek <buytenh@gnu.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: suggestion: splitting the xfs list
References: <news2mail-20010505170925.3A80EA93.NOFFLE@gray.example.com> <20010505141612.A30232@gnu.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Lennert Buytenhek wrote:

> Sounds like a good plan. I would be most interested in a list with
> just announcements, for example.

Hi Lennert - there is such a list, see the mailing list page on the xfs
website.


> You may subscribe to the mailing list by sending a message 
> to the address:
> 
>       majordomo@oss.sgi.com

...

> Anybody wishing to not be involved with day to day 
> XFS discussions may subscribe to the announcements only list:
>
>      subscribe linux-xfs-announce your@email.address

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 12:25:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45JPat18405
	for linux-xfs-outgoing; Sat, 5 May 2001 12:25:36 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45JPZF18402
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 12:25:35 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f45JPSU24934;
	Sat, 5 May 2001 14:25:28 -0500 (CDT)
Message-ID: <3AF45406.BFB1F78C@sgi.com>
Date: Sat, 05 May 2001 14:27:02 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Johannes Eriksson <joheriks@abo.fi>, linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in> <3AF41C77.D1A23AA9@sgi.com> <20010505200401.A16626@infa.abo.fi> <3AF43774.62270B72@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ah, I see now that it's probably a result of building the userspace
packages on an older system - the man location is set during "configure"
so if it's in /usr/man rather than /usr/share/man, that's probably a
result of building on a non-FHS 2.0 compliant system.

Still, next spin, we can clean that up.

Thanks for pointing it out!

-Eric

Eric Sandeen wrote:
> 
> Johannes Eriksson wrote:
> 
> > Why? Red Hat 7.x also puts man pages in /usr/share/man, which is where
> > they should be according to FHS 2.0.
> 
> Good question.  :)  Nathan did the RPM packages, I think - we can
> probably fix that up next time around.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 13:14:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45KEkF19199
	for linux-xfs-outgoing; Sat, 5 May 2001 13:14:46 -0700
Received: from marvin.linux-dude.com (c-f08a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.240])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45KEjF19196
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 13:14:45 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f45KEec00749;
	Sat, 5 May 2001 22:14:40 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Keith Owens <kaos@melbourne.sgi.com>
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Date: Sat, 5 May 2001 22:14:40 +0200
X-Mailer: KMail [version 1.2]
References: <17466.989071943@ocs3.ocs-net>
In-Reply-To: <17466.989071943@ocs3.ocs-net>
Cc: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Message-Id: <01050522144000.00690@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Saturday 05 May 2001 16:12, you wrote:
> On Sat, 5 May 2001 15:57:01 +0200,
>
> Jarek Luberek <jarek@swipnet.se> wrote:
> >makemap hash -f /etc/mail/access.db < /etc/mail/access
> >takes almost two minutes to complete. The access_db has only
>
> strace -c makemap hash -f /etc/mail/access.db < /etc/mail/access
>
> will give a summary of system calls and speed, as a first step in
> working out where the delay is.
After wiping the eggs from my face I had a look at the strace
both from the good run and the bad.

Where the good does a few things like
----------
open("/etc/mail/access.db", O_RDWR|O_CREAT|O_TRUNC, 0644) = 5
shmat(5, 0x242, 0x2)                    = ?
stat64("/etc/mail/access.db", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
brk(0x805b000)                          = 0x805b000
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
lseek(5, 0, SEEK_SET)                   = 0
write(5, "\0\6\25a\0\0\0\2\0\0\4\322\0\0\20\0\0\0\0\f\0\0\1\0\0\0"..., 260) = 
260
lseek(5, 12288, SEEK_SET)               = 12288
-----------

execution on the xfs partition is full of,

-------
lseek(5, 786432, SEEK_SET)              = 786432
write(5, "\0\0\372\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536)
= 65536
lseek(5, 131072, SEEK_SET)              = 131072
write(5, "\2\0\1\20\0\0\366\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536) 
= 65536
lseek(5, 524288, SEEK_SET)              = 524288
write(5, "\4\0\367\377\3\0\3\20\362\377\344\377\362\377\0\0\0\0\0"..., 65536) 
= 65536
lseek(5, 655360, SEEK_SET)              = 655360
write(5, "\0\0\372\377\0\0\366\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536)
= 65536
--------


close to 20000 lines of it. I have to go back and figure out why my access.db
got corrupt. 
The difference between the dumps seems to be:

lseek(5, 0, SEEK_SET)                   = 0
write(5, "\0\6\25a\0\0\0\2\0\0\4\322\0\0\20\0\0\0\0\f\0\0\1\0\0\0"..., 260) = 
260
lseek(5, 12288, SEEK_SET)               = 12288

in the good dump and

lseek(5, 0, SEEK_SET)                   = 0
write(5, "\0\6\25a\0\0\0\2\0\0\4\322\0\1\0\0\0\0\0\20\0\0\1\0\0\0"..., 260) = 
260
lseek(5, 196608, SEEK_SET)              = 196608


Which b.t.w. reminds me that /etc/hosts was full of NULL yesterday too. May 
be the same problem. I'll keep looking for clues.

Greetings,
Jarek


From owner-linux-xfs@oss.sgi.com Sat May  5 13:29:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45KTag19424
	for linux-xfs-outgoing; Sat, 5 May 2001 13:29:36 -0700
Received: from marvin.linux-dude.com (c-e18a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.225])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45KTZF19421
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 13:29:35 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f45KTX200729;
	Sat, 5 May 2001 22:29:33 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: linux-xfs@oss.sgi.com, Keith Owens <kaos@melbourne.sgi.com>
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Date: Sat, 5 May 2001 22:29:32 +0200
X-Mailer: KMail [version 1.2]
References: <17466.989071943@ocs3.ocs-net> <01050522144000.00690@marvin>
In-Reply-To: <01050522144000.00690@marvin>
MIME-Version: 1.0
Message-Id: <01050522293200.00688@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I just went back to the xfs partition an it seems that
every time I run the makemap command I get a file
of the size  154599424. The correct size is 28672.

Finally, the output from strace -c on the xfs partition:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 53.34    4.030099         788      5113           write
 44.63    3.371511         651      5182           read
  1.87    0.141185          14     10284           lseek

The time of the makemap command on the xfs partition
was this time 

real    0m24.263s
user    0m0.070s
sys     0m7.650s

Greetings,
jarek

From owner-linux-xfs@oss.sgi.com Sat May  5 14:49:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45LnTT20805
	for linux-xfs-outgoing; Sat, 5 May 2001 14:49:29 -0700
Received: from dusnt051.satama.de (dusmail.owd.de [194.77.80.139])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45LnRF20802
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 14:49:28 -0700
Received: from 194.77.80.136 by dusnt051.satama.de (InterScan E-Mail VirusWall NT); Sat, 05 May 2001 23:49:10 +0200 (W. Europe Daylight Time)
Received: from bellapc.satama (dhcp-179.satama.de [194.77.80.179]) by dus010.satama.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D35JSMNP; Sat, 5 May 2001 23:49:09 +0200
Date: Sat, 5 May 2001 23:45:00 +0200 (CEST)
From: Andriy.Bilous@satama.de
X-Sender: bella@bellapc.satama
To: linux <dahouet@gmx.net>
cc: Chmouel Boudjnah <chmouel@mandrakesoft.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
In-Reply-To: <200105051958490712.007ED63E@mail.gmx.de>
Message-ID: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Uncomment
CC              = $(CROSS_COMPILE)gcc -V egcs-2.91.66
and comment
CC             = $(CROSS_COMPILE)kgcc

-- 
E-mail: Andriy.Bilous@satama.de


From owner-linux-xfs@oss.sgi.com Sat May  5 15:23:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45MNll21104
	for linux-xfs-outgoing; Sat, 5 May 2001 15:23:47 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45MNjF21101
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:23:45 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA09271
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:23:45 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA92118;
	Sat, 5 May 2001 15:22:28 -0700 (PDT)
Date: Sat, 5 May 2001 15:22:05 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Sipos Ferenc <sferi@dumballah.tvnet.hu>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: rh 7.1 installation question
In-Reply-To: <3AF3E2A9.70603@dumballah.tvnet.hu>
Message-ID: <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I don't have any redhat 7.1 cds, I used to choose the network
> installation method, because I have fast connection. I've tried the sgi
> installer's bootnet image, and it works. My question is: is it possible,
> that after the network installation of sgi's xfs install the redhat rpms
> in a network way like the original network installation method? I don't
> want to try it out, because it's a home machine, and if it won't work,
> than I have to reinstall everything. Please tell me, if anybody has such
> experience, because it it works, I will reinstall my system.

my understanding is that you cannot do a mixed install with part CD and
part network. if you want network, need to have an archive of the RH 7.1 +
XFS images in one location.  Eric (or anyone else), correct me if I am
wrong?

at some point, I think we were going to put an anonymous ftp up on oss of
redhat+xfs but there were legal problems with having crypto rpms up there
(and sgi did not want to go through the legal headaches of making sure it
would be ok (you may think that the US opened up their encryption export
policy, but there are still some legal questions about sticking stuff on
the internet if you have not gotten g'ment permission (but IANAL))).

so, if somebody who is not in the US or does not care if they get a call
from the FBI or MPO :) wants to put up an ftp or http archive of all three
CD's, this is what you can do:

Copy redhat disk1 into a directory...then disk2...then sgi xfs disk.
each time, make sure to copy *over* all the existing files that conflict.
then, you should have a directory archive that can be installed from the
three different network methods (assuming you have put this directory
structure in a publicly accessable place :)

and then watch your bandwith come to a screaching halt when you advertise
this to linux-xfs...

later,
-tduffy



From owner-linux-xfs@oss.sgi.com Sat May  5 15:34:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45MY3p21209
	for linux-xfs-outgoing; Sat, 5 May 2001 15:34:03 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45MY2F21206
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:34:02 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f45MXvmZ010276;
	Sat, 5 May 2001 17:33:57 -0500 (CDT)
Message-ID: <3AF47FCF.B6D92A72@thebarn.com>
Date: Sat, 05 May 2001 17:33:51 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jarek Luberek <jarek@swipnet.se>
CC: linux-xfs@oss.sgi.com, Keith Owens <kaos@melbourne.sgi.com>
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
References: <17466.989071943@ocs3.ocs-net> <01050522144000.00690@marvin> <01050522293200.00688@marvin>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jarek Luberek wrote:

This is probably the same problem as rpm --rebuilddb

the db package apparently query the files system for the
"optimal" transfer size, on XFS this is 64k on ext2 it's 4k.

The theory is that db is using a 64k blocks for every record rather
than 4k?

You can turn this number down in xfs... hmm maybe I can make it
a tunable parameter, that way we can test this theory quickly.



> Hi,
>
> I just went back to the xfs partition an it seems that
> every time I run the makemap command I get a file
> of the size  154599424. The correct size is 28672.
>
> Finally, the output from strace -c on the xfs partition:
>
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  53.34    4.030099         788      5113           write
>  44.63    3.371511         651      5182           read
>   1.87    0.141185          14     10284           lseek
>
> The time of the makemap command on the xfs partition
> was this time
>
> real    0m24.263s
> user    0m0.070s
> sys     0m7.650s
>
> Greetings,
> jarek

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat May  5 15:36:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45Mav321272
	for linux-xfs-outgoing; Sat, 5 May 2001 15:36:57 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45MavF21269
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:36:57 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f45MammZ010362;
	Sat, 5 May 2001 17:36:48 -0500 (CDT)
Message-ID: <3AF4807B.877D6E55@thebarn.com>
Date: Sat, 05 May 2001 17:36:43 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jarek Luberek <jarek@swipnet.se>
CC: Keith Owens <kaos@melbourne.sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
References: <17466.989071943@ocs3.ocs-net> <01050522144000.00690@marvin>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jarek Luberek wrote:

>
> Which b.t.w. reminds me that /etc/hosts was full of NULL yesterday too. May
> be the same problem. I'll keep looking for clues.

Did the system come down abnormally?
It's possible to have unwritten data in cache that would not be on
disk of the system crash or was not cleanly shutdown.
Since file size updates are  one thing that is not logged, the size of the file
may have been updated correctly but the actually data never went to disk.


>
>
> Greetings,
> Jarek

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat May  5 15:39:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45Md7E21294
	for linux-xfs-outgoing; Sat, 5 May 2001 15:39:07 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45Md6F21291
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 15:39:06 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f45Md1mZ010394;
	Sat, 5 May 2001 17:39:02 -0500 (CDT)
Message-ID: <3AF48100.D475D1E7@thebarn.com>
Date: Sat, 05 May 2001 17:38:56 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: Chmouel Boudjnah <chmouel@mandrakesoft.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
References: <200105051930130023.0064A46E@mail.gmx.de>
	 <m3ae4rwsdf.fsf@giants.mandrakesoft.com> <200105051958490712.007ED63E@mail.gmx.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:

> hi
>
> thanks for your answer.
> i red in the mailing list archive, that kgcc was not required

The devel tree has been fixed not the 1.0 tree.

>
>
> so i have installed egcs 1.1.2-44mdk

make sure to do a "make mrproper "  before switching compilers.


>
> now when i try to compile
> i've made a : make clean; make dep
> i have this when i do a make bzImage :
> kgcc  -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
> <command line>: warning: "cpu" re-asserted
> <command line>: warning: "machine" re-asserted
> In file included from /usr/src/linux-xfs/include/linux/kernel.h:10,
>                  from /usr/src/linux-xfs/include/linux/wait.h:13,
>                  from /usr/src/linux-xfs/include/linux/fs.h:12,
>                  from /usr/src/linux-xfs/include/linux/capability.h:17,
>                  from /usr/src/linux-xfs/include/linux/binfmts.h:5,
>                  from /usr/src/linux-xfs/include/linux/sched.h:9,
>                  from /usr/src/linux-xfs/include/linux/mm.h:4,
>                  from /usr/src/linux-xfs/include/linux/slab.h:14,
>                  from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
>                  from init/main.c:15:
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: parse error before `__gnuc_va_list'
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: warning: data definition has no type or storage class
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: parse error before `va_list'
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: warning: data definition has no type or storage class
> In file included from /usr/src/linux-xfs/include/linux/wait.h:13,
>                  from /usr/src/linux-xfs/include/linux/fs.h:12,
>                  from /usr/src/linux-xfs/include/linux/capability.h:17,
>                  from /usr/src/linux-xfs/include/linux/binfmts.h:5,
>                  from /usr/src/linux-xfs/include/linux/sched.h:9,
>                  from /usr/src/linux-xfs/include/linux/mm.h:4,
>                  from /usr/src/linux-xfs/include/linux/slab.h:14,
>                  from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
>                  from init/main.c:15:
> /usr/src/linux-xfs/include/linux/kernel.h:62: parse error before `va_list'
> /usr/src/linux-xfs/include/linux/kernel.h:62: warning: function declaration isn't a prototype
> cpp: -lang-c: linker input file unused since linking not done
> make: *** [init/main.o] Erreur 1
>
> thanks
> @++
> Nico
>
> Le 05/05/2001 à 19:41 Chmouel Boudjnah a écrit :
>
> >"linux" <dahouet@gmx.net> writes:
> >
> >> hi,
> >>
> >> i have a mandrake 8.0 on an athlon proc.
> >> i changed my kernel for an 2.4.3 for some network reasons
> >> and now, i would like to have a journaling filesystem , so XFS...
> >
> >use kgcc :

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat May  5 16:01:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45N1lV21521
	for linux-xfs-outgoing; Sat, 5 May 2001 16:01:47 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45N1jF21512
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:01:45 -0700
Received: (qmail 25181 invoked by uid 0); 5 May 2001 23:01:39 -0000
Received: from adsl-4-48.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.48)
  by mail.gmx.net (mail02) with SMTP; 5 May 2001 23:01:39 -0000
Message-ID: <200105060100330924.019315D3@mail.gmx.de>
In-Reply-To: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama>
References: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sun, 06 May 2001 01:00:33 +0200
From: "linux" <dahouet@gmx.net>
To: Andriy.Bilous@satama.de
Cc: "Chmouel Boudjnah" <chmouel@mandrakesoft.com>, linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f45N1kF21514
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

thanks for your answer,

i tried this once but it was complaining about not finding cpp0
[root@bretagne linux-xfs]# make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c
scripts/split-include include/linux/autoconf.h include/config
gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
gcc: installation problem, cannot exec `cpp0': Aucun fichier ou r?pertoire de ce type
make: *** [init/main.o] Erreur 1
[root@bretagne linux-xfs]# locate cpp0
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/cpp0
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/tradcpp0

cpp0 is not at the right place ? where do i put it  ?
thanks
@++
nico 


Le 05/05/2001 à 23:45 Andriy.Bilous@satama.de a écrit :

>Uncomment
>CC              = $(CROSS_COMPILE)gcc -V egcs-2.91.66
>and comment
>CC             = $(CROSS_COMPILE)kgcc
u


From owner-linux-xfs@oss.sgi.com Sat May  5 16:02:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45N2gW21543
	for linux-xfs-outgoing; Sat, 5 May 2001 16:02:42 -0700
Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45N2fF21539
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:02:41 -0700
Received: from apal-192.ii.uib.no (apal.ii.uib.no) [129.177.192.27] 
	by ii.uib.no with esmtp (Exim 3.03)
	id 14wB4b-0005I4-00 ; Sun, 06 May 2001 01:02:49 +0200
Received: (from janfrode@localhost)
	by apal.ii.uib.no (8.9.3+Sun/8.9.3) id BAA00431;
	Sun, 6 May 2001 01:02:38 +0200 (MEST)
Date: Sun, 6 May 2001 01:02:38 +0200
From: Jan-Frode Myklebust <janfrode@parallab.uib.no>
To: Tom Duffy <tduffy@engr.sgi.com>
Cc: Sipos Ferenc <sferi@dumballah.tvnet.hu>, linux-xfs@oss.sgi.com
Subject: Re: rh 7.1 installation question
Message-ID: <20010506010237.A52@ii.uib.no>
References: <3AF3E2A9.70603@dumballah.tvnet.hu> <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com>; from tduffy@engr.sgi.com on Sat, May 05, 2001 at 03:22:05PM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, May 05, 2001 at 03:22:05PM -0700, Tom Duffy wrote:
> 
> Copy redhat disk1 into a directory...then disk2...then sgi xfs disk.
> each time, make sure to copy *over* all the existing files that conflict.
> then, you should have a directory archive that can be installed from the
> three different network methods (assuming you have put this directory
> structure in a publicly accessable place :)

done, or rather.. The necessary RH7.1 files are linked into the same
directory structure.

	ftp://ftp.ii.uib.no/pub/RedHat-7.1-XFS/

Connected to the world (UNINETT) by 155MBit ATM.

> 
> and then watch your bandwith come to a screaching halt when you advertise
> this to linux-xfs...
> 

Haven't been any problem so far, but it would probably be good if
there showed up more mirrors listed at the oss.sgi.com webpages.



  -jf

From owner-linux-xfs@oss.sgi.com Sat May  5 16:26:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45NQIk21947
	for linux-xfs-outgoing; Sat, 5 May 2001 16:26:18 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45NQHF21944
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:26:17 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f45NOtB00166;
	Sat, 5 May 2001 18:24:56 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF498D9.477C9936@thebarn.com>
Date: Sat, 05 May 2001 19:20:41 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan-Frode Myklebust <janfrode@parallab.uib.no>
CC: Tom Duffy <tduffy@engr.sgi.com>, Sipos Ferenc <sferi@dumballah.tvnet.hu>,
   linux-xfs@oss.sgi.com
Subject: Re: rh 7.1 installation question
References: <3AF3E2A9.70603@dumballah.tvnet.hu> <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com> <20010506010237.A52@ii.uib.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jan-Frode Myklebust wrote:

Or you could just grab it from ftp://ftp.thebarn.com/SGI/install
This directory is maintained as such RH7.1 + 7.1 updates + SGI XFS

In fact a nice mirror site would be good.


> On Sat, May 05, 2001 at 03:22:05PM -0700, Tom Duffy wrote:
> >
> > Copy redhat disk1 into a directory...then disk2...then sgi xfs disk.
> > each time, make sure to copy *over* all the existing files that conflict.
> > then, you should have a directory archive that can be installed from the
> > three different network methods (assuming you have put this directory
> > structure in a publicly accessable place :)
>
> done, or rather.. The necessary RH7.1 files are linked into the same
> directory structure.
>
>         ftp://ftp.ii.uib.no/pub/RedHat-7.1-XFS/
>
> Connected to the world (UNINETT) by 155MBit ATM.
>
> >
> > and then watch your bandwith come to a screaching halt when you advertise
> > this to linux-xfs...
> >
>
> Haven't been any problem so far, but it would probably be good if
> there showed up more mirrors listed at the oss.sgi.com webpages.
>
>   -jf

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Sat May  5 16:26:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45NQgW21958
	for linux-xfs-outgoing; Sat, 5 May 2001 16:26:42 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45NQfF21955
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:26:41 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f45NQMB00173;
	Sat, 5 May 2001 18:26:22 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF49931.EA6E1939@thebarn.com>
Date: Sat, 05 May 2001 19:22:09 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: Andriy.Bilous@satama.de, Chmouel Boudjnah <chmouel@mandrakesoft.com>,
   linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
References: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama> <200105060100330924.019315D3@mail.gmx.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:

Mandrake 8.0 has kgcc, you need to use it.


> Hi,
>
> thanks for your answer,
>
> i tried this once but it was complaining about not finding cpp0
> [root@bretagne linux-xfs]# make bzImage
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c
> scripts/split-include include/linux/autoconf.h include/config
> gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
> gcc: installation problem, cannot exec `cpp0': Aucun fichier ou r?pertoire de ce type
> make: *** [init/main.o] Erreur 1
> [root@bretagne linux-xfs]# locate cpp0
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/cpp0
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/tradcpp0
>
> cpp0 is not at the right place ? where do i put it  ?
> thanks
> @++
> nico
>
> Le 05/05/2001 à 23:45 Andriy.Bilous@satama.de a écrit :
>
> >Uncomment
> >CC              = $(CROSS_COMPILE)gcc -V egcs-2.91.66
> >and comment
> >CC             = $(CROSS_COMPILE)kgcc
> u

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Sat May  5 16:30:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45NUkp22143
	for linux-xfs-outgoing; Sat, 5 May 2001 16:30:46 -0700
Received: from nic-41-c85-24.mw.mediaone.net (nic-41-c85-24.mn.mediaone.net [66.41.85.24])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f45NUiF22134
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:30:44 -0700
Received: from localhost (localhost.localdomain [127.0.0.1])
	by nic-41-c85-24.mw.mediaone.net (8.11.2/8.11.2) with ESMTP id f45NSjr02032
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 18:28:45 -0500
Date: Sat, 5 May 2001 18:28:45 -0500 (CDT)
From: "Scott M. Hoffman" <scott1021@mediaone.net>
X-X-Sender:  <scott@nic-41-c85-24.mw.mediaone.net>
Reply-To: <scott1021@mediaone.net>
To: <linux-xfs@oss.sgi.com>
Subject: Updates for later gcc versions?
Message-ID: <Pine.LNX.4.33.0105051802150.1974-100000@nic-41-c85-24.mw.mediaone.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  After trying the patch for linux-2.4.4, using gcc 2.95.3, I'm wondering
if there are plans to support the more up to date compilers, as it seems
that the linux-kernel group has the kernel working well with even the RH7
and 7.1 gccs (2.96-64 and 2.96-81).
  If you're interested, the non-xfs kernel (2.4.4, and 2.4.5-pre1) works
fine on my system compiled with gcc 2.95.3. Using the image created from
patching 2.4.4, or 2.4.5-pre1, my system hangs at the ide init stage.  This is
where I had problems before, trying 2.4.2-ac12, which actually rebooted my
system at that point.
  On a side note, while compiling, I noticed quite a bit of the following
messages: xfs_log.h:60 _lsn_cmp defined but not used
  I'm more than happy to try any patches, or provide further info.

Scott


From owner-linux-xfs@oss.sgi.com Sat May  5 16:49:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f45NnYP23008
	for linux-xfs-outgoing; Sat, 5 May 2001 16:49:34 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f45NnWF23005
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 16:49:32 -0700
Received: (qmail 29571 invoked by uid 0); 5 May 2001 23:49:26 -0000
Received: from adsl-4-48.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.48)
  by mail.gmx.net (mp002-rz3) with SMTP; 5 May 2001 23:49:26 -0000
Message-ID: <200105060149260199.01BED4C7@mail.gmx.de>
In-Reply-To: <3AF49931.EA6E1939@thebarn.com>
References: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama>
 <200105060100330924.019315D3@mail.gmx.de>
 <3AF49931.EA6E1939@thebarn.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sun, 06 May 2001 01:49:26 +0200
From: "linux" <dahouet@gmx.net>
To: "Russell Cattelan" <cattelan@thebarn.com>
Cc: Andriy.Bilous@satama.de, "Chmouel Boudjnah" <chmouel@mandrakesoft.com>,
   linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f45NnXF23006
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Le 05/05/2001 à 19:22 Russell Cattelan a écrit :

>linux wrote:
>
>Mandrake 8.0 has kgcc, you need to use it.

ok, one person says to 
Uncomment
CC              = $(CROSS_COMPILE)gcc -V egcs-2.91.66
and comment
CC             = $(CROSS_COMPILE)kgcc

so i start again :
i have a mandrake 8.0 linux box
and there was no kgcc on it
so i installed egcs 1.1.2-44mdk
and now i have kgcc in /usr/bin

and i started with a fresh kernel 2.4.3 downloaded from kernel.org
i applied the two recommended patches :
linux-2.4-xfs-1.0.patch
linux-2.4.3-core-xfs-1.0.patch 

and choose the two kernel option (built in kernel)
i do a make dep
and the make bzImage fails :
[root@bretagne linux-xfs]# make bzImage
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c
scripts/split-include include/linux/autoconf.h include/config
kgcc  -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
<command line>: warning: "cpu" re-asserted
<command line>: warning: "machine" re-asserted
In file included from /usr/src/linux-xfs/include/linux/kernel.h:10,
                 from /usr/src/linux-xfs/include/linux/wait.h:13,
                 from /usr/src/linux-xfs/include/linux/fs.h:12,
                 from /usr/src/linux-xfs/include/linux/capability.h:17,
                 from /usr/src/linux-xfs/include/linux/binfmts.h:5,
                 from /usr/src/linux-xfs/include/linux/sched.h:9,
                 from /usr/src/linux-xfs/include/linux/mm.h:4,
                 from /usr/src/linux-xfs/include/linux/slab.h:14,
                 from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: parse error before `__gnuc_va_list'
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:43: warning: data definition has no type or storage class
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: parse error before `va_list'
/usr/lib/gcc-lib/i586-mandrake-linux/2.96/include/stdarg.h:110: warning: data definition has no type or storage class
In file included from /usr/src/linux-xfs/include/linux/wait.h:13,
                 from /usr/src/linux-xfs/include/linux/fs.h:12,
                 from /usr/src/linux-xfs/include/linux/capability.h:17,
                 from /usr/src/linux-xfs/include/linux/binfmts.h:5,
                 from /usr/src/linux-xfs/include/linux/sched.h:9,
                 from /usr/src/linux-xfs/include/linux/mm.h:4,
                 from /usr/src/linux-xfs/include/linux/slab.h:14,
                 from /usr/src/linux-xfs/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/src/linux-xfs/include/linux/kernel.h:62: parse error before `va_list'
/usr/src/linux-xfs/include/linux/kernel.h:62: warning: function declaration isn't a prototype
cpp: -lang-c: linker input file unused since linking not done
make: *** [init/main.o] Erreur 1

so what can i do, i don't understand what's going on
thanks for your help
@++
nico


From owner-linux-xfs@oss.sgi.com Sat May  5 18:42:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f461g0S24626
	for linux-xfs-outgoing; Sat, 5 May 2001 18:42:00 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f461fxF24623
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 18:41:59 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f461fwA17215;
	Sat, 5 May 2001 20:41:58 -0500 (CDT)
Message-ID: <3AF4AC45.3AADD654@sgi.com>
Date: Sat, 05 May 2001 20:43:33 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: scott1021@mediaone.net
CC: linux-xfs@oss.sgi.com
Subject: Re: Updates for later gcc versions?
References: <Pine.LNX.4.33.0105051802150.1974-100000@nic-41-c85-24.mw.mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Scott M. Hoffman" wrote:
> 
>   After trying the patch for linux-2.4.4, using gcc 2.95.3, I'm wondering
> if there are plans to support the more up to date compilers, as it seems
> that the linux-kernel group has the kernel working well with even the RH7
> and 7.1 gccs (2.96-64 and 2.96-81).

We do plan to get newer gcc's tested & working.  I'm not sure Red Hat's
kernel is the best measure of how well "2.96" works, there are well over
100 (200?) patches in their kernel, and probably patches to gcc as well
- some of that may have to do with making 2.96 compile the kernel.

There ARE fixes in the devel tree for 2.95.x, (the latest "official"
gcc) that are not yet in the 1.0 tree.

>   On a side note, while compiling, I noticed quite a bit of the following
> messages: xfs_log.h:60 _lsn_cmp defined but not used

Quoting Russell a week or so ago:

> Yes that is because the 2.95.3 compiler has a problem with
> one of the inline functions, as such an ifdef turns off the
> inline for that function. The side affect being the function is
> defined for each file that includes that header file.
> It's a hack to get around a bug in gcc 2.95.3.


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 18:48:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f461mJL24782
	for linux-xfs-outgoing; Sat, 5 May 2001 18:48:19 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f461mIF24779
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 18:48:18 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f461mBU06796;
	Sat, 5 May 2001 20:48:11 -0500 (CDT)
Message-ID: <3AF4ADBC.F6645F36@sgi.com>
Date: Sat, 05 May 2001 20:49:48 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Duffy <tduffy@engr.sgi.com>
CC: Sipos Ferenc <sferi@dumballah.tvnet.hu>, linux-xfs@oss.sgi.com
Subject: Re: rh 7.1 installation question
References: <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Duffy wrote:
 
> my understanding is that you cannot do a mixed install with part CD and
> part network. if you want network, need to have an archive of the RH 7.1 +
> XFS images in one location.  Eric (or anyone else), correct me if I am
> wrong?

That's correct.  If anyone wants to hack anaconda to implement that (1/3
CD, 2/3 network), I'll accept patches.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May  5 18:56:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f461u3124896
	for linux-xfs-outgoing; Sat, 5 May 2001 18:56:03 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f461u2F24893
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 18:56:02 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14wDlv-0000rg-00; Sun, 06 May 2001 13:55:43 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Eric Sandeen" <sandeen@sgi.com>,
   "Linux-Xfs@Oss. Sgi. Com" <linux-xfs@oss.sgi.com>
Subject: RH GCC 2.96 patches
Date: Sun, 6 May 2001 13:55:12 +1200
Message-ID: <KPECIILENDDLPCNIMLOFKEKGCDAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

http://rpmfind.net/linux/RPM/redhat/7.1/i386////gcc-2.96-81.i386.html

has a changelog of the RHL-specific patches. Not sure how complete the list
is though.

--
Juha

The malformed orange
Fails to satisfy the eye:
Segmentation fault.



From owner-linux-xfs@oss.sgi.com Sat May  5 19:29:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f462Tve25443
	for linux-xfs-outgoing; Sat, 5 May 2001 19:29:57 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f462ToF25440
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 19:29:51 -0700
Received: (qmail 8979 invoked from network); 6 May 2001 02:29:47 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 6 May 2001 02:29:47 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@ocs.com.au>
To: Daniel Podlejski <underley@underley.eu.org>
cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com
Subject: Re: XFS and Alan kernel tree 
In-reply-to: Your message of "Sat, 05 May 2001 23:08:16 +0200."
             <20010505230816.A31544@witch.underley.eu.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 06 May 2001 12:29:46 +1000
Message-ID: <21978.989116186@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, 5 May 2001 23:08:16 +0200, 
Daniel Podlejski <underley@underley.eu.org> wrote:
>I merge XFS witch Alan tree (2.4.4-ac5). It's seems to be stable.
>Patch against Alan tree is avaliable at:
>
>http://www.underley.eu.org/linux/patch.ac-xfs.diff.bz2
>
>It's 1.0 SGI release. Only XFS, pagebuf and POSIX ACLs code, without KDB.

linux-xfs added to cc: list.  Could you try adding
ftp://oss.sgi.com/projects/kdb/download/ix86/kdb-v1.8-2.4.4-ac5.gz
to your patch?


From owner-linux-xfs@oss.sgi.com Sat May  5 20:50:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f463o1r26478
	for linux-xfs-outgoing; Sat, 5 May 2001 20:50:01 -0700
Received: from moe.rice.edu (moe.rice.edu [128.42.5.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f463njF26472
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 20:49:45 -0700
Received: from photino.sid.rice.edu (photino.sid.rice.edu [128.42.162.116])
	by moe.rice.edu (8.9.0/8.9.0) with ESMTP id WAA29861
	for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 22:49:44 -0500 (CDT)
Received: from photino.sid.rice.edu (rjain@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f463nidi022629
        for <linux-xfs@oss.sgi.com>; Sat, 5 May 2001 22:49:44 -0500
Received: (from rjain@localhost)
        by photino.sid.rice.edu (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f463niqT022627
        for linux-xfs@oss.sgi.com; Sat, 5 May 2001 22:49:44 -0500
Date: Sat, 5 May 2001 22:49:44 -0500
From: Rahul Jain <rahul@rice.edu>
To: linux-xfs@oss.sgi.com
Subject: Re: rh 7.1 installation question
Message-ID: <20010505224944.A22614@photino.sid.rice.edu>
Reply-To: Rahul Jain <rahul@rice.edu>
Mail-Followup-To: linux-xfs@oss.sgi.com
References: <Pine.LNX.4.30.0105051512170.25517-100000@dbear.engr.sgi.com> <3AF4ADBC.F6645F36@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AF4ADBC.F6645F36@sgi.com>; from sandeen@sgi.com on Sat, May 05, 2001 at 08:49:48PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, May 05, 2001 at 08:49:48PM -0500, Eric Sandeen wrote:
> Tom Duffy wrote:
>  
> > my understanding is that you cannot do a mixed install with part CD and
> > part network. if you want network, need to have an archive of the RH 7.1 +
> > XFS images in one location.  Eric (or anyone else), correct me if I am
> > wrong?
> 
> That's correct.  If anyone wants to hack anaconda to implement that (1/3
> CD, 2/3 network), I'll accept patches.  :)
> 

If only you had used debian :)

-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

From owner-linux-xfs@oss.sgi.com Sun May  6 00:26:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f467QnZ28810
	for linux-xfs-outgoing; Sun, 6 May 2001 00:26:49 -0700
Received: from marvin (c-ec8a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.236])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f467QfF28806
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 00:26:42 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f467QFB00727;
	Sun, 6 May 2001 09:26:15 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Date: Sun, 6 May 2001 09:26:15 +0200
X-Mailer: KMail [version 1.2]
References: <17466.989071943@ocs3.ocs-net> <01050522144000.00690@marvin> <3AF4807B.877D6E55@thebarn.com>
In-Reply-To: <3AF4807B.877D6E55@thebarn.com>
MIME-Version: 1.0
Message-Id: <01050609261500.00687@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sunday 06 May 2001 00:36, you wrote:
> Jarek Luberek wrote:
> > Which b.t.w. reminds me that /etc/hosts was full of NULL yesterday too.
> > May be the same problem. I'll keep looking for clues.
>
> Did the system come down abnormally?
Possibly. My GeForce256 locks up occasionally during boot (which is why I 
started to use a journaling file system in the first place)
> It's possible to have unwritten data in cache that would not be on
> disk of the system crash or was not cleanly shutdown.
I do edit /etc/hosts every boot and the lock-up occurs soon
after that when X start. Is xfs journaling meta-data only?

> Since file size updates are  one thing that is not logged, the size of the
> file may have been updated correctly but the actually data never went to
> disk.

/jarek

From owner-linux-xfs@oss.sgi.com Sun May  6 02:54:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f469sUa30855
	for linux-xfs-outgoing; Sun, 6 May 2001 02:54:30 -0700
Received: from smtp-server2.tampabay.rr.com (smtp-server2.tampabay.rr.com [65.32.1.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f469sNF30852
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 02:54:24 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f469oTv22915;
	Sun, 6 May 2001 05:50:30 -0400 (EDT)
Message-ID: <3AF51FA1.1DA5DE2B@cfl.rr.com>
Date: Sun, 06 May 2001 05:55:45 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Chandramouli <ssmouli@wipro.co.in>
CC: linux-xfs@oss.sgi.com, Nithya <Nithya.Ganesan@wipro.com>
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chandramouli wrote:
> 
> hi All,
> 
>     Could you please provide me some information on how to install XFS
> on SuSE7.1 linux. Or if you know a place where this doc. already exists
> please point me to that ......
> 
> Thanks in advance
> Regds
> Mouli

I havn't tried it with SUSE's kernel/7.2. But I know that SuSE's 2.2.18
kernel and 6.4
would not play together. When I did it for SuSE 6.4 I HAD to use a
vanilla kernel and
apply the XFS path. If I also wanted reiser I had to apply the XFS first
then the reiser.
Or was it the other way around. Don't remember..
Anyway if you use a vanilla kernel you really shouldn't have any problem
if there is
still a patch for XFS around. Also you might want to be sure you have
upgraded your gcc
from SUSE to 2.95.3. Back on my 6.4 SuSE box I got it all to play but
had to use the
2.91.6 gcc. The 2.95.2 didn't work but the 2.91.6 caused me headaches
with Xfree so
I gave up on it until they get everything working with the (official
lastest stable
compiler). That is 2.95.3 now and I've heard XFS is ok with that. I may
try again here
soon also. So I guess you best route is to get vanilla kernel sources
and apply the
XFS patch to it and use the 2.95.3 gcc compiler from SuSE. 
Good luck.
-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Sun May  6 03:04:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46A4Y231035
	for linux-xfs-outgoing; Sun, 6 May 2001 03:04:34 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46A4WF31031
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:04:32 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f46A4Uf19763
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 18:04:30 +0800
Received: from kalapati ([203.167.26.9]) by sisa.i-manila.com.ph ; Sun, 06 May 2001 18:04:34 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id CFF4112F9
	for <linux-xfs@oss.sgi.com>; Sun,  6 May 2001 18:03:38 +0800 (PHT)
Date: Sun, 6 May 2001 18:03:38 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: XFS ACLs, Samba 2.2, EAs and the Linux 2.4.4 kernel
Message-ID: <Pine.LNX.4.21.0105061745390.10780-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I'm new to the list and to XFS. I am doing preliminary research to assess
whether we should use XFS in our Samba server or not. We intend to use the
latest release of Samba (v2.2) which supposedly supports XFS ACLs, on a
Linux machine with the latest Linux 2.4.4 kernel patched up to support XFS
Release 1.0.

Has anyone actually set up a server with Samba 2.2 acknowledging XFS ACLs?

Also, there is this Extended Attributes and Access Control Lists for Linux
project at <http://acl.bestbits.at/>. It looks to me like this is a bunch
of patches and tools to make ext2 and the Linux kernel work with EAs and
ACLs.

Does XFS need these patches? Or does XFS implement ACLs on its own, with
its own tools and such? Does XFS support EAs?

In line with ACLs, where can I read up on how XFS implements them? In
particular I'd like to find out about how default ACLs and inheritance are
implemented in XFS.

Please be patient, and if this has been answered before or has an answer
somewhere on the XFS website, please help me out with some URLs.
Unfortunately I can't seem to find a search engine to help me weed out the
XFS mailing list archives to find what I need. Perhaps having a message
search in the XFS mailing list would be a good idea. (Or maybe there is
one, in which case someone please point me out to the right direction).

Thanks a lot in advance! :)

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sun May  6 03:24:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46AOOp31388
	for linux-xfs-outgoing; Sun, 6 May 2001 03:24:24 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46AONF31383
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:24:23 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f46AOLf21922
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 18:24:21 +0800
Received: from kalapati ([203.167.26.9]) by sisa.i-manila.com.ph ; Sun, 06 May 2001 18:24:26 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 4072112F9
	for <linux-xfs@oss.sgi.com>; Sun,  6 May 2001 18:24:12 +0800 (PHT)
Date: Sun, 6 May 2001 18:24:12 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Comparing XFS with ext3 and ReiserFS
Message-ID: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

This is potential flame bait, so I hope the worst doesn't happen. There
are a number of journalling filesystems out there for Linux, and among
them are XFS, ext3, and ReiserFS. In line with my evaluation of XFS, I'm
looking for documents that compare these three filesystems (or more
importantly, XFS vs ext3, and XFS vs ReiserFS).

I already know that for now ACLs only work with XFS (because the EA/ACL
project doesn't support ext3 yet, and ReiserFS is waiting until version 4
to start implementing ACLs). So that's one difference (with XFS winning
over the two other alternatives).

Does anyone have information on performance? Space utilization?
Reliability when recovering from unclean shutdowns?

In the area of reliability when recovering from unclean shutdowns I'm
particularly interested at how XFS deals with its cache/buffer. For
example in mail queues, with ext2 directories can be flagged using chattr
as +S so that all work done with these directories are synchronous. A
little slower, but this is much more stable especially for these queues.
With ReiserFS AFAIK mail queues currently run on a risk because perfectly
timed power downs could cause mail to "disappear". How would situations
like this be handled by XFS?

Again, thank you all in advance.

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sun May  6 03:48:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46Am1531661
	for linux-xfs-outgoing; Sun, 6 May 2001 03:48:01 -0700
Received: from stine.vestdata.no (IDENT:0@[195.204.68.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46AlxF31658
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:47:59 -0700
Received: (from ragnark@localhost)
	by stine.vestdata.no (8.9.3/8.9.3) id MAA11821;
	Sun, 6 May 2001 12:47:46 +0200
Date: Sun, 6 May 2001 12:47:45 +0200
From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <xfs@ragnark.vestdata.no>
To: Federico Sevilla III <jijo@i-manila.com.ph>
Cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010506124745.B11559@vestdata.no>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.5i
In-Reply-To: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>; from Federico Sevilla III on Sun, May 06, 2001 at 06:24:12PM +0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 06, 2001 at 06:24:12PM +0800, Federico Sevilla III wrote:
> Does anyone have information on performance? Space utilization?
reiserfs with tails enabled (default) should be more space-efficient.
When it comes to performance I belive it depends on what kind of load
you're using it for. I believe reiserfs will be faster for lots of small
files, but XFS will be faster for streaming big files.
I'll post real numbers once we've run som real tests though.

> Reliability when recovering from unclean shutdowns?
> 
> In the area of reliability when recovering from unclean shutdowns I'm
> particularly interested at how XFS deals with its cache/buffer. For
> example in mail queues, with ext2 directories can be flagged using chattr
> as +S so that all work done with these directories are synchronous. A
> little slower, but this is much more stable especially for these queues.
> With ReiserFS AFAIK mail queues currently run on a risk because perfectly
> timed power downs could cause mail to "disappear". How would situations
> like this be handled by XFS?

I think this is a misunderstanding.
All three filesystems will guarantee you that the filesystem is intact
after a crash, but data isn't journaled (except with ext3 and
data-journaling enabled), so it doesn't ensure that the _content_ of the
files are up-to-date. Your application should use fsync to ensure this.
(chattr +S on ext2 is just a different way of using fsync)

A MTA should write the mail to disk (and use fsync) _before_ it tells
the sender that the mail has been accepted. This way there is no risk of
loosing mail. I believe qmail doesn't use fsync, but relies on the
filesystem beeing mounted with sync-option (or chattr +S on that
directory). Because doing all IO syncroniously would kill performance,
the reiserfs-team fixed qmail instead of suggesting that people mount
with sync option (or implement chattr +S).


-- 
Ragnar Kjørstad
Big Storage

From owner-linux-xfs@oss.sgi.com Sun May  6 03:48:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46AmGI31672
	for linux-xfs-outgoing; Sun, 6 May 2001 03:48:16 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46AmFF31669
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:48:16 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id E51541E09C; Sun,  6 May 2001 12:48:14 +0200 (MEST)
Date: Sun, 6 May 2001 12:48:08 +0200
From: Andi Kleen <ak@suse.de>
To: Federico Sevilla III <jijo@i-manila.com.ph>
Cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010506124808.A30378@gruyere.muc.suse.de>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>; from jijo@i-manila.com.ph on Sun, May 06, 2001 at 06:24:12PM +0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 06, 2001 at 06:24:12PM +0800, Federico Sevilla III wrote:
> Does anyone have information on performance? Space utilization?
> Reliability when recovering from unclean shutdowns?

I hear there is a secret source called "xfs website" which
has information on all that and more.

> 
> In the area of reliability when recovering from unclean shutdowns I'm
> particularly interested at how XFS deals with its cache/buffer. For
> example in mail queues, with ext2 directories can be flagged using chattr
> as +S so that all work done with these directories are synchronous. A
> little slower, but this is much more stable especially for these queues.
> With ReiserFS AFAIK mail queues currently run on a risk because perfectly
> timed power downs could cause mail to "disappear". How would situations
> like this be handled by XFS?

reiserfs doesn't have this problem. Although it doesn't have synchronous
metadata flushing it has fully sequential metadata flushing. This means
if the mail application did an fsync() on the file data (which it has to) 
then after the fsync returns the directory entry of the file should be
safely on disk because it was created in an earlier transaction, and 
transactions are always flushed in order.
XFS has similar semantics AFAIK.

[modulo IDE/SCSI write cache issues of course; to be really safe you would need
to turn it off but the performance goes through the toilet -- this caveat 
is shared by any file system or application the relies on ordered writes]

-Andi

From owner-linux-xfs@oss.sgi.com Sun May  6 03:50:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46AosA31733
	for linux-xfs-outgoing; Sun, 6 May 2001 03:50:54 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46AoqF31730
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:50:52 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id MAA889852
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 12:50:49 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA11596; Sun, 6 May 2001 20:49:29 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA56877;
	Sun, 6 May 2001 20:49:28 +1000 (EST)
Date: Sun, 6 May 2001 20:49:28 +1000
From: Nathan Scott <nathans@sgi.com>
To: Federico Sevilla III <jijo@i-manila.com.ph>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS ACLs, Samba 2.2, EAs and the Linux 2.4.4 kernel
Message-ID: <20010506204927.A63214@wobbly.melbourne.sgi.com>
References: <Pine.LNX.4.21.0105061745390.10780-100000@kalapati.jijo.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <Pine.LNX.4.21.0105061745390.10780-100000@kalapati.jijo.local>; from jijo@i-manila.com.ph on Sun, May 06, 2001 at 06:03:38PM +0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On Sun, May 06, 2001 at 06:03:38PM +0800, Federico Sevilla III wrote:
> Hi everyone,
> 
> I'm new to the list and to XFS. I am doing preliminary research to assess
> whether we should use XFS in our Samba server or not. We intend to use the
> latest release of Samba (v2.2) which supposedly supports XFS ACLs, on a
> Linux machine with the latest Linux 2.4.4 kernel patched up to support XFS
> Release 1.0.
> 
> Has anyone actually set up a server with Samba 2.2 acknowledging XFS ACLs?
> 

I believe the Connex folk are building a product offering just that -
they'll be able to add more details than I can.  (John?)

> Also, there is this Extended Attributes and Access Control Lists for Linux
> project at <http://acl.bestbits.at/>. It looks to me like this is a bunch
> of patches and tools to make ext2 and the Linux kernel work with EAs and
> ACLs.
> 
> Does XFS need these patches?

No.  At this stage these are largely disjoint projects.

> Or does XFS implement ACLs on its own, with its own tools and such?

Yes.

> Does XFS support EAs?

Yes.

> 
> In line with ACLs, where can I read up on how XFS implements them? In
> particular I'd like to find out about how default ACLs and inheritance are
> implemented in XFS.
> 

I guess there's three main sources: the draft posix ACL standard,
the man pages that come with the ACL and EA commands (see cmd/acl
and cmd/attr in the xfs cvs repository), and the kernel source.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun May  6 03:54:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46AssL31852
	for linux-xfs-outgoing; Sun, 6 May 2001 03:54:54 -0700
Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46AsqF31848
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 03:54:53 -0700
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1)
	id 14wMB1-000FLR-0X
	for linux-xfs@oss.sgi.com; Sun, 6 May 2001 11:54:32 +0100
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 626FE27F1
	for <linux-xfs@oss.sgi.com>; Sun,  6 May 2001 11:53:02 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 84C50125E6; Sun,  6 May 2001 11:53:00 +0100 (BST)
Date: Sun, 6 May 2001 11:52:59 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re: Comparing XFS with ext3 and ReiserFS
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
In-Reply-To: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010506105300.84C50125E6@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f46AsrF31849
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 6 May 2001 18:24:12 +0800 (PHT) Federico Sevilla III <Federico Sevilla III <jijo@i-manila.com.ph>> wrote:
 
> This is potential flame bait, so I hope the worst doesn't happen. There
> are a number of journalling filesystems out there for Linux, and among
> them are XFS, ext3, and ReiserFS. In line with my evaluation of XFS, I'm
> looking for documents that compare these three filesystems (or more
> importantly, XFS vs ext3, and XFS vs ReiserFS).

I have done a comparison for my own purposes, perhaps I should publish the
results.

Ext3 is simply ext2 with journalling, as such it is different to XFS,
ReiserFS and IBM's JFS which are intended to provide more advanced
filesystem capabilities generally (including journalling).

Apart from the more general extention of capabilities, there are two main
differences (at a technical level) between ext3 and the others. One is the
work involved in converting from ext2, ext3 is the only one where one can
convert without having to use dump and restore, for that reason if your
main need is to add journalling to an existing system and have the system
down for the minimum time while converting then it is the one to go for.

The other difference from what I have read is that ext3 allows journalling
of the file content data as well as the metadata, the other three (as far
as I can see) only journal metadata. This may be important to you.

> I already know that for now ACLs only work with XFS (because the EA/ACL
> project doesn't support ext3 yet, and ReiserFS is waiting until version 4
> to start implementing ACLs). So that's one difference (with XFS winning
> over the two other alternatives).
> 

I don't know about the EA/ACL project, but RSBAC seems to run happily on
ext3, you just have to be a little careful about the patches or you dont
get access control on files in an ext3 filesystem.

> Does anyone have information on performance? Space utilization?
> Reliability when recovering from unclean shutdowns?
> 

Ext3 performance is almost identical to ext2, this may be a definite down
for you.

As to reliability, I have had no problems with ext3. I understand that
Sourceforge converted all their existing filesystems to ext3 around
October last year and have been using ReiserFS on all new filesystems
since the same time.


--
Keith Matthews

Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Sun May  6 04:04:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46B4Gx32081
	for linux-xfs-outgoing; Sun, 6 May 2001 04:04:16 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46B4EF32078
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 04:04:15 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 14C0E1E09C; Sun,  6 May 2001 13:04:14 +0200 (MEST)
Date: Sun, 6 May 2001 13:04:13 +0200
From: Andi Kleen <ak@suse.de>
To: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <xfs@ragnark.vestdata.no>
Cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010506130413.B30378@gruyere.muc.suse.de>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506124745.B11559@vestdata.no>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010506124745.B11559@vestdata.no>; from xfs@ragnark.vestdata.no on Sun, May 06, 2001 at 12:47:45PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 06, 2001 at 12:47:45PM +0200, Ragnar Kjørstad wrote:
> A MTA should write the mail to disk (and use fsync) _before_ it tells
> the sender that the mail has been accepted. This way there is no risk of
> loosing mail. I believe qmail doesn't use fsync, but relies on the
> filesystem beeing mounted with sync-option (or chattr +S on that
> directory). Because doing all IO syncroniously would kill performance,
> the reiserfs-team fixed qmail instead of suggesting that people mount
> with sync option (or implement chattr +S).

qmail uses fsync, but relies on the file system to flush metadata
in the spool dir (directory names etc.) synchronously. The guarantee 
in reiserfs that fsync flushes all pending transactions works fine with
qmail. The fsync on the file data after file create forces the filename
on disk which has been in an earlier transaction, and any other metadata 
operations after the fsync (rename/link in Maildir etc.) which could be lost 
are redoable after a crash.

I am not sure if XFS has the same strong ordering (fsync flushing all pending
transactions), perhaps one of the XFS developers could comment.

-Andi

From owner-linux-xfs@oss.sgi.com Sun May  6 06:58:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46DwlP03408
	for linux-xfs-outgoing; Sun, 6 May 2001 06:58:47 -0700
Received: from vela.salleURL.edu (vela.salleURL.edu [130.206.42.85])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46DwiF03405
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 06:58:45 -0700
Received: from localhost (localhost [127.0.0.1])
	by vela.salleURL.edu (8.9.3/8.9.1) with ESMTP id QAA28110
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 16:05:34 GMT
Date: Sun, 6 May 2001 16:05:34 +0000 (GMT)
From: Carles Pina i Estany <is08139@salleURL.edu>
To: <linux-xfs@oss.sgi.com>
Subject: xfs into kernel & Debian
Message-ID: <Pine.LNX.4.33.0105061554260.28061-100000@vela.salleURL.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,

Anybody does know when xfs will be into kernel? (Without patch, officially
into kernel).

And, anybody knows if there are some installation disk for Debian?

PD: Please, send a CC to me because I am not in the list

----
Carles Pina i Estany - #Linux User: 87347 - is08139@salleURL.edu - Pinux
   URL: http://www.salleURL.edu/~is08139
   Debian Woody   Kernel 2.4.4 @ Pentium II 450 MHz 128 MB with ReiserFS
   Debian Woody   Kernel 2.4.4 @ Laptop Pentium 166 MHz 48 MB
   Debian Potato  Kernel 2.4.3 @ Pentium 233 MHz 96 MB with ReiserFS
   ­Horror! Mi disco duro se ha ablandado


From owner-linux-xfs@oss.sgi.com Sun May  6 07:24:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46EOO903889
	for linux-xfs-outgoing; Sun, 6 May 2001 07:24:24 -0700
Received: from sisinteli07.udg.es (sisinteli07.udg.es [130.206.125.95])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46EO7F03885
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 07:24:08 -0700
Received: from gcs by sisinteli07.udg.es with local (Exim 3.22 #1 (Debian))
	id 14wPQV-0007li-00
	for <linux-xfs@oss.sgi.com>; Sun, 06 May 2001 16:22:23 +0200
Date: Sun, 6 May 2001 16:22:23 +0200
From: GCS <gcs@agentsinside.com>
To: linux-xfs@oss.sgi.com
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010506162223.A29723@sisinteli07.udg.es>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: =?iso-8859-1?B?PFBpbmUuTE5YLjQuMjEuMDEw?=
	=?iso-8859-1?Q?5061818500=2E10780-100000=40kalapati=2Ejijo=2Elocal=3E=3B_?=
	=?iso-8859-1?Q?from_jijo=40i-manila=2Ecom=2Eph_on_V=2C_M=C1?=
	=?iso-8859-1?Q?J?= 06, 2001 at 06:24:12 +0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

On V, MÁJ 06, 2001 at 06:24:12 +0800, Federico Sevilla III wrote:

> This is potential flame bait, so I hope the worst doesn't happen.
 Yes, so take my answer as my experience, no more. I do not want to say
which one is the best.

> Does anyone have information on performance? Space utilization?
 I _think_ performance is about the same for XFS and ReiserFS. I forgot
to make a compare test, when I moved to XFS from ReiserFS. Oh, and a
little remark: as I know ext3 patches are for 2.2.x kernels only. It
seems no one is intrested to port it to 2.4.x kernels. Thus I think ext3
lost the game here. :-/ About space utilization: as I know ReiserFS can
put several small files into one cluster, thus preserve more space for
other files. On the other hand, XFS is lazy to allocate inodes, and only
get more (against free clusters to store the file itself) if it is
necessary. The only drawback as I know, that XFS never gives back these
inode clusters. This means, if you create millions of very small files,
and after you delete them, you see your disk storage size shrink.

> Reliability when recovering from unclean shutdowns?
 The only winner is XFS here. I never had any problems with it. The only
thing happened is my enlightenment configuration file got trashed when
it was middle of the writing I guess. But it is not a bug. As for
ReiserFS, it had some problems for me. I noticed several fs corruption,
and I had to run the recover utility. It is fixed the problems, but it
took some time (I have a 16Gb slice). Also, I always deleted the
corrupted directories after. Maybe I got back them cleanly, maybe not,
never checked. Just deleted, and recreated the things.
Also, in the early kernels, ReiserFS was known for file handling bugs,
which corrupted the files afaik.

> With ReiserFS AFAIK mail queues currently run on a risk because perfectly
> timed power downs could cause mail to "disappear". How would situations
> like this be handled by XFS?
 Sure, ReiserFS has (had?) problems with it, but you could download a
patch against this problem. XFS does not have this problem, but I do not
know about it for sure.

Just my thoughts,
Laszlo Boszormenyi

From owner-linux-xfs@oss.sgi.com Sun May  6 07:36:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46EaFT04074
	for linux-xfs-outgoing; Sun, 6 May 2001 07:36:15 -0700
Received: from theirongiant.weebeastie.net (root@theirongiant.weebeastie.net [203.62.148.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46EaCF04070
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 07:36:13 -0700
Received: (from hogarth@localhost)
	by theirongiant.weebeastie.net (8.9.3/8.9.3/Debian 8.9.3-21) id AAA01014;
	Mon, 7 May 2001 00:34:57 +1000
Date: Mon, 7 May 2001 00:34:57 +1000
From: CaT <cat@zip.com.au>
To: GCS <gcs@agentsinside.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010507003457.A478@zip.com.au>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506162223.A29723@sisinteli07.udg.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010506162223.A29723@sisinteli07.udg.es>; from gcs@agentsinside.com on Sun, May 06, 2001 at 04:22:23PM +0200
Organisation: Furball Inc.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 06, 2001 at 04:22:23PM +0200, GCS wrote:
> > Does anyone have information on performance? Space utilization?
>  I _think_ performance is about the same for XFS and ReiserFS. I forgot
> to make a compare test, when I moved to XFS from ReiserFS. Oh, and a
> little remark: as I know ext3 patches are for 2.2.x kernels only. It
> seems no one is intrested to port it to 2.4.x kernels. Thus I think ext3
> lost the game here. :-/ About space utilization: as I know ReiserFS can

Small note: ext3 is being ported to 2.4.x by a few folks. SCT is currently
AFK I believe and has plans on doing this himself when he gets back
(if I remember things correctly). I believe the folks doing the port
are attempting to make SCT's life easier. :)

Don't have anything to say about XFS though. Still looking into it and
may have a few q's of my own soon.

:)

-- 
CaT (cat@zip.com.au)		*** Jenna has joined the channel.
				<cat> speaking of mental giants..
				<Jenna> me, a giant, bullshit
				<Jenna> And i'm not mental
					- An IRC session, 20/12/2000


From owner-linux-xfs@oss.sgi.com Sun May  6 07:37:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46EbF604136
	for linux-xfs-outgoing; Sun, 6 May 2001 07:37:15 -0700
Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46Eb9F04131
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 07:37:12 -0700
Received: (from ragnark@localhost)
	by stine.vestdata.no (8.9.3/8.9.3) id QAA14504;
	Sun, 6 May 2001 16:37:02 +0200
Date: Sun, 6 May 2001 16:37:01 +0200
From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <xfs@ragnark.vestdata.no>
To: GCS <gcs@agentsinside.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010506163701.B12080@vestdata.no>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506162223.A29723@sisinteli07.udg.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.5i
In-Reply-To: <20010506162223.A29723@sisinteli07.udg.es>; from GCS on Sun, May 06, 2001 at 04:22:23PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 06, 2001 at 04:22:23PM +0200, GCS wrote:
> > Does anyone have information on performance? Space utilization?
>  I _think_ performance is about the same for XFS and ReiserFS. I forgot
> to make a compare test, when I moved to XFS from ReiserFS. Oh, and a
> little remark: as I know ext3 patches are for 2.2.x kernels only. It
> seems no one is intrested to port it to 2.4.x kernels. Thus I think ext3
> lost the game here. :-/ About space utilization: as I know ReiserFS can
> put several small files into one cluster, thus preserve more space for
> other files. On the other hand, XFS is lazy to allocate inodes, and only
> get more (against free clusters to store the file itself) if it is
> necessary. The only drawback as I know, that XFS never gives back these
> inode clusters. This means, if you create millions of very small files,
> and after you delete them, you see your disk storage size shrink.

Reiserfs doesn't have "inodes", so it never reservers space for
stat-data. 


-- 
Ragnar Kjørstad
Big Storage

From owner-linux-xfs@oss.sgi.com Sun May  6 07:59:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46ExGx04374
	for linux-xfs-outgoing; Sun, 6 May 2001 07:59:16 -0700
Received: from kjh.linuxworld.pe.kr (IDENT:qmailr@[211.217.77.139])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f46ExDF04370
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 07:59:15 -0700
Received: (qmail 24695 invoked from network); 6 May 2001 14:58:41 -0000
Received: from kjh.linuxworld.pe.kr (HELO linuxworld.pe.kr) (kimjihoe@211.217.77.139)
  by kjh.linuxworld.pe.kr with SMTP; 6 May 2001 14:58:41 -0000
Message-ID: <3AF566A0.1020404@linuxworld.pe.kr>
Date: Sun, 06 May 2001 23:58:40 +0900
From: kimjihoe <kimjihoe@linuxworld.pe.kr>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-XFS i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: ko, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: can't compile xfsprogs-1.2.0.src.tar.gz
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

i use kernel 2.4.3 with linux-2.4.2-core-xfs-1.0.patch and 
linux-2.4.3-core-xfs-1.0.patch.

i try to compile xfsprogs-1.2.0, but fail with following messages.

 In file included from ../include/lvm_user.h:41,
                           from xfs_mkfs.c:43:
../include/liblvm.h:88:21: lvm_log.h: no such file or directory
../include/liblvm.h:89:24: lvm_config.h: no such file or directory


where is lvm_log.h and lvm_config.h ?


Thanks in advance.

JiHoe Kim


From owner-linux-xfs@oss.sgi.com Sun May  6 08:06:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46F6rb04640
	for linux-xfs-outgoing; Sun, 6 May 2001 08:06:53 -0700
Received: from kjh.linuxworld.pe.kr (IDENT:qmailr@[211.217.77.139])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f46F6pF04637
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 08:06:51 -0700
Received: (qmail 24724 invoked from network); 6 May 2001 15:06:17 -0000
Received: from kjh.linuxworld.pe.kr (HELO linuxworld.pe.kr) (kimjihoe@211.217.77.139)
  by kjh.linuxworld.pe.kr with SMTP; 6 May 2001 15:06:17 -0000
Message-ID: <3AF56869.591504C2@linuxworld.pe.kr>
Date: Mon, 07 May 2001 00:06:17 +0900
From: kimjihoe <kimjihoe@linuxworld.pe.kr>
X-Mailer: Mozilla 4.76 [ko] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: ko
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: can't compile xfsprogs-1.2.0.src.tar.gz
References: <3AF566A0.1020404@linuxworld.pe.kr>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



kimjihoe wrote:
> 
> i use kernel 2.4.3 with linux-2.4.2-core-xfs-1.0.patch and
sorry, not linux-2.4.2-core-xfs-1.0.patch, it's linux-2.4-xfs-1.0.patch
> linux-2.4.3-core-xfs-1.0.patch.
> 
> i try to compile xfsprogs-1.2.0, but fail with following messages.
> 
>  In file included from ../include/lvm_user.h:41,
>                            from xfs_mkfs.c:43:
> ../include/liblvm.h:88:21: lvm_log.h: no such file or directory
> ../include/liblvm.h:89:24: lvm_config.h: no such file or directory
> 
> where is lvm_log.h and lvm_config.h ?
> 
> Thanks in advance.
> 
> JiHoe Kim

From owner-linux-xfs@oss.sgi.com Sun May  6 08:24:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46FOeK04974
	for linux-xfs-outgoing; Sun, 6 May 2001 08:24:40 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46FOTF04970
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 08:24:29 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f46FONU04609;
	Sun, 6 May 2001 10:24:23 -0500 (CDT)
Message-ID: <3AF56D0E.B69442F1@sgi.com>
Date: Sun, 06 May 2001 10:26:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Carles Pina i Estany <is08139@salleurl.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs into kernel & Debian
References: <Pine.LNX.4.33.0105061554260.28061-100000@vela.salleURL.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Carles Pina i Estany wrote:

> Anybody does know when xfs will be into kernel? (Without patch, officially
> into kernel).

Ok, this one needs to go in the FAQ.  :)

It is a goal, we are working on it, but as you might expect, we can't
give you a date at this point.

> And, anybody knows if there are some installation disk for Debian?

Someone is working on them - keep an eye on
http://www.markybob.com/xfsboot/

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May  6 08:27:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46FRHL05051
	for linux-xfs-outgoing; Sun, 6 May 2001 08:27:17 -0700
Received: from egghead.curl.com (egghead.curl.com [216.230.83.4])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f46FRGF05048
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 08:27:16 -0700
Received: (qmail 11822 invoked by uid 10171); 6 May 2001 11:27:11 -0400
From: patl@cag.lcs.mit.edu (Patrick J. LoPresti)
To: linux-xfs@oss.sgi.com
Subject: Re: Comparing XFS with ext3 and ReiserFS
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506105300.84C50125E6@rebutia.sweeney.demon.co.uk>
Date: 06 May 2001 11:27:11 -0400
In-Reply-To: <mit.lcs.mail.linux-xfs/20010506105300.84C50125E6@rebutia.sweeney.demon.co.uk>
Message-ID: <s5gbsp6a46o.fsf@egghead.curl.com>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Matthews <keith_m@sweeney.demon.co.uk> writes:

> The other difference from what I have read is that ext3 allows journalling
> of the file content data as well as the metadata, the other three (as far
> as I can see) only journal metadata. This may be important to you.

I apologize if this is a stupid question, but how could data
journalling possibly matter to anybody?

I mean, as long as the data are written to disk before the metadata
are written to the journal, there is no reliability to be gained by
journalling the data.  What am I missing?

Along the same lines: Somebody else said that they power-cycled their
XFS system, ended up with garbage in one of their files, but says this
is "not a bug".  Excuse me?  How could a corrupted file not be a bug?

Perhaps what I am really asking is: Does XFS write the data to disk
before the metadata, or not?

Thanks!

 - Pat

From owner-linux-xfs@oss.sgi.com Sun May  6 09:45:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46GjVl07133
	for linux-xfs-outgoing; Sun, 6 May 2001 09:45:31 -0700
Received: from kjh.linuxworld.pe.kr (IDENT:qmailr@[211.217.77.139])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f46GjUF07129
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 09:45:30 -0700
Received: (qmail 29511 invoked from network); 6 May 2001 16:44:59 -0000
Received: from kjh.linuxworld.pe.kr (HELO linuxworld.pe.kr) (kimjihoe@211.217.77.139)
  by kjh.linuxworld.pe.kr with SMTP; 6 May 2001 16:44:59 -0000
Message-ID: <3AF57F8A.8DE96442@linuxworld.pe.kr>
Date: Mon, 07 May 2001 01:44:58 +0900
From: kimjihoe <kimjihoe@linuxworld.pe.kr>
X-Mailer: Mozilla 4.76 [ko] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: ko
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: can't compile xfsprogs-1.2.0.src.tar.gz
References: <3AF566A0.1020404@linuxworld.pe.kr>
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

OK, it's in cvs tree.

but, why isn't it in tarball, and source rpm?

./Makepkgs does not include it in packages.

why? is there any specail reason?
 
JiHoe Kim

From owner-linux-xfs@oss.sgi.com Sun May  6 10:12:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46HCN407770
	for linux-xfs-outgoing; Sun, 6 May 2001 10:12:23 -0700
Received: from marvin.linux-dude.com (c-d28a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.210])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46HCLF07765
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 10:12:21 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f46HCF500668;
	Sun, 6 May 2001 19:12:15 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Date: Sun, 6 May 2001 19:12:15 +0200
X-Mailer: KMail [version 1.2]
References: <01050515570100.01078@marvin> <01050610421500.00890@marvin> <3AF5693F.A41ACA22@sgi.com>
In-Reply-To: <3AF5693F.A41ACA22@sgi.com>
MIME-Version: 1.0
Message-Id: <01050619121500.00664@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sunday 06 May 2001 17:09, you wrote:
> Hi Jarek - I'll look at this tomorrow.
>
> But in the meantime, can you try something?  Try mounting your xfs root
> (or whatever contains /etc) with "-o biosize=13"
>
> This solved the problem with someone who was having similar problems
> when rebuilding an rpm database, I think it may be related (along with
> the explanation Russell sent).
If 
         mount / -o remount,biosize=13 counts

then I have tried that. Results are as before (/etc is a subdirectory of / ).

Greetings,
jarek

From owner-linux-xfs@oss.sgi.com Sun May  6 10:35:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46HZ6Z08325
	for linux-xfs-outgoing; Sun, 6 May 2001 10:35:06 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46HZ5F08322
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 10:35:05 -0700
Received: from thebarn.com (phuck-wi0.thebarn.com [10.0.0.130])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f46HXhB01897;
	Sun, 6 May 2001 12:33:44 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Message-ID: <3AF5985A.ED8817E4@thebarn.com>
Date: Sun, 06 May 2001 13:30:51 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: kimjihoe <kimjihoe@linuxworld.pe.kr>
CC: linux-xfs@oss.sgi.com
Subject: Re: can't compile xfsprogs-1.2.0.src.tar.gz
References: <3AF566A0.1020404@linuxworld.pe.kr> <3AF57F8A.8DE96442@linuxworld.pe.kr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kimjihoe wrote:

This is part of the current "situation" with LVM.
you need to grab beta 6 from sistina.com and install
the libs and header files.


> OK, it's in cvs tree.
>
> but, why isn't it in tarball, and source rpm?
>
> ./Makepkgs does not include it in packages.
>
> why? is there any specail reason?
>
> JiHoe Kim

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Sun May  6 11:44:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46Iioo09586
	for linux-xfs-outgoing; Sun, 6 May 2001 11:44:50 -0700
Received: from rdb.linux-help.org (root@cc192618-b.oakrdg1.tn.home.com [65.8.221.188])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46IinF09583
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 11:44:49 -0700
Received: from localhost (rdicaire@localhost)
	by rdb.linux-help.org (8.11.3/8.10.2) with ESMTP id f46If1726390
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 14:41:06 -0400
Date: Sun, 6 May 2001 14:41:01 -0400 (EDT)
From: <rdicaire@rdb.linux-help.org>
To: linux-xfs@oss.sgi.com
Subject: ACLs,XFS,Linux nfs v3
Message-ID: <Pine.LNX.4.21.0105061435280.25170-100000@rdb.linux-help.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is there ACL support over NFS mounted XFS filesystems?

chacl -l /home/spgrp_docs/test
chacl: error getting ACL on "/home/spgrp_docs/test": Operation not
supported

/home is nfs mounted.

I've updated util-linux (2.10o), latest knfsd, and latest CVS devel tree
of XFS for 2.4.4. 

Have I missed something or is this just not possible at present?


From owner-linux-xfs@oss.sgi.com Sun May  6 12:12:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46JCB010122
	for linux-xfs-outgoing; Sun, 6 May 2001 12:12:11 -0700
Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JCAF10118
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 12:12:10 -0700
Received: from [209.86.24.117] (user-38lc63l.dialup.mindspring.com [209.86.24.117])
	by barry.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id PAA16976;
	Sun, 6 May 2001 15:12:02 -0400 (EDT)
From: John M Trostel <jtrostel@mindspring.com>
Message-ID: <2.0.2-402229-264-A-OEWW@mail.mindspring.com>
To: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Cc: " Linux XFS Mailing List" <linux-xfs@oss.sgi.com>
Date: Sun, 6 May 2001 15:03:04 -0500
Subject: Re: XFS ACLs, Samba 2.2, EAs and the Linux 2.4.4 kernel
X-Mailer: Eudora 2.0.2 for PalmOS
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

As Nathan mentioned, I have been doing a bit of work integrating XFS 
ACLs into Samba 2.2.  Some answers to specific parts of your questions 
are written below:

Federico Sevilla III wrote:

> 
> Hi everyone,
> 
> I'm new to the list and to XFS. I am doing preliminary research to assess
> whether we should use XFS in our Samba server or not. We intend to use the
> latest release of Samba (v2.2) which supposedly supports XFS ACLs, on a
> Linux machine with the latest Linux 2.4.4 kernel patched up to support XFS
> Release 1.0.
> 
> Has anyone actually set up a server with Samba 2.2 acknowledging XFS ACLs?

I am running several servers using XFS ACLs on Samba 2.2, including my 
personal machine. While some small issues are being worked through, the 
setup generally works well.

> Also, there is this Extended Attributes and Access Control Lists for Linux
> project at <http://acl.bestbits.at/>. It looks to me like this is a bunch
> of patches and tools to make ext2 and the Linux kernel work with EAs and
> ACLs.
> 
> Does XFS need these patches? Or does XFS implement ACLs on its own, with
> its own tools and such? Does XFS support EAs?

XFS does not need these patches. Indeed, a system with these patches 
mixed with  XFS will probably not work very well. Hopefully, these 2 
implementations will converge in the near future. If you are going to 
try XFS, use the tools available from the SGI XFS site. It has it's own 
tools to manage both ACLs  & EAs.
> In line with ACLs, where can I read up on how XFS implements them? In
> particular I'd like to find out about how default ACLs and inheritance are
> implemented in XFS.

The XFS ACL implementation is well documented in both the XFS man pages. 
Default ACLs & inheritance closely follow the posix 'standard', so that 
would be a good read also.

> Please be patient, and if this has been answered before or has an answer
> somewhere on the XFS website, please help me out with some URLs.

A link to the posix 'standards' can be found through links at Andrea's 
bestbits site. I am writing this on my PDA & so do not have immeadiate 
access to get the exact URLs for you. Poking around the bestbits site 
should reveal the link though.

There have been some recent patches to both XFS  & Samba 2.2 to further 
refine both the ACL implementation & the operation with Samba. When you 
get to the point of implementing XFS & Samba, send me another e-mail & I 
will fill you in on the particulars.

From owner-linux-xfs@oss.sgi.com Sun May  6 12:36:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46JaLk11005
	for linux-xfs-outgoing; Sun, 6 May 2001 12:36:21 -0700
Received: from post.webmailer.de (natpost.webmailer.de [192.67.198.65] (may be forged))
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JaJF11002
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 12:36:19 -0700
Received: from alderan.ohlmeier.de (p3E991B33.dip.t-dialin.net [62.153.27.51])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id VAA22897
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 21:36:17 +0200 (MET DST)
Received: from cloudcity (cloudcity.ohlmeier.de [192.168.0.1])
	by alderan.ohlmeier.de (Postfix) with SMTP id 7CD671F6B3
	for <linux-xfs@oss.sgi.com>; Sun,  6 May 2001 21:36:38 +0200 (CEST)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Nils Ohlmeier <lists@ohlmeier.de>
To: linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
Date: Sun, 6 May 2001 21:42:13 +0200
X-Mailer: KMail [version 1.2]
References: <3AF3BF07.5C0E03CB@wipro.co.in>
In-Reply-To: <3AF3BF07.5C0E03CB@wipro.co.in>
MIME-Version: 1.0
Message-Id: <01050621421301.00673@cloudcity>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f46JaKF11003
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Am Samstag,  5. Mai 2001 10:51 schrieben Sie:
> hi All,
>
>     Could you please provide me some information on how to install XFS
> on SuSE7.1 linux. Or if you know a place where this doc. already exists
> please point me to that ......

Hi Mouli,

i'm running XFS on SuSE Linux 7.1. No problems so far.
Follow the instructions on the website. Their should nothing special you have 
to look for.
I grabed a clean kernel tarball (2.4.2, because i had hangs with 2.4.3) and 
patched it with the patchfiles from sgi. The only thing you should correct 
after patching is the compiler command: CC = $(CROSS_COMPILE)gcc.
Build the commands and the kernel and have fun.

I haven't tryed to patch the SuSE kernel yet.

BTW: I'm running XFS as root filesystem on a softwareraid level 1.

Greetings
   Nils Ohlmeier

From owner-linux-xfs@oss.sgi.com Sun May  6 12:51:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46Jpkp11514
	for linux-xfs-outgoing; Sun, 6 May 2001 12:51:46 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46JpiF11509
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 12:51:45 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 14wUZ4-0001SR-00; Mon, 07 May 2001 07:51:34 +1200
Date: Mon, 7 May 2001 07:51:34 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: GCS <gcs@agentsinside.com>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
In-Reply-To: <20010506162223.A29723@sisinteli07.udg.es>
Message-ID: <Pine.LNX.4.33.0105070750090.3624-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 6 May 2001, GCS wrote:

> other files. On the other hand, XFS is lazy to allocate inodes, and only
> get more (against free clusters to store the file itself) if it is
> necessary. The only drawback as I know, that XFS never gives back these
> inode clusters. This means, if you create millions of very small files,
> and after you delete them, you see your disk storage size shrink.

If that's correct, XFS would be less than ideal for e.g. a Squid or a news
volume.



-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Sun May  6 13:42:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46Kg7V12782
	for linux-xfs-outgoing; Sun, 6 May 2001 13:42:07 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f46Kg6F12779
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 13:42:06 -0700
Message-Id: <200105062042.f46Kg6F12779@oss.sgi.com>
Received: (qmail 9934 invoked by uid 0); 6 May 2001 20:41:59 -0000
Received: from f-216-212.cvx-leipzig.ipdial.viaginterkom.de (HELO temple) (62.180.212.216)
  by mail.gmx.net (mp006-rz3) with SMTP; 6 May 2001 20:41:59 -0000
From: "Andreas Piesk" <a.piesk@gmx.net>
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Date: Sun, 06 May 2001 22:44:49 +0200
Reply-To: "Andreas Piesk" <a.piesk@gmx.net>
X-Mailer: PMMail 2000 Professional (2.20.2300) For Windows 2000 (5.0.2195;1)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: xfs <-> kaio problem
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hiho,

there seems to be a conflict between xfs and kaio.
(both from sgi :)

the offending code is in arch/i386/kernel/entry.S :

xfs want these syscalls:
#define __NR__attrctl          250
#define __NR__acl_get          251
#define __NR__acl_set          252

and kaio this one:
#define __NR_aio               251

i patched my xfs-sources because i need both xfs and kaio.
the problem is that some third party software (sybase)
depends on kaio and the kaio-syscalls.

could someone from sgi clarify this issue ?

thanks & ciao -ap

--
Andreas Piesk a.piesk@gmx.net

PGP Public Key Fingerprint: 23CB A7E2 2E53 373C  DBCD 8EFC 7777 61C1



From owner-linux-xfs@oss.sgi.com Sun May  6 15:11:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46MBRD14745
	for linux-xfs-outgoing; Sun, 6 May 2001 15:11:27 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46MBRF14742
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 15:11:27 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f46MB0W04019
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 17:11:00 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sun, 6 May 2001 17:11:00 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Tuning XFS for peak performance. (fwd)
Message-ID: <Pine.LNX.4.33.0105061710360.3947-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Could someone please give me some info regarding this post I made sometime
ago?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

---------- Forwarded message ----------
Date: Sat, 5 May 2001 12:31:04 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: linux-xfs@oss.sgi.com
Subject: Tuning XFS for peak performance.

Is there a document which has a configuration matrix of how XFS should be
setup to offer peak performance? Say, for a mail/news server format your
xfs partitions with these parameters, adjusting the journal size as needed
for x% of your drive. Or perhpaps more importantly, a drive of size X
needs a journal of x%, a drive of size XX needs a journal of x%, etc? Is
there anything which exists like this? Does anyone have any tips here? I'm
seeing less than stellar system performance. While stable, it doesn't do
me any good if I have to wait 5 mins for PINE to open when it's only
moving a few messages from inbox to other boxes. The same operation would
take 30 seconds with ReiserFS.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Sun May  6 16:20:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f46NK4F15922
	for linux-xfs-outgoing; Sun, 6 May 2001 16:20:04 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f46NK3F15918
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 16:20:03 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f46NJtA19401;
	Sun, 6 May 2001 18:19:55 -0500 (CDT)
Message-ID: <3AF5DC85.FACD3C1@sgi.com>
Date: Sun, 06 May 2001 18:21:41 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Saarinen <juha@saarinen.org>
CC: GCS <gcs@agentsinside.com>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
References: <Pine.LNX.4.33.0105070750090.3624-100000@vimfuego.saarinen.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Juha Saarinen wrote:
> 
> On Sun, 6 May 2001, GCS wrote:
> 
> > This means, if you create millions of very small files,
> > and after you delete them, you see your disk storage size shrink.
> 
> If that's correct, XFS would be less than ideal for e.g. a Squid or a news
> volume.

It is correct, but it doesn't necessarily follow that it's a poor choice
for a news server or other application that has a large number of files.

It's NOT that every created inode wastes space.  If you have some
application that, on average, uses 1 million inodes, and sometimes
spikes to 1.1 million inodes, then you might sometimes have 100,000
unused, but still allocated, inodes on the system.

In other words, the "high water mark" of allocated inodes is never
reduced.

But that's not so bad - create a fresh ext2 system, and you start off
with allocated, but 100% unused inodes right from the start.  And if you
didn't create it with _enough_ inodes, then your app will fail when it
runs out.  So you make the ext2 filesystem with, maybe, 1.5x what you
anticipate.  Which seems like a bigger waste...

So with XFS, you only waste space if you dramatically change the inode
usage downward.  If you use a filesystem for a squid cache, then delete
all those files and make one big vidcap file, then yes, you'd be wasting
space.  But that sort of scenario isn't too likely. 

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May  6 17:27:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f470ReT17234
	for linux-xfs-outgoing; Sun, 6 May 2001 17:27:40 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f470RcF17231
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 17:27:38 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA04157
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 17:26:15 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14722; Mon, 7 May 2001 10:26:14 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA65323;
	Mon, 7 May 2001 10:26:12 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105071026.ZM65164@wobbly.melbourne.sgi.com>
Date: Mon, 7 May 2001 10:26:11 -0500
In-Reply-To: Eric Sandeen <sandeen@sgi.com>
        "Re: XFS on SuSE7.1" (May  5,  2:27pm)
References: <3AF3BF07.5C0E03CB@wipro.co.in>  <3AF41C77.D1A23AA9@sgi.com> 
	<20010505200401.A16626@infa.abo.fi> 
	<3AF43774.62270B72@sgi.com>  <3AF45406.BFB1F78C@sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Eric Sandeen <sandeen@sgi.com>, Johannes Eriksson <joheriks@abo.fi>,
   linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 5,  2:27pm, Eric Sandeen wrote:
> Subject: Re: XFS on SuSE7.1
> Ah, I see now that it's probably a result of building the userspace
> packages on an older system - the man location is set during "configure"
> so if it's in /usr/man rather than /usr/share/man, that's probably a
> result of building on a non-FHS 2.0 compliant system.
> 
> Still, next spin, we can clean that up.
> 
> Thanks for pointing it out!
> 

I'm not sure there's too much we can change in our rpms,
since we want these to work on "older" systems too (ie.
systems which use /usr/man and do not have /usr/share/man
on the default man search path).

What I might do though is change the default location to
install to.  Currently, if we cannot make an educated guess
as to the correct location, we fall back to /usr/doc (this
is whats biting the Mandrake folk, I'll bet).  Instead, it
seems like guessing at /usr/share/man is the right thing to
do, with so many distros starting to follow the fhs now.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun May  6 17:44:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f470ioa17413
	for linux-xfs-outgoing; Sun, 6 May 2001 17:44:50 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f470inF17410
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 17:44:49 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA00060
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 17:55:35 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14824; Mon, 7 May 2001 10:43:30 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA65277;
	Mon, 7 May 2001 10:43:29 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105071043.ZM64602@wobbly.melbourne.sgi.com>
Date: Mon, 7 May 2001 10:43:27 -0500
In-Reply-To: Russell Cattelan <cattelan@thebarn.com>
        "Re: can't compile xfsprogs-1.2.0.src.tar.gz" (May  6,  1:30pm)
References: <3AF566A0.1020404@linuxworld.pe.kr> 
	<3AF57F8A.8DE96442@linuxworld.pe.kr> 
	<3AF5985A.ED8817E4@thebarn.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: kimjihoe <kimjihoe@linuxworld.pe.kr>
Subject: Re: can't compile xfsprogs-1.2.0.src.tar.gz
Cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 6,  1:30pm, Russell Cattelan wrote:
> Subject: Re: can't compile xfsprogs-1.2.0.src.tar.gz
> kimjihoe wrote:
> 
> This is part of the current "situation" with LVM.

no, this is actually our own (my) fault - we're missing
some include/Makefile entries for these files - I just
wasn't aware that new ones had been added since last time
I checked this.  I'll put a fix into the dev tree shortly.

> 
> > OK, it's in cvs tree.
> >
> > but, why isn't it in tarball, and source rpm?
> >

cmd/xfsprogs/include/Makefile is missing references to
these files.  The Makefiles drive the contents of the
source tar/rpm files.

thanks for the problem report.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun May  6 18:05:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4715we17876
	for linux-xfs-outgoing; Sun, 6 May 2001 18:05:58 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4715uF17873
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 18:05:57 -0700
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA910159
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 03:05:53 +0200 (CEST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA72143;
	Mon, 7 May 2001 11:04:28 +1000 (EST)
Date: Mon, 7 May 2001 11:04:27 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: "Christian, Chip" <chip.christian@storageapps.com>
Cc: "'Linux XFS (E-mail)'" <linux-xfs@oss.sgi.com>
Subject: Re: chacl usage
Message-ID: <20010507110427.E137572@boing.melbourne.sgi.com>
References: <23D04BDBA646D411BDDD00D0B774B539028C888A@SA-BWMAIL1>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <23D04BDBA646D411BDDD00D0B774B539028C888A@SA-BWMAIL1>; from chip.christian@storageapps.com on Fri, May 04, 2001 at 11:38:34AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Christian,

On Fri, May 04, 2001 at 11:38:34AM -0400, Christian, Chip wrote:
> Oh, and I specified
>       CONFIG_FS_POSIX_ACL=y
> when building the kernel.
>
> >  -----Original Message-----
> > From:       Christian, Chip
> > Sent:       Friday, May 04, 2001 11:37
> > To: Linux XFS (E-mail)
> > Subject:    chacl usage
> >
> > Am I missing something to get acls to work on XFS?  I'm on a frsh RedHat 7.1install, built a kernel from the 1.0 XFS release.  I installed the SGI
acl-1.0.1-0.  Built an XFS filesystem:
> >
> > [root@betanas1 pkgs]# chacl u::rwx,g::rwx,o::rwx foo
> > chacl: error setting access acl on "foo": Function not implemented

This is strange.
The only way I know that you'd be getting ENOSYS (Function not implemented)
for ACLs is if CONFIG_FS_POSIX_ACL is not set.
(See linux/fs/noposix_acl.c (used in linux/fs/Makefile))

Are you sure you have the right kernel running ?

--Tim

From owner-linux-xfs@oss.sgi.com Sun May  6 19:38:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f472cOT19682
	for linux-xfs-outgoing; Sun, 6 May 2001 19:38:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f472cNF19678
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:38:23 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA04360
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:38:21 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA59054
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 12:36:56 +1000 (EST)
Date: Mon, 7 May 2001 12:36:56 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105070236.MAA59054@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - EA qa test output change
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Just updating an output file for an Ext.Attr QA test.

--Tim

Date:  Sun May  6 19:35:35 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94130a
cmd/xfstests/020.out - 1.2
	- Update for new error code msg.
	  This should have gone in with the change which meant
	  that EINVAL is no longer reported for an EA op not being
	  present for a FS - op not supported error generated now.



From owner-linux-xfs@oss.sgi.com Sun May  6 19:43:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f472hp319817
	for linux-xfs-outgoing; Sun, 6 May 2001 19:43:51 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f472hpF19814
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:43:51 -0700
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA07560
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:54:37 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA70551;
	Mon, 7 May 2001 12:42:30 +1000 (EST)
Date: Mon, 7 May 2001 12:42:30 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: rdicaire@rdb.linux-help.org
Cc: linux-xfs@oss.sgi.com
Subject: Re: ACLs,XFS,Linux nfs v3
Message-ID: <20010507124230.F137572@boing.melbourne.sgi.com>
References: <Pine.LNX.4.21.0105061435280.25170-100000@rdb.linux-help.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <Pine.LNX.4.21.0105061435280.25170-100000@rdb.linux-help.org>; from rdicaire@rdb.linux-help.org on Sun, May 06, 2001 at 02:41:01PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

On Sun, May 06, 2001 at 02:41:01PM -0400, rdicaire@rdb.linux-help.org wrote:
> Is there ACL support over NFS mounted XFS filesystems?
> 
Nope.
We haven't looked into it.

> chacl -l /home/spgrp_docs/test
> chacl: error getting ACL on "/home/spgrp_docs/test": Operation not
> supported
This means that the XFS acl_get/set iop is not set for the file system
in question. We only set this for a local XFS file system.

> 
> Have I missed something or is this just not possible at present?
> 
The latter....not possible at present. Sorry.

--Tim

From owner-linux-xfs@oss.sgi.com Sun May  6 19:49:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f472n6X19927
	for linux-xfs-outgoing; Sun, 6 May 2001 19:49:06 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f472n4F19922
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:49:04 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA905827
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 04:49:01 +0200 (CEST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA12276
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 12:47:43 +1000 (EST)
Date: Mon, 7 May 2001 12:47:43 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105070247.MAA12276@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - cmds
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Sun May  6 19:46:00 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94133a
cmd/acl/configure.in - 1.3
cmd/attr/configure.in - 1.3
cmd/dmapi/configure.in - 1.5
cmd/xfsdump/configure.in - 1.4
cmd/xfsprogs/configure.in - 1.4
cmd/xfstests/configure.in - 1.5
	- in the absence of any compelling information to suggest
	  otherwise, fall back to installing man pages in /usr/share/man,
	  rather than /usr/man.

cmd/xfsprogs/include/Makefile - 1.4
cmd/xfsprogs/doc/CHANGES - 1.17
	- fixed build issues relating to local lvm headers.

cmd/xfsprogs/VERSION - 1.16
	- bump minor - 1.2.5.


From owner-linux-xfs@oss.sgi.com Sun May  6 19:59:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f472xbu20118
	for linux-xfs-outgoing; Sun, 6 May 2001 19:59:37 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f472xYF20115
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:59:34 -0700
Received: from boing.melbourne.sgi.com ([134.14.55.141]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA01401
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 19:59:29 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA53001;
	Mon, 7 May 2001 12:58:10 +1000 (EST)
Date: Mon, 7 May 2001 12:58:10 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: John M Trostel <jtrostel@mindspring.com>
Cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS ACLs, Samba 2.2, EAs and the Linux 2.4.4 kernel
Message-ID: <20010507125810.G137572@boing.melbourne.sgi.com>
References: <2.0.2-402229-264-A-OEWW@mail.mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <2.0.2-402229-264-A-OEWW@mail.mindspring.com>; from jtrostel@mindspring.com on Sun, May 06, 2001 at 03:03:04PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Federico,

On Sun, May 06, 2001 at 03:03:04PM -0500, John M Trostel wrote:
> > In line with ACLs, where can I read up on how XFS implements them? In
> > particular I'd like to find out about how default ACLs and inheritance are
> > implemented in XFS.
> 
> The XFS ACL implementation is well documented in both the XFS man pages. 
> Default ACLs & inheritance closely follow the posix 'standard', so that 
> would be a good read also.
> 
Sections 5.3.1.2, B.23.4 and B.23.5 would be relevant ones
to read about default ACLs.

The 1.0 release, however, applies default ACLs which are
affected by the umask. This has been fixed in the CVS tree
so that default ACLs are used in preference to the umask.
(the fix didn't make it in time to 1.0).

> > Please be patient, and if this has been answered before or has an answer
> > somewhere on the XFS website, please help me out with some URLs.
> 
> A link to the posix 'standards' can be found through links at Andrea's 
> bestbits site. I am writing this on my PDA & so do not have immeadiate 
> access to get the exact URLs for you. Poking around the bestbits site 
> should reveal the link though.

http://wt.xpilot.org/posix.1e/download.html

--Tim

From owner-linux-xfs@oss.sgi.com Sun May  6 22:47:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f475l3c23221
	for linux-xfs-outgoing; Sun, 6 May 2001 22:47:03 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f475l2F23218
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 22:47:02 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA23541
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 22:45:39 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16667; Mon, 7 May 2001 15:45:42 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA65845;
	Mon, 7 May 2001 15:45:41 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105071545.ZM65936@wobbly.melbourne.sgi.com>
Date: Mon, 7 May 2001 15:45:40 -0500
In-Reply-To: Jarek Luberek <jarek@swipnet.se>
        "Re: Incredibly slow rebuild of small access_db on xfs partition" (May  6,  7:12pm)
References: <01050515570100.01078@marvin>  <01050610421500.00890@marvin> 
	<3AF5693F.A41ACA22@sgi.com>  <01050619121500.00664@marvin>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Jarek Luberek <jarek@swipnet.se>, Eric Sandeen <sandeen@sgi.com>,
   linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 6,  7:12pm, Jarek Luberek wrote:
> Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
> On Sunday 06 May 2001 17:09, you wrote:
> > Hi Jarek - I'll look at this tomorrow.
> >
> > But in the meantime, can you try something?  Try mounting your xfs root
> > (or whatever contains /etc) with "-o biosize=13"
> >
> > This solved the problem with someone who was having similar problems
> > when rebuilding an rpm database, I think it may be related (along with
> > the explanation Russell sent).
> If 
>          mount / -o remount,biosize=13 counts
> 
> then I have tried that. Results are as before (/etc is a subdirectory of / ).
> 

no, that wont do it.  you'll need to umount, then mount with
new biosize option for it to have any effect at all.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sun May  6 22:58:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f475ww323341
	for linux-xfs-outgoing; Sun, 6 May 2001 22:58:58 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f475wrF23338
	for <linux-xfs@oss.sgi.com>; Sun, 6 May 2001 22:58:53 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA26803
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 07:58:50 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id HAA12095
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 07:58:49 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP id 9503F57306
	for <linux-xfs@oss.sgi.com>; Mon,  7 May 2001 08:07:07 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP id 3231025835
	for <linux-xfs@oss.sgi.com>; Mon,  7 May 2001 08:08:21 +0200 (CEST)
Message-ID: <3AF63A3B.2C296D1A@ch.sauter-bc.com>
Date: Mon, 07 May 2001 08:01:31 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: XFS RedHat installer
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

First of all I want to say that XFS is sooooooooo cool :-)
This is what I was really waiting for and I'm very happy
to see SGI doing it. SGI is great.

I found two problems with the XFS RedHat installer:

1) Boot floppy:
When doing a mkbootdisk 2.4.2-xxxxx I saw that the content couldn't
fit on the disk. Then I tried the following:
fdformat /dev/fd0u1722
mkbootdisk --device /dev/fd0u1722 2.4.2-xxxxx
The disk was created successfully but unfortunately it didn't boot
anyway. I guess it is a problem with the used 'syslinux'. Did
you try something like this ?

2) Software RAID does not work. At least when used for boot/root
volumes. After investigating the problem I found your note about
devfs beeing enabled and after using devfs=nomount as kernel parameter
it worked perfectly. Now my question is: Why did you enable devfs
and what problems my I run in when using devfs=nomount???

Greetings
Simon

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Mon May  7 00:36:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f477apA25040
	for linux-xfs-outgoing; Mon, 7 May 2001 00:36:51 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f477anF25036
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 00:36:50 -0700
Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14wfZY-0006qt-00
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 09:36:48 +0200
Received: from p3ee0d5ef.dip.t-dialin.net ([62.224.213.239] helo=educators.de)
	by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14wfZT-00085r-00
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 09:36:43 +0200
Message-ID: <3AF65085.31E3B94B@educators.de>
Date: Mon, 07 May 2001 09:36:37 +0200
From: Felix Ide <ide@educators.de>
X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Problem with 2.4.3, xfs, knfsd: "getfh failed: Operation not permitted"
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everybody,

first thanks to everyone involved in this project, xfs is great for
(mostly) all our needs...!

Except for a NFS problem:
We're useing SuSE 7.1, plain 2.4.3 kernel, patches 1.0 from sgi's
website, nfsutils updated to 0.3.1.
When I start the nfsserver I get the following messages:
...
woodstock.educators.de:/nfs: Invalid argument
...
where /nfs is a xfs filesystem. knfsd works fine with ext2 in parallel.

When I then try to mount this fs, I get the following messages in my
logfile:
...
rpc.mountd: authenticated mount request from 192.168.10.103:677 for /nfs
rpc.mountd: getfh failed: Operation not permitted 
...

I didnt't find anything helpful in the mailing list archive, so please
excuse me if this is a well-knows problem.

Thanks for your help,
Felix

BTW: I built SuSE-7.1 RPMs, anyone interested? Perhaps you(sgi) could
put then in your download section.

From owner-linux-xfs@oss.sgi.com Mon May  7 01:09:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4789Hm25547
	for linux-xfs-outgoing; Mon, 7 May 2001 01:09:17 -0700
Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4789GF25544
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 01:09:16 -0700
Received: from cs.ucr.edu (CBL-richy33.hs.earthlink.net [207.217.170.84])
	by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id BAA18986
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 01:09:17 -0700 (PDT)
Message-ID: <3AF65819.34D450A1@cs.ucr.edu>
Date: Mon, 07 May 2001 01:08:57 -0700
From: Daniel Tabuenca <dtabuenc@cs.ucr.edu>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Problem with 2.4.3, xfs, knfsd: "getfh failed: Operation not 
 permitted"
References: <3AF65085.31E3B94B@educators.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't think this is an xfs problem . I get this problem ocassionally
and it is usually solved by killing and restarting rpc.mountd, or doing
an exportfs -r

> woodstock.educators.de:/nfs: Invalid argument
> ...
> where /nfs is a xfs filesystem. knfsd works fine with ext2 in parallel.
> 
> When I then try to mount this fs, I get the following messages in my
> logfile:
> ...
> rpc.mountd: authenticated mount request from 192.168.10.103:677 for /nfs
> rpc.mountd: getfh failed: Operation not permitted
> ...

From owner-linux-xfs@oss.sgi.com Mon May  7 01:34:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f478Yh926056
	for linux-xfs-outgoing; Mon, 7 May 2001 01:34:43 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f478YfF26053
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 01:34:41 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 14wgTS-0002GR-00; Mon, 07 May 2001 20:34:34 +1200
Date: Mon, 7 May 2001 20:34:34 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Eric Sandeen <sandeen@sgi.com>
cc: GCS <gcs@agentsinside.com>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
In-Reply-To: <3AF5DC85.FACD3C1@sgi.com>
Message-ID: <Pine.LNX.4.33.0105072033570.3624-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 6 May 2001, Eric Sandeen wrote:

> It's NOT that every created inode wastes space.  If you have some
> application that, on average, uses 1 million inodes, and sometimes
> spikes to 1.1 million inodes, then you might sometimes have 100,000
> unused, but still allocated, inodes on the system.
>
> In other words, the "high water mark" of allocated inodes is never
> reduced.
>
> But that's not so bad - create a fresh ext2 system, and you start off
> with allocated, but 100% unused inodes right from the start.  And if you
> didn't create it with _enough_ inodes, then your app will fail when it
> runs out.  So you make the ext2 filesystem with, maybe, 1.5x what you
> anticipate.  Which seems like a bigger waste...
>
> So with XFS, you only waste space if you dramatically change the inode
> usage downward.  If you use a filesystem for a squid cache, then delete
> all those files and make one big vidcap file, then yes, you'd be wasting
> space.  But that sort of scenario isn't too likely.

Just out of curiosity, how does NTFS handle such a scenario?


-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Mon May  7 05:00:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47C0C131896
	for linux-xfs-outgoing; Mon, 7 May 2001 05:00:12 -0700
Received: from dnb.no (mail3.dnb.no [193.212.168.26])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47C08F31893
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 05:00:09 -0700
Received: from abrap401.dnb.no (unverified) by dnb.no
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T535ff21708c1d4a81ab18@dnb.no> for <linux-xfs@oss.sgi.com>;
 Mon, 7 May 2001 13:59:46 +0200
Received: by abrap401.dnb.no with Internet Mail Service (5.5.2653.19)
	id <FB3HDPS7>; Mon, 7 May 2001 13:59:56 +0200
Message-ID: <3A28D7599E96D21190570001FA323F2601F9E5AB@k11ap005.dnb.no>
From: "Schaller, Christian" <christian.schaller@dnb.no>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: SGI/RedHat 7.1 with XFS installer
Date: Mon, 7 May 2001 13:59:55 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,
I have installed your version of RH7.1 and the system now works pretty good
for me. Thanks for the great work. 
Anyway there is what I deem to be a small bug in the setup and it is related
to devfs and IDE cdrom players.

On both my own and a friends computer the installation failed (both cases
being fresh installs, not upgrades)  in setting up the cdrom player which I
think was caused by /dev/cdrom already existing. When I deleted /dev/cdrom
and rebooted devfs managed to create /dev/cdroms/cdrom0 and make a symlink
to /dev/cdrom and things started to work well.

You might also want to consider removing some packages like the Red Hat
sound configuration tool since it doesn't work with devfs and only confuses
people since it seems to work ok, but then gets reset at reboot. I had never
used devfs before this so it took me some time and reading before I figured
out what was happening.

Sincerely,
Christian 




* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the virus programs used
in the DnB Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

From owner-linux-xfs@oss.sgi.com Mon May  7 06:37:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47DbPc05262
	for linux-xfs-outgoing; Mon, 7 May 2001 06:37:25 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47DbOF05254
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 06:37:24 -0700
Received: (qmail 9298 invoked by uid 0); 7 May 2001 13:37:17 -0000
Received: from adsl-3-83.adsl.easynet.fr (HELO mail.gmx.de) (212.11.27.83)
  by mail.gmx.net (mail04) with SMTP; 7 May 2001 13:37:17 -0000
Message-ID: <200105071537080970.00A6D1A0@mail.gmx.de>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Mon, 07 May 2001 15:37:08 +0200
From: "linux" <dahouet@gmx.net>
To: linux-xfs@oss.sgi.com
Subject: Linux 2.4.4 + xfs
Mime-Version: 1.0
Content-Type: text/plain; charset="WINDOWS-1250"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f47DbPF05260
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,


i had a kernel 2.4.3 and i tried to compile it with xfs support in kernel
and it failed ! i had gcc 2.95 , i installed kgcc with egcs 1.1.2
and failed again. i didn't want to downgrade my kernel
so i downloaded kernel 2.4.4.
i applied the linux-2.4.4-xfs-TEST.patch (the  linux-2.4.4-xfs-cvs-05022001.patch.gz
didn't work for me).
and i managed to compile it with gcc 2.95 !
so i have now a little partition with xfs : good

but 

1.how stable is xfs with kernel 2.4.4 ?
2.is it sue to make the root filesystem xfs ?

thanks
@++
nico


From owner-linux-xfs@oss.sgi.com Mon May  7 07:57:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Evjq11113
	for linux-xfs-outgoing; Mon, 7 May 2001 07:57:45 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47EvhF11108
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 07:57:44 -0700
Received: from [195.20.224.209] (helo=mrvdom02.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14wmSE-0005qg-00
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 16:57:42 +0200
Received: from pc19eb790.dip.t-dialin.net ([193.158.183.144] helo=educators.de)
	by mrvdom02.schlund.de with esmtp (Exim 2.12 #2)
	id 14wmR0-0007en-00
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 16:56:26 +0200
Message-ID: <3AF6B793.80C02401@educators.de>
Date: Mon, 07 May 2001 16:56:19 +0200
From: Felix Ide <ide@educators.de>
X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Problem with 2.4.3, xfs, knfsd: "getfh failed: Operation not 
 permitted"
References: <3AF65085.31E3B94B@educators.de> <3AF65819.34D450A1@cs.ucr.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Daniel Tabuenca wrote:
> 
> I don't think this is an xfs problem . I get this problem ocassionally
> and it is usually solved by killing and restarting rpc.mountd, or doing
> an exportfs -r
> 
> > woodstock.educators.de:/nfs: Invalid argument
> > ...
> > where /nfs is a xfs filesystem. knfsd works fine with ext2 in parallel.
> >
> > When I then try to mount this fs, I get the following messages in my
> > logfile:
> > ...
> > rpc.mountd: authenticated mount request from 192.168.10.103:677 for /nfs
> > rpc.mountd: getfh failed: Operation not permitted
> > ...

I'm quite sure that it is an xfs problem, because I tried it on
different mountpoints with different partitions and the "Invalid
argument" messages in combination with "getfh failed" do only show up on
xfs, ext2 works well.

Thanks,
Felix

From owner-linux-xfs@oss.sgi.com Mon May  7 08:16:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47FGTn11922
	for linux-xfs-outgoing; Mon, 7 May 2001 08:16:29 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47FGOF11914
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 08:16:24 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <JCFDDL63>; Mon, 7 May 2001 11:16:04 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C88A3@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "'Timothy Shimmin'" <tes@boing.melbourne.sgi.com>
Cc: "'Linux XFS (E-mail)'" <linux-xfs@oss.sgi.com>
Subject: RE: chacl usage
Date: Mon, 7 May 2001 11:16:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0D708.A1DF2580"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0D708.A1DF2580
Content-Type: text/plain

Tim,

Call me Chip...

For sure I'm running the proper kernel.  I just built it once more so I could tell you I built it this morning ;-)

noposix_acl.o isn't created, but posix_acl.o is, as another point of verification.

Attached is my .config.  /boot/vmlinuz is the only kernel listed in lilo.conf.  I do this:
	make mrproper
	cp ~/config .config
	make menuconfig (verify settings...)
	make dep
	make bzImage
	make modules
	make modules_install	
	cp arch/i386/boot/bzImage /boot/vmlinuz
	lilo
	init 6


-----Original Message-----
From: Timothy Shimmin [mailto:tes@boing.melbourne.sgi.com]
Sent: Sunday, May 06, 2001 21:04
To: Christian, Chip
Cc: 'Linux XFS (E-mail)'
Subject: Re: chacl usage


Hi Christian,

On Fri, May 04, 2001 at 11:38:34AM -0400, Christian, Chip wrote:
> Oh, and I specified
>       CONFIG_FS_POSIX_ACL=y
> when building the kernel.
>
> >  -----Original Message-----
> > From:       Christian, Chip
> > Sent:       Friday, May 04, 2001 11:37
> > To: Linux XFS (E-mail)
> > Subject:    chacl usage
> >
> > Am I missing something to get acls to work on XFS?  I'm on a frsh RedHat 7.1install, built a kernel from the 1.0 XFS release.  I installed the SGI
acl-1.0.1-0.  Built an XFS filesystem:
> >
> > [root@betanas1 pkgs]# chacl u::rwx,g::rwx,o::rwx foo
> > chacl: error setting access acl on "foo": Function not implemented

This is strange.
The only way I know that you'd be getting ENOSYS (Function not implemented)
for ACLs is if CONFIG_FS_POSIX_ACL is not set.
(See linux/fs/noposix_acl.c (used in linux/fs/Makefile))

Are you sure you have the right kernel running ?

--Tim


------_=_NextPart_000_01C0D708.A1DF2580
Content-Type: application/octet-stream;
	name=".config"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename=".config"

#=0A=
# Automatically generated by make menuconfig: don't edit=0A=
#=0A=
CONFIG_X86=3Dy=0A=
CONFIG_ISA=3Dy=0A=
# CONFIG_SBUS is not set=0A=
CONFIG_UID16=3Dy=0A=
=0A=
#=0A=
# Code maturity level options=0A=
#=0A=
CONFIG_EXPERIMENTAL=3Dy=0A=
=0A=
#=0A=
# Loadable module support=0A=
#=0A=
CONFIG_MODULES=3Dy=0A=
CONFIG_MODVERSIONS=3Dy=0A=
CONFIG_KMOD=3Dy=0A=
=0A=
#=0A=
# Processor type and features=0A=
#=0A=
# CONFIG_M386 is not set=0A=
# CONFIG_M486 is not set=0A=
# CONFIG_M586 is not set=0A=
# CONFIG_M586TSC is not set=0A=
# CONFIG_M586MMX is not set=0A=
# CONFIG_M686 is not set=0A=
CONFIG_MPENTIUMIII=3Dy=0A=
# CONFIG_MPENTIUM4 is not set=0A=
# CONFIG_MK6 is not set=0A=
# CONFIG_MK7 is not set=0A=
# CONFIG_MCRUSOE is not set=0A=
# CONFIG_MWINCHIPC6 is not set=0A=
# CONFIG_MWINCHIP2 is not set=0A=
# CONFIG_MWINCHIP3D is not set=0A=
CONFIG_X86_WP_WORKS_OK=3Dy=0A=
CONFIG_X86_INVLPG=3Dy=0A=
CONFIG_X86_CMPXCHG=3Dy=0A=
CONFIG_X86_BSWAP=3Dy=0A=
CONFIG_X86_POPAD_OK=3Dy=0A=
CONFIG_X86_L1_CACHE_SHIFT=3D5=0A=
CONFIG_X86_TSC=3Dy=0A=
CONFIG_X86_GOOD_APIC=3Dy=0A=
CONFIG_X86_PGE=3Dy=0A=
CONFIG_X86_USE_PPRO_CHECKSUM=3Dy=0A=
# CONFIG_TOSHIBA is not set=0A=
# CONFIG_MICROCODE is not set=0A=
# CONFIG_X86_MSR is not set=0A=
# CONFIG_X86_CPUID is not set=0A=
# CONFIG_E820_PROC is not set=0A=
CONFIG_NOHIGHMEM=3Dy=0A=
# CONFIG_HIGHMEM4G is not set=0A=
# CONFIG_HIGHMEM64G is not set=0A=
# CONFIG_1GB is not set=0A=
CONFIG_2GB=3Dy=0A=
# CONFIG_3GB is not set=0A=
# CONFIG_MATH_EMULATION is not set=0A=
# CONFIG_MTRR is not set=0A=
CONFIG_SMP=3Dy=0A=
CONFIG_HAVE_DEC_LOCK=3Dy=0A=
=0A=
#=0A=
# General setup=0A=
#=0A=
CONFIG_NET=3Dy=0A=
# CONFIG_VISWS is not set=0A=
CONFIG_X86_IO_APIC=3Dy=0A=
CONFIG_X86_LOCAL_APIC=3Dy=0A=
CONFIG_PCI=3Dy=0A=
# CONFIG_PCI_GOBIOS is not set=0A=
# CONFIG_PCI_GODIRECT is not set=0A=
CONFIG_PCI_GOANY=3Dy=0A=
CONFIG_PCI_BIOS=3Dy=0A=
CONFIG_PCI_DIRECT=3Dy=0A=
CONFIG_PCI_NAMES=3Dy=0A=
# CONFIG_EISA is not set=0A=
# CONFIG_MCA is not set=0A=
CONFIG_HOTPLUG=3Dy=0A=
=0A=
#=0A=
# PCMCIA/CardBus support=0A=
#=0A=
CONFIG_PCMCIA=3Dy=0A=
CONFIG_CARDBUS=3Dy=0A=
# CONFIG_I82365 is not set=0A=
# CONFIG_TCIC is not set=0A=
CONFIG_SYSVIPC=3Dy=0A=
# CONFIG_BSD_PROCESS_ACCT is not set=0A=
CONFIG_SYSCTL=3Dy=0A=
CONFIG_KCORE_ELF=3Dy=0A=
# CONFIG_KCORE_AOUT is not set=0A=
# CONFIG_BINFMT_AOUT is not set=0A=
CONFIG_BINFMT_ELF=3Dy=0A=
# CONFIG_BINFMT_MISC is not set=0A=
# CONFIG_PM is not set=0A=
# CONFIG_ACPI is not set=0A=
# CONFIG_APM is not set=0A=
=0A=
#=0A=
# Memory Technology Devices (MTD)=0A=
#=0A=
# CONFIG_MTD is not set=0A=
=0A=
#=0A=
# Parallel port support=0A=
#=0A=
# CONFIG_PARPORT is not set=0A=
=0A=
#=0A=
# Plug and Play configuration=0A=
#=0A=
CONFIG_PNP=3Dy=0A=
CONFIG_ISAPNP=3Dy=0A=
=0A=
#=0A=
# Block devices=0A=
#=0A=
CONFIG_BLK_DEV_FD=3Dy=0A=
# CONFIG_BLK_DEV_XD is not set=0A=
# CONFIG_PARIDE is not set=0A=
# CONFIG_BLK_CPQ_DA is not set=0A=
# CONFIG_BLK_CPQ_CISS_DA is not set=0A=
# CONFIG_BLK_DEV_DAC960 is not set=0A=
# CONFIG_BLK_DEV_LOOP is not set=0A=
# CONFIG_BLK_DEV_NBD is not set=0A=
# CONFIG_BLK_DEV_RAM is not set=0A=
# CONFIG_BLK_DEV_INITRD is not set=0A=
=0A=
#=0A=
# Multi-device support (RAID and LVM)=0A=
#=0A=
CONFIG_MD=3Dy=0A=
CONFIG_BLK_DEV_MD=3Dy=0A=
# CONFIG_MD_LINEAR is not set=0A=
# CONFIG_MD_RAID0 is not set=0A=
# CONFIG_MD_RAID1 is not set=0A=
# CONFIG_MD_RAID5 is not set=0A=
CONFIG_MD_MULTIPATH=3Dy=0A=
# CONFIG_BLK_DEV_LVM is not set=0A=
=0A=
#=0A=
# Networking options=0A=
#=0A=
CONFIG_PACKET=3Dy=0A=
# CONFIG_PACKET_MMAP is not set=0A=
# CONFIG_NETLINK is not set=0A=
# CONFIG_NETFILTER is not set=0A=
# CONFIG_FILTER is not set=0A=
CONFIG_UNIX=3Dy=0A=
CONFIG_INET=3Dy=0A=
# CONFIG_TUX is not set=0A=
CONFIG_IP_MULTICAST=3Dy=0A=
# CONFIG_IP_ADVANCED_ROUTER is not set=0A=
# CONFIG_IP_PNP is not set=0A=
# CONFIG_NET_IPIP is not set=0A=
# CONFIG_NET_IPGRE is not set=0A=
# CONFIG_IP_MROUTE is not set=0A=
# CONFIG_INET_ECN is not set=0A=
# CONFIG_SYN_COOKIES is not set=0A=
# CONFIG_IPV6 is not set=0A=
# CONFIG_KHTTPD is not set=0A=
# CONFIG_ATM is not set=0A=
# CONFIG_IPX is not set=0A=
# CONFIG_ATALK is not set=0A=
# CONFIG_DECNET is not set=0A=
# CONFIG_BRIDGE is not set=0A=
# CONFIG_X25 is not set=0A=
# CONFIG_LAPB is not set=0A=
# CONFIG_LLC is not set=0A=
# CONFIG_NET_DIVERT is not set=0A=
# CONFIG_ECONET is not set=0A=
# CONFIG_WAN_ROUTER is not set=0A=
# CONFIG_NET_FASTROUTE is not set=0A=
# CONFIG_NET_HW_FLOWCONTROL is not set=0A=
=0A=
#=0A=
# QoS and/or fair queueing=0A=
#=0A=
# CONFIG_NET_SCHED is not set=0A=
=0A=
#=0A=
# Telephony Support=0A=
#=0A=
# CONFIG_PHONE is not set=0A=
# CONFIG_PHONE_IXJ is not set=0A=
=0A=
#=0A=
# ATA/IDE/MFM/RLL support=0A=
#=0A=
CONFIG_IDE=3Dy=0A=
=0A=
#=0A=
# IDE, ATA and ATAPI Block devices=0A=
#=0A=
CONFIG_BLK_DEV_IDE=3Dy=0A=
# CONFIG_BLK_DEV_HD_IDE is not set=0A=
# CONFIG_BLK_DEV_HD is not set=0A=
CONFIG_BLK_DEV_IDEDISK=3Dy=0A=
# CONFIG_IDEDISK_MULTI_MODE is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_IBM is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set=0A=
# CONFIG_BLK_DEV_IDEDISK_WD is not set=0A=
# CONFIG_BLK_DEV_COMMERIAL is not set=0A=
# CONFIG_BLK_DEV_TIVO is not set=0A=
# CONFIG_BLK_DEV_IDECS is not set=0A=
CONFIG_BLK_DEV_IDECD=3Dy=0A=
# CONFIG_BLK_DEV_IDETAPE is not set=0A=
# CONFIG_BLK_DEV_IDEFLOPPY is not set=0A=
# CONFIG_BLK_DEV_IDESCSI is not set=0A=
CONFIG_BLK_DEV_CMD640=3Dy=0A=
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set=0A=
# CONFIG_BLK_DEV_ISAPNP is not set=0A=
CONFIG_BLK_DEV_RZ1000=3Dy=0A=
CONFIG_BLK_DEV_IDEPCI=3Dy=0A=
CONFIG_IDEPCI_SHARE_IRQ=3Dy=0A=
# CONFIG_BLK_DEV_IDEDMA_PCI is not set=0A=
# CONFIG_BLK_DEV_OFFBOARD is not set=0A=
# CONFIG_IDEDMA_PCI_AUTO is not set=0A=
# CONFIG_BLK_DEV_IDEDMA is not set=0A=
# CONFIG_IDEDMA_PCI_WIP is not set=0A=
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set=0A=
# CONFIG_BLK_DEV_AEC62XX is not set=0A=
# CONFIG_AEC62XX_TUNING is not set=0A=
# CONFIG_BLK_DEV_ALI15X3 is not set=0A=
# CONFIG_WDC_ALI15X3 is not set=0A=
# CONFIG_BLK_DEV_AMD7409 is not set=0A=
# CONFIG_AMD7409_OVERRIDE is not set=0A=
# CONFIG_BLK_DEV_CMD64X is not set=0A=
# CONFIG_BLK_DEV_CY82C693 is not set=0A=
# CONFIG_BLK_DEV_CS5530 is not set=0A=
# CONFIG_BLK_DEV_HPT34X is not set=0A=
# CONFIG_HPT34X_AUTODMA is not set=0A=
# CONFIG_BLK_DEV_HPT366 is not set=0A=
# CONFIG_BLK_DEV_PIIX is not set=0A=
# CONFIG_PIIX_TUNING is not set=0A=
# CONFIG_BLK_DEV_NS87415 is not set=0A=
# CONFIG_BLK_DEV_OPTI621 is not set=0A=
# CONFIG_BLK_DEV_PDC202XX is not set=0A=
# CONFIG_PDC202XX_BURST is not set=0A=
# CONFIG_BLK_DEV_OSB4 is not set=0A=
# CONFIG_BLK_DEV_SIS5513 is not set=0A=
# CONFIG_BLK_DEV_SLC90E66 is not set=0A=
# CONFIG_BLK_DEV_TRM290 is not set=0A=
# CONFIG_BLK_DEV_VIA82CXXX is not set=0A=
# CONFIG_IDE_CHIPSETS is not set=0A=
# CONFIG_IDEDMA_AUTO is not set=0A=
# CONFIG_DMA_NONPCI is not set=0A=
CONFIG_BLK_DEV_IDE_MODES=3Dy=0A=
=0A=
#=0A=
# SCSI support=0A=
#=0A=
CONFIG_SCSI=3Dy=0A=
CONFIG_BLK_DEV_SD=3Dy=0A=
CONFIG_SD_EXTRA_DEVS=3D128=0A=
# CONFIG_CHR_DEV_ST is not set=0A=
# CONFIG_CHR_DEV_OSST is not set=0A=
# CONFIG_BLK_DEV_SR is not set=0A=
CONFIG_CHR_DEV_SG=3Dy=0A=
CONFIG_SCSI_DEBUG_QUEUES=3Dy=0A=
CONFIG_SCSI_MULTI_LUN=3Dy=0A=
CONFIG_SCSI_CONSTANTS=3Dy=0A=
# CONFIG_SCSI_LOGGING is not set=0A=
=0A=
#=0A=
# SCSI low-level drivers=0A=
#=0A=
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set=0A=
# CONFIG_SCSI_7000FASST is not set=0A=
# CONFIG_SCSI_ACARD is not set=0A=
# CONFIG_SCSI_AHA152X is not set=0A=
# CONFIG_SCSI_AHA1542 is not set=0A=
# CONFIG_SCSI_AHA1740 is not set=0A=
CONFIG_SCSI_AACRAID=3Dy=0A=
# CONFIG_SCSI_AIC7XXX is not set=0A=
# CONFIG_SCSI_AIC7XXX_OLD is not set=0A=
# CONFIG_SCSI_ADVANSYS is not set=0A=
# CONFIG_SCSI_IN2000 is not set=0A=
# CONFIG_SCSI_AM53C974 is not set=0A=
CONFIG_SCSI_MEGARAID=3Dy=0A=
# CONFIG_SCSI_BUSLOGIC is not set=0A=
# CONFIG_SCSI_CPQFCTS is not set=0A=
# CONFIG_SCSI_DMX3191D is not set=0A=
# CONFIG_SCSI_DTC3280 is not set=0A=
# CONFIG_SCSI_EATA is not set=0A=
# CONFIG_SCSI_EATA_DMA is not set=0A=
# CONFIG_SCSI_EATA_PIO is not set=0A=
# CONFIG_SCSI_FUTURE_DOMAIN is not set=0A=
# CONFIG_SCSI_GDTH is not set=0A=
# CONFIG_SCSI_GENERIC_NCR5380 is not set=0A=
# CONFIG_SCSI_IPS is not set=0A=
# CONFIG_SCSI_INITIO is not set=0A=
# CONFIG_SCSI_INIA100 is not set=0A=
# CONFIG_SCSI_NCR53C406A is not set=0A=
# CONFIG_SCSI_NCR53C7xx is not set=0A=
# CONFIG_SCSI_NCR53C8XX is not set=0A=
CONFIG_SCSI_SYM53C8XX=3Dy=0A=
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D4=0A=
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32=0A=
CONFIG_SCSI_NCR53C8XX_SYNC=3D20=0A=
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set=0A=
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set=0A=
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set=0A=
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set=0A=
# CONFIG_SCSI_PAS16 is not set=0A=
# CONFIG_SCSI_PCI2000 is not set=0A=
# CONFIG_SCSI_PCI2220I is not set=0A=
# CONFIG_SCSI_PSI240I is not set=0A=
# CONFIG_SCSI_QLOGIC_FAS is not set=0A=
# CONFIG_SCSI_QLOGIC_ISP is not set=0A=
# CONFIG_SCSI_QLOGIC_FC is not set=0A=
# CONFIG_SCSI_QLOGIC_1280 is not set=0A=
CONFIG_SCSI_QLOGIC_QLA2100=3Dm=0A=
# CONFIG_SCSI_SEAGATE is not set=0A=
# CONFIG_SCSI_SIM710 is not set=0A=
# CONFIG_SCSI_SYM53C416 is not set=0A=
# CONFIG_SCSI_DC390T is not set=0A=
# CONFIG_SCSI_T128 is not set=0A=
# CONFIG_SCSI_U14_34F is not set=0A=
# CONFIG_SCSI_ULTRASTOR is not set=0A=
# CONFIG_SCSI_DEBUG is not set=0A=
=0A=
#=0A=
# PCMCIA SCSI adapter support=0A=
#=0A=
# CONFIG_SCSI_PCMCIA is not set=0A=
=0A=
#=0A=
# Fusion MPT device support=0A=
#=0A=
# CONFIG_FUSION is not set=0A=
# CONFIG_FUSION_BOOT is not set=0A=
# CONFIG_FUSION_ISENSE is not set=0A=
# CONFIG_FUSION_CTL is not set=0A=
# CONFIG_FUSION_LAN is not set=0A=
=0A=
#=0A=
# IEEE 1394 (FireWire) support=0A=
#=0A=
# CONFIG_IEEE1394 is not set=0A=
=0A=
#=0A=
# I2O device support=0A=
#=0A=
# CONFIG_I2O is not set=0A=
# CONFIG_I2O_PCI is not set=0A=
# CONFIG_I2O_BLOCK is not set=0A=
# CONFIG_I2O_LAN is not set=0A=
# CONFIG_I2O_SCSI is not set=0A=
# CONFIG_I2O_PROC is not set=0A=
=0A=
#=0A=
# Network device support=0A=
#=0A=
CONFIG_NETDEVICES=3Dy=0A=
=0A=
#=0A=
# ARCnet devices=0A=
#=0A=
# CONFIG_ARCNET is not set=0A=
CONFIG_DUMMY=3Dm=0A=
# CONFIG_BONDING is not set=0A=
# CONFIG_EQUALIZER is not set=0A=
# CONFIG_TUN is not set=0A=
# CONFIG_NET_SB1000 is not set=0A=
=0A=
#=0A=
# Ethernet (10 or 100Mbit)=0A=
#=0A=
CONFIG_NET_ETHERNET=3Dy=0A=
# CONFIG_NET_VENDOR_3COM is not set=0A=
# CONFIG_LANCE is not set=0A=
# CONFIG_NET_VENDOR_SMC is not set=0A=
# CONFIG_NET_VENDOR_RACAL is not set=0A=
# CONFIG_AT1700 is not set=0A=
# CONFIG_DEPCA is not set=0A=
# CONFIG_HP100 is not set=0A=
# CONFIG_NET_ISA is not set=0A=
CONFIG_NET_PCI=3Dy=0A=
# CONFIG_PCNET32 is not set=0A=
# CONFIG_ADAPTEC_STARFIRE is not set=0A=
# CONFIG_AC3200 is not set=0A=
# CONFIG_APRICOT is not set=0A=
# CONFIG_CS89x0 is not set=0A=
# CONFIG_TULIP is not set=0A=
# CONFIG_DE4X5 is not set=0A=
# CONFIG_DGRS is not set=0A=
# CONFIG_DM9102 is not set=0A=
CONFIG_EEPRO100=3Dm=0A=
# CONFIG_EEPRO100_PM is not set=0A=
# CONFIG_LNE390 is not set=0A=
# CONFIG_E100 is not set=0A=
# CONFIG_NATSEMI is not set=0A=
# CONFIG_NE2K_PCI is not set=0A=
# CONFIG_NE3210 is not set=0A=
# CONFIG_ES3210 is not set=0A=
# CONFIG_8139TOO is not set=0A=
# CONFIG_SIS900 is not set=0A=
# CONFIG_EPIC100 is not set=0A=
# CONFIG_SUNDANCE is not set=0A=
# CONFIG_TLAN is not set=0A=
# CONFIG_VIA_RHINE is not set=0A=
# CONFIG_WINBOND_840 is not set=0A=
# CONFIG_HAPPYMEAL is not set=0A=
# CONFIG_NET_POCKET is not set=0A=
=0A=
#=0A=
# Ethernet (1000 Mbit)=0A=
#=0A=
CONFIG_E1000=3Dm=0A=
# CONFIG_ACENIC is not set=0A=
# CONFIG_NET_BROADCOM is not set=0A=
# CONFIG_HAMACHI is not set=0A=
# CONFIG_YELLOWFIN is not set=0A=
# CONFIG_SK98LIN is not set=0A=
# CONFIG_FDDI is not set=0A=
# CONFIG_HIPPI is not set=0A=
# CONFIG_PPP is not set=0A=
# CONFIG_SLIP is not set=0A=
=0A=
#=0A=
# Wireless LAN (non-hamradio)=0A=
#=0A=
# CONFIG_CIPE is not set=0A=
# CONFIG_NET_RADIO is not set=0A=
=0A=
#=0A=
# Token Ring devices=0A=
#=0A=
# CONFIG_TR is not set=0A=
# CONFIG_NET_FC is not set=0A=
# CONFIG_RCPCI is not set=0A=
# CONFIG_SHAPER is not set=0A=
=0A=
#=0A=
# Wan interfaces=0A=
#=0A=
# CONFIG_WAN is not set=0A=
=0A=
#=0A=
# PCMCIA network device support=0A=
#=0A=
CONFIG_NET_PCMCIA=3Dy=0A=
# CONFIG_PCMCIA_3C589 is not set=0A=
# CONFIG_PCMCIA_3C574 is not set=0A=
# CONFIG_PCMCIA_FMVJ18X is not set=0A=
CONFIG_PCMCIA_PCNET=3Dy=0A=
# CONFIG_PCMCIA_NMCLAN is not set=0A=
# CONFIG_PCMCIA_SMC91C92 is not set=0A=
# CONFIG_PCMCIA_XIRC2PS is not set=0A=
# CONFIG_ARCNET_COM20020_CS is not set=0A=
# CONFIG_PCMCIA_IBMTR is not set=0A=
# CONFIG_PCMCIA_XIRCOM is not set=0A=
# CONFIG_PCMCIA_XIRTULIP is not set=0A=
CONFIG_NET_PCMCIA_RADIO=3Dy=0A=
CONFIG_PCMCIA_RAYCS=3Dy=0A=
# CONFIG_PCMCIA_NETWAVE is not set=0A=
# CONFIG_PCMCIA_WAVELAN is not set=0A=
# CONFIG_PCMCIA_WVLAN is not set=0A=
# CONFIG_AIRONET4500_CS is not set=0A=
# CONFIG_AIRONET4800_CS is not set=0A=
CONFIG_PCMCIA_NETCARD=3Dy=0A=
=0A=
#=0A=
# Amateur Radio support=0A=
#=0A=
# CONFIG_HAMRADIO is not set=0A=
=0A=
#=0A=
# IrDA (infrared) support=0A=
#=0A=
# CONFIG_IRDA is not set=0A=
=0A=
#=0A=
# ISDN subsystem=0A=
#=0A=
# CONFIG_ISDN is not set=0A=
=0A=
#=0A=
# Old CD-ROM drivers (not SCSI, not IDE)=0A=
#=0A=
# CONFIG_CD_NO_IDESCSI is not set=0A=
=0A=
#=0A=
# Input core support=0A=
#=0A=
# CONFIG_INPUT is not set=0A=
=0A=
#=0A=
# Character devices=0A=
#=0A=
CONFIG_VT=3Dy=0A=
CONFIG_VT_CONSOLE=3Dy=0A=
CONFIG_SERIAL=3Dy=0A=
# CONFIG_SERIAL_CONSOLE is not set=0A=
# CONFIG_SERIAL_EXTENDED is not set=0A=
# CONFIG_SERIAL_NONSTANDARD is not set=0A=
CONFIG_UNIX98_PTYS=3Dy=0A=
CONFIG_UNIX98_PTY_COUNT=3D256=0A=
=0A=
#=0A=
# I2C support=0A=
#=0A=
# CONFIG_I2C is not set=0A=
=0A=
#=0A=
# Mice=0A=
#=0A=
# CONFIG_BUSMOUSE is not set=0A=
CONFIG_MOUSE=3Dy=0A=
CONFIG_PSMOUSE=3Dy=0A=
# CONFIG_82C710_MOUSE is not set=0A=
# CONFIG_PC110_PAD is not set=0A=
=0A=
#=0A=
# Joysticks=0A=
#=0A=
# CONFIG_JOYSTICK is not set=0A=
# CONFIG_QIC02_TAPE is not set=0A=
=0A=
#=0A=
# Watchdog Cards=0A=
#=0A=
# CONFIG_WATCHDOG is not set=0A=
# CONFIG_INTEL_RNG is not set=0A=
# CONFIG_NVRAM is not set=0A=
# CONFIG_RTC is not set=0A=
# CONFIG_DTLK is not set=0A=
# CONFIG_R3964 is not set=0A=
# CONFIG_APPLICOM is not set=0A=
=0A=
#=0A=
# Ftape, the floppy tape device driver=0A=
#=0A=
# CONFIG_FTAPE is not set=0A=
CONFIG_AGP=3Dy=0A=
CONFIG_AGP_INTEL=3Dy=0A=
CONFIG_AGP_I810=3Dy=0A=
CONFIG_AGP_VIA=3Dy=0A=
CONFIG_AGP_AMD=3Dy=0A=
CONFIG_AGP_SIS=3Dy=0A=
CONFIG_AGP_ALI=3Dy=0A=
CONFIG_DRM=3Dy=0A=
CONFIG_DRM_TDFX=3Dy=0A=
# CONFIG_DRM_GAMMA is not set=0A=
# CONFIG_DRM_R128 is not set=0A=
CONFIG_DRM_RADEON=3Dy=0A=
# CONFIG_DRM_I810 is not set=0A=
# CONFIG_DRM_MGA is not set=0A=
CONFIG_PCMCIA_SERIAL=3Dy=0A=
=0A=
#=0A=
# PCMCIA character device support=0A=
#=0A=
# CONFIG_PCMCIA_SERIAL_CS is not set=0A=
# CONFIG_PCMCIA_SERIAL_CB is not set=0A=
=0A=
#=0A=
# Multimedia devices=0A=
#=0A=
# CONFIG_VIDEO_DEV is not set=0A=
=0A=
#=0A=
# File systems=0A=
#=0A=
CONFIG_QUOTA=3Dy=0A=
CONFIG_FS_POSIX_ACL=3Dy=0A=
# CONFIG_AUTOFS_FS is not set=0A=
CONFIG_AUTOFS4_FS=3Dy=0A=
# CONFIG_REISERFS_FS is not set=0A=
# CONFIG_REISERFS_CHECK is not set=0A=
# CONFIG_ADFS_FS is not set=0A=
# CONFIG_ADFS_FS_RW is not set=0A=
# CONFIG_AFFS_FS is not set=0A=
# CONFIG_HFS_FS is not set=0A=
# CONFIG_BFS_FS is not set=0A=
CONFIG_FAT_FS=3Dy=0A=
CONFIG_MSDOS_FS=3Dy=0A=
# CONFIG_UMSDOS_FS is not set=0A=
CONFIG_VFAT_FS=3Dy=0A=
# CONFIG_EFS_FS is not set=0A=
# CONFIG_JFFS_FS is not set=0A=
# CONFIG_CRAMFS is not set=0A=
# CONFIG_TMPFS is not set=0A=
# CONFIG_RAMFS is not set=0A=
CONFIG_ISO9660_FS=3Dy=0A=
# CONFIG_JOLIET is not set=0A=
# CONFIG_MINIX_FS is not set=0A=
# CONFIG_NTFS_FS is not set=0A=
# CONFIG_NTFS_RW is not set=0A=
# CONFIG_HPFS_FS is not set=0A=
CONFIG_PROC_FS=3Dy=0A=
# CONFIG_DEVFS_FS is not set=0A=
# CONFIG_DEVFS_MOUNT is not set=0A=
# CONFIG_DEVFS_DEBUG is not set=0A=
CONFIG_DEVPTS_FS=3Dy=0A=
# CONFIG_QNX4FS_FS is not set=0A=
# CONFIG_QNX4FS_RW is not set=0A=
# CONFIG_ROMFS_FS is not set=0A=
CONFIG_EXT2_FS=3Dy=0A=
# CONFIG_SYSV_FS is not set=0A=
# CONFIG_SYSV_FS_WRITE is not set=0A=
# CONFIG_UDF_FS is not set=0A=
# CONFIG_UDF_RW is not set=0A=
# CONFIG_UFS_FS is not set=0A=
# CONFIG_UFS_FS_WRITE is not set=0A=
CONFIG_PAGE_BUF=3Dy=0A=
CONFIG_XFS_FS=3Dy=0A=
# CONFIG_XFS_DMAPI is not set=0A=
CONFIG_XFS_QUOTA=3Dy=0A=
# CONFIG_XFS_DEBUG is not set=0A=
# CONFIG_XFS_VNODE_TRACING is not set=0A=
=0A=
#=0A=
# Network File Systems=0A=
#=0A=
# CONFIG_CODA_FS is not set=0A=
CONFIG_NFS_FS=3Dy=0A=
CONFIG_NFS_V3=3Dy=0A=
# CONFIG_ROOT_NFS is not set=0A=
CONFIG_NFSD=3Dy=0A=
CONFIG_NFSD_V3=3Dy=0A=
CONFIG_SUNRPC=3Dy=0A=
CONFIG_LOCKD=3Dy=0A=
CONFIG_LOCKD_V4=3Dy=0A=
# CONFIG_SMB_FS is not set=0A=
# CONFIG_NCP_FS is not set=0A=
# CONFIG_NCPFS_PACKET_SIGNING is not set=0A=
# CONFIG_NCPFS_IOCTL_LOCKING is not set=0A=
# CONFIG_NCPFS_STRONG is not set=0A=
# CONFIG_NCPFS_NFS_NS is not set=0A=
# CONFIG_NCPFS_OS2_NS is not set=0A=
# CONFIG_NCPFS_SMALLDOS is not set=0A=
# CONFIG_NCPFS_NLS is not set=0A=
# CONFIG_NCPFS_EXTRAS is not set=0A=
=0A=
#=0A=
# Partition Types=0A=
#=0A=
CONFIG_PARTITION_ADVANCED=3Dy=0A=
# CONFIG_ACORN_PARTITION is not set=0A=
# CONFIG_OSF_PARTITION is not set=0A=
# CONFIG_AMIGA_PARTITION is not set=0A=
# CONFIG_ATARI_PARTITION is not set=0A=
# CONFIG_MAC_PARTITION is not set=0A=
CONFIG_MSDOS_PARTITION=3Dy=0A=
# CONFIG_BSD_DISKLABEL is not set=0A=
# CONFIG_MINIX_SUBPARTITION is not set=0A=
# CONFIG_SOLARIS_X86_PARTITION is not set=0A=
# CONFIG_UNIXWARE_DISKLABEL is not set=0A=
# CONFIG_SGI_PARTITION is not set=0A=
# CONFIG_ULTRIX_PARTITION is not set=0A=
# CONFIG_SUN_PARTITION is not set=0A=
# CONFIG_SMB_NLS is not set=0A=
CONFIG_NLS=3Dy=0A=
=0A=
#=0A=
# Native Language Support=0A=
#=0A=
CONFIG_NLS_DEFAULT=3D"iso8859-1"=0A=
# CONFIG_NLS_CODEPAGE_437 is not set=0A=
# CONFIG_NLS_CODEPAGE_737 is not set=0A=
# CONFIG_NLS_CODEPAGE_775 is not set=0A=
# CONFIG_NLS_CODEPAGE_850 is not set=0A=
# CONFIG_NLS_CODEPAGE_852 is not set=0A=
# CONFIG_NLS_CODEPAGE_855 is not set=0A=
# CONFIG_NLS_CODEPAGE_857 is not set=0A=
# CONFIG_NLS_CODEPAGE_860 is not set=0A=
# CONFIG_NLS_CODEPAGE_861 is not set=0A=
# CONFIG_NLS_CODEPAGE_862 is not set=0A=
# CONFIG_NLS_CODEPAGE_863 is not set=0A=
# CONFIG_NLS_CODEPAGE_864 is not set=0A=
# CONFIG_NLS_CODEPAGE_865 is not set=0A=
# CONFIG_NLS_CODEPAGE_866 is not set=0A=
# CONFIG_NLS_CODEPAGE_869 is not set=0A=
# CONFIG_NLS_CODEPAGE_874 is not set=0A=
# CONFIG_NLS_CODEPAGE_932 is not set=0A=
# CONFIG_NLS_CODEPAGE_936 is not set=0A=
# CONFIG_NLS_CODEPAGE_949 is not set=0A=
# CONFIG_NLS_CODEPAGE_950 is not set=0A=
# CONFIG_NLS_ISO8859_1 is not set=0A=
# CONFIG_NLS_ISO8859_2 is not set=0A=
# CONFIG_NLS_ISO8859_3 is not set=0A=
# CONFIG_NLS_ISO8859_4 is not set=0A=
# CONFIG_NLS_ISO8859_5 is not set=0A=
# CONFIG_NLS_ISO8859_6 is not set=0A=
# CONFIG_NLS_ISO8859_7 is not set=0A=
# CONFIG_NLS_ISO8859_8 is not set=0A=
# CONFIG_NLS_ISO8859_9 is not set=0A=
# CONFIG_NLS_ISO8859_14 is not set=0A=
# CONFIG_NLS_ISO8859_15 is not set=0A=
# CONFIG_NLS_KOI8_R is not set=0A=
# CONFIG_NLS_UTF8 is not set=0A=
=0A=
#=0A=
# Console drivers=0A=
#=0A=
CONFIG_VGA_CONSOLE=3Dy=0A=
# CONFIG_VIDEO_SELECT is not set=0A=
# CONFIG_MDA_CONSOLE is not set=0A=
=0A=
#=0A=
# Frame-buffer support=0A=
#=0A=
# CONFIG_FB is not set=0A=
=0A=
#=0A=
# Sound=0A=
#=0A=
# CONFIG_SOUND is not set=0A=
=0A=
#=0A=
# USB support=0A=
#=0A=
CONFIG_USB=3Dy=0A=
# CONFIG_USB_DEBUG is not set=0A=
# CONFIG_USB_DEVICEFS is not set=0A=
# CONFIG_USB_BANDWIDTH is not set=0A=
CONFIG_USB_UHCI_ALT=3Dy=0A=
# CONFIG_USB_OHCI is not set=0A=
# CONFIG_USB_AUDIO is not set=0A=
# CONFIG_USB_BLUETOOTH is not set=0A=
CONFIG_USB_STORAGE=3Dy=0A=
# CONFIG_USB_STORAGE_DEBUG is not set=0A=
# CONFIG_USB_STORAGE_FREECOM is not set=0A=
# CONFIG_USB_STORAGE_HP8200e is not set=0A=
# CONFIG_USB_ACM is not set=0A=
# CONFIG_USB_PRINTER is not set=0A=
# CONFIG_USB_DC2XX is not set=0A=
# CONFIG_USB_MDC800 is not set=0A=
# CONFIG_USB_SCANNER is not set=0A=
# CONFIG_USB_MICROTEK is not set=0A=
# CONFIG_USB_HP5300 is not set=0A=
# CONFIG_USB_IBMCAM is not set=0A=
# CONFIG_USB_OV511 is not set=0A=
# CONFIG_USB_DSBR is not set=0A=
# CONFIG_USB_DABUSB is not set=0A=
# CONFIG_USB_PLUSB is not set=0A=
# CONFIG_USB_PEGASUS is not set=0A=
# CONFIG_USB_KAWETH is not set=0A=
# CONFIG_USB_USBNET is not set=0A=
# CONFIG_USB_USS720 is not set=0A=
=0A=
#=0A=
# USB Serial Converter support=0A=
#=0A=
# CONFIG_USB_SERIAL is not set=0A=
# CONFIG_USB_RIO500 is not set=0A=
=0A=
#=0A=
# Kernel hacking=0A=
#=0A=
CONFIG_DEBUG_IOVIRT=3Dy=0A=
# CONFIG_MAGIC_SYSRQ is not set=0A=

------_=_NextPart_000_01C0D708.A1DF2580--

From owner-linux-xfs@oss.sgi.com Mon May  7 08:21:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47FL5w12306
	for linux-xfs-outgoing; Mon, 7 May 2001 08:21:05 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47FL4F12303
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 08:21:05 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f47FL1K28314;
	Mon, 7 May 2001 10:21:01 -0500 (CDT)
Message-ID: <3AF6BDCD.3478335@sgi.com>
Date: Mon, 07 May 2001 10:22:53 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Linux 2.4.4 + xfs
References: <200105071537080970.00A6D1A0@mail.gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"linux" wrote:

> i had a kernel 2.4.3 and i tried to compile it with xfs support in kernel
> and it failed ! i had gcc 2.95 , i installed kgcc with egcs 1.1.2
> and failed again. i didn't want to downgrade my kernel
> so i downloaded kernel 2.4.4.
> i applied the linux-2.4.4-xfs-TEST.patch (the  linux-2.4.4-xfs-cvs-05022001.patch.gz
> didn't work for me).

Could you provide some information about how these failed, so that we
can fix them if it's a real problem?

> 1.how stable is xfs with kernel 2.4.4 ?

Unknown - 2.4.4 is largely untested at this point.

> 2.is it sue to make the root filesystem xfs ?

Root XFS filesystems should be fine, many people are running that way.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May  7 08:41:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Ff0O13007
	for linux-xfs-outgoing; Mon, 7 May 2001 08:41:00 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47FewF13003
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 08:40:58 -0700
Received: (qmail 16300 invoked by uid 0); 7 May 2001 15:40:51 -0000
Received: from adsl-3-43.adsl.easynet.fr (HELO mail.gmx.de) (212.11.27.43)
  by mail.gmx.net (mp030-rz3) with SMTP; 7 May 2001 15:40:51 -0000
Message-ID: <200105071740430171.0117F359@mail.gmx.de>
In-Reply-To: <3AF6BDCD.3478335@sgi.com>
References: <200105071537080970.00A6D1A0@mail.gmx.de>
 <3AF6BDCD.3478335@sgi.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Mon, 07 May 2001 17:40:43 +0200
From: "linux" <dahouet@gmx.net>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Linux 2.4.4 + xfs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f47FexF13005
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Le 07/05/2001 à 10:22 Eric Sandeen a écrit :
>Could you provide some information about how these failed, so that we
>can fix them if it's a real problem?
you can see a few posts in the list archive.

>> 1.how stable is xfs with kernel 2.4.4 ?
>Unknown - 2.4.4 is largely untested at this point.
do you want to do some test with my config ?

>> 2.is it sue to make the root filesystem xfs ?
>Root XFS filesystems should be fine, many people are running that way.
ok i'm about to try to migrate my server today.

thanks
@++
nico


From owner-linux-xfs@oss.sgi.com Mon May  7 09:12:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47GCSm13620
	for linux-xfs-outgoing; Mon, 7 May 2001 09:12:28 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47GCRF13617
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 09:12:28 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA16835
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 09:11:05 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA21343; Mon, 7 May 2001 11:11:11 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f47GABe11075;
	Mon, 7 May 2001 12:10:11 -0400
Message-ID: <3AF6C8E2.ACF6EA1@thebarn.com>
Date: Mon, 07 May 2001 12:10:10 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Linux 2.4.4 + xfs
References: <200105071537080970.00A6D1A0@mail.gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:

> Hi,
>
> i had a kernel 2.4.3 and i tried to compile it with xfs support in kernel
> and it failed ! i had gcc 2.95 , i installed kgcc with egcs 1.1.2
> and failed again. i didn't want to downgrade my kernel
> so i downloaded kernel 2.4.4.
> i applied the linux-2.4.4-xfs-TEST.patch (the  linux-2.4.4-xfs-cvs-05022001.patch.gz
> didn't work for me).

Since I've manage to make some stupid mistakess when generating patches in
the past, I make sure to test the patches before I put them on oss.
I tested the CVS patch and it does work.
how did you try and apply it.

>
> and i managed to compile it with gcc 2.95 !
> so i have now a little partition with xfs : good
>
> but
>
> 1.how stable is xfs with kernel 2.4.4 ?

It's not, and some of the problems my be linux releated and not XFS, but
we need to track them down.



> 2.is it sue to make the root filesystem xfs ?
>
> thanks
> @++
> nico

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May  7 09:18:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47GIWo13758
	for linux-xfs-outgoing; Mon, 7 May 2001 09:18:32 -0700
Received: from sith.mimuw.edu.pl (qmailr@sith.mimuw.edu.pl [193.0.97.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47GITF13754
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 09:18:29 -0700
Received: (qmail 22546 invoked by uid 1645); 7 May 2001 16:23:48 -0000
Date: Mon, 7 May 2001 18:23:48 +0200
From: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
To: linux-xfs@oss.sgi.com
Subject: XFS and nfsd_operations patch
Message-ID: <20010507182348.F2753@sith.mimuw.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
X-Operating-System: Linux 2.4.2-xfs i686
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,
Some time ago Neil Brown made an nfsd_operations patch (available at
http://cgi.cse.unsw.edu.au/~neilb/patches/linux/) which needs a
find_parent method[1]. This patch is required for reiserfs to work
reliably with NFS and as I want both reiserfs and XFS to be servable
via NFS I made a small patch for XFS to work with nfsd_operations.

Could some XFS hacker please check the following code if it's correct?
I tested it, it Works For Me(tm) but I want to be on the safe side :)

[1] struct dentry * get_parent(struct dentry *child):
    get_parent should find the parent directory for the given child which is
    also a directory.  In the event that it cannot be found, or storage space
    cannot be allocated, a %ERR_PTR should be returned.


struct dentry * linvfs_get_parent(struct dentry *child)
{
	int		error;
	vnode_t		*vp, *cvp;
	pathname_t	pn;
	pathname_t      *pnp = &pn;
	struct inode	*ip = NULL;
	struct dentry	*parent;

	vp = LINVFS_GET_VP(child->d_inode);
	ASSERT(vp);

	/*
	 * Initialize a pathname_t to pass down.
	 */
	bzero(pnp, sizeof(pathname_t));
	pnp->pn_complen = 2;
	pnp->pn_path = "..";

	cvp = NULL;

	VOP_LOOKUP(vp, "..", &cvp, pnp, 0, NULL, NULL, error);
	if (!error) {
		ASSERT(cvp);
		ip = LINVFS_GET_IP(cvp);
		if (!ip) {
			VN_RELE(cvp);
			return ERR_PTR(-EACCES);
		}
		linvfs_set_inode_ops(ip);
		error = linvfs_revalidate_core(ip, ATTR_COMM);
	}

	parent = d_make_alias(ip);
	if (!parent) {
		VN_RELE(cvp);
		parent = ERR_PTR(-ENOMEM);
	}

	return parent;
}

Jan
-- 
Jan Rêkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio

From owner-linux-xfs@oss.sgi.com Mon May  7 09:48:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Gmo514566
	for linux-xfs-outgoing; Mon, 7 May 2001 09:48:50 -0700
Received: from newman.aits.uillinois.edu (newman.aits.uillinois.edu [128.174.25.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47GmjF14558
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 09:48:45 -0700
Received: from aitsmail.aiss.uic.edu (aitsmail.aiss.uic.edu [131.193.163.60])
	by newman.aits.uillinois.edu (8.11.0/8.11.0) with ESMTP id f47Gmdf22016
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 11:48:39 -0500
Received: by aitsmail.aiss.uic.edu with Internet Mail Service (5.5.2650.21)
	id <JR61CJKJ>; Mon, 7 May 2001 11:48:39 -0500
Message-ID: <3D285CB805FDD311B1C700D0B720E04D022ACECA@aitsmail.aiss.uic.edu>
From: "Streit, Chris" <cstreit@uillinois.edu>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: afer partion creation
Date: Mon, 7 May 2001 11:48:38 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0D715.90BFFC40"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0D715.90BFFC40
Content-Type: text/plain;
	charset="iso-8859-1"

after a raid partion creation in the installer it crashes. I have done this
same install, on the same hardware a few times now with rh 7.1 cd's

the machine is a dell poweredge server 2450, dual 600 p3, and 256 meg of
ram.

here is the output from the crash <<anacdump.txt>> 

------_=_NextPart_000_01C0D715.90BFFC40
Content-Type: text/plain;
	name="anacdump.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="anacdump.txt"

Traceback (innermost last):=0A=
  File "/usr/bin/anaconda", line 520, in ?=0A=
    intf.run(todo, test =3D test)=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 392, in =
run=0A=
    self.icw.run ()=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 880, in =
run=0A=
    mainloop ()=0A=
  File "/usr/lib/python1.5/site-packages/gtk.py", line 2554, in =
mainloop=0A=
    _gtk.gtk_main()=0A=
  File "/usr/lib/python1.5/site-packages/gtk.py", line 125, in =
__call__=0A=
    ret =3D apply(self.func, a)=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/gui.py", line 482, in =
nextClicked=0A=
    next =3D self.currentScreen.getNext ()=0A=
  File =
"/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line =
130, in getNext=0A=
    rc =3D self.lba32Check ()=0A=
  File =
"/var/tmp/anaconda-7.1//usr/lib/anaconda/iw/rootpartition_gui.py", line =
76, in lba32Check=0A=
    maxcyl =3D self.todo.fstab.getBootPartitionMaxCylFromDesired()=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 241, in =
getBootPartitionMaxCylFromDesired=0A=
    bootpart =3D self.getBootDevice()=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 267, in =
getBootDevice=0A=
    for (mntpoint, partition, fsystem, doFormat, size) in =
self.mountList():=0A=
  File "/var/tmp/anaconda-7.1//usr/lib/anaconda/fstab.py", line 1040, =
in mountList=0A=
    self.fsCache[(device, mntpoint)] =3D (1, fsystem)=0A=
NameError: fsystem=0A=
=0A=
Local variables in innermost frame:=0A=
size: 32067=0A=
mntpoint: /boot=0A=
makeup: ['Raid000', 'Raid001']=0A=
device: md0=0A=
raidType: 1=0A=
start: 63=0A=
sortMounts: <function sortMounts at 84f5a90>=0A=
fsType: xfs=0A=
devices: [('sda1', 'Raid000', 7, 63, 32067, 2, 0), ('sdb1', 'Raid001', =
7, 63, 32067, 2, 0), ('sda5', 'Raid010', 7, 32193, 2875572, 181, 0), =
('sdb5', 'Raid011', 7, 32193, 2875572, 181, 0), ('sdc1', 'Raid012', 7, =
63, 2875572, 179, 0), ('sdd1', 'Raid013', 7, 63, 2875572, 179, 0), =
('sda6', 'Raid006', 7, 2907828, 706797, 225, 0), ('sdb6', 'Raid007', 7, =
2907828, 706797, 225, 0), ('sdc5', 'Raid008', 7, 2875698, 706797, 223, =
0), ('sdd5', 'Raid009', 7, 2875698, 706797, 223, 0), ('sdc6', =
'Raid004', 7, 3582558, 353367, 245, 0), ('sdd6', 'Raid005', 7, 3582558, =
353367, 245, 0), ('sda7', 'Raid002', 7, 3614688, 353367, 247, 0), =
('sdb7', 'Raid003', 7, 3614688, 353367, 247, 0)]=0A=
fstab: []=0A=
self: <fstab.GuiFstab instance at 84977b0>=0A=
raid: [('<Swap Partition>', 'md1', 'swap', 5, 63, 32067, ['Raid002', =
'Raid003', 'Raid004', 'Raid005']), ('/boot', 'md0', 'xfs', 1, 63, =
32067, ['Raid000', 'Raid001']), ('/home', 'md2', 'xfs', 5, 32193, =
2875572, ['Raid006', 'Raid007', 'Raid008', 'Raid009']), ('/', 'md3', =
'xfs', 5, 32193, 2875572, ['Raid010', 'Raid011', 'Raid012', =
'Raid013'])]=0A=
skipExtra: 0=0A=
=0A=
ToDo object:=0A=
(itodo=0A=
ToDo=0A=
p1=0A=
(dp2=0A=
S'resState'=0A=
p3=0A=
S''=0A=
sS'progressWindow'=0A=
p4=0A=
NsS'setupFilesystems'=0A=
p5=0A=
I1=0A=
sS'monitorVsync'=0A=
p6=0A=
S''=0A=
sS'videoCardStateNode'=0A=
p7=0A=
S''=0A=
sS'serial'=0A=
p8=0A=
I0=0A=
sS'ddruidReadOnly'=0A=
p9=0A=
I0=0A=
sS'bootdisk'=0A=
p10=0A=
I0=0A=
sS'videoRamState'=0A=
p11=0A=
S''=0A=
sS'monitorOriginalName'=0A=
p12=0A=
S''=0A=
sS'language'=0A=
p13=0A=
(itodo=0A=
Language=0A=
(dp14=0A=
S'langInfoByName'=0A=
p15=0A=
(dp16=0A=
S'Arabic (Yemen)'=0A=
p17=0A=
(S'ar_YE'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Spanish (Argentina)'=0A=
p18=0A=
(S'es_AR'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Italian (Italy)'=0A=
p19=0A=
(S'it_IT@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Lebanon)'=0A=
p20=0A=
(S'ar_LB'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Spanish (Guatemala)'=0A=
p21=0A=
(S'es_GT'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Libyan Arab Jamahiriya)'=0A=
p22=0A=
(S'ar_LY'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Arabic (Oman)'=0A=
p23=0A=
(S'ar_OM'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Arabic (Iraq)'=0A=
p24=0A=
(S'ar_IQ'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Spanish (Chile)'=0A=
p25=0A=
(S'es_CL'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (South Africa)'=0A=
p26=0A=
(S'en_ZA'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'French (Switzerland)'=0A=
p27=0A=
(S'fr_CH'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Bahrein)'=0A=
p28=0A=
(S'ar_BH'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Croatian'=0A=
p29=0A=
(S'hr_HR'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'French (France)'=0A=
p30=0A=
(S'fr_FR@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Greenlandic (Greenland)'=0A=
p31=0A=
(S'kl_GL'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Korean (Republic of Korea)'=0A=
p32=0A=
(S'ko_KR.euckr'=0A=
S'iso01'=0A=
S'lat0-16'=0A=
tsS'Ukrainian'=0A=
p33=0A=
(S'uk_UA'=0A=
S'koi8-u'=0A=
S'cyr-sun16'=0A=
tsS'Spanish (Mexico)'=0A=
p34=0A=
(S'es_MX'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Greek'=0A=
p35=0A=
(S'el_GR'=0A=
S'iso07'=0A=
S'gr.f16'=0A=
tsS'Spanish (El Salvador)'=0A=
p36=0A=
(S'es_SV'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Honduras)'=0A=
p37=0A=
(S'es_HN'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Costa Rica)'=0A=
p38=0A=
(S'es_CR'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Dutch (Netherlands)'=0A=
p39=0A=
(S'nl_NL@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Serbian (Yugoslavia)'=0A=
p40=0A=
(S'sr_YU@cyrillic'=0A=
S'iso05'=0A=
S'cyr-sun16'=0A=
tsS'Russian (Ukraine)'=0A=
p41=0A=
(S'ru_UA'=0A=
S'koi8-u'=0A=
S'cyr-sun16'=0A=
tsS'Afrikaans (South Africa)'=0A=
p42=0A=
(S'af_ZA'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Norwegian'=0A=
p43=0A=
(S'no_NO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Morocco)'=0A=
p44=0A=
(S'ar_MA'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Portuguese (Portugal)'=0A=
p45=0A=
(S'pt_PT@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Algeria)'=0A=
p46=0A=
(S'ar_DZ'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'French (Belgium)'=0A=
p47=0A=
(S'fr_BE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Indonesian'=0A=
p48=0A=
(S'id_ID'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Danish'=0A=
p49=0A=
(S'da_DK'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Denmark)'=0A=
p50=0A=
(S'en_DK'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Faroese (Faroe Islands)'=0A=
p51=0A=
(S'fo_FO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Galician (Spain)'=0A=
p52=0A=
(S'gl_ES@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'English (New Zealand)'=0A=
p53=0A=
(S'en_NZ'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Bolivia)'=0A=
p54=0A=
(S'es_BO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Cornish (Britain)'=0A=
p55=0A=
(S'kw_GB'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (United Arab Emirates)'=0A=
p56=0A=
(S'ar_AE'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'German (Austria)'=0A=
p57=0A=
(S'de_AT@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Romanian'=0A=
p58=0A=
(S'ro_RO'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Spanish (Paraguay)'=0A=
p59=0A=
(S'es_PY'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Hebrew (Israel)'=0A=
p60=0A=
(S'he_IL'=0A=
S'iso08'=0A=
S'LatArCyrHeb-16'=0A=
tsS'German (Luxemburg)'=0A=
p61=0A=
(S'de_LU@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (USA)'=0A=
p62=0A=
(S'es_US'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Portuguese (Brasil)'=0A=
p63=0A=
(S'pt_BR'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Equador)'=0A=
p64=0A=
(S'es_EC'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Polish'=0A=
p65=0A=
(S'pl_PL'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Slovak'=0A=
p66=0A=
(S'sk_SK'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Macedonian'=0A=
p67=0A=
(S'mk_MK'=0A=
S'iso05'=0A=
S'cyr-sun16'=0A=
tsS'Spanish (Spain)'=0A=
p68=0A=
(S'es_ES@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Syrian Arab Republic)'=0A=
p69=0A=
(S'ar_SY'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Czech'=0A=
p70=0A=
(S'cs_CZ'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Irish'=0A=
p71=0A=
(S'ga_IE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Jordan)'=0A=
p72=0A=
(S'ar_JO'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Italian (Switzerland)'=0A=
p73=0A=
(S'it_CH'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'German (Belgium)'=0A=
p74=0A=
(S'de_BE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Albanian'=0A=
p75=0A=
(S'sq_AL'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Finnish'=0A=
p76=0A=
(S'fi_FI@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Swedish (Sweden)'=0A=
p77=0A=
(S'sv_SE'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Peru)'=0A=
p78=0A=
(S'es_PE'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Dutch (Belgium)'=0A=
p79=0A=
(S'nl_BE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Panama)'=0A=
p80=0A=
(S'es_PA'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Venezuela)'=0A=
p81=0A=
(S'es_VE'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Great Britain)'=0A=
p82=0A=
(S'en_GB'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Russian'=0A=
p83=0A=
(S'ru_RU.koi8r'=0A=
S'koi8-u'=0A=
S'cyr-sun16'=0A=
tsS'Norwegian, Nynorsk (Norway)'=0A=
p84=0A=
(S'nn_NO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Zimbabwe)'=0A=
p85=0A=
(S'en_ZW'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (USA)'=0A=
p86=0A=
(S'en_US'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Nicaragua)'=0A=
p87=0A=
(S'es_NI'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Kuwait)'=0A=
p88=0A=
(S'ar_KW'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Spanish (Colombia)'=0A=
p89=0A=
(S'es_CO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Basque (Spain)'=0A=
p90=0A=
(S'eu_ES@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Qatar)'=0A=
p91=0A=
(S'ar_QA'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Arabic (Egypt)'=0A=
p92=0A=
(S'ar_EG'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'English (Ireland)'=0A=
p93=0A=
(S'en_IE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Hungarian'=0A=
p94=0A=
(S'hu_HU'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Arabic (Tunisia)'=0A=
p95=0A=
(S'ar_TN'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'French (Luxemburg)'=0A=
p96=0A=
(S'fr_LU@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Japanese'=0A=
p97=0A=
(S'ja_JP.eucJP'=0A=
S'iso01'=0A=
S'lat0-16'=0A=
tsS'Swedish (Finland)'=0A=
p98=0A=
(S'sv_FI@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Saudi Arabia)'=0A=
p99=0A=
(S'ar_SA'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Spanish (Dominican Republic)'=0A=
p100=0A=
(S'es_DO'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'French (Canada)'=0A=
p101=0A=
(S'fr_CA'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Canada)'=0A=
p102=0A=
(S'en_CA'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'German (Germany)'=0A=
p103=0A=
(S'de_DE@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Slovenian (Slovenia)'=0A=
p104=0A=
(S'sl_SI'=0A=
S'iso02'=0A=
S'lat2-sun16'=0A=
tsS'Spanish (Uruguay)'=0A=
p105=0A=
(S'es_UY'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'German (Switzerland)'=0A=
p106=0A=
(S'de_CH'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Australia)'=0A=
p107=0A=
(S'en_AU'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Catalan (Spain)'=0A=
p108=0A=
(S'ca_ES@euro'=0A=
S'iso15'=0A=
S'lat0-sun16'=0A=
tsS'Spanish (Puerto Rico)'=0A=
p109=0A=
(S'es_PR'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Turkish'=0A=
p110=0A=
(S'tr_TR'=0A=
S'iso09'=0A=
S'lat5-sun16'=0A=
tsS'Estonian'=0A=
p111=0A=
(S'et_EE'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Arabic (Sudan)'=0A=
p112=0A=
(S'ar_SD'=0A=
S'iso06'=0A=
S'LatArCyrHeb-16'=0A=
tsS'Icelandic'=0A=
p113=0A=
(S'is_IS'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'English (Botswana)'=0A=
p114=0A=
(S'en_BW'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tsS'Manx Gaelic (Britain)'=0A=
p115=0A=
(S'gv_GB'=0A=
S'iso01'=0A=
S'lat0-sun16'=0A=
tssS'allSupportedLangs'=0A=
p116=0A=
(lp117=0A=
g42=0A=
ag75=0A=
ag46=0A=
ag28=0A=
ag92=0A=
ag24=0A=
ag72=0A=
ag88=0A=
ag20=0A=
ag22=0A=
ag44=0A=
ag23=0A=
ag91=0A=
ag99=0A=
ag112=0A=
ag69=0A=
ag95=0A=
ag56=0A=
ag17=0A=
ag90=0A=
ag108=0A=
ag55=0A=
ag29=0A=
ag70=0A=
ag49=0A=
ag79=0A=
ag39=0A=
ag107=0A=
ag114=0A=
ag102=0A=
ag50=0A=
ag82=0A=
ag93=0A=
ag53=0A=
ag26=0A=
ag86=0A=
ag85=0A=
ag111=0A=
ag51=0A=
ag76=0A=
ag47=0A=
ag101=0A=
ag30=0A=
ag96=0A=
ag27=0A=
ag52=0A=
ag57=0A=
ag74=0A=
ag103=0A=
ag61=0A=
ag106=0A=
ag35=0A=
ag31=0A=
ag60=0A=
ag94=0A=
ag113=0A=
ag48=0A=
ag71=0A=
ag19=0A=
ag73=0A=
ag97=0A=
ag32=0A=
ag67=0A=
ag115=0A=
ag43=0A=
ag84=0A=
ag65=0A=
ag63=0A=
ag45=0A=
ag58=0A=
ag83=0A=
ag41=0A=
ag40=0A=
ag66=0A=
ag104=0A=
ag18=0A=
ag54=0A=
ag25=0A=
ag89=0A=
ag38=0A=
ag100=0A=
ag36=0A=
ag64=0A=
ag21=0A=
ag37=0A=
ag34=0A=
ag87=0A=
ag80=0A=
ag59=0A=
ag78=0A=
ag109=0A=
ag68=0A=
ag62=0A=
ag105=0A=
ag81=0A=
ag98=0A=
ag77=0A=
ag110=0A=
ag33=0A=
asS'info'=0A=
p118=0A=
(dp119=0A=
S'SUPPORTED'=0A=
p120=0A=
NssS'supported'=0A=
p121=0A=
(lsS'default'=0A=
p122=0A=
NsbsS'instClass'=0A=
p123=0A=
(icustom=0A=
InstallClass=0A=
(dp124=0A=
S'rootPasswordCrypted'=0A=
p125=0A=
I0=0A=
sS'raidList'=0A=
p126=0A=
(lsS'nameserver'=0A=
p127=0A=
S''=0A=
sS'x'=0A=
NsS'rootPassword'=0A=
p128=0A=
NsS'makeBootdisk'=0A=
p129=0A=
I0=0A=
sS'installType'=0A=
p130=0A=
NsS'postScript'=0A=
p131=0A=
NsS'earlySwapOn'=0A=
p132=0A=
I0=0A=
sS'networkDevice'=0A=
p133=0A=
NsS'fstab'=0A=
p134=0A=
(lsS'clearText'=0A=
p135=0A=
NsS'lilo'=0A=
p136=0A=
(S'mbr'=0A=
p137=0A=
I1=0A=
S''=0A=
tsg13=0A=
NsS'name'=0A=
p138=0A=
S''=0A=
sS'postInChroot'=0A=
p139=0A=
I0=0A=
sS'pixmap'=0A=
p140=0A=
S''=0A=
sS'partitions'=0A=
p141=0A=
(lp142=0A=
(S'/boot'=0A=
p143=0A=
(I48=0A=
I-1=0A=
I0=0A=
t(S''=0A=
I-1=0A=
I0=0A=
t(I0=0A=
S'xfs'=0A=
p144=0A=
I0=0A=
tNta(S'/'=0A=
(I700=0A=
I-1=0A=
I1=0A=
t(S''=0A=
I-1=0A=
I0=0A=
t(I0=0A=
g144=0A=
I0=0A=
tNta(S'swap'=0A=
p145=0A=
(I512=0A=
I1024=0A=
I1=0A=
t(S''=0A=
I-1=0A=
I0=0A=
t(I0=0A=
NI0=0A=
tNtasS'clearType'=0A=
p146=0A=
S'wkst'=0A=
p147=0A=
sS'gateway'=0A=
p148=0A=
S''=0A=
sS'mouse'=0A=
p149=0A=
NsS'packages'=0A=
p150=0A=
NsS'timezone'=0A=
p151=0A=
NsS'zeroMbr'=0A=
p152=0A=
I0=0A=
sS'keyboard'=0A=
p153=0A=
NsS'groups'=0A=
p154=0A=
NsS'bootProto'=0A=
p155=0A=
NsS'netmask'=0A=
p156=0A=
S''=0A=
sS'langdefault'=0A=
p157=0A=
NsS'skipSteps'=0A=
p158=0A=
(dsS'auth'=0A=
p159=0A=
(I1=0A=
I1=0A=
I0=0A=
S''=0A=
I0=0A=
S''=0A=
I0=0A=
I0=0A=
S''=0A=
S''=0A=
I0=0A=
S''=0A=
S''=0A=
S''=0A=
I0=0A=
S''=0A=
S''=0A=
tsS'hostname'=0A=
p160=0A=
NsS'langsupported'=0A=
p161=0A=
NsS'showgroups'=0A=
p162=0A=
NsS'ip'=0A=
p163=0A=
S''=0A=
sS'firewall'=0A=
p164=0A=
(I-1=0A=
I1=0A=
(lp165=0A=
S''=0A=
I0=0A=
I0=0A=
I0=0A=
I0=0A=
I0=0A=
I0=0A=
tsS'defaultRunlevel'=0A=
p166=0A=
NsS'desktop'=0A=
p167=0A=
S''=0A=
sS'clearPartText'=0A=
p168=0A=
S'Automatic partitioning will erase any preexisting Linux installations =
on your system.'=0A=
p169=0A=
sS'clearParts'=0A=
p170=0A=
I2=0A=
sbsS'bdstate'=0A=
p171=0A=
S''=0A=
sS'extraModules'=0A=
p172=0A=
(lp173=0A=
sS'rootpassword'=0A=
p174=0A=
NsS'fdDevice'=0A=
p175=0A=
S'fd0'=0A=
p176=0A=
sS'installSystem'=0A=
p177=0A=
I1=0A=
sS'comps'=0A=
p178=0A=
NsS'verifiedState'=0A=
p179=0A=
Nsg159=0A=
(itodo=0A=
Authentication=0A=
(dp180=0A=
S'useNIS'=0A=
p181=0A=
I0=0A=
sS'nisServer'=0A=
p182=0A=
S''=0A=
sS'useLdap'=0A=
p183=0A=
I0=0A=
sS'krb5Kdc'=0A=
p184=0A=
S''=0A=
sS'ldapTLS'=0A=
p185=0A=
S''=0A=
sS'useHesiod'=0A=
p186=0A=
I0=0A=
sS'ldapServer'=0A=
p187=0A=
S''=0A=
sS'nisDomain'=0A=
p188=0A=
S''=0A=
sS'krb5Realm'=0A=
p189=0A=
S''=0A=
sS'useLdapauth'=0A=
p190=0A=
I0=0A=
sS'hesiodRhs'=0A=
p191=0A=
S''=0A=
sS'useShadow'=0A=
p192=0A=
I1=0A=
sS'nisuseBroadcast'=0A=
p193=0A=
I0=0A=
sS'useKrb5'=0A=
p194=0A=
I0=0A=
sS'useMD5'=0A=
p195=0A=
I1=0A=
sS'ldapBasedn'=0A=
p196=0A=
S''=0A=
sS'krb5Admin'=0A=
p197=0A=
S''=0A=
sS'hesiodLhs'=0A=
p198=0A=
S''=0A=
sS'hesiodDlhs'=0A=
p199=0A=
S''=0A=
sbsS'users'=0A=
p200=0A=
NsS'hdList'=0A=
p201=0A=
NsS'dhcpState'=0A=
p202=0A=
S''=0A=
sS'method'=0A=
p203=0A=
(iimage=0A=
CdromInstallMethod=0A=
p204=0A=
(dp205=0A=
g4=0A=
=0A=
<failed>=0A=

------_=_NextPart_000_01C0D715.90BFFC40--

From owner-linux-xfs@oss.sgi.com Mon May  7 10:00:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47H0wZ14848
	for linux-xfs-outgoing; Mon, 7 May 2001 10:00:58 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47H0vF14845
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:00:57 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA15323
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:00:56 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA18016
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:00:56 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for linux-xfs@oss.sgi.com; Mon, 7 May 2001 10:00:40 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id KAA28820
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:00:39 -0700
Message-Id: <3AF6D4B7.7D996728@pipcws.ca.boeing.com>
Date: Mon, 07 May 2001 10:00:39 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS <linux-xfs@oss.sgi.com>
Subject: XFS + LVM Installer
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a question for SGI:
Is there any chance of adding another mod to your XFS installer? (two actually).

1) How about adding LVM support at install time (Mandrake has this). It's nice
to lay out the Logical Volumes when you install the system. It eliminates the
need to tear your newly installed system apart to add LVM control (once you've
lived with it, you can't live without it!).

2) How about an XFS enabled installer for Mandrake? Just a thought... :)

	Thanks!

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Mon May  7 10:16:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47HGB715142
	for linux-xfs-outgoing; Mon, 7 May 2001 10:16:11 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HG9F15139
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:16:09 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f47HG4k04623;
	Mon, 7 May 2001 12:16:04 -0500 (CDT)
Message-ID: <3AF6D8C7.AB1EE929@sgi.com>
Date: Mon, 07 May 2001 12:17:59 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Streit, Chris" <cstreit@uillinois.edu>
CC: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: afer partion creation
References: <3D285CB805FDD311B1C700D0B720E04D022ACECA@aitsmail.aiss.uic.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Chris - 

Yep, this is a bug, due to a mis-named variable.

Please grab the disk image at http://lager.dyndns.org/raid-update.img
and dd it to a floppy.

Boot the installer normally, then type "linux updates" at the boot
prompt, and insert the update disk when prompted.

We'll get this up on the FTP site soon.

Thanks,

-Eric

"Streit, Chris" wrote:
> 
> after a raid partion creation in the installer it crashes. I have done this
> same install, on the same hardware a few times now with rh 7.1 cd's

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May  7 10:19:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47HJu115215
	for linux-xfs-outgoing; Mon, 7 May 2001 10:19:56 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HJtF15212
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:19:55 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f47HJqK26727;
	Mon, 7 May 2001 12:19:52 -0500 (CDT)
Message-ID: <3AF6D9A7.C755CDEF@sgi.com>
Date: Mon, 07 May 2001 12:21:43 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
CC: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM Installer
References: <3AF6D4B7.7D996728@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts wrote:
 
> 1) How about adding LVM support at install time (Mandrake has this). It's nice
> to lay out the Logical Volumes when you install the system. It eliminates the
> need to tear your newly installed system apart to add LVM control (once you've
> lived with it, you can't live without it!).
> 
> 2) How about an XFS enabled installer for Mandrake? Just a thought... :)

Take a look in the archives, someone is working on this (the Mandrake
installer) - it's in the "Mandrake RPMs" thread I think.  Might be the
best route to LVM support at install time, since adding it to the Red
Hat installer is an unknown quantity of work...  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May  7 10:21:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47HLnY15264
	for linux-xfs-outgoing; Mon, 7 May 2001 10:21:49 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HLmF15261
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:21:48 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA19180
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:21:47 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA02156
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:21:44 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 7 May 2001 10:21:39 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id KAA35388;
	Mon, 7 May 2001 10:21:38 -0700
Message-Id: <3AF6D9A2.C415753B@pipcws.ca.boeing.com>
Date: Mon, 07 May 2001 10:21:38 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Felix Ide <ide@educators.de>
CC: linux-xfs@oss.sgi.com
Subject: Re: Problem with 2.4.3, xfs, knfsd: "getfh failed: Operation not permitted"
References: <3AF65085.31E3B94B@educators.de> <3AF65819.34D450A1@cs.ucr.edu> <3AF6B793.80C02401@educators.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Felix Ide wrote:
> 
> Daniel Tabuenca wrote:
> >
> > I don't think this is an xfs problem . I get this problem ocassionally
> > and it is usually solved by killing and restarting rpc.mountd, or doing
> > an exportfs -r
> >
> > > woodstock.educators.de:/nfs: Invalid argument
> > > ...
> > > where /nfs is a xfs filesystem. knfsd works fine with ext2 in parallel.
> > >
> > > When I then try to mount this fs, I get the following messages in my
> > > logfile:
> > > ...
> > > rpc.mountd: authenticated mount request from 192.168.10.103:677 for /nfs
> > > rpc.mountd: getfh failed: Operation not permitted
> > > ...
> 
> I'm quite sure that it is an xfs problem, because I tried it on
> different mountpoints with different partitions and the "Invalid
> argument" messages in combination with "getfh failed" do only show up on
> xfs, ext2 works well.

I'm getting exactly the same error!
I tried stopping & restarting mountd, as well as the nfs daemons, and exportfs
-r (as well as clearing out /etc/exports & rebuiling it, just in case it had
spurrious chars in it). All to no avail.

I'm running Mandrake 8.0 with a patched kernel.
I'm actually glad to hear I'm not the only one with this problem. Now we just
need a solution. ;)

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Mon May  7 10:29:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47HTrp15401
	for linux-xfs-outgoing; Mon, 7 May 2001 10:29:53 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HTqF15398
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:29:53 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id KAA02009
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:29:51 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id KAA08841
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:29:50 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Mon, 7 May 2001 10:29:42 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id KAA35400;
	Mon, 7 May 2001 10:29:42 -0700
Message-Id: <3AF6DB86.915FFB0C@pipcws.ca.boeing.com>
Date: Mon, 07 May 2001 10:29:42 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM Installer
References: <3AF6D4B7.7D996728@pipcws.ca.boeing.com> <3AF6D9A7.C755CDEF@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:
> 
> Ric Tibbetts wrote:
> 
> > 1) How about adding LVM support at install time (Mandrake has this). It's nice
> > to lay out the Logical Volumes when you install the system. It eliminates the
> > need to tear your newly installed system apart to add LVM control (once you've
> > lived with it, you can't live without it!).
> >
> > 2) How about an XFS enabled installer for Mandrake? Just a thought... :)
> 
> Take a look in the archives, someone is working on this (the Mandrake
> installer) - it's in the "Mandrake RPMs" thread I think.  Might be the
> best route to LVM support at install time, since adding it to the Red
> Hat installer is an unknown quantity of work...  :)
> 

Thanks Eric!
I'll take a look at the archives.
Given that I'm running Mandrake (at the moment), and since they already have LVM
support at install time, I'll hope for the Mandrake XFS enabled installer ;)



-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Mon May  7 10:42:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Hgj815910
	for linux-xfs-outgoing; Mon, 7 May 2001 10:42:45 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47HgjF15907
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:42:45 -0700
Received: from madurai.engr.sgi.com ([163.154.5.75]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA06826
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 10:42:42 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA68701; Mon, 7 May 2001 10:36:35 -0700 (PDT)
Message-ID: <3AF6DDAC.F05EF57F@sgi.com>
Date: Mon, 07 May 2001 10:38:52 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andreas Piesk <a.piesk@gmx.net>
CC: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: xfs <-> kaio problem
References: <200105062042.f46Kg6F12779@oss.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Andreas Piesk wrote:
> 
> hiho,
> 
> there seems to be a conflict between xfs and kaio.
> (both from sgi :)
> 
> the offending code is in arch/i386/kernel/entry.S :
> 
> xfs want these syscalls:
> #define __NR__attrctl          250
> #define __NR__acl_get          251
> #define __NR__acl_set          252
> 
> and kaio this one:
> #define __NR_aio               251
> 
> i patched my xfs-sources because i need both xfs and kaio.
> the problem is that some third party software (sybase)
> depends on kaio and the kaio-syscalls.
> 
> could someone from sgi clarify this issue ?
> 


I think the best solution is to move the KAIO syscall;
you should be using the dynamically linked (.so) version
of the KAIO library, so moving the syscall number should
work out OK. I'll post new patches on KAIO soon (today
if possible). Also, I'm curious to hear your experiences
with Sybase + KAIO.

Cheers,

ananth.


--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon May  7 11:43:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47IhIP18916
	for linux-xfs-outgoing; Mon, 7 May 2001 11:43:18 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47IhDF18913
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 11:43:17 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA950389
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 20:43:10 +0200 (CEST)
	mail_from (sandeen@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA35211 for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 13:41:54 -0500 (CDT)
Received: (from sandeen@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f47Ies929377
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 14:40:54 -0400
Date: Mon, 7 May 2001 14:40:54 -0400
From: Eric Sandeen <sandeen@sgi.com>
Message-Id: <200105071840.f47Ies929377@gibble.americas.sgi.com>
Subject: TAKE - Installer update disk
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Added top-level makefile target to make an "updates" floppy to fix
misc installer problems.  Currently fstab.py and harddrive.py are
included, to fix some raid problems & allow installs from ISO images on the
local hard drive.

After update disk image has been dd'd to a floppy, the user can type 
"linux updates" or "text updates" at the installer boot prompt to use
this update floppy.

Date:  Mon May  7 11:38:16 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/xfs1/eric/installer

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/sgi-install/1.5/xfs-promo-installer/


Modid:  1.5:sgi-install:94183a
anaconda/updates/fstab.py - 1.1
	- added fstab.py to updates disk - fix raid installer error

anaconda/updates/README - 1.1
	- README for updates disk/dir

anaconda/updates/harddrive.py - 1.1
	- added harddrive.py to updates disk - allow local hard drive iso installs

Makefile - 1.7
	- Added "updatedisk" target to make installer updates floppy image



From owner-linux-xfs@oss.sgi.com Mon May  7 12:30:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47JUbn19860
	for linux-xfs-outgoing; Mon, 7 May 2001 12:30:37 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47JUZF19857
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 12:30:36 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f47JTqg02229;
	Mon, 7 May 2001 14:29:53 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 7 May 2001 14:29:52 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: linux <dahouet@gmx.net>, <linux-xfs@oss.sgi.com>
Subject: Re: Linux 2.4.4 + xfs
In-Reply-To: <3AF6BDCD.3478335@sgi.com>
Message-ID: <Pine.LNX.4.33.0105071428210.1715-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm using the 2.4.4 source tree from SGI's cvs. I must say, it is quite
nice. I've still got some kinda slow sluggish thing happening to my
system, Don't know if that's nautilus causing that or if it's XFS or what.
The odd thing is this only started happening after I upgraded to 7.1 with
XFS. Anyway, I've had no stability problems with the 2.4.4 kernel in a
production office environment, and continue to use it to this day. If you
have any problems lemme know.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Mon May  7 13:00:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47K0in20889
	for linux-xfs-outgoing; Mon, 7 May 2001 13:00:44 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47K0gF20886
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 13:00:42 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <JCFDDNP7>; Mon, 7 May 2001 16:00:29 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C88A5@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "'Timothy Shimmin'" <tes@boing.melbourne.sgi.com>
Cc: "'Linux XFS (E-mail)'" <linux-xfs@oss.sgi.com>
Subject: RE: chacl usage
Date: Mon, 7 May 2001 16:00:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Well, I found the problem.

libacl/acl.c knows that SYS__acl_get is 251 while SYS__acl_set is 252.  That's all well and good if I build my kernel exactly the way you built yours.

Since I built mine without CONFIG_TUX, my higher numbered system calls line up one lower.  Obviously not an SGI-induced problem.  Whoever make the entry.S changes for TUX needed a 
#else 
	.long SYMBOL_NAME(sys_ni_syscall)

-----Original Message-----
From: Christian, Chip [mailto:chip.christian@storageapps.com]
Sent: Monday, May 07, 2001 11:16
To: 'Timothy Shimmin'
Cc: 'Linux XFS (E-mail)'
Subject: RE: chacl usage


Tim,

Call me Chip...

For sure I'm running the proper kernel.  I just built it once more so I could tell you I built it this morning ;-)

noposix_acl.o isn't created, but posix_acl.o is, as another point of verification.

Attached is my .config.  /boot/vmlinuz is the only kernel listed in lilo.conf.  I do this:
	make mrproper
	cp ~/config .config
	make menuconfig (verify settings...)
	make dep
	make bzImage
	make modules
	make modules_install	
	cp arch/i386/boot/bzImage /boot/vmlinuz
	lilo
	init 6


-----Original Message-----
From: Timothy Shimmin [mailto:tes@boing.melbourne.sgi.com]
Sent: Sunday, May 06, 2001 21:04
To: Christian, Chip
Cc: 'Linux XFS (E-mail)'
Subject: Re: chacl usage


Hi Christian,

On Fri, May 04, 2001 at 11:38:34AM -0400, Christian, Chip wrote:
> Oh, and I specified
>       CONFIG_FS_POSIX_ACL=y
> when building the kernel.
>
> >  -----Original Message-----
> > From:       Christian, Chip
> > Sent:       Friday, May 04, 2001 11:37
> > To: Linux XFS (E-mail)
> > Subject:    chacl usage
> >
> > Am I missing something to get acls to work on XFS?  I'm on a frsh RedHat 7.1install, built a kernel from the 1.0 XFS release.  I installed the SGI
acl-1.0.1-0.  Built an XFS filesystem:
> >
> > [root@betanas1 pkgs]# chacl u::rwx,g::rwx,o::rwx foo
> > chacl: error setting access acl on "foo": Function not implemented

This is strange.
The only way I know that you'd be getting ENOSYS (Function not implemented)
for ACLs is if CONFIG_FS_POSIX_ACL is not set.
(See linux/fs/noposix_acl.c (used in linux/fs/Makefile))

Are you sure you have the right kernel running ?

--Tim


From owner-linux-xfs@oss.sgi.com Mon May  7 13:01:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47K1Lw20911
	for linux-xfs-outgoing; Mon, 7 May 2001 13:01:21 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f47K1KF20908
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 13:01:20 -0700
Received: (qmail 27144 invoked by uid 0); 7 May 2001 20:01:13 -0000
Received: from adsl-1-154.adsl.easynet.fr (HELO mail.gmx.de) (212.11.30.154)
  by mail.gmx.net (mp020-rz3) with SMTP; 7 May 2001 20:01:13 -0000
Message-ID: <200105072201030952.02064E06@mail.gmx.de>
In-Reply-To: <Pine.LNX.4.33.0105071428210.1715-100000@UberGeek.coremetrics.com>
References: <Pine.LNX.4.33.0105071428210.1715-100000@UberGeek.coremetrics.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Mon, 07 May 2001 22:01:03 +0200
From: "linux" <dahouet@gmx.net>
To: "Austin Gonyou" <austin@coremetrics.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Linux 2.4.4 + xfs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f47K1LF20909
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

i'm about to finish my migration. (20gb of system)
and i boot from a spare partition with a xfs root filesystem
and there's no first problem.

the annoying thing is that when we will change version of kernel, we
will need new a patch or by hoping that by then, xfs will be integrated into
the kernel.

any experiment is appreciated with this kernel 

thanks


Le 07/05/2001 à 14:29 Austin Gonyou a écrit :

>I'm using the 2.4.4 source tree from SGI's cvs. I must say, it is quite
>nice. I've still got some kinda slow sluggish thing happening to my
>system, Don't know if that's nautilus causing that or if it's XFS or what.
>The odd thing is this only started happening after I upgraded to 7.1 with
>XFS. Anyway, I've had no stability problems with the 2.4.4 kernel in a
>production office environment, and continue to use it to this day. If you
>have any problems lemme know.



From owner-linux-xfs@oss.sgi.com Mon May  7 13:14:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47KESk21159
	for linux-xfs-outgoing; Mon, 7 May 2001 13:14:28 -0700
Received: from smtp4.xs4all.nl (smtp4.xs4all.nl [194.109.6.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47KERF21156
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 13:14:27 -0700
Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44])
	by smtp4.xs4all.nl (8.9.3/8.9.3) with ESMTP id WAA13670
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:14:25 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id WAA07473
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:14:25 +0200 (CEST)
Date: Mon, 7 May 2001 22:14:25 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: linux-xfs@oss.sgi.com
Subject: Re: Linux 2.4.4 + xfs
In-Reply-To: <Pine.LNX.4.33.0105071428210.1715-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.BSI.4.10.10105072156430.3413-100000@xs3.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 7 May 2001, Austin Gonyou wrote:

> I'm using the 2.4.4 source tree from SGI's cvs. I must say, it is quite
> nice. I've still got some kinda slow sluggish thing happening to my
> system, Don't know if that's nautilus causing that or if it's XFS or what.
> The odd thing is this only started happening after I upgraded to 7.1 with
> XFS. Anyway, I've had no stability problems with the 2.4.4 kernel in a
> production office environment, and continue to use it to this day. If you
> have any problems lemme know.

For server use it seems to hold up reasonably well for something which
is not thoroughly tested ;)
The test machine at work holded up nicely when doing some light testing.
Samba seemed a bit sluggish during kernel compiles though. This was a
redhat 7.0 system and is upgraded using the SGI xfs installer. This is a
standard dell desktop machine with a PIII 450 256MB ram and a 40GB IDE
disk.

On my home machine I had a machine lockup during browsing with mozilla but 
that could have been because of the nvidia drivers for my TNT2.
I had been playing "soldier of fortune" for a couple of hours and went
browsing after that. It locked up about 5 minutes after that.
Last thing I saw in the log was the unloading of es1371. No messages after
that :-/

All in all it's actually positive. The work machine stayed up and the home
game machines are up faster after a crash with xfs :-)

Bye
Seth


From owner-linux-xfs@oss.sgi.com Mon May  7 13:51:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47KphX22048
	for linux-xfs-outgoing; Mon, 7 May 2001 13:51:43 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47KpgF22045
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 13:51:43 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f47KoaN02853;
	Mon, 7 May 2001 15:50:36 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 7 May 2001 15:50:36 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
cc: Eric Sandeen <sandeen@sgi.com>, Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM Installer
In-Reply-To: <3AF6DB86.915FFB0C@pipcws.ca.boeing.com>
Message-ID: <Pine.LNX.4.33.0105071550060.1715-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

What can someone do to use LVM and allow for expandable raid volumes? As
in raid 0 or raid 5? Ideas?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Mon May  7 14:29:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47LTtW23096
	for linux-xfs-outgoing; Mon, 7 May 2001 14:29:55 -0700
Received: from marvin.linux-dude.com (c-e08a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.224])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47LTqF23093
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:29:53 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f47LTiB00723;
	Mon, 7 May 2001 23:29:44 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition
Date: Mon, 7 May 2001 23:29:44 +0200
X-Mailer: KMail [version 1.2]
References: <01050515570100.01078@marvin> <01050721045600.04519@marvin> <3AF6F3B3.1687F7F@sgi.com>
In-Reply-To: <3AF6F3B3.1687F7F@sgi.com>
MIME-Version: 1.0
Message-Id: <01050723294400.00685@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Monday 07 May 2001 21:12, you wrote:
> Jarek Luberek wrote:
> > 8.11.1
>
> Hm...
>
Suse ;-)
>
> > > Did you get a chance to try a fresh mount with -o biosize=13?
> >
> > Yes. At least I did a -o remount,biosize=13. Same result.
Finally some success. I booted into my reiserfs partition with
the xfs-enabled kernel from cvs and mounted the xfs partition
with biosize=13 (as you suggested) and chroot:ted there.
Voila, 

/etc/mail > mount
/dev/hda6 on / type xfs (rw,biosize=13)
proc on /proc type proc (rw)
none on proc type proc (rw)
root@marvin:/etc/mail > time make
Rebuilding /etc/mail/access.db.
makemap hash -f /etc/mail/access.db < /etc/mail/access
test -e /etc/mail/access.db && touch /etc/mail/access.db
 
real    0m0.081s
user    0m0.050s
sys     0m0.030s
root@marvin:/etc/mail >

Ok so it was cached this time but even the first time I run the
comman it was quite satisfactory. Now, back to the manual.
What is biosize=13 :-) and how do I set the lilo option. I find
out. Thanks for all help.

Greetings,
jarek

From owner-linux-xfs@oss.sgi.com Mon May  7 14:47:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Llip23462
	for linux-xfs-outgoing; Mon, 7 May 2001 14:47:44 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47LlhF23459
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:47:43 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA18177
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:46:21 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1726929; Mon, 7 May 2001 16:46:25 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA70968; Mon, 7 May 2001 16:46:25 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f47LnNp32701; Mon, 7 May 2001 16:49:23 -0500
Message-Id: <200105072149.f47LnNp32701@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Jarek Luberek <jarek@swipnet.se>
cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Incredibly slow rebuild of small access_db on xfs partition 
In-Reply-To: Message from Jarek Luberek <jarek@swipnet.se> 
   of "Mon, 07 May 2001 23:29:44 +0200." <01050723294400.00685@marvin> 
Date: Mon, 07 May 2001 16:49:23 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> Finally some success. I booted into my reiserfs partition with
> the xfs-enabled kernel from cvs and mounted the xfs partition
> with biosize=13 (as you suggested) and chroot:ted there.
> Voila, 
> 
> /etc/mail > mount
> /dev/hda6 on / type xfs (rw,biosize=13)
> proc on /proc type proc (rw)
> none on proc type proc (rw)
> root@marvin:/etc/mail > time make
> Rebuilding /etc/mail/access.db.
> makemap hash -f /etc/mail/access.db < /etc/mail/access
> test -e /etc/mail/access.db && touch /etc/mail/access.db
>  
> real    0m0.081s
> user    0m0.050s
> sys     0m0.030s
> root@marvin:/etc/mail >
> 
> Ok so it was cached this time but even the first time I run the
> comman it was quite satisfactory. Now, back to the manual.
> What is biosize=13 :-) and how do I set the lilo option. I find
> out. Thanks for all help.

The biosize mount option sets the default I/O size reported by xfs to be
that power of 2 - so 8K in this case, 8K is the lowest it will go without
code changes. This affects the st_blksize reported by stat which is being
used by various applications to determine the size to use for operations.

It may be that use of this field is a little different on Linux and Irix
and having it default to 64K is more problem than it is worth. It also looks
like there is no generic mechanism for passing mount options for the root
filesystem.

If you want to change the values used by default you can do this by changing
some constants in fs/xfs/xfs_mount.h and rebuilding. Change these values:

/*
 * Default minimum read and write sizes.
 */
#define XFS_READIO_LOG_SMALL    15      /* <= 32MB memory */
#define XFS_WRITEIO_LOG_SMALL   15
#define XFS_READIO_LOG_LARGE    16      /* > 32MB memory */
#define XFS_WRITEIO_LOG_LARGE   16

To all be 13

Steve

> 
> Greetings,
> jarek



From owner-linux-xfs@oss.sgi.com Mon May  7 14:51:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47LpCd23554
	for linux-xfs-outgoing; Mon, 7 May 2001 14:51:12 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47Lp8F23550
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:51:12 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA18675
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:49:45 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60492 for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:49:51 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f47Lmoc29079
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 17:48:51 -0400
Date: Mon, 7 May 2001 17:48:51 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105072148.f47Lmoc29079@gibble.americas.sgi.com>
Subject: TAKE - add diff script to 1.0 tree
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May  7 14:48:08 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0
Merged by:  cattelan
Merged mods:  2.4.x-xfs:slinx:91724a,2.4.x-xfs:slinx:92474a,2.4.x-xfs:slinx:93327a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0


Modid:  2.4.x-xfs-r1.0:slinx:94209a
cmd/xfsmisc/XFSgenPatch.pl - 1.1
	- Merge of 2.4.x-xfs:slinx:91724a originally by cattelan on 04/04/01
	  Checking this in for safe keeping.
	  Merge of 2.4.x-xfs:slinx:92474a originally by cattelan on 04/13/01
	  Add iobuf.h and iobuf.c to the list of core linux files that need to be changed.
	  Merge of 2.4.x-xfs:slinx:93327a originally by nathans on 04/24/01
	  add attr_kern.h into the mix.



From owner-linux-xfs@oss.sgi.com Mon May  7 14:53:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47LriP23627
	for linux-xfs-outgoing; Mon, 7 May 2001 14:53:44 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47LriF23624
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:53:44 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19021
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 14:52:22 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA34614 for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:52:28 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f47LpSD29164
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 17:51:28 -0400
Date: Mon, 7 May 2001 17:51:28 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105072151.f47LpSD29164@gibble.americas.sgi.com>
Subject: TAKE - XFSgenPatch.pl 2.4.2 file list.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May  7 14:50:32 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-r1.0

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs-r1.0


Modid:  2.4.x-xfs-r1.0:slinx:94210a
cmd/xfsmisc/XFSgenPatch.pl - 1.2
	- Fix file list for 2.4.2 ... devel version at 2.4.3.



From owner-linux-xfs@oss.sgi.com Mon May  7 15:08:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47M8L524056
	for linux-xfs-outgoing; Mon, 7 May 2001 15:08:21 -0700
Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47M8JF24053
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:08:19 -0700
Received: from localhost (justin@localhost)
	by rogue.tripp.org (8.9.3/8.9.3) with ESMTP id QAA43998
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:08:18 -0600 (MDT)
	(envelope-from justin@tripp.org)
Date: Mon, 7 May 2001 16:07:08 -0600 (MDT)
From: Justin Tripp <justin@tripp.org>
To: Steve Lord <lord@sgi.com>
cc: <inux-xfs@oss.sgi.com>
Subject: Re: Errors using amanda/xfsdump 
In-Reply-To: <200104261815.f3QIFCp31375@jen.americas.sgi.com>
Message-ID: <Pine.BSF.4.33.0105071558590.43788-100000@rogue.tripp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


On Thu, 26 Apr 2001, Steve Lord wrote:

>
> Having thought about this some more, I am almost certain that the problem
> is arising because of the mix of local and remote access to the filesystem.
>
> I would still like to see stack traces if you get a chance, but I think I
> know what happened.
>
> Steve

Okay -- I have had a chance to hook up a serial console to my machine and
have been able to get it to crash again.  The error messages and stack
traces are as follows:

xfs_iget_core: ambiguous vns: vp/0xc3fd43a8, invp/0xc6da98c8
Unable to handle kernel NULL pointer dereference at virtual address
00000008
 printing eip:
d08f90bf
*pde = 00000000

Entering kdb (current=0xce112000, pid 859) on processor 1 Oops: Oops
due to oops @ 0xd08f90bf
eax = 0x00000080 ebx = 0xc6da98c8 ecx = 0xc158a800 edx = 0x00000000
esi = 0xc6da98c8 edi = 0xcf84c710 esp = 0xce113a2c eip = 0xd08f90bf
ebp = 0x00000001 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010282
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xce1139f8

kdb> bt
    EBP       EIP         Function(args)
0x00000001 0xd08f90bf [xfs]vn_revalidate+0x1f (0xc6da98c8, 0x80)
                               xfs .text 0xd0896060 0xd08f90a0 0xd08f9158
           0xd08cf0f0 [xfs]xfs_iget_core+0x77c (0xc6da98c8, 0xc158a800, 0x0, 0x)
                               xfs .text 0xd0896060 0xd08ce974 0xd08cf118
           0xd08cf188 [xfs]xfs_vn_iget+0x34 (0xc6da98c8, 0xc158a800, 0x0, 0x5c0)
                               xfs .text 0xd0896060 0xd08cf154 0xd08cf190
           0xd08f8e81 [xfs]vn_initialize+0xd5 (0xc144aa60, 0xc6da97c0, 0x1)
                               xfs .text 0xd0896060 0xd08f8dac 0xd08f8efc
           0xd08f8366 [xfs]linvfs_read_inode+0x1e (0xc6da97c0)
                               xfs .text 0xd0896060 0xd08f8348 0xd08f8398
           0xc0148227 get_new_inode+0xe3 (0xcf860000, 0x5c02354, 0xc1462228, 0x)
                               kernel .text 0xc0100000 0xc0148144 0xc01482bc
           0xc0148575 iget4+0xdd (0xcf860000, 0x5c02354, 0x0, 0x0, 0xcf867508)
                               kernel .text 0xc0100000 0xc0148498 0xc0148580
           0xd08f15c7 [xfs]xfs_open_by_handle+0x113 (0xc01c586b, 0xbfff9a80, 0x)
                               xfs .text 0xd0896060 0xd08f14b4 0xd08f17d0
           0xd08f28fd [xfs]xfs_ioctl+0xbb9 (0xcf66faf0, 0xcf867400, 0xcdfb2da0,)
                               xfs .text 0xd0896060 0xd08f1d44 0xd08f2c40
           0xd08f10eb [xfs]linvfs_ioctl+0x2f (0xcf867400, 0xcdfb2da0, 0xc01c586)
                               xfs .text 0xd0896060 0xd08f10bc 0xd08f10f4
           0xc0142056 sys_ioctl+0x1ea (0x5, 0xc01c586b, 0xbfff9a80, 0x80e7a40, )
                               kernel .text 0xc0100000 0xc0141e6c 0xc01420b0
           0xc010701f system_call+0x33
                               kernel .text 0xc0100000 0xc0106fec 0xc0107024



ps of the current processes shows that 859 is xfsdump.

0xce112000 00000859 00000857  1  001  run   0xce112350*xfsdump

The output of the xfsdump would lead one to believe that it was doing the
normal files (e.g. non-directory files).

/usr/sbin/xfsdump: version 3.0 - Running single-threaded
/usr/sbin/xfsdump: WARNING: most recent level 0 dump was interrupted, but
not resuming that dump since resume (-R) option not specified
/usr/sbin/xfsdump: level 0 dump of fpga:/ibm1
/usr/sbin/xfsdump: dump date: Mon May  7 14:35:41 2001
/usr/sbin/xfsdump: session id: fc05be66-5713-4a8e-961c-de1bf6ed607c
/usr/sbin/xfsdump: session label: ""
/usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified)
/usr/sbin/xfsdump: ino map phase 2: constructing initial dump list
/usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary)
/usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2)
/usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream)
/usr/sbin/xfsdump: ino map construction complete
/usr/sbin/xfsdump: estimated dump size: 1836213504 bytes
/usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
/usr/sbin/xfsdump: dumping ino map
/usr/sbin/xfsdump: dumping directories
/usr/sbin/xfsdump: dumping non-directory files

I am not able to make this fail consistently, but it does seem to fail
fairly regularly.  Any help would be greatly appreciated.


				.justin.


> >
> > I have been trying to backup xfs partitions using amanda, and there seems
> > to be a problem with xfsdump.  Amanda suprisingly recognized xfsdump and
> > seems to tried to do the backup correctly.  On the other hand, whenever we
> > attempted to backup the machine would belly-up hard.
> >
> > The problem is vexing, because sometimes it will fail consistently and
> > quickly, yet other times it seems to take all day to fail.  I am doing to
> > following to replicate the amanda backup:
> >
> > ssh xfs_machine -l root "/usr/sbin/xfsdump -F -l 0 - /dev/sda1" | gzip -6
> > - > file.gz
> >
> > At the same time the xfs_machine is serving up a partition nfs and the
> > partition is being read and written, by two independant news spools.
> > Doing a usenet news spool over nfs onto xfs, may not be the best
> > performance-wise, but I think most may agree that a news server can hit
> > disks pretty hard when it comes to file ops.
> >
> > After xfsdump caused the machine to fail, got the following error message
> > on the console:
> >
> > xfs_iget_core: ambiguous vns: vp/0xc3a543c8 invp/0xcf89d948
> >
> > Unable to handle kernel NULL pointer dereference at virtual address
> > 00000008
> >
> > printing eip:
> >   d08f90bf
> > *pdc=00000000
> >
> > Entering kdb (current=0xc96dc00, pid 803) on processor 1
> > Oops: Oops
> >   due to oops @ 0xd08490bf ...
> >
> > The process listing showed that xfs was pid 803.
> >
> > I have been unable to reliable recreate the failure.  Sometimes it fails,
> > and some times it does not.  (It does seem to fail more reliably in the
> > morning :) )  I am backing up about 2G of files produced by the news
> > servers.  Any ideas?
> >
> > The machine is a Dual 500 MHz PIII, and the filesystems run on top of the
> > 3ware IDE raid card with 4 46G disks running in RAID level 5.  (138G
> > filesystem available...)  The XFS is the 2.4.3 version from April 5th.
> >
> >
> >
> > 				.justin.
> >
> > ------------------------------------------------------------------------
> > Justin Leonard Tripp                                   justin@ee.byu.edu
> > Configurable Computing Laboratory Research Assistant      CB 461 x8-7206
> > Electrical and Computer Engineering Department  Brigham Young University
> >
> >
>
>
>



From owner-linux-xfs@oss.sgi.com Mon May  7 15:12:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47MCHw24149
	for linux-xfs-outgoing; Mon, 7 May 2001 15:12:18 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47MCHF24146
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:12:17 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07438
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:23:05 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1733358 for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 17:11:01 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA58532 for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 17:11:01 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f47MDwK01601; Mon, 7 May 2001 17:13:58 -0500
Message-Id: <200105072213.f47MDwK01601@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: Linux 2.4.4 + xfs
Date: Mon, 07 May 2001 17:13:58 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,

Just back from a weeks vacation, slogging through my email backlog, I notice
a fair demand for a 2.4.4 xfs patch out there, and that people are using the
development tree.

Looking at what happened to kiobufs in 2.4.4, I think we are going to have to
make some changes in XFS, we are using them as a simple page container
object, and they got a lot more expensive to use. I suspect the memory
used to do anything serious with XFS shot up in the 2.4.4 tree, this
may explain 'sluggish behavior'. Hopefully I can come up with a fix
in the next few days, but management has seen fit to book me up with
several long meetings this week.

So in the meantime, take XFS on 2.4.4 with a pinch of salt, it will change
in the near future.

Steve



From owner-linux-xfs@oss.sgi.com Mon May  7 15:13:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47MD5I24219
	for linux-xfs-outgoing; Mon, 7 May 2001 15:13:05 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47MD4F24216
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:13:05 -0700
Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14wtFX-0001Ld-00
	for linux-xfs@oss.sgi.com; Tue, 8 May 2001 00:13:03 +0200
Received: from pd901e253.dip.t-dialin.net ([217.1.226.83] helo=kernelpanix.aura.of.mankind)
	by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14wtFV-0001jn-00
	for linux-xfs@oss.sgi.com; Tue, 8 May 2001 00:13:01 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f47LX4A14509
	for linux-xfs@oss.sgi.com; Mon, 7 May 2001 23:33:04 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Mon, 7 May 2001 23:33:04 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: linux-xfs@oss.sgi.com
Subject: man page for xfs mount
Message-ID: <20010507233304.A14248@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi

i missing a man page for all the xfs mountoptions.
a mount_xfs man page were really nice.


btw: the xfs_fsr manpage on
http://linux-xfs.sgi.com/projects/xfs/manpages.html is outdated, the lilo
section is missing.


utz

From owner-linux-xfs@oss.sgi.com Mon May  7 15:34:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47MYkk24709
	for linux-xfs-outgoing; Mon, 7 May 2001 15:34:46 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47MYiF24706
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:34:45 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id PAA04557
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 15:34:36 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA22051; Tue, 8 May 2001 08:33:06 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA68442;
	Tue, 8 May 2001 08:33:05 +1000 (EST)
Date: Tue, 8 May 2001 08:33:04 +1000
From: Nathan Scott <nathans@sgi.com>
To: utz lehmann <xfs@s2y4n2c.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: man page for xfs mount
Message-ID: <20010508083304.A63344@wobbly.melbourne.sgi.com>
References: <20010507233304.A14248@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <20010507233304.A14248@s2y4n2c.de>; from xfs@s2y4n2c.de on Mon, May 07, 2001 at 11:33:04PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On Mon, May 07, 2001 at 11:33:04PM +0200, utz lehmann wrote:
> hi
> 
> i missing a man page for all the xfs mountoptions.
> a mount_xfs man page were really nice.
> 

you need to get a more recent version of mount(8) - the XFS
mount options are all documented there, along with all the
other filesystem mount options.

alternatively use linux/Documentation/filesystems/xfs.txt.

> 
> btw: the xfs_fsr manpage on
> http://linux-xfs.sgi.com/projects/xfs/manpages.html is outdated, the lilo
> section is missing.
> 

I'm not sure how often this gets updated, but it probably
reflects the man pages that were released with 1.0 (where
this wasn't documented).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon May  7 16:44:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Ni6a26281
	for linux-xfs-outgoing; Mon, 7 May 2001 16:44:06 -0700
Received: from dragon.vcu.edu (dragon.vcu.edu [128.172.65.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47Ni5F26278
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:44:05 -0700
Received: from comet.vcu.edu (comet.vcu.edu [128.172.1.33])
	by dragon.vcu.edu (8.9.3/8.9.3) with ESMTP id TAA6811809
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 19:44:16 -0400 (EDT)
Date: Mon, 7 May 2001 19:44:04 -0400 (EDT)
From: K Mitchell Russell <kmrussel@hsc.vcu.edu>
X-Sender: kmrussel@comet.vcu.edu
To: linux-xfs@oss.sgi.com
Subject: XFS + RSBAC
Message-ID: <Pine.A41.4.10.10105071423320.42368-100000@comet.vcu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Colleagues,

I have patched a kernel with XFS 1.0 and the Rule-Set Based Access
Controls (www.rsbac.org). This is of particular importance to me for
using Linux to power medical record repositories, requiring data
integrity (journaled fs), performance, and security (mandatory access
controls, role compatibility, ACLs, etc.)

The system seems to run fine even using RSBAC's 'check on init'
function. This function caused problems with ReiserFS as ReiserFS works
internally with 64 bit inode numbers, and RSBAC was removing entries for
inode, which was making ReiserFS complain. Now my impression is that XFS
uses 64 bit inodes, but somehow this is more compatible than the
ReiserFS usage because I am not getting the same errors. Does XFS use 64
bit inodes? Anyone care to comment?

Finally, there is one part of the patch in RSBAC that is still FS
dependent, a secure delete function that patches the fs/ext2/namei.c
(for example) in ext2 by adding the following to ext2_unlink():

if(inode->i_nlink == 1)
  rsbac_sec_del(dentry);

Now they have only implemented this into ext2, vfat, dos, and minix
fs's, but would be nice for XFS integration as well. Where would such a
patch work, or does XFS have an interface for this?

Anyone with further interest in both XFS and the RSBAC patches is
welcome to cross post to the rsbac@rsbac.org mailing list.

Thanks in advance, and congratulations on creating an excellent product
in XFS and supporting open source software!

Regards,
Mitchell


________________________________________________________________________
K. Mitchell Russell, M.D.                         | kmrussel@hsc.vcu.edu
Research Fellow, MedITAC Research Lab             |   www.meditac.com





From owner-linux-xfs@oss.sgi.com Mon May  7 16:45:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f47Nj2Q26384
	for linux-xfs-outgoing; Mon, 7 May 2001 16:45:02 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f47Nj2F26381
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:45:02 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00794
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 16:55:49 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA60682; Mon, 7 May 2001 18:43:44 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f47Nghe29763;
	Mon, 7 May 2001 19:42:43 -0400
Message-ID: <3AF732F3.2E0E3B28@thebarn.com>
Date: Mon, 07 May 2001 19:42:43 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
CC: linux-xfs@oss.sgi.com, Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
			<m3bspbwotj.fsf@giants.mandrakesoft.com>
			<3AF0A70D.C5CE4733@thebarn.com>
			<m37kzyrhj1.fsf@giants.mandrakesoft.com>
			<3AF1A6DC.67C1CA2F@thebarn.com> <m3bsp9xwdi.fsf@giants.mandrakesoft.com> <3AF2D62A.775AEFF2@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts wrote:

Ok I build the Mandrake 8.0 kernel rpm with XFS 1.0
included.
Everything is in the "testing" directory on oss.sgi.com.

I've also removed the jumbo patch and replaced with a mandrake "core" patch,
to use this patch the XFS will also be needed "linux-2.4-xfs-1.0.patch.gz"

The src rpm has everything tied together so I would recommend that if you really
want to build the tree.

I haven't booted the kernels so if anybody is brave enough to try please report
back.


> Chmouel Boudjnah wrote:
> >
> > Russell Cattelan <cattelan@thebarn.com> writes:
> >
> > > If you don't mind, I'll will put this link in our "news" segment on our
> > > web page?
> >
> > Sure.
> >
> > > > > I've  build a patch against the 8.0 kernel src rpm, haven't tested it
> > > > > yet but it does compile.
> > > > > Anybody want help finish it.?
> > > > Could you send me the patch, i had a lot of conflict and i did the
> > > > kernel-xfs on a vanilla 2.4.4 generated patch from cvs.
> > > ftp://oss.sgi.com/projects/xfs/download/testing/mdkl2.4.3-xfs.patch
> > > this was a real quick attempt to get it to compile, area that are suspect
> > > and may not be right :
> > > dquot.c
>
> To anyone that's interested. I applied this patch to a clean Mandrake 2.4.3
> kernel last night.
> It applied cleanly, and the resulting code compiled without error. The system
> booted normally, and all "looked" well. BUT: I have not done any testing! It was
> late when the build finished. I will be doing more with it over the week-end.
>
> But the preliminary view of it is: It works.
>
> --
> __________________________________________________________
> Ric Tibbetts
> Boeing Shared Services Group
> UNIX System Administration
> Seattle Server Operations
> __________________________________________________________

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May  7 17:03:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4803Sw26670
	for linux-xfs-outgoing; Mon, 7 May 2001 17:03:28 -0700
Received: from smtp.xhmul.net (p3E9EDD21.dip.t-dialin.net [62.158.221.33])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4803QF26667
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 17:03:27 -0700
Received: from mail.xhmul.net (uranus.xhmul.net [192.168.74.3])
	by smtp.xhmul.net (Postfix) with ESMTP id 216A4319CD8
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 02:03:20 +0200 (CEST)
Received: from charon (charon.xhmul.net [192.168.74.10])
	by mail.xhmul.net (Postfix) with SMTP id A2C9D81F253
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 02:03:18 +0200 (CEST)
Message-ID: <004001c0d752$4dc3edb0$0a4aa8c0@xhmul.net>
From: "Carl Rueder" <carl@xhmul.dyndns.org>
To: <linux-xfs@oss.sgi.com>
Subject: Great!
Date: Tue, 8 May 2001 02:03:10 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm using XFS a few days now, first the cvs-tree, now the release 1.0 with
kernel 2.4.3 and it's a really great job you did!

Maybe I may ask here some questions about filesystems (especially newer ones
like XFS and some generally questions).

In ext2 the data block is found by walking through all correspondig inodes
which are ordered in a linked list, right?
In xfs (like ReiserFS) the data blocks are referenced by inodes which are
ordered within a btree, right? Therefore the work with many files within a
directory isn't slowed down by walking through a list. But, why is ReiserFS
a few times faster than xfs when working in a directory which contains about
100.000 small files (about 1k in size)? Where's my gap in understanding this
phenomenon?

Another questions (more in general): BSD-derivates are using a UFS or FFS
file system. How's the data referenced there? Like ext2 with some linked
lists or is there also a tree for finding the data? What's the feature named
"soft updates" there? Some people are saying it eliminates the need for
journalling. But what's behind this? Sync writes?

Thank you for your answers!
Carl



From owner-linux-xfs@oss.sgi.com Mon May  7 20:48:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f483mum00630
	for linux-xfs-outgoing; Mon, 7 May 2001 20:48:56 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f483mrF00627
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 20:48:53 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id UAA04399
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 20:48:52 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id UAA01370;
	Mon, 7 May 2001 20:47:35 -0700 (PDT)
Date: Mon, 7 May 2001 20:47:07 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Simon Matter <simon.matter@ch.sauter-bc.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS RedHat installer
In-Reply-To: <3AF63A3B.2C296D1A@ch.sauter-bc.com>
Message-ID: <Pine.LNX.4.30.0105072041330.25517-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 1) Boot floppy:
> When doing a mkbootdisk 2.4.2-xxxxx I saw that the content couldn't
> fit on the disk. Then I tried the following:
> fdformat /dev/fd0u1722
> mkbootdisk --device /dev/fd0u1722 2.4.2-xxxxx
> The disk was created successfully but unfortunately it didn't boot
> anyway. I guess it is a problem with the used 'syslinux'. Did
> you try something like this ?

unfortunately, you cannot boot off of a superformatted floppy...this is a
limitation of the BIOS.

> 2) Software RAID does not work. At least when used for boot/root
> volumes. After investigating the problem I found your note about
> devfs beeing enabled and after using devfs=nomount as kernel parameter
> it worked perfectly. Now my question is: Why did you enable devfs
> and what problems my I run in when using devfs=nomount???

we enabled devfs because we expect people who are going to be using xfs to
have shitload of disks.  if you want many disks, the static dev filesystem
on linux will not work.  plus, if you remove a scsi controller or a disk,
things will get shifted around (sdc becomes sdb, etc.).

there are many other benefits to devfs and you will need to have it
running for big systems and lots of disks which we assume is a place xfs
will fit in nicely...

unfortunately, not all things have been ported to using devfs nicely, on
the other hand, I have devfs working with a md systems fine.

the other thing is that sgi sponsored development of devfs for our big
systems and we would like to see more exposure using it...

-tduffy


From owner-linux-xfs@oss.sgi.com Mon May  7 21:46:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f484kwL01611
	for linux-xfs-outgoing; Mon, 7 May 2001 21:46:58 -0700
Received: from ibu.chadera.net ([63.145.197.180])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f484kvF01608
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 21:46:57 -0700
Received: from chadera.net (darkstar.keluarga.lan [192.168.100.2])
	by ibu.chadera.net (8.9.3/8.9.3) with ESMTP id VAA07712
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 21:46:37 -0700
Message-ID: <3AF77A27.3F48D449@chadera.net>
Date: Mon, 07 May 2001 21:46:31 -0700
From: Ric Tibbetts <ric@chadera.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-mdk+xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: CVS v1.0 kernel won't compile
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is strange.
I'm running Mandrake 8.0, with a patched Mandrake kernel to get XFS. And
yes, XFS is working, but not without problems. So I thought I'd grab the
1.0 tree off CVS and compile it to see if another anoying problem would
go away.

What I did:

CVS: Got the 1.0 release cvs tree.

Copy .config to .../linux
# > make oldconfig
# > make dep
# > make bzImage

Errors out at:

gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__
-I/usr/src/linux/include  -traditional
-c head.S -o head.o
head.S:203: unterminated character constant
make[1]: *** [head.o] Error 1
make[1]: Leaving directory
`/usr/src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2

So, back to cvs, ran cvs -z3 update -d (to get the latest bits).

ran:
# > cp .config ..
# > make mrproper
# > cp ../.config .
# > make oldconfig
# > make dep
# > make bzImage

Build dies with same error as before.

Solutions? Anyone?

	Thanks in advance!

		Ric

From owner-linux-xfs@oss.sgi.com Mon May  7 21:54:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f484sjp01727
	for linux-xfs-outgoing; Mon, 7 May 2001 21:54:45 -0700
Received: from ibu.chadera.net ([63.145.197.180])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f484siF01724
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 21:54:44 -0700
Received: from chadera.net (darkstar.keluarga.lan [192.168.100.2])
	by ibu.chadera.net (8.9.3/8.9.3) with ESMTP id VAA07726
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 21:54:24 -0700
Message-ID: <3AF77BFB.5CE8F569@chadera.net>
Date: Mon, 07 May 2001 21:54:19 -0700
From: Ric Tibbetts <ric@chadera.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-mdk+xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: NFS Export problem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, here's the problem I was trying to solve by using the latest CVS
tree.
When I try to NFS export an XFS filesystem, I get the following error:

the_otherbox.com:/nfs: Invalid argument

Note: This is ONLY with XFS filesystems. ext2 filesystems export fine.

the setup:

Mandrake 8.0 (still stock, except for the kernel munging, and the XFS
filesystems

Mandrake 2.4.3 kernel source + a patch made for that kernel.

I've seen another individual here with the same problem, different
distribution.
Is anyone else running a 2.4.3 kernel with NFS exports working? Or have
an idea of what's wrong?

	Thanks in advance

		Ric

From owner-linux-xfs@oss.sgi.com Mon May  7 22:08:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4858RA01958
	for linux-xfs-outgoing; Mon, 7 May 2001 22:08:27 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4858RF01955
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:08:27 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id WAA07390
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:08:25 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24439; Tue, 8 May 2001 15:07:06 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Ric Tibbetts <ric@chadera.net>
cc: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile 
In-reply-to: Your message of "Mon, 07 May 2001 21:46:31 MST."
             <3AF77A27.3F48D449@chadera.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 May 2001 15:07:05 +1000
Message-ID: <19497.989298425@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 07 May 2001 21:46:31 -0700, 
Ric Tibbetts <ric@chadera.net> wrote:
>gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__
>-I/usr/src/linux/include  -traditional
>-c head.S -o head.o
>head.S:203: unterminated character constant

XFS CVS should be using the 2.4 version of arch/i386/kernel/head.S.
Compare that file against a clean 2.4 kernel, they should be identical.
If not there is a CVS problem or a download corruption, try erasing
arch/i386/kernel/head.S and fetching a fresh copy from CVS.

If the files are identical then your cpp, gcc or gas is doing something
strange.  Which versions are you running?


From owner-linux-xfs@oss.sgi.com Mon May  7 22:10:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f485AuC02018
	for linux-xfs-outgoing; Mon, 7 May 2001 22:10:56 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f485AtF02015
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:10:55 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f485AnmZ030879;
	Tue, 8 May 2001 00:10:49 -0500 (CDT)
Message-ID: <3AF78D39.6834CD0@thebarn.com>
Date: Tue, 08 May 2001 01:07:53 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@chadera.net>
CC: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile
References: <3AF77A27.3F48D449@chadera.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts wrote:

kgcc!

> This is strange.
> I'm running Mandrake 8.0, with a patched Mandrake kernel to get XFS. And
> yes, XFS is working, but not without problems. So I thought I'd grab the
> 1.0 tree off CVS and compile it to see if another anoying problem would
> go away.
>
> What I did:
>
> CVS: Got the 1.0 release cvs tree.
>
> Copy .config to .../linux
> # > make oldconfig
> # > make dep
> # > make bzImage
>
> Errors out at:
>
> gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__
> -I/usr/src/linux/include  -traditional
> -c head.S -o head.o
> head.S:203: unterminated character constant
> make[1]: *** [head.o] Error 1
> make[1]: Leaving directory
> `/usr/src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel'
> make: *** [_dir_arch/i386/kernel] Error 2
>
> So, back to cvs, ran cvs -z3 update -d (to get the latest bits).
>
> ran:
> # > cp .config ..
> # > make mrproper
> # > cp ../.config .
> # > make oldconfig
> # > make dep
> # > make bzImage
>
> Build dies with same error as before.
>
> Solutions? Anyone?
>
>         Thanks in advance!
>
>                 Ric


From owner-linux-xfs@oss.sgi.com Mon May  7 22:15:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f485Fqj02084
	for linux-xfs-outgoing; Mon, 7 May 2001 22:15:52 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f485FpF02081
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:15:52 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id WAA11800
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:14:28 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24493; Tue, 8 May 2001 15:14:28 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Russell Cattelan <cattelan@thebarn.com>
cc: Ric Tibbetts <ric@chadera.net>, Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile 
In-reply-to: Your message of "Tue, 08 May 2001 01:07:53 EST."
             <3AF78D39.6834CD0@thebarn.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 08 May 2001 15:14:28 +1000
Message-ID: <19772.989298868@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 08 May 2001 01:07:53 -0500, 
Russell Cattelan <cattelan@thebarn.com> wrote:
>kgcc!

He is already using gcc -V egcs-2.91.66 == kgcc.


From owner-linux-xfs@oss.sgi.com Mon May  7 22:17:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f485H5d02106
	for linux-xfs-outgoing; Mon, 7 May 2001 22:17:05 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f485H5F02101
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:17:05 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f485GxmZ031047;
	Tue, 8 May 2001 00:16:59 -0500 (CDT)
Message-ID: <3AF78EAB.EE871BC0@thebarn.com>
Date: Tue, 08 May 2001 01:14:03 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@chadera.net>
CC: Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: NFS Export problem
References: <3AF77BFB.5CE8F569@chadera.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts wrote:

Yes I would guess this is same problem other people are experiencing.
I have quite  few nfs exported file systems and haven't run across this
problem,
so guess we need to dig into your setup a bit more.

what options are you specifying in /etc/exportfs?
how many network interfaces do you have?

Anything else that might be relevant.


> Ok, here's the problem I was trying to solve by using the latest CVS
> tree.
> When I try to NFS export an XFS filesystem, I get the following error:
>
> the_otherbox.com:/nfs: Invalid argument
>
> Note: This is ONLY with XFS filesystems. ext2 filesystems export fine.
>
> the setup:
>
> Mandrake 8.0 (still stock, except for the kernel munging, and the XFS
> filesystems
>
> Mandrake 2.4.3 kernel source + a patch made for that kernel.
>
> I've seen another individual here with the same problem, different
> distribution.
> Is anyone else running a 2.4.3 kernel with NFS exports working? Or have
> an idea of what's wrong?
>
>         Thanks in advance
>
>                 Ric


From owner-linux-xfs@oss.sgi.com Mon May  7 22:20:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f485Kx802174
	for linux-xfs-outgoing; Mon, 7 May 2001 22:20:59 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f485KwF02171
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 22:20:58 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f485KlmZ031147;
	Tue, 8 May 2001 00:20:47 -0500 (CDT)
Message-ID: <3AF78F90.1148B7CB@thebarn.com>
Date: Tue, 08 May 2001 01:17:52 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Owens <kaos@melbourne.sgi.com>
CC: Ric Tibbetts <ric@chadera.net>, Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile
References: <19772.989298868@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Owens wrote:

> On Tue, 08 May 2001 01:07:53 -0500,
> Russell Cattelan <cattelan@thebarn.com> wrote:
> >kgcc!
>
> He is already using gcc -V egcs-2.91.66 == kgcc.

Nope, that doesn't work on Mandrake 8.0 systems for some reason ,
previous version of Mandrake that worked fine.
I've been bitten by that every time the kernel is updated and I forget
to switch the Makefile back to kgcc.



From owner-linux-xfs@oss.sgi.com Mon May  7 23:16:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f486GK203176
	for linux-xfs-outgoing; Mon, 7 May 2001 23:16:20 -0700
Received: from tower.braxis.co.uk (root@pa7.solec.sdi.tpnet.pl [213.77.165.7])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f486GGF03173
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 23:16:16 -0700
Received: from localhost (wysek@localhost)
	by tower.braxis.co.uk (8.11.2/8.11.2) with ESMTP id f486Fpu26322
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:15:51 +0200
Date: Tue, 8 May 2001 08:15:51 +0200 (CEST)
From: Piotr Wysocki <wysek@tower.braxis.co.uk>
To: linux-xfs@oss.sgi.com
Subject: What about 2.4.5-pre1 ?
Message-ID: <Pine.LNX.4.21.0105080810430.26241-100000@tower.braxis.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everybody,
I'm interested in using XFS at my server, but I haven't found
2.4.5-pre1-xfs kernel..are there any patches ? Maybe there are already
patched kernel ? If not, I'll choose 2.4.3, not 2.4.4 because of the
fork()..
I was also looking for it on some ftp-sites..

-- 
  *--------"Being alive, you matter much more."--------*
 | Piotr Wysocki (wysek@tower.braxis.co.uk) [wysek/elk] |
 | telephone +48605 111115  | http://wysek.braxis.co.uk |
 | BLUG reg. member #0012   | Linux reg. member #207707 |


From owner-linux-xfs@oss.sgi.com Mon May  7 23:21:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f486LjF03343
	for linux-xfs-outgoing; Mon, 7 May 2001 23:21:45 -0700
Received: from femail4.sdc1.sfba.home.com (femail4.sdc1.sfba.home.com [24.0.95.84])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f486LjF03340
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 23:21:45 -0700
Received: from home.com ([24.5.216.111]) by femail4.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010508061841.YISX14836.femail4.sdc1.sfba.home.com@home.com>
          for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 23:18:41 -0700
Message-ID: <3AF78F27.6040001@home.com>
Date: Mon, 07 May 2001 23:16:07 -0700
From: Ron Wolfe <cruiserman@home.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686; en-US; 0.8.1) Gecko/20010425
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: kernel 2.4.4 and patching
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

i am using xfs with rh 7.1 and am  very pleased so far on my laptop.  i 
want to compile the latest kernel 2.4.4 and patch it with the xfs 
patchfiles.  I downloaded linux-2.4-xfs-1.0.patch.gz and the 
linux-2.4.3-core-xfs-1.0.patch.gz.  Will this 2.4.3 patch work on 2.4.4 
or do i need to stick with 2.4.3.  If i have to stick with 2.4.3 when do 
you expect a 2.4.4 patch.  Thank you for your time.

Ron Wolfe


From owner-linux-xfs@oss.sgi.com Mon May  7 23:46:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f486kfe03723
	for linux-xfs-outgoing; Mon, 7 May 2001 23:46:41 -0700
Received: from femail2.sdc1.sfba.home.com (femail2.sdc1.sfba.home.com [24.0.95.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f486kfF03720
	for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 23:46:41 -0700
Received: from home.com ([24.5.216.111]) by femail2.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010508064602.FKRE27407.femail2.sdc1.sfba.home.com@home.com>
          for <linux-xfs@oss.sgi.com>; Mon, 7 May 2001 23:46:02 -0700
Message-ID: <3AF794FA.4090807@home.com>
Date: Mon, 07 May 2001 23:40:58 -0700
From: Ron Wolfe <cruiserman@home.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686; en-US; 0.8.1) Gecko/20010425
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: patching 2.4.3
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

i just downloaded the patchfiles for 2.4.3 and after trying:
patch -p1 < linux-2.4.3-core-xfs-1.0.patch.gz

i immediately get:
patch unexpectedly ends in middle of line
patch:**** Only garbage was found in the patch input.

i also tried the linux-2.4-xfs-1.0.patch and i get a lot of jiberish fly 
by then it asks for file to patch: if i denote linux/ or linux-2.4.3 
then it says:
patch:****File /usr/src/linux is not a regular file -- cant open

any suggestions would be greatly appreciated.

Ron Wolfe


From owner-linux-xfs@oss.sgi.com Tue May  8 00:22:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f487Md804428
	for linux-xfs-outgoing; Tue, 8 May 2001 00:22:39 -0700
Received: from sati.virbus.de (mail.virbus.de [145.253.246.201])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f487MbF04425
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 00:22:37 -0700
Received: from sati.virbus.de (localhost [127.0.0.1])
	by sati.virbus.de (8.9.3/8.9.3) with ESMTP id JAA08422
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:22:25 +0200
Received: from vivasvat (saraswati.virbus.de [212.144.5.199])
	by sati.virbus.de (8.9.3/8.9.3) with SMTP id JAA08412;
	Tue, 8 May 2001 09:22:24 +0200
Reply-To: <apiesk@virbus.de>
From: "Andreas Piesk" <apiesk@virbus.de>
To: <ananth@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfs <-> kaio
Date: Tue, 8 May 2001 09:22:23 +0200
Message-ID: <31D95EFC91E3D311A57800105A4AF6751AF90B@cambio.virbus.de>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <31D95EFC91E3D311A57800105A4AF6752C15D3@cambio.virbus.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> I think the best solution is to move the KAIO syscall;
> you should be using the dynamically linked (.so) version
> of the KAIO library, so moving the syscall number should
> work out OK. I'll post new patches on KAIO soon (today
> if possible). Also, I'm curious to hear your experiences
> with Sybase + KAIO.
> 

i agree, moving the kaio syscalls would be the best solution.
but unfortunately, sybase-11.0.3.3 (the only one with aio support)
cannot use the new kaio-libs. they are using a somewhat outdated
version. if i remember right, the initialization failed.
if i'm on site (today evening), i will do some checks
and mail the result directly to ananth@sgi.com.

my experiences with kaio are good so far. i measured an improvement
of approx. 15% in my db-benchmarks (2 kaio-threads).
i'm using sybase-11.0.3.3 + rawio + kaio. 

ciao -ap


From owner-linux-xfs@oss.sgi.com Tue May  8 00:42:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f487giU05023
	for linux-xfs-outgoing; Tue, 8 May 2001 00:42:44 -0700
Received: from ibu.chadera.net ([63.145.197.180])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f487ghF05019
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 00:42:43 -0700
Received: from chadera.net (darkstar.keluarga.lan [192.168.100.2])
	by ibu.chadera.net (8.9.3/8.9.3) with ESMTP id AAA07984;
	Tue, 8 May 2001 00:42:12 -0700
Message-ID: <3AF7A34F.5B7C7D1C@chadera.net>
Date: Tue, 08 May 2001 00:42:07 -0700
From: Ric Tibbetts <ric@chadera.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-mdk+xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Keith Owens <kaos@melbourne.sgi.com>,
   Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile
References: <19772.989298868@kao2.melbourne.sgi.com> <3AF78F90.1148B7CB@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Keith Owens wrote:
> 
> > On Tue, 08 May 2001 01:07:53 -0500,
> > Russell Cattelan <cattelan@thebarn.com> wrote:
> > >kgcc!
> >
> > He is already using gcc -V egcs-2.91.66 == kgcc.
> 
> Nope, that doesn't work on Mandrake 8.0 systems for some reason ,
> previous version of Mandrake that worked fine.
> I've been bitten by that every time the kernel is updated and I forget
> to switch the Makefile back to kgcc.

On this box:
kgcc -v
Reading specs from
/usr/lib/gcc-lib/i586-mandrake-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release /
Linux-Mandrake 8.0)

gcc -v
Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.96/specs
gcc version 2.96 20000731 (Linux-Mandrake 8.0 2.96-0.48mdk)


This is a stock, straight off the CD Mandrake 8.0 box (except for the
kernel).
Also, you'll notice that when it was compiling, it WAS using kgcc:

The original error message:

gcc -V egcs-2.91.66 -D__ASSEMBLY__ -D__KERNEL__
-I/usr/src/linux/include  -traditional
-c head.S -o head.o
head.S:203: unterminated character constant
make[1]: *** [head.o] Error 1
make[1]: Leaving directory
`/usr/src/linux-2.4-xfs-r1.0/linux/arch/i386/kernel'
make: *** [_dir_arch/i386/kernel] Error 2

I can switch the Makefile, and try it, but it looks like it's already
using that version.

	Ric

From owner-linux-xfs@oss.sgi.com Tue May  8 01:08:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48882B06090
	for linux-xfs-outgoing; Tue, 8 May 2001 01:08:02 -0700
Received: from ibu.chadera.net ([63.145.197.180])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48881F06086
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 01:08:01 -0700
Received: from chadera.net (darkstar.keluarga.lan [192.168.100.2])
	by ibu.chadera.net (8.9.3/8.9.3) with ESMTP id BAA08026;
	Tue, 8 May 2001 01:07:32 -0700
Message-ID: <3AF7A93F.840764AD@chadera.net>
Date: Tue, 08 May 2001 01:07:27 -0700
From: Ric Tibbetts <ric@chadera.net>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-mdk+xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Keith Owens <kaos@melbourne.sgi.com>,
   Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: CVS v1.0 kernel won't compile
References: <19772.989298868@kao2.melbourne.sgi.com> <3AF78F90.1148B7CB@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Keith Owens wrote:
> 
> > On Tue, 08 May 2001 01:07:53 -0500,
> > Russell Cattelan <cattelan@thebarn.com> wrote:
> > >kgcc!
> >
> > He is already using gcc -V egcs-2.91.66 == kgcc.
> 
> Nope, that doesn't work on Mandrake 8.0 systems for some reason ,
> previous version of Mandrake that worked fine.
> I've been bitten by that every time the kernel is updated and I forget
> to switch the Makefile back to kgcc.


And the verdict is:
That solved the compile problem. I changed the Makefile to kgcc (even
though it reported that it was using that version anyway), and
"voila!".. It built without error.

Can anyone explain that one? :)

	Thanks!

	Ric

Now if we can solve the NFS problem. 
	Tomorrow. It's too late for that tonight..

From owner-linux-xfs@oss.sgi.com Tue May  8 01:24:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f488Omv06580
	for linux-xfs-outgoing; Tue, 8 May 2001 01:24:48 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f488OkF06576
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 01:24:47 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f488OZK32627;
	Tue, 8 May 2001 10:24:35 +0200
Message-Id: <4.3.2.7.2.20010508101840.0377bfb8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 08 May 2001 10:24:44 +0200
To: Tom Duffy <tduffy@engr.sgi.com>,
   Simon Matter <simon.matter@ch.sauter-bc.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: XFS RedHat installer
Cc: <linux-xfs@oss.sgi.com>
In-Reply-To: <Pine.LNX.4.30.0105072041330.25517-100000@dbear.engr.sgi.co
 m>
References: <3AF63A3B.2C296D1A@ch.sauter-bc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 20:47 7-5-2001 -0700, Tom Duffy wrote:
> > 1) Boot floppy:
> > When doing a mkbootdisk 2.4.2-xxxxx I saw that the content couldn't
> > fit on the disk. Then I tried the following:
> > fdformat /dev/fd0u1722
> > mkbootdisk --device /dev/fd0u1722 2.4.2-xxxxx
> > The disk was created successfully but unfortunately it didn't boot
> > anyway. I guess it is a problem with the used 'syslinux'. Did
> > you try something like this ?
>
>unfortunately, you cannot boot off of a superformatted floppy...this is a
>limitation of the BIOS.

What bios?? I can booted super formatted floppy's for my linuxrouter 
machine at home on a old 486PC which are 1680 I believe.
I have encountered one machine with a external drives that would not boot 
these floppies. A toshiba with an external drive (portege 7800).

So I have good succes with that. I believe they also succeeded in making a 
2.88MB bootable cdrom ;-) Information about that should be somewhere in the 
archives. I am not 100% sure though.

Bye

--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Tue May  8 02:51:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f489p4e08891
	for linux-xfs-outgoing; Tue, 8 May 2001 02:51:04 -0700
Received: from jxmls04.se.mediaone.net (jxmls04.se.mediaone.net [24.129.0.51])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f489p3F08888
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 02:51:03 -0700
Received: from enterprise (rr-163-49-194.atl.mediaone.net [24.163.49.194])
	by jxmls04.se.mediaone.net (8.11.1/8.11.1) with SMTP id f489oTX20979;
	Tue, 8 May 2001 05:50:29 -0400 (EDT)
Reply-To: <JHamilton@Earthling.Net>
From: "Justin Hamilton" <JHamilton2000@MediaOne.Net>
To: "Ron Wolfe" <cruiserman@home.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: patching 2.4.3
Date: Tue, 8 May 2001 05:50:25 -0400
Message-ID: <LDEDJPMKHIOLPMHDAKLFGEBOIDAA.JHamilton2000@MediaOne.Net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
In-reply-to: <3AF794FA.4090807@home.com>
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

You need to gunzip,then patch:

gunzip -cd linux-2.4.3-core-xfs-1.0.patch.gz | patch -p1

Justin

-----Original Message-----
From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On
Behalf Of Ron Wolfe
Sent: Tuesday, May 08, 2001 2:41 AM
To: linux-xfs@oss.sgi.com
Subject: patching 2.4.3


i just downloaded the patchfiles for 2.4.3 and after trying:
patch -p1 < linux-2.4.3-core-xfs-1.0.patch.gz

i immediately get:
patch unexpectedly ends in middle of line
patch:**** Only garbage was found in the patch input.

i also tried the linux-2.4-xfs-1.0.patch and i get a lot of jiberish fly 
by then it asks for file to patch: if i denote linux/ or linux-2.4.3 
then it says:
patch:****File /usr/src/linux is not a regular file -- cant open

any suggestions would be greatly appreciated.

Ron Wolfe



From owner-linux-xfs@oss.sgi.com Tue May  8 02:51:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f489pID08913
	for linux-xfs-outgoing; Tue, 8 May 2001 02:51:18 -0700
Received: from sisa.i-manila.com.ph ([208.155.152.18])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f489pHF08909
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 02:51:17 -0700
Received: from kalapati ([203.167.1.146]) by sisa.i-manila.com.ph ; Tue, 08 May 2001 17:51:18 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id AB50E177F
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 17:48:42 +0800 (PHT)
Date: Tue, 8 May 2001 17:48:42 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: kernel 2.4.4 and patching
In-Reply-To: <3AF78F27.6040001@home.com>
Message-ID: <Pine.LNX.4.21.0105081747300.2456-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 7 May 2001 at 23:16, Ron Wolfe wrote:
> i want to compile the latest kernel 2.4.4 and patch it with the xfs
> patchfiles.  I downloaded linux-2.4-xfs-1.0.patch.gz and the
> linux-2.4.3-core-xfs-1.0.patch.gz.  Will this 2.4.3 patch work on
> 2.4.4 or do i need to stick with 2.4.3.  If i have to stick with 2.4.3
> when do you expect a 2.4.4 patch.  Thank you for your time.

I don't think the patch for the 2.4.3 kernel will work with 2.4.4. AFAIK
you will have to use the development tree for that, and a recent message
from Steve Lord with the subject "Linux 2.4.4 + xfs" looks like he doesn't
recommend XFS with Linux 2.4.4 for the faint of heart just yet because of
certain issues that have to be ironed out first.

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Tue May  8 02:51:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f489pJV08922
	for linux-xfs-outgoing; Tue, 8 May 2001 02:51:19 -0700
Received: from sisa.i-manila.com.ph ([208.155.152.18])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f489pIF08914
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 02:51:18 -0700
Received: from kalapati ([203.167.1.146]) by sisa.i-manila.com.ph ; Tue, 08 May 2001 17:47:21 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 9E0442C2C
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 17:45:22 +0800 (PHT)
Date: Tue, 8 May 2001 17:45:22 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: XFS and small files (was: Great!)
In-Reply-To: <004001c0d752$4dc3edb0$0a4aa8c0@xhmul.net>
Message-ID: <Pine.LNX.4.21.0105081743030.2456-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 8 May 2001 at 02:03, Carl Rueder wrote:
> Therefore the work with many files within a directory isn't slowed
> down by walking through a list. But, why is ReiserFS a few times
> faster than xfs when working in a directory which contains about
> 100.000 small files (about 1k in size)? Where's my gap in
> understanding this phenomenon?

This looks like an important issue to find (1) proof of, and (2) answers
for. If indeed ReiserFS performs better than XFS on directories with small
files, the former filesystem would be a better solution speedwise for the
likes of Maildirs, where mail is stored in individual small files versus
in a single large mbox-type file.

Perhaps an expert in the list could help out with answers?

Thanks in advance!

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Tue May  8 02:51:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f489pLe08932
	for linux-xfs-outgoing; Tue, 8 May 2001 02:51:21 -0700
Received: from sisa.i-manila.com.ph ([208.155.152.18])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f489pJF08926
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 02:51:20 -0700
Received: from kalapati ([203.167.1.146]) by sisa.i-manila.com.ph ; Tue, 08 May 2001 17:47:21 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 896F1177F
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 17:42:02 +0800 (PHT)
Date: Tue, 8 May 2001 17:42:02 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Errors using amanda/xfsdump
In-Reply-To: <Pine.BSF.4.33.0105071558590.43788-100000@rogue.tripp.org>
Message-ID: <Pine.LNX.4.21.0105081734340.2456-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f489pKF08930
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, this is a little late and not particularly XFS-specific but ...

> The machine is a Dual 500 MHz PIII, and the filesystems run on top of
> the 3ware IDE raid card with 4 46G disks running in RAID level 5.  
> (138G filesystem available...)  The XFS is the 2.4.3 version from
> April 5th.

3Ware sent me an e-mail about a problem they found with their Escalade
6400 controllers, RAID 5, and ext2. Their e-mail did not have conclusive
information on any other filesystem, but I'm thinking that XFS could be
affected, too. I "dirty hack" seems to be to mount the ext2 partition with
the sync option. Maybe XFS treats a disk in a similar manner, making XFS
"immune"?

Anywa, until a patch comes out (expected somewhere around May 15) for
their software, RAID 5 looks iffy. Or does it?

Here is a copy of the e-mail I got for whatever it's worth. :)

 --> Jijo

---------- Forwarded message ----------
Date: Wed, 2 May 2001 09:24:15 -0700
From: Mike Wentz <mike.wentz@3ware.com>
Subject: 3ware Technical Bulletin concerning RAID 5

             Important Technical Bulletin


Dear customer,

You are receiving this email because you are a registered
owner of a 3ware Escalade 6400 Series Storage
Switch, or you have opened a Tech Support case with 3ware
on a 6400, 6410 or 6800 Series Escalade Storage Switch.

3ware has found a bug in our RAID 5 code that can cause file
system errors resulting in possible loss of data. This
problem has only been experienced on Linux operating systems
running the default ext2 file system, however, other file
systems may be affected.

Products affected:           Escalade 6400, 6410 and 6800
Software Versions affected:  6.5 and 6.6
RAID level affected:         RAID 5
Operating systems affected:    
                  Known:     Linux with default ext2 file
                             system
                  Possible:  Win98/ME, WinNT, Win2000

************************************************************

Symptoms:
1. 3ware BIOS VERIFY command reports VERIFY Failed.
2. Linux fsck -vf command returns inode and/or superblock
   errors when run while the array is in degraded mode.
3. Windows chkdsk command returns errors on the MFT
   (Master File Table).

************************************************************

Problem description:
1. In Linux, the RAID 5 parity data can get corrupted during
   writes.
2. On Microsoft operating systems, parity and/or user data
   can get corrupted during writes.

************************************************************

Is my data corrupted?
There are two factors that determine whether or not your
data is affected:
1. Whether or not the array has ever degraded
2. Which operating system you are using

If the array has never degraded, then the data should be
fine.

If the array has degraded, then there is a potential that
your data is affected. In most cases, the operating system
will detect the errors and correct them. It is possible,
however, that the operating system cannot detect and correct
all the errors, in which case you will need to restore from
backup.

To date, this problem has only been seen on Linux operating
systems running the ext2 default file system.

3ware has not yet found an instance where user data on a
Microsoft operating system has been affected, however, it is
theoretically possible.

************************************************************
I'm using RAID 5, what should I do?
Depending on your operating system and the state of the
array, the following actions are recommended:

Linux:

If the RAID 5 has never degraded there are two choices:
1. Reconfigure the array to RAID 1 or RAID 10.
2. Mount the file system in synchronous mode. Synchronous
   mode will prevent the parity data from being affected,
   thereby eliminating the problem. Please note that there
   is a significant performance penalty.
 
                  Command syntax:
mount -t ext2 /dev/device_node /mountpoint -o sync

If the array has degraded run fsck to repair damaged data.
1. If the repair completes successfully, you may either
   convert the array to RAID 1 or RAID 10, or run the file
   system in synchronous mode.
2. If the repair is unsuccessful, you will need to restore
   from backup.

Microsoft NT, 98, ME or 2000:

If the RAID 5 array has never degraded you should
reconfigure the array to RAID 1 or RAID 10.

If the array has degraded, run chkdsk /R to repair damaged
data.
1. If the repair completes successfully, reconfigure the
   array to RAID 1 or RAID 10.
2. If the repair is unsuccessful, you will need to restore
   from backup.

************************************************************

What happens if I stay on RAID 5?
1. 3ware does not recommend using RAID 5 on any Microsoft
   operating system at this time.
2. If you are running Linux and wish to remain on RAID 5,
   3ware recommends you mount the file system in synchronous
   mode.

************************************************************

When will a RAID 5 fix be available?
1. 3ware has identified the cause of the problem and
   developed a fix. We are in the process of testing to
   insure that it completely corrects the problem. We
   anticipate having the fix available on or before
   May 15, 2001.
2. If you would like to register to be notified when the
   fix is available please click here:   
   http://www.3ware.com/support/contact3wareraid5.asp

3ware regrets any inconvenience this problem may cause you.

Sincerely
Michael L. Wentz
Director, Customer Service (650.269.2977)


From owner-linux-xfs@oss.sgi.com Tue May  8 03:28:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48AS7S09845
	for linux-xfs-outgoing; Tue, 8 May 2001 03:28:07 -0700
Received: from smtp-relay.noc.dsvr.net (smtp-relay.noc.dsvr.net [212.69.192.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48AS6F09842
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 03:28:06 -0700
Received: from [212.69.210.21] (helo=dsvr.net)
	by smtp-relay.noc.dsvr.net with esmtp (Exim 3.16 #1)
	id 14x4il-000GgA-00
	for linux-xfs@oss.sgi.com; Tue, 08 May 2001 11:27:59 +0100
Message-ID: <3AF7D7DD.4E1D3934@dsvr.net>
Date: Tue, 08 May 2001 12:26:21 +0100
From: rob <rob@dsvr.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: linux/xfs mount problem - 512byte cluster size
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've checked out 2.4.4-xfs  from cvs (i think this is the head branch)
as I need to desperately access an Octane drives.

The problem is the Octane has been formatted with a cluster size of 512
bytes and the xfs driver for linux seems to only support 4096 bytes and
therefore wont mount it.

Any info on support for variable cluster sizes the driver supports ?

Error reported by mount :

XFS: Trying to mount file system with blocksize 512 bytes
XFS: Only page-sized (4096 bytes) blocksize currently works.
XFS: SB validate failed


Best regards

Rob Fielding.
rob@dsvr.net



From owner-linux-xfs@oss.sgi.com Tue May  8 04:24:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48BOMS11137
	for linux-xfs-outgoing; Tue, 8 May 2001 04:24:22 -0700
Received: from his4200.hytec.co.uk (mailserv.hytec.co.uk [195.166.97.153])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48BOLF11134
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 04:24:21 -0700
Received: by his4200.hytec.co.uk with Internet Mail Service (5.5.2650.21)
	id <JCGP58WD>; Tue, 8 May 2001 12:24:14 +0100
Message-ID: <C119E2EA562DD31193CE00105A41D05A384C2A@his4200.hytec.co.uk>
From: Derrick Llewelyn <Derrick.Llewelyn@hytec.co.uk>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Failed to Boot
Date: Tue, 8 May 2001 12:24:08 +0100 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I am installing on an Intel 2150 with an Adaptec AIC 7896N SCSI controller
on the motherboard.

Your installer works very well and I can do a network installation - however
on rebooting the machine, the AIC7xxx module times out and the machine never
gets past this stage.

Any advice would be appreciated.


Derrick Llewelyn
Software Engineer
Hytec Information Systems
Eynsham, Oxon



Email Disclaimer
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. You may use and apply
this information only for its intended purpose. When addressed to our
clients any opinions or advice or quotations contained in this email are
subject to the Hytec standard terms and conditions. Neither Hytec nor the
sender accepts responsibility for viruses. It is your responsibility to scan
the email and any attachments. 


From owner-linux-xfs@oss.sgi.com Tue May  8 05:15:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48CFDR13081
	for linux-xfs-outgoing; Tue, 8 May 2001 05:15:13 -0700
Received: from server.hpc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48CFCF13078
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 05:15:12 -0700
Received: from harrar.hpc.utexas.edu (harrar.hpc.utexas.edu [129.116.218.194])
	by server.hpc.utexas.edu (8.11.2/8.11.0) with ESMTP id f48CF2J01181;
	Tue, 8 May 2001 07:15:03 -0500
Message-Id: <5.0.2.1.2.20010508070815.02046278@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Tue, 08 May 2001 07:15:13 -0500
To: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: Re: kernel 2.4.4 and patching
In-Reply-To: <Pine.LNX.4.21.0105081747300.2456-100000@kalapati.jijo.loca
 l>
References: <3AF78F27.6040001@home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


If you running with the linux-2.4.4 development source you should think about
appling the linux-2.4.5-pre1 patch to it.   It backs out some change to fork
that caused some process hangs under linux-2.4.4.


Bill Jones


From owner-linux-xfs@oss.sgi.com Tue May  8 05:27:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48CRcX13417
	for linux-xfs-outgoing; Tue, 8 May 2001 05:27:38 -0700
Received: from sisinteli07.udg.es (sisinteli07.udg.es [130.206.125.95])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48CRYF13412
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 05:27:35 -0700
Received: from gcs by sisinteli07.udg.es with local (Exim 3.22 #1 (Debian))
	id 14x6Yl-0008GJ-00
	for <linux-xfs@oss.sgi.com>; Tue, 08 May 2001 14:25:47 +0200
Date: Tue, 8 May 2001 14:25:46 +0200
From: GCS <gcs@agentsinside.com>
To: linux-xfs@oss.sgi.com
Subject: Re: Tuning XFS for peak performance. (fwd)
Message-ID: <20010508142546.A31442@sisinteli07.udg.es>
References: <Pine.LNX.4.33.0105061710360.3947-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <Pine.LNX.4.33.0105061710360.3947-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Sun, May 06, 2001 at 05:11:00PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Austin,

On Sun, May 06, 2001 at 05:11:00PM -0500, Austin Gonyou wrote:

> While stable, it doesn't do
> me any good if I have to wait 5 mins for PINE to open when it's only
> moving a few messages from inbox to other boxes. The same operation would
> take 30 seconds with ReiserFS.
 Personaly I do not think it is a problem with XFS. First, please check
your drive with "hdparm -t /dev/hda" (I suppose it is hda in your
machine). Maybe you compiled your kernel without proper DMA support on
the IDE bus or just does not set it up with hdparm. For me ReiserFS and
XFS gives the same performance more or less.
 (In brackets: pine is slooow, and has more holes than a cheese has.
Change to mutt, it performs mailbox operations much more faster, etc).

Regards, Laszlo

From owner-linux-xfs@oss.sgi.com Tue May  8 06:35:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48DZ0E15603
	for linux-xfs-outgoing; Tue, 8 May 2001 06:35:00 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48DYxF15600
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 06:34:59 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f48DYqD04538;
	Tue, 8 May 2001 08:34:52 -0500 (CDT)
Message-ID: <3AF7F674.388891@sgi.com>
Date: Tue, 08 May 2001 08:36:52 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@dsvr.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte cluster size
References: <3AF7D7DD.4E1D3934@dsvr.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Rob - 

XFS for Linux only supports block sizes that are the same as the size of
a memory page.  On ia32 systems, this means a 4k blocksize.

Support for other block sizes is on the TODO list, but at this point,
you will not be able to mount an XFS filesystem with 512k blocks.

xfsdump/xfsrestore is one option to get the data from your Octane onto a
Linux XFS filesystem.

-Eric

rob wrote:

> I've checked out 2.4.4-xfs  from cvs (i think this is the head branch)
> as I need to desperately access an Octane drives.
> 
> The problem is the Octane has been formatted with a cluster size of 512
> bytes and the xfs driver for linux seems to only support 4096 bytes and
> therefore wont mount it.
> 
> Any info on support for variable cluster sizes the driver supports ?
> 
> Error reported by mount :
> 
> XFS: Trying to mount file system with blocksize 512 bytes
> XFS: Only page-sized (4096 bytes) blocksize currently works.
> XFS: SB validate failed


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 06:35:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48DZIE15618
	for linux-xfs-outgoing; Tue, 8 May 2001 06:35:18 -0700
Received: from rogue.tripp.org (fdsl9.slkc.uswest.net [209.181.83.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48DZGF15614
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 06:35:16 -0700
Received: from localhost (justin@localhost)
	by rogue.tripp.org (8.9.3/8.9.3) with ESMTP id HAA51936;
	Tue, 8 May 2001 07:35:03 -0600 (MDT)
	(envelope-from justin@tripp.org)
Date: Tue, 8 May 2001 07:35:03 -0600 (MDT)
From: Justin Tripp <justin@tripp.org>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Errors using amanda/xfsdump
In-Reply-To: <Pine.LNX.4.21.0105081734340.2456-100000@kalapati.jijo.local>
Message-ID: <Pine.BSF.4.33.0105080720100.51666-100000@rogue.tripp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f48DZHF15615
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I do not believe this is the problem.  For the RAID 5 failure to occur,
one must run the raid in degraded mode (e.g. with a disk failed.)  My raid
has not run in the degraded mode, so according to them, it is not a
problem.  My own observations seem indicate that there may be a problem
with XFS.

I have already been able to sucessfully backup the drives before I
exported them via NFS and started running NNTP spools across the NFS
exports.  It seems to be the way, I am using the drives that causes the
failure.  If I start the NNTP daemons running across the file system
(examining articles to see what ones exist and how old they are) as
a backup is going, it seems to consistently fail.  The oops says that it
occurs in xfsdump and the software trace seems to indicate it was the XFS
code that attempted to dereference a NULL pointer.  So, I am led to
believe that the problem may lie in XFS.  I could be convinced to
re-arrange the array (since it currently has no real data anyway), but I
currently do not believe that it will make a difference.


				.justin.

------------------------------------------------------------------------
Justin Leonard Tripp                                   justin@ee.byu.edu
Configurable Computing Laboratory Research Assistant      CB 461 x8-7206
Electrical and Computer Engineering Department  Brigham Young University

On Tue, 8 May 2001, Federico Sevilla III wrote:

> Hi, this is a little late and not particularly XFS-specific but ...
>
> > The machine is a Dual 500 MHz PIII, and the filesystems run on top of
> > the 3ware IDE raid card with 4 46G disks running in RAID level 5.
> > (138G filesystem available...)  The XFS is the 2.4.3 version from
> > April 5th.
>
> 3Ware sent me an e-mail about a problem they found with their Escalade
> 6400 controllers, RAID 5, and ext2. Their e-mail did not have conclusive
> information on any other filesystem, but I'm thinking that XFS could be
> affected, too. I "dirty hack" seems to be to mount the ext2 partition with
> the sync option. Maybe XFS treats a disk in a similar manner, making XFS
> "immune"?
>
> Anywa, until a patch comes out (expected somewhere around May 15) for
> their software, RAID 5 looks iffy. Or does it?
>
> Here is a copy of the e-mail I got for whatever it's worth. :)
>
>  --> Jijo
>
> ---------- Forwarded message ----------
> Date: Wed, 2 May 2001 09:24:15 -0700
> From: Mike Wentz <mike.wentz@3ware.com>
> Subject: 3ware Technical Bulletin concerning RAID 5
>
>              Important Technical Bulletin
>
>
> Dear customer,
>
> You are receiving this email because you are a registered
> owner of a 3ware Escalade 6400 Series Storage
> Switch, or you have opened a Tech Support case with 3ware
> on a 6400, 6410 or 6800 Series Escalade Storage Switch.
>
> 3ware has found a bug in our RAID 5 code that can cause file
> system errors resulting in possible loss of data. This
> problem has only been experienced on Linux operating systems
> running the default ext2 file system, however, other file
> systems may be affected.
>
> Products affected:           Escalade 6400, 6410 and 6800
> Software Versions affected:  6.5 and 6.6
> RAID level affected:         RAID 5
> Operating systems affected:    
>                   Known:     Linux with default ext2 file
>                              system
>                   Possible:  Win98/ME, WinNT, Win2000
>
> ************************************************************
>
> Symptoms:
> 1. 3ware BIOS VERIFY command reports VERIFY Failed.
> 2. Linux fsck -vf command returns inode and/or superblock
>    errors when run while the array is in degraded mode.
> 3. Windows chkdsk command returns errors on the MFT
>    (Master File Table).
>
> ************************************************************
>
> Problem description:
> 1. In Linux, the RAID 5 parity data can get corrupted during
>    writes.
> 2. On Microsoft operating systems, parity and/or user data
>    can get corrupted during writes.
>
> ************************************************************
>
> Is my data corrupted?
> There are two factors that determine whether or not your
> data is affected:
> 1. Whether or not the array has ever degraded
> 2. Which operating system you are using
>
> If the array has never degraded, then the data should be
> fine.
>
> If the array has degraded, then there is a potential that
> your data is affected. In most cases, the operating system
> will detect the errors and correct them. It is possible,
> however, that the operating system cannot detect and correct
> all the errors, in which case you will need to restore from
> backup.
>
> To date, this problem has only been seen on Linux operating
> systems running the ext2 default file system.
>
> 3ware has not yet found an instance where user data on a
> Microsoft operating system has been affected, however, it is
> theoretically possible.
>
> ************************************************************
> I'm using RAID 5, what should I do?
> Depending on your operating system and the state of the
> array, the following actions are recommended:
>
> Linux:
>
> If the RAID 5 has never degraded there are two choices:
> 1. Reconfigure the array to RAID 1 or RAID 10.
> 2. Mount the file system in synchronous mode. Synchronous
>    mode will prevent the parity data from being affected,
>    thereby eliminating the problem. Please note that there
>    is a significant performance penalty.
>  
>                   Command syntax:
> mount -t ext2 /dev/device_node /mountpoint -o sync
>
> If the array has degraded run fsck to repair damaged data.
> 1. If the repair completes successfully, you may either
>    convert the array to RAID 1 or RAID 10, or run the file
>    system in synchronous mode.
> 2. If the repair is unsuccessful, you will need to restore
>    from backup.
>
> Microsoft NT, 98, ME or 2000:
>
> If the RAID 5 array has never degraded you should
> reconfigure the array to RAID 1 or RAID 10.
>
> If the array has degraded, run chkdsk /R to repair damaged
> data.
> 1. If the repair completes successfully, reconfigure the
>    array to RAID 1 or RAID 10.
> 2. If the repair is unsuccessful, you will need to restore
>    from backup.
>
> ************************************************************
>
> What happens if I stay on RAID 5?
> 1. 3ware does not recommend using RAID 5 on any Microsoft
>    operating system at this time.
> 2. If you are running Linux and wish to remain on RAID 5,
>    3ware recommends you mount the file system in synchronous
>    mode.
>
> ************************************************************
>
> When will a RAID 5 fix be available?
> 1. 3ware has identified the cause of the problem and
>    developed a fix. We are in the process of testing to
>    insure that it completely corrects the problem. We
>    anticipate having the fix available on or before
>    May 15, 2001.
> 2. If you would like to register to be notified when the
>    fix is available please click here:   
>    http://www.3ware.com/support/contact3wareraid5.asp
>
> 3ware regrets any inconvenience this problem may cause you.
>
> Sincerely
> Michael L. Wentz
> Director, Customer Service (650.269.2977)
>
>


From owner-linux-xfs@oss.sgi.com Tue May  8 06:40:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48DeDb15731
	for linux-xfs-outgoing; Tue, 8 May 2001 06:40:13 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48DeBF15728
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 06:40:11 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA07570
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 06:51:00 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1729155; Tue, 8 May 2001 08:38:53 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA17345; Tue, 8 May 2001 08:38:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f48Dffq03576; Tue, 8 May 2001 08:41:42 -0500
Message-Id: <200105081341.f48Dffq03576@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Justin Tripp <justin@tripp.org>
cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Errors using amanda/xfsdump 
In-Reply-To: Message from Justin Tripp <justin@tripp.org> 
   of "Tue, 08 May 2001 07:35:03 MDT." <Pine.BSF.4.33.0105080720100.51666-100000@rogue.tripp.org> 
Content-Transfer-Encoding: 8bit
Date: Tue, 08 May 2001 08:41:41 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Justin, you are correct, you have found a scenario which xfs cannot always
cope with - in fact there is a deliberate panic in there. This will only
be triggered by the combination of NFS and local access to xfs - and probably
very heavy access at that. This is going to take some design work to fix.

Steve

> 
> I do not believe this is the problem.  For the RAID 5 failure to occur,
> one must run the raid in degraded mode (e.g. with a disk failed.)  My raid
> has not run in the degraded mode, so according to them, it is not a
> problem.  My own observations seem indicate that there may be a problem
> with XFS.
> 
> I have already been able to sucessfully backup the drives before I
> exported them via NFS and started running NNTP spools across the NFS
> exports.  It seems to be the way, I am using the drives that causes the
> failure.  If I start the NNTP daemons running across the file system
> (examining articles to see what ones exist and how old they are) as
> a backup is going, it seems to consistently fail.  The oops says that it
> occurs in xfsdump and the software trace seems to indicate it was the XFS
> code that attempted to dereference a NULL pointer.  So, I am led to
> believe that the problem may lie in XFS.  I could be convinced to
> re-arrange the array (since it currently has no real data anyway), but I
> currently do not believe that it will make a difference.
> 
> 
> 				.justin.
> 
> ------------------------------------------------------------------------
> Justin Leonard Tripp                                   justin@ee.byu.edu
> Configurable Computing Laboratory Research Assistant      CB 461 x8-7206
> Electrical and Computer Engineering Department  Brigham Young University
> 
> On Tue, 8 May 2001, Federico Sevilla III wrote:
> 
> > Hi, this is a little late and not particularly XFS-specific but ...
> >
> > > The machine is a Dual 500 MHz PIII, and the filesystems run on top of
> > > the 3ware IDE raid card with 4 46G disks running in RAID level 5.
> > > (138G filesystem available...)  The XFS is the 2.4.3 version from
> > > April 5th.
> >
> > 3Ware sent me an e-mail about a problem they found with their Escalade
> > 6400 controllers, RAID 5, and ext2. Their e-mail did not have conclusive
> > information on any other filesystem, but I'm thinking that XFS could be
> > affected, too. I "dirty hack" seems to be to mount the ext2 partition with
> > the sync option. Maybe XFS treats a disk in a similar manner, making XFS
> > "immune"?
> >
> > Anywa, until a patch comes out (expected somewhere around May 15) for
> > their software, RAID 5 looks iffy. Or does it?
> >
> > Here is a copy of the e-mail I got for whatever it's worth. :)
> >
> >  --> Jijo
> >
> > ---------- Forwarded message ----------
> > Date: Wed, 2 May 2001 09:24:15 -0700
> > From: Mike Wentz <mike.wentz@3ware.com>
> > Subject: 3ware Technical Bulletin concerning RAID 5
> >
> >              Important Technical Bulletin
> >
> >
> > Dear customer,
> >
> > You are receiving this email because you are a registered
> > owner of a 3ware Escalade 6400 Series Storage
> > Switch, or you have opened a Tech Support case with 3ware
> > on a 6400, 6410 or 6800 Series Escalade Storage Switch.
> >
> > 3ware has found a bug in our RAID 5 code that can cause file
> > system errors resulting in possible loss of data. This
> > problem has only been experienced on Linux operating systems
> > running the default ext2 file system, however, other file
> > systems may be affected.
> >
> > Products affected:           Escalade 6400, 6410 and 6800
> > Software Versions affected:  6.5 and 6.6
> > RAID level affected:         RAID 5
> > Operating systems affected:    
> >                   Known:     Linux with default ext2 file
> >                              system
> >                   Possible:  Win98/ME, WinNT, Win2000
> >
> > ************************************************************
> >
> > Symptoms:
> > 1. 3ware BIOS VERIFY command reports VERIFY Failed.
> > 2. Linux fsck -vf command returns inode and/or superblock
> >    errors when run while the array is in degraded mode.
> > 3. Windows chkdsk command returns errors on the MFT
> >    (Master File Table).
> >
> > ************************************************************
> >
> > Problem description:
> > 1. In Linux, the RAID 5 parity data can get corrupted during
> >    writes.
> > 2. On Microsoft operating systems, parity and/or user data
> >    can get corrupted during writes.
> >
> > ************************************************************
> >
> > Is my data corrupted?
> > There are two factors that determine whether or not your
> > data is affected:
> > 1. Whether or not the array has ever degraded
> > 2. Which operating system you are using
> >
> > If the array has never degraded, then the data should be
> > fine.
> >
> > If the array has degraded, then there is a potential that
> > your data is affected. In most cases, the operating system
> > will detect the errors and correct them. It is possible,
> > however, that the operating system cannot detect and correct
> > all the errors, in which case you will need to restore from
> > backup.
> >
> > To date, this problem has only been seen on Linux operating
> > systems running the ext2 default file system.
> >
> > 3ware has not yet found an instance where user data on a
> > Microsoft operating system has been affected, however, it is
> > theoretically possible.
> >
> > ************************************************************
> > I'm using RAID 5, what should I do?
> > Depending on your operating system and the state of the
> > array, the following actions are recommended:
> >
> > Linux:
> >
> > If the RAID 5 has never degraded there are two choices:
> > 1. Reconfigure the array to RAID 1 or RAID 10.
> > 2. Mount the file system in synchronous mode. Synchronous
> >    mode will prevent the parity data from being affected,
> >    thereby eliminating the problem. Please note that there
> >    is a significant performance penalty.
> >  
> >                   Command syntax:
> > mount -t ext2 /dev/device_node /mountpoint -o sync
> >
> > If the array has degraded run fsck to repair damaged data.
> > 1. If the repair completes successfully, you may either
> >    convert the array to RAID 1 or RAID 10, or run the file
> >    system in synchronous mode.
> > 2. If the repair is unsuccessful, you will need to restore
> >    from backup.
> >
> > Microsoft NT, 98, ME or 2000:
> >
> > If the RAID 5 array has never degraded you should
> > reconfigure the array to RAID 1 or RAID 10.
> >
> > If the array has degraded, run chkdsk /R to repair damaged
> > data.
> > 1. If the repair completes successfully, reconfigure the
> >    array to RAID 1 or RAID 10.
> > 2. If the repair is unsuccessful, you will need to restore
> >    from backup.
> >
> > ************************************************************
> >
> > What happens if I stay on RAID 5?
> > 1. 3ware does not recommend using RAID 5 on any Microsoft
> >    operating system at this time.
> > 2. If you are running Linux and wish to remain on RAID 5,
> >    3ware recommends you mount the file system in synchronous
> >    mode.
> >
> > ************************************************************
> >
> > When will a RAID 5 fix be available?
> > 1. 3ware has identified the cause of the problem and
> >    developed a fix. We are in the process of testing to
> >    insure that it completely corrects the problem. We
> >    anticipate having the fix available on or before
> >    May 15, 2001.
> > 2. If you would like to register to be notified when the
> >    fix is available please click here:   
> >    http://www.3ware.com/support/contact3wareraid5.asp
> >
> > 3ware regrets any inconvenience this problem may cause you.
> >
> > Sincerely
> > Michael L. Wentz
> > Director, Customer Service (650.269.2977)
> >
> >



From owner-linux-xfs@oss.sgi.com Tue May  8 06:48:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Dmi815897
	for linux-xfs-outgoing; Tue, 8 May 2001 06:48:44 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48DmhF15893
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 06:48:43 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f48Dmg709312;
	Tue, 8 May 2001 08:48:42 -0500 (CDT)
Message-ID: <3AF7F9B3.5DA9AD9A@sgi.com>
Date: Tue, 08 May 2001 08:50:43 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Tuning XFS for peak performance. (fwd)
References: <Pine.LNX.4.33.0105061710360.3947-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:

> While stable, it doesn't do
> me any good if I have to wait 5 mins for PINE to open when it's only
> moving a few messages from inbox to other boxes. The same operation would
> take 30 seconds with ReiserFS.

This may be yet another issue with the default i/o size and databases. 
(we've seen this for rpm databases and sendmail access.db)

I don't know for sure how pine uses gdbm, but I see that it is a
requirement, so this is the likely culprit.

Try mounting whichever filesystem contains the pine message database
with the "-o biosize=13" option.

If you want to make this the default, quoting Steve:

> If you want to change the values used by default you can do this by changing
> some constants in fs/xfs/xfs_mount.h and rebuilding. Change these values:
> 
> /*
>  * Default minimum read and write sizes.
>  */
> #define XFS_READIO_LOG_SMALL    15      /* <= 32MB memory */
> #define XFS_WRITEIO_LOG_SMALL   15
> #define XFS_READIO_LOG_LARGE    16      /* > 32MB memory */
> #define XFS_WRITEIO_LOG_LARGE   16
> 
> To all be 13

Sorry it took a while for an answer, it didn't click in my head right
away.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 07:56:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Eu8017238
	for linux-xfs-outgoing; Tue, 8 May 2001 07:56:08 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48EtqF17233
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 07:55:52 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48ErID09071;
	Tue, 8 May 2001 09:53:24 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 09:53:18 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: GCS <gcs@agentsinside.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Tuning XFS for peak performance. (fwd)
In-Reply-To: <20010508142546.A31442@sisinteli07.udg.es>
Message-ID: <Pine.LNX.4.33.0105080949080.9013-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It's very possible that that's the case, pine, that is, but it's NOT only
pine which is slow. It is pretty much all operations, in X. This was NOT
the case before however. The only real difference right now, is the advent
of XFS. I did a full backup of my system, before reinstalling, and now
things are slower. I've tried some things here on the list, biosize,
logbuff, etc. I've DEFINITELY gained a noticable amount of speed. I need
to tweak something else now. My DMA settings are not an issue, I've got
everything turned up as high as my hardware allows. Not to mention, if
this was a scsi system, hdparm won't to crap for me. I'm experimenting
with this FS on my desktop to see if it's alright for oracle to run on.
That may give us some performance increase there, also, I'm trying to
tweak it so I know what to do in the event of a performance issue.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 8 May 2001, GCS wrote:

> Hi Austin,
>
> On Sun, May 06, 2001 at 05:11:00PM -0500, Austin Gonyou wrote:
>
> > While stable, it doesn't do
> > me any good if I have to wait 5 mins for PINE to open when it's only
> > moving a few messages from inbox to other boxes. The same operation would
> > take 30 seconds with ReiserFS.
>  Personaly I do not think it is a problem with XFS. First, please check
> your drive with "hdparm -t /dev/hda" (I suppose it is hda in your
> machine). Maybe you compiled your kernel without proper DMA support on
> the IDE bus or just does not set it up with hdparm. For me ReiserFS and
> XFS gives the same performance more or less.
>  (In brackets: pine is slooow, and has more holes than a cheese has.
> Change to mutt, it performs mailbox operations much more faster, etc).
>
> Regards, Laszlo
>


From owner-linux-xfs@oss.sgi.com Tue May  8 07:57:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48EvHA17288
	for linux-xfs-outgoing; Tue, 8 May 2001 07:57:17 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48EvHF17285
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 07:57:17 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48EsKK09083;
	Tue, 8 May 2001 09:54:26 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 09:54:20 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: rob <rob@dsvr.net>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: linux/xfs mount problem - 512byte cluster size
In-Reply-To: <3AF7D7DD.4E1D3934@dsvr.net>
Message-ID: <Pine.LNX.4.33.0105080954010.9013-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is it possible to lowlevel the drive and reformat it properly?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 8 May 2001, rob wrote:

> Hi,
>
> I've checked out 2.4.4-xfs  from cvs (i think this is the head branch)
> as I need to desperately access an Octane drives.
>
> The problem is the Octane has been formatted with a cluster size of 512
> bytes and the xfs driver for linux seems to only support 4096 bytes and
> therefore wont mount it.
>
> Any info on support for variable cluster sizes the driver supports ?
>
> Error reported by mount :
>
> XFS: Trying to mount file system with blocksize 512 bytes
> XFS: Only page-sized (4096 bytes) blocksize currently works.
> XFS: SB validate failed
>
>
> Best regards
>
> Rob Fielding.
> rob@dsvr.net
>


From owner-linux-xfs@oss.sgi.com Tue May  8 07:57:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Evl617301
	for linux-xfs-outgoing; Tue, 8 May 2001 07:57:47 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48EvlF17298
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 07:57:47 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48EtuY09091;
	Tue, 8 May 2001 09:55:56 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 09:55:56 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Tuning XFS for peak performance. (fwd)
In-Reply-To: <3AF7F9B3.5DA9AD9A@sgi.com>
Message-ID: <Pine.LNX.4.33.0105080955160.9013-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Where can I look for biosize, etc, mount option descriptions? I've been
looking around, but I'm not familiar with all the xfs tools yet, so I
don't know where it is.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 8 May 2001, Eric Sandeen wrote:

> Austin Gonyou wrote:
>
> > While stable, it doesn't do
> > me any good if I have to wait 5 mins for PINE to open when it's only
> > moving a few messages from inbox to other boxes. The same operation would
> > take 30 seconds with ReiserFS.
>
> This may be yet another issue with the default i/o size and databases.
> (we've seen this for rpm databases and sendmail access.db)
>
> I don't know for sure how pine uses gdbm, but I see that it is a
> requirement, so this is the likely culprit.
>
> Try mounting whichever filesystem contains the pine message database
> with the "-o biosize=13" option.
>
> If you want to make this the default, quoting Steve:
>
> > If you want to change the values used by default you can do this by changing
> > some constants in fs/xfs/xfs_mount.h and rebuilding. Change these values:
> >
> > /*
> >  * Default minimum read and write sizes.
> >  */
> > #define XFS_READIO_LOG_SMALL    15      /* <= 32MB memory */
> > #define XFS_WRITEIO_LOG_SMALL   15
> > #define XFS_READIO_LOG_LARGE    16      /* > 32MB memory */
> > #define XFS_WRITEIO_LOG_LARGE   16
> >
> > To all be 13
>
> Sorry it took a while for an answer, it didn't click in my head right
> away.  :)
>
> -Eric
>
>


From owner-linux-xfs@oss.sgi.com Tue May  8 07:59:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48ExJ217340
	for linux-xfs-outgoing; Tue, 8 May 2001 07:59:19 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48ExJF17337
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 07:59:19 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48EvY409107
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:57:34 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 09:57:34 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS + LVM + Epanding
Message-ID: <Pine.LNX.4.33.0105080956490.9013-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is this in the works? Has anyone tried this? Can MD devices be used and
expanded if formatted with XFS?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Tue May  8 08:01:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48F1Dh17408
	for linux-xfs-outgoing; Tue, 8 May 2001 08:01:13 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48F1CF17404
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:01:12 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f48F19l12957;
	Tue, 8 May 2001 10:01:09 -0500 (CDT)
Message-ID: <3AF80AAF.E1D4A839@sgi.com>
Date: Tue, 08 May 2001 10:03:11 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Tuning XFS for peak performance. (fwd)
References: <Pine.LNX.4.33.0105080955160.9013-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> Where can I look for biosize, etc, mount option descriptions? I've been
> looking around, but I'm not familiar with all the xfs tools yet, so I
> don't know where it is.

Until everyone gets the updated "mount" package,
/usr/src/linux/Documentation/filesystems/xfs.txt is a good place to
look:

  biosize=size
        Sets the preferred buffered I/O size (default size is 64K).
        "size" must be expressed as the logarithm (base2) of the
        desired I/O size.
        Valid values for this option are 14 through 16, inclusive
        (i.e. 16K, 32K, and 64K bytes).  On machines with a 4K
        pagesize, 13 (8K bytes) is also a valid size.
        The preferred buffered I/O size can also be altered on an
        individual file basis using the ioctl(2) system call.



-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 08:03:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48F3eW17523
	for linux-xfs-outgoing; Tue, 8 May 2001 08:03:40 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48F3eF17519
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:03:40 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA04249
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:03:37 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1740508; Tue, 8 May 2001 10:02:20 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA84066; Tue, 8 May 2001 10:02:20 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f48F57N08723; Tue, 8 May 2001 10:05:08 -0500
Message-Id: <200105081505.f48F57N08723@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Tuning XFS for peak performance. (fwd) 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Tue, 08 May 2001 09:53:18 CDT." <Pine.LNX.4.33.0105080949080.9013-100000@UberGeek.coremetrics.com> 
Date: Tue, 08 May 2001 10:05:07 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Are you running the released kernel or the development tree? There are some
very distinct issues with memory consumption in the 2.4.4 tree right now.

Steve


> It's very possible that that's the case, pine, that is, but it's NOT only
> pine which is slow. It is pretty much all operations, in X. This was NOT
> the case before however. The only real difference right now, is the advent
> of XFS. I did a full backup of my system, before reinstalling, and now
> things are slower. I've tried some things here on the list, biosize,
> logbuff, etc. I've DEFINITELY gained a noticable amount of speed. I need
> to tweak something else now. My DMA settings are not an issue, I've got
> everything turned up as high as my hardware allows. Not to mention, if
> this was a scsi system, hdparm won't to crap for me. I'm experimenting
> with this FS on my desktop to see if it's alright for oracle to run on.
> That may give us some performance increase there, also, I'm trying to
> tweak it so I know what to do in the event of a performance issue.
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 


From owner-linux-xfs@oss.sgi.com Tue May  8 08:53:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48FrJU19320
	for linux-xfs-outgoing; Tue, 8 May 2001 08:53:19 -0700
Received: from smtp-relay.noc.dsvr.net (smtp-relay.noc.dsvr.net [212.69.192.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48FrHF19316
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:53:17 -0700
Received: from [212.69.210.21] (helo=dsvr.net)
	by smtp-relay.noc.dsvr.net with esmtp (Exim 3.16 #1)
	id 14x9nY-000GMW-00
	for linux-xfs@oss.sgi.com; Tue, 08 May 2001 16:53:16 +0100
Message-ID: <3AF8241A.3146A323@dsvr.net>
Date: Tue, 08 May 2001 17:51:38 +0100
From: rob <rob@dsvr.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize
References: <3AF7D7DD.4E1D3934@dsvr.net> <3AF7F674.388891@sgi.com> <3AF80F10.3842D3F5@dsvr.net> <3AF80B90.ABA9DEB6@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks Eric


> >
> > Hi Eric, thanks for your reply. If you have a few minutes, can you read thru
> > this and make any comments on my situation/reasoning behind fixing it.
>
> Hm, I can half-answer some of your questions, but I don't know for sure
> on others.
>
> So, I'd suggest that you distill your last message down into the
> fundamental questions and send it back to the list, but here are a few
> pieces of information:
>

Cheers. I'll post this back to the list for now. I'll sort out those other
questions later :)

>
> xfsdump (at least on linux) only operates on a mounted filesystem.

er.. but i can't mount the xfs filesystem due to the 512byte blocksize....

>
> xfsdump can be used to transfer from linux <-> irix.
> 4k blocksize should work fine under Irix
> see "man xfsdump" for the "-b blocksize" option.

ok. This is what i get (all you non-linux types forgive the linux notations -
i've read quite a bit of the news groups :)

/dev/hdb is an 9 GB IDE disk, contents (currently) ext2 however it's not mounted,
and it's ready to be blanked by whatever happens next

Disk /dev/hdb: 128 heads, 63 sectors, 782 cylinders
Units = cylinders of 8064 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1   *         1       740   2983648+  83  Linux
/dev/hdb2           741       782    169344   82  Linux swap


/dev/sda is a 4 GB SCSI disk from the Octane.

fdisk or sda
----- partitions -----
   Device  Info      Start       End   Sectors  Id  System
/dev/sda1  boot       245      8154   8622303   a  SGI xfs
/dev/sda2  swap         4       244    262144   3  SGI raw
/dev/sda9               0         3      4096   0  SGI volhdr
/dev/sda11              0      8154   8888543   6  SGI volume
----- bootinfo -----
Bootfile: /unix
----- directory entries -----
 0: sgilabel   sector    2 size     512
 1: ide        sector    3 size  268288
 2: sash       sector  527 size  268288
 3: IP30prom   sector 1051 size  913408

Fair enough. OK. So we attempt to 'dump' the filesystem from my unreadable
(512bytes blocksize) xfs disk (i'm deliberately not using the word partition as i
normally would) to the IDE drive (not currently xfs, but ext2). Neither are
mounted :

xfsdump -f /dev/hdb1 -b 512 /dev/sda1

after being prompted for a label i get the following error :

xfsdump: ERROR: /dev/sda1 does not identify a file system

which suggests to me that xfsdump cannot read the filesystem due to this 512byte
!= 4096byte incompatability with the SGI Octane disk and the linux XFS driver.

I get this also with the following command line variations :

xfsdump -f /dev/hdb1 -b 512 /dev/sda
xfsdump -f /dev/hdb1 /dev/sda
xfsdump -f /dev/hdb1 /dev/sda1

Could anyone offer any help/advice.

Best regards

Rob Fielding
rob@dsvr.net



From owner-linux-xfs@oss.sgi.com Tue May  8 08:54:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48FsJB19360
	for linux-xfs-outgoing; Tue, 8 May 2001 08:54:19 -0700
Received: from mail1.ee.byu.edu (mail.ee.byu.edu [128.187.31.153])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48FsIF19357
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:54:18 -0700
Received: from twilight.ee.byu.edu (twilight.ee.byu.edu [128.187.30.200])
	by mail1.ee.byu.edu (8.11.2/8.11.2) with ESMTP id f48Fs5J11948;
	Tue, 8 May 2001 09:54:05 -0600
Date: Tue, 8 May 2001 09:54:05 -0600 (MDT)
From: David W Dougall <davidd@ee.byu.edu>
To: Tom Duffy <tduffy@engr.sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: NFS problems
In-Reply-To: <Pine.LNX.4.30.0105032234500.25517-100000@dbear.engr.sgi.com>
Message-ID: <Pine.LNX.4.33.0105080951530.17427-100000@twilight.ee.byu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



On Thu, 3 May 2001, Tom Duffy wrote:

> > Are you referring to the second last Q on
> > http://nfs.sourceforge.net ?
>
> yes, you are right.  this is the bug I was thinking of...
>
> > This is the other way around; having problems with a Linux NFS
> > server and an IRIX NFS client, this is not what Trond's patch
> > is referring to.
> >
> > Anyway, if the problem is solved both in the Linux kernel,
> > glibc, and in IRIX then everybody would be happy.
>
> oh, ok, did not know there was another bug...what is the correct fix in
> IRIX cause I will post a bug and push it back to the folks here who can
> deal with it...
>
> -tduffy
>
In my understanding of the bug, the irix client does not read non-32 bit
headers correctly in nfsv3.  On the linux nfs mailing list, this has been
discussed in depth and the bug has been reported and accepted by SGI.
--David Dougall



From owner-linux-xfs@oss.sgi.com Tue May  8 08:56:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48FuuZ19456
	for linux-xfs-outgoing; Tue, 8 May 2001 08:56:56 -0700
Received: from smtp-relay.noc.dsvr.net (smtp-relay.noc.dsvr.net [212.69.192.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48FutF19450
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 08:56:55 -0700
Received: from [212.69.210.21] (helo=dsvr.net)
	by smtp-relay.noc.dsvr.net with esmtp (Exim 3.16 #1)
	id 14x9r2-000Go5-00
	for linux-xfs@oss.sgi.com; Tue, 08 May 2001 16:56:52 +0100
Message-ID: <3AF824F2.D905BB6B@dsvr.net>
Date: Tue, 08 May 2001 17:55:14 +0100
From: rob <rob@dsvr.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize (sorry if this is a 
 dupe)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

(sorry if this is a dupe, netscape-mail is a piece of sh*t)

Thanks Eric


> >
> > Hi Eric, thanks for your reply. If you have a few minutes, can you
read thru
> > this and make any comments on my situation/reasoning behind fixing
it.
>
> Hm, I can half-answer some of your questions, but I don't know for
sure
> on others.
>
> So, I'd suggest that you distill your last message down into the
> fundamental questions and send it back to the list, but here are a few

> pieces of information:
>

Cheers. I'll post this back to the list for now. I'll sort out those
other
questions later :)

>
> xfsdump (at least on linux) only operates on a mounted filesystem.

er.. but i can't mount the xfs filesystem due to the 512byte
blocksize....

>
> xfsdump can be used to transfer from linux <-> irix.
> 4k blocksize should work fine under Irix
> see "man xfsdump" for the "-b blocksize" option.

ok. This is what i get (all you non-linux types forgive the linux
notations -
i've read quite a bit of the news groups :)

/dev/hdb is an 9 GB IDE disk, contents (currently) ext2 however it's not
mounted,
and it's ready to be blanked by whatever happens next

Disk /dev/hdb: 128 heads, 63 sectors, 782 cylinders
Units = cylinders of 8064 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hdb1   *         1       740   2983648+  83  Linux
/dev/hdb2           741       782    169344   82  Linux swap


/dev/sda is a 4 GB SCSI disk from the Octane.

fdisk or sda
----- partitions -----
   Device  Info      Start       End   Sectors  Id  System
/dev/sda1  boot       245      8154   8622303   a  SGI xfs
/dev/sda2  swap         4       244    262144   3  SGI raw
/dev/sda9               0         3      4096   0  SGI volhdr
/dev/sda11              0      8154   8888543   6  SGI volume
----- bootinfo -----
Bootfile: /unix
----- directory entries -----
 0: sgilabel   sector    2 size     512
 1: ide        sector    3 size  268288
 2: sash       sector  527 size  268288
 3: IP30prom   sector 1051 size  913408

Fair enough. OK. So we attempt to 'dump' the filesystem from my
unreadable
(512bytes blocksize) xfs disk (i'm deliberately not using the word
partition as i
normally would) to the IDE drive (not currently xfs, but ext2). Neither
are
mounted :

xfsdump -f /dev/hdb1 -b 512 /dev/sda1

after being prompted for a label i get the following error :

xfsdump: ERROR: /dev/sda1 does not identify a file system

which suggests to me that xfsdump cannot read the filesystem due to this
512byte
!= 4096byte incompatability with the SGI Octane disk and the linux XFS
driver.

I get this also with the following command line variations :

xfsdump -f /dev/hdb1 -b 512 /dev/sda
xfsdump -f /dev/hdb1 /dev/sda
xfsdump -f /dev/hdb1 /dev/sda1

Could anyone offer any help/advice.

Best regards

Rob Fielding
rob@dsvr.net




From owner-linux-xfs@oss.sgi.com Tue May  8 09:03:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48G3wo19716
	for linux-xfs-outgoing; Tue, 8 May 2001 09:03:58 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48G3wF19712
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:03:58 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA03340
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:03:57 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA481856; Tue, 8 May 2001 11:02:11 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA81503; Tue, 8 May 2001 11:02:11 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f48G4wE09228; Tue, 8 May 2001 11:04:58 -0500
Message-Id: <200105081604.f48G4wE09228@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: rob <rob@dsvr.net>
cc: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize 
In-Reply-To: Message from rob <rob@dsvr.net> 
   of "Tue, 08 May 2001 17:51:38 BST." <3AF8241A.3146A323@dsvr.net> 
Date: Tue, 08 May 2001 11:04:58 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I think currently the only solution is to do the dump on an irix box and
the restore on the linux box, this should work. Unfortunately if the
reason for you needing this is to get data from a disk on a dead octane
this does not help very much. We are working on the blocksize support
but I expect it will not be available for several weeks yet.

Steve



From owner-linux-xfs@oss.sgi.com Tue May  8 09:05:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48G5rO19782
	for linux-xfs-outgoing; Tue, 8 May 2001 09:05:53 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48G5qF19779
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:05:52 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f48G5lE05414;
	Tue, 8 May 2001 11:05:47 -0500 (CDT)
Message-ID: <3AF819D6.729E7E0B@sgi.com>
Date: Tue, 08 May 2001 11:07:50 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@dsvr.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize
References: <3AF7D7DD.4E1D3934@dsvr.net> <3AF7F674.388891@sgi.com> <3AF80F10.3842D3F5@dsvr.net> <3AF80B90.ABA9DEB6@sgi.com> <3AF8241A.3146A323@dsvr.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

rob wrote:

> > xfsdump (at least on linux) only operates on a mounted filesystem.
> 
> er.. but i can't mount the xfs filesystem due to the 512byte blocksize....

Right.  You will have to use xfsdump after mounting the filesystem on an
Irix system, then restore the resulting dump to the Linux system.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 09:10:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48GAJ319955
	for linux-xfs-outgoing; Tue, 8 May 2001 09:10:19 -0700
Received: from smtp-relay.noc.dsvr.net (smtp-relay.noc.dsvr.net [212.69.192.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48GAHF19952
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:10:17 -0700
Received: from [212.69.210.21] (helo=dsvr.net)
	by smtp-relay.noc.dsvr.net with esmtp (Exim 3.16 #1)
	id 14xA40-000ILR-00
	for linux-xfs@oss.sgi.com; Tue, 08 May 2001 17:10:16 +0100
Message-ID: <3AF82816.835613D6@dsvr.net>
Date: Tue, 08 May 2001 18:08:38 +0100
From: rob <rob@dsvr.net>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize
References: <200105081604.f48G4wE09228@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord wrote:

> I think currently the only solution is to do the dump on an irix box and
> the restore on the linux box, this should work. Unfortunately if the
> reason for you needing this is to get data from a disk on a dead octane
> this does not help very much. We are working on the blocksize support
> but I expect it will not be available for several weeks yet.
>
> Steve

Yup, that's what i was begining to think.

(To recap - i have a bust irix installation AND a tar backup on the same
drive. My answer lies in being able to uncompress the tar archive over the
installed irix installation. I cannot boot the os as it is - cause its half
6.5.5 and 6.5.11, duh! -  and I don't think i can instigate anything much
from the PROM - pointers welcome - so my solution would be to stick the
drive in another computer that can read/write to the disk and unarchive the
tar, pop the drive back in and bingo!)

How about this : I have a spare Indigo2. It's running 6.2. It cannot read
the disk either - for reasons i don't know, but best guess the same
blocksize issue. Would xfsdump work on here to the same effect ? I'm out of
SCA to SCSI converters, but if this would work, i could 'find' one PDQ :)

Sorry this is going a little off topic.

Best regards

Rob Fielding
rob@dsvr.net






From owner-linux-xfs@oss.sgi.com Tue May  8 09:16:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48GGUQ20187
	for linux-xfs-outgoing; Tue, 8 May 2001 09:16:30 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48GGTF20184
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:16:29 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA22838
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:16:28 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA02766
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 09:16:21 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Tue, 8 May 2001 09:16:14 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id JAA26854;
	Tue, 8 May 2001 09:16:13 -0700
Message-Id: <3AF81BCD.32FE3567@pipcws.ca.boeing.com>
Date: Tue, 08 May 2001 09:16:13 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Ric Tibbetts <ric@chadera.net>, Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: NFS Export problem
References: <3AF77BFB.5CE8F569@chadera.net> <3AF78EAB.EE871BC0@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, I did some looking at this last night. It appears that the problem comes in
trying to make the NFS support as a module. The kernel that I have that is
failing the export, this is the case (NFS Server is a module). I built a "quick
& dirty" version with the NFS server compiled in, and the export worked fine.
Now I need to run the same test on my "good" kernel tonight.

I'll test this more tonight when I get home. But if any of the other folks out
there that are experienceing this want to build a kernel today, check this area
out. I'd be interested in seeing the results.

	Ric


Russell Cattelan wrote:
> 
> Ric Tibbetts wrote:
> 
> Yes I would guess this is same problem other people are experiencing.
> I have quite  few nfs exported file systems and haven't run across this
> problem,
> so guess we need to dig into your setup a bit more.
> 
> what options are you specifying in /etc/exportfs?
> how many network interfaces do you have?
> 
> Anything else that might be relevant.
> 
> > Ok, here's the problem I was trying to solve by using the latest CVS
> > tree.
> > When I try to NFS export an XFS filesystem, I get the following error:
> >
> > the_otherbox.com:/nfs: Invalid argument
> >
> > Note: This is ONLY with XFS filesystems. ext2 filesystems export fine.
> >
> > the setup:
> >
> > Mandrake 8.0 (still stock, except for the kernel munging, and the XFS
> > filesystems
> >
> > Mandrake 2.4.3 kernel source + a patch made for that kernel.
> >
> > I've seen another individual here with the same problem, different
> > distribution.
> > Is anyone else running a 2.4.3 kernel with NFS exports working? Or have
> > an idea of what's wrong?
> >
> >         Thanks in advance
> >
> >                 Ric

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Tue May  8 10:02:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48H20621649
	for linux-xfs-outgoing; Tue, 8 May 2001 10:02:00 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48H20F21646
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 10:02:00 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f48H20EZ028443
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 10:02:00 -0700
Date: Tue, 8 May 2001 10:02:00 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: linux-xfs@oss.sgi.com
Subject: XFS 1.0/Quota
Message-ID: <Pine.LNX.4.21.0105081000470.11379-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Does quota work on XFS 1.0?  I've been trying to get it to work with no
success.  I've read documentation which say that quota does work but for
some reason I dont think that's true.



*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************


From owner-linux-xfs@oss.sgi.com Tue May  8 10:27:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48HR9v22260
	for linux-xfs-outgoing; Tue, 8 May 2001 10:27:09 -0700
Received: from tcni.tcni.iot.dtag.de (tcni.tcni.iot.dtag.de [194.25.220.202])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48HR4F22254
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 10:27:05 -0700
Received: from steinberg.dhs.org (tcni.tcni.iot.dtag.de [127.0.0.1])
	by tcni.tcni.iot.dtag.de (8.11.2/8.11.2) with ESMTP id f48HR2F14681
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 19:27:02 +0200
Message-ID: <3AF82C66.FFC6282@steinberg.dhs.org>
Date: Tue, 08 May 2001 19:27:02 +0200
From: Dirk Steinberg <dws@steinberg.dhs.org>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: XFS + LVM + Epanding
References: <Pine.LNX.4.33.0105080956490.9013-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f48HR8F22258
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

XFS + LVM works. Expanding works, too.

Very easy. Convenient. Just try it. Running Redhat 7.1 + XFS 1.0.

# lvcreate -n test -L 100M nilab01
lvcreate
lvcreate -- doing automatic backup of "nilab01"
lvcreate -- logical volume "/dev/nilab01/test" successfully created

# mkfs.xfs /dev/nilab01/test
meta-data=/dev/nilab01/test      isize=256    agcount=6, agsize=4267 blks
data     =                       bsize=4096   blocks=25600, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
# mount /dev/nilab01/test /mnt
# lvextend -L +10M /dev/nilab01/test
lvextend
lvextend -- rounding size to physical extent boundary
lvextend -- extending logical volume "/dev/nilab01/test" to 112 MB
lvextend -- doing automatic backup of volume group "nilab01"
lvextend -- logical volume "/dev/nilab01/test" successfully extended

# xfs_growfs /mnt 
meta-data=/mnt                   isize=256    agcount=6, agsize=4267 blks
data     =                       bsize=4096   blocks=25600, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 25600 to 28672
# df /mnt
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/nilab01/test
               xfs    107M  128k  107M   1% /mnt
# umount /mnt
# lvremove  /dev/nilab01/test        
lvremove
lvremove -- do you really want to remove "/dev/nilab01/test"? [y/n]: y
lvremove -- doing automatic backup of volume group "nilab01"
lvremove -- logical volume "/dev/nilab01/test" successfully removed

# 

Austin Gonyou wrote:
> 
> Is this in the works? Has anyone tried this? Can MD devices be used and
> expanded if formatted with XFS?
> 
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com

------------------------------------------
Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg
Ringstr. 2, D-53567 Buchholz, Germany
Phone: +49-2683-9793-20, fax: -29
Mobile/GSM: +49-170-818-9793
Email: dws@steinberg.dhs.org

From owner-linux-xfs@oss.sgi.com Tue May  8 12:13:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48JD0S26909
	for linux-xfs-outgoing; Tue, 8 May 2001 12:13:00 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JCuF26903
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 12:12:56 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id PAA23670;
	Tue, 8 May 2001 15:12:30 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Tue, 8 May 2001 15:12:30 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: John Trostel <jtrostel@connex.com>
cc: <pac@fortuitous.com>, <linux-xfs@oss.sgi.com>
Subject: RE: vmware broken again:
In-Reply-To: <XFMail.20010504110935.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.30.0105081510420.23667-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 4 May 2001 at 11:09am, John Trostel wrote

> Look at /usr/lib/vmware/modules/source/vmnet.tar (from vmware build 799)

*snip*

> This made my vmware work again... YMMV

FWIW, VMware put out a 2.4-aware release candidate last week.  It
installed on an SGI-RH7.1-Release-1.0 based system, but that's all I can
attest to.  I'd be interested in further test results...

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


From owner-linux-xfs@oss.sgi.com Tue May  8 12:30:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48JUh027308
	for linux-xfs-outgoing; Tue, 8 May 2001 12:30:43 -0700
Received: from tera.umi.com (tera.umi.com [192.195.245.144])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JUfF27305
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 12:30:41 -0700
Received: from zeeb-nt01.umi.bhowell.com (zeeb-nt01.umi.bhowell.com [165.215.60.41])
	by tera.umi.com (8.10.1/8.10.1) with ESMTP id f48JTa4489401;
	Tue, 8 May 2001 15:29:36 -0400 (EDT)
Received: from insanegeeks.com (172.24.4.52 [172.24.4.52]) by zeeb-nt01.umi.bhowell.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KLG69JM1; Tue, 8 May 2001 15:30:32 -0400
Message-ID: <3AF84005.8CE71E1E@insanegeeks.com>
Date: Tue, 08 May 2001 14:50:45 -0400
From: Thomas Suiter <InsaneGeek@insanegeeks.com>
X-Mailer: Mozilla 4.75C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: rob <rob@dsvr.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux/xfs mount problem - 512byte blocksize
References: <200105081604.f48G4wE09228@jen.americas.sgi.com> <3AF82816.835613D6@dsvr.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> (To recap - i have a bust irix installation AND a tar backup on the same
> drive. My answer lies in being able to uncompress the tar archive over the
> installed irix installation. I cannot boot the os as it is - cause its half
> 6.5.5 and 6.5.11, duh! -  and I don't think i can instigate anything much
> from the PROM - pointers welcome - so my solution would be to stick the
> drive in another computer that can read/write to the disk and unarchive the
> tar, pop the drive back in and bingo!)
>
> How about this : I have a spare Indigo2. It's running 6.2. It cannot read
> the disk either - for reasons i don't know, but best guess the same
> blocksize issue. Would xfsdump work on here to the same effect ? I'm out of
> SCA to SCSI converters, but if this would work, i could 'find' one PDQ :)

As long as you have a good swap partition (if not you could boot into fx from
prom and create one), you can boot into miniroot on the Octane from CD by
using the "install system software" option.  Once in, do a "shroot" and it
will do a chroot to your /root directory.  Outside of that you could maybe try
something using the Indigo2 as a diskless workstation server, boot up your
Octane from the Indigo2 and then manually mount your local drive.

Thomas Suiter


From owner-linux-xfs@oss.sgi.com Tue May  8 12:34:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48JY8R27372
	for linux-xfs-outgoing; Tue, 8 May 2001 12:34:08 -0700
Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48JY7F27369
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 12:34:07 -0700
Received: from mediaone.net (localhost [127.0.0.1])
	by dsl-squash.corp.sgi.com (Postfix) with ESMTP id 359F92D546
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 15:33:53 -0400 (EDT)
Message-ID: <3AF84A21.62CAEBF0@mediaone.net>
Date: Tue, 08 May 2001 15:33:53 -0400
From: J Landman <landman@mediaone.net>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: question on XFS+devfsd, and a quick suggestion
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Folks:

  I think this is a FAQ but it isn't in the FAQ as far as I can tell.  I
am also not sure who owns the problem in reality, as it appears to be
more of a devfsd setup than an XFS problem.  But it is worth working up
an answer to, as I am sure that it is a FAQ (and will be for new folks
doing devfsd on a distro to get XFS).

  I just downloaded the 7.1 installer, and installed the XFS with RedHat
7.1 to my laptop (erasing an older Mandrake 7.2 install).  In the older
install, my audio and cdrom worked fine.  With the new install on there,
they do not work, and from what I can see, it is a devfsd issue.

  Looking at the hardware tree for the drive, and the /etc/devfsd.conf
file, I cannot really figure out how to force the CDROM to be visible. 
I have added some LOOKUP lines to the devfsd.conf file, that seem to
work when I force a modprobe of sound.  I would like the CD to be
visible too.  This is an IDE CD ( /dev/hdb in the old nomenclature).

  What I cannot tell from the /etc/devfsd.conf file is how it mapped the
tree to the /dev/hda in the first place.  I am sure that the solution to
my problem is very much related to this.  If someone could point me to a
document which explains this mapping (specific to the 1.0 XFS installer
for RedHat) and where to look to add to it (specifically so I can set up
a mapping for my CD) I would appreciate it.  

  Note:  I did look in /dev/cdroms/ and there was no entry for cdrom0. 
This is where the problem is.  I need to get the cdrom0 noticed in the
first place in order to make this work.  Clues/hints are requested. 

  The suggestion:  The installer gets you to a screen giving you the
ability to partition using one of three methods.  Two of the three
methods do not give you the ability to create an XFS partition (I tried
them).  It would be nice if you added the ability to create an XFS
partition (or filesystem) on top of the existing fdisk/disk druid
system, or somehow specifically indicated which partition to use (both
say linux native).  There wasn't an indication of how to go about
creating any particular file system atop the linux native partition. 
Words to that effect would have been helpful. Looking at my "xfs
partition" (xfs file system atop a linux partition) makes me wonder
whether or not the disk druid/fdisk would have worked.  

-- 
 Joe Landman,
 landman@mediaone.net

From owner-linux-xfs@oss.sgi.com Tue May  8 13:11:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48KBHP29442
	for linux-xfs-outgoing; Tue, 8 May 2001 13:11:17 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KBGF29439
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 13:11:16 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f48KBDt01118;
	Tue, 8 May 2001 15:11:13 -0500 (CDT)
Message-ID: <3AF8535C.F880D049@sgi.com>
Date: Tue, 08 May 2001 15:13:16 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: J Landman <landman@mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: question on XFS+devfsd, and a quick suggestion
References: <3AF84A21.62CAEBF0@mediaone.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

J Landman wrote:

>   Note:  I did look in /dev/cdroms/ and there was no entry for cdrom0.
> This is where the problem is.  I need to get the cdrom0 noticed in the
> first place in order to make this work.  Clues/hints are requested.

try "modprobe ide-cd"

After that, /dev/cdroms/cdrom* and /dev/cdrom should show up.  In
theory, just looking for /dev/cdrom should also load the module and
create the links, with devfsd set as we have it:

[root@lite /root]# lsmod | grep cdrom <-- no cdrom modules
[root@lite /root]# ls -l /dev/cd*     <-- no cdrom device
ls: /dev/cd*: No such file or directory

... but lookup /dev/cdrom, and the module loads and the link is created:

[root@lite /root]# ls -l /dev/cdrom
lr-xr-xr-x    1 root     root           13 May  8 14:53 /dev/cdrom ->
cdroms/cdrom0
[root@lite /root]# lsmod | grep cdrom
cdrom   31097   0  (autoclean) [ide-cd sr_mod]


>   The suggestion:  The installer gets you to a screen giving you the
> ability to partition using one of three methods.  Two of the three
> methods do not give you the ability to create an XFS partition (I tried
> them).  

You're confusing terminology a little here - you create a "Linux Native"
partition, then you format that partition - either with ext2, xfs,
reiserfs, or whatever.

The installer defaults to XFS on all but the custom installation. 
There's a little bit of warning about this on the method selection
screen - i.e. "Laptop system on XFS"  The idea is that anyone who feels
the need to mix-n-match filesystems also would be choosing the custom
system install.

> It would be nice if you added the ability to create an XFS
> partition (or filesystem) on top of the existing fdisk/disk druid
> system, or somehow specifically indicated which partition to use (both
> say linux native).  

Disk druid only handles partitioning, this is (mostly) unrelated to
filesystem selection.  Both XFS and ext2 _do_ live on the same type of
partition ("Linux Native").

After you go through partitioning, it should ask you about filesystem
formatting, which is when you get to choose between ext2 and XFS for
each partition.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 13:15:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48KFcS29766
	for linux-xfs-outgoing; Tue, 8 May 2001 13:15:38 -0700
Received: from skl1.ukl.uni-freiburg.de (skl1.ukl.uni-freiburg.de [193.196.199.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f48KFbF29757
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 13:15:37 -0700
Received: (qmail 19971 invoked by alias); 8 May 2001 20:15:33 -0000
Received: (qmail 19966 invoked from network); 8 May 2001 20:15:32 -0000
Received: from msm201.ukl.uni-freiburg.de (HELO ukl.uni-freiburg.de) (193.196.218.201)
  by skl1.ukl.uni-freiburg.de with SMTP; 8 May 2001 20:15:32 -0000
Message-ID: <3AF853EB.93F813F5@ukl.uni-freiburg.de>
Date: Tue, 08 May 2001 22:15:39 +0200
From: "Manfred W. Baumstark" <maba@ukl.uni-freiburg.de>
Organization: Medizinische Universitaetsklink Freiburg
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en,de
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: question on XFS+devfsd, and a quick suggestion
References: <3AF84A21.62CAEBF0@mediaone.net>
Content-Type: multipart/mixed;
 boundary="------------F2307F61EEE2B33E3323F4E8"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------F2307F61EEE2B33E3323F4E8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is really a FAQ! For me the following works, maybe there are better
solutions...

For some reason the cdrom modules are not automatically loaded: I load the
cdrom modules by "modprobe ide-cd" in rc.local. Maybe someone can tell us
how to fix this more elegant...
 
To get your favourate links in /dev you have to add lines like this to
/etc/devfsd.conf:

REGISTER     mydir/mydev  CFUNCTION GLOBAL symlink $devname mydev
UNREGISTER   mydir/mydev  CFUNCTION GLOBAL unlink  mydev

To get /dev/cdrom I use:

REGISTER        ide/host0/bus0/target1/lun0/cd  CFUNCTION GLOBAL symlink
$devname
cdrom
UNREGISTER      ide/host0/bus0/target1/lun0/cd  CFUNCTION GLOBAL unlink
cdrom

I think mydir/mydev has to be the actual device not a link, i.e.
cdroms/cdrom0 did not work.

Manfred

J Landman wrote:
> 
> Folks:
> 
>   I think this is a FAQ but it isn't in the FAQ as far as I can tell.  I
> am also not sure who owns the problem in reality, as it appears to be
> more of a devfsd setup than an XFS problem.  But it is worth working up
> an answer to, as I am sure that it is a FAQ (and will be for new folks
> doing devfsd on a distro to get XFS).
> 
>   I just downloaded the 7.1 installer, and installed the XFS with RedHat
> 7.1 to my laptop (erasing an older Mandrake 7.2 install).  In the older
> install, my audio and cdrom worked fine.  With the new install on there,
> they do not work, and from what I can see, it is a devfsd issue.
> 
>   Looking at the hardware tree for the drive, and the /etc/devfsd.conf
> file, I cannot really figure out how to force the CDROM to be visible.
> I have added some LOOKUP lines to the devfsd.conf file, that seem to
> work when I force a modprobe of sound.  I would like the CD to be
> visible too.  This is an IDE CD ( /dev/hdb in the old nomenclature).
> 
>   What I cannot tell from the /etc/devfsd.conf file is how it mapped the
> tree to the /dev/hda in the first place.  I am sure that the solution to
> my problem is very much related to this.  If someone could point me to a
> document which explains this mapping (specific to the 1.0 XFS installer
> for RedHat) and where to look to add to it (specifically so I can set up
> a mapping for my CD) I would appreciate it.
> 
>   Note:  I did look in /dev/cdroms/ and there was no entry for cdrom0.
> This is where the problem is.  I need to get the cdrom0 noticed in the
> first place in order to make this work.  Clues/hints are requested.
> 
>   The suggestion:  The installer gets you to a screen giving you the
> ability to partition using one of three methods.  Two of the three
> methods do not give you the ability to create an XFS partition (I tried
> them).  It would be nice if you added the ability to create an XFS
> partition (or filesystem) on top of the existing fdisk/disk druid
> system, or somehow specifically indicated which partition to use (both
> say linux native).  There wasn't an indication of how to go about
> creating any particular file system atop the linux native partition.
> Words to that effect would have been helpful. Looking at my "xfs
> partition" (xfs file system atop a linux partition) makes me wonder
> whether or not the disk druid/fdisk would have worked.
> 
> --
>  Joe Landman,
>  landman@mediaone.net
--------------F2307F61EEE2B33E3323F4E8
Content-Type: text/x-vcard; charset=us-ascii;
 name="maba.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Manfred W. Baumstark
Content-Disposition: attachment;
 filename="maba.vcf"

begin:vcard 
n:Baumstark;Manfred
tel;fax:+49 761 270 7470
tel;work:+49 761 270 7496
x-mozilla-html:TRUE
org:University Hospital Freiburg;Rehabilitative and Preventive Sportsmedicine
adr:;;Hugstetter Str. 55;Freiburg;;D-79106;Germany
version:2.1
email;internet:manfred.baumstark@uni-freiburg.de
title:Dr.
x-mozilla-cpt:;29056
fn:Manfred Baumstark
end:vcard

--------------F2307F61EEE2B33E3323F4E8--


From owner-linux-xfs@oss.sgi.com Tue May  8 13:22:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48KMTc30107
	for linux-xfs-outgoing; Tue, 8 May 2001 13:22:29 -0700
Received: from lynx.unf.edu (lynx.unf.edu [139.62.201.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KMSF30104
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 13:22:29 -0700
Received: by lynx.unf.edu with Internet Mail Service (5.5.2650.21)
	id <2Z0RQN04>; Tue, 8 May 2001 16:22:21 -0400
Message-ID: <CFB7B892437FD21183DC0020484017EB0A7794CE@lynx.unf.edu>
From: "Schincke, Keith" <kschin@lynx.unf.edu>
To: "Xfs (E-mail)" <linux-xfs@oss.sgi.com>
Subject: chacl question
Date: Tue, 8 May 2001 16:22:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I have used the ACL support that Tru64 Unix uses in their file system. Their
setacl command allows the setting of an individual ACL permission "setacl -d
-u user:luser:rw-".

My question is is there any plans to implement chacl in this way? Unless I
missed something, I have to type in the whole list of ACLs just to add a new
one.  It would make it easier than having to retype a long acl entry just to
add a new person to the list.

Keith Schincke

From owner-linux-xfs@oss.sgi.com Tue May  8 13:26:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48KQ6P30219
	for linux-xfs-outgoing; Tue, 8 May 2001 13:26:06 -0700
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48KQ5F30214
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 13:26:05 -0700
Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217])
	by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f48KPAa12898;
	Tue, 8 May 2001 16:25:10 -0400 (EDT)
Date: Tue, 8 May 2001 16:25:27 -0400 (EDT)
From: J Landman <landman@mediaone.net>
X-X-Sender:  <landman@dsl-squash.corp.sgi.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: question on XFS+devfsd, and a quick suggestion
In-Reply-To: <3AF8535C.F880D049@sgi.com>
Message-ID: <Pine.LNX.4.32.0105081617260.28848-100000@dsl-squash.corp.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 8 May 2001, Eric Sandeen wrote:

> >   The suggestion:  The installer gets you to a screen giving you the
> > ability to partition using one of three methods.  Two of the three
> > methods do not give you the ability to create an XFS partition (I tried
> > them).
>
> You're confusing terminology a little here - you create a "Linux Native"
> partition, then you format that partition - either with ext2, xfs,
> reiserfs, or whatever.

I was unaware which partition type you were installing onto.  The problem
comes from the intermingling of "Linux native" in the partition sense
(type 83), and "Linux native" in the file system sense, which tends to be
taken to be ext2.  I was unaware that XFS installs atop a type 83
partition.

> Disk druid only handles partitioning, this is (mostly) unrelated to
> filesystem selection.  Both XFS and ext2 _do_ live on the same type of
> partition ("Linux Native").

True, with the caveat that the usual course of most installers (the RedHat
in particular) ask you the mount point and the file system type at the
point of creation of the partition (the custom partitioner in particular).
The RedHat tool (launched from the XFS install CD) lets you create a /
mount point, as a Linux native file system.  It doesn't indicate XFS as an
option.  If this option can be selected later, I would like to point out
that this breaks with the direction from several distros, specifically
RedHat, Mandrake, and others.

> After you go through partitioning, it should ask you about filesystem
> formatting, which is when you get to choose between ext2 and XFS for
> each partition.

See above.  Look at the Mandrake disk partitioner/file system mountpoint
and file system type installer for an example of a good way to do this.

-- 
 Joe Landman,
 landman@mediaone.net



From owner-linux-xfs@oss.sgi.com Tue May  8 14:16:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48LGFV32454
	for linux-xfs-outgoing; Tue, 8 May 2001 14:16:15 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48LGEF32451
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 14:16:14 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48LFJk11951;
	Tue, 8 May 2001 16:15:19 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 16:15:19 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Dirk Steinberg <dws@steinberg.dhs.org>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding
In-Reply-To: <3AF82C66.FFC6282@steinberg.dhs.org>
Message-ID: <Pine.LNX.4.33.0105081614240.11209-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dood!!! Thanks! Ok, so now that I see that it can work and seems to work
well. I'd like to ask one more question..to be fare. I didn't see a df
output after you created the first volume. Could we see that?, just to get
the "before and after" snapshot?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 8 May 2001, Dirk Steinberg wrote:

> XFS + LVM works. Expanding works, too.
>
> Very easy. Convenient. Just try it. Running Redhat 7.1 + XFS 1.0.
>
> # lvcreate -n test -L 100M nilab01
> lvcreate
> lvcreate -- doing automatic backup of "nilab01"
> lvcreate -- logical volume "/dev/nilab01/test" successfully created
>
> # mkfs.xfs /dev/nilab01/test
> meta-data=/dev/nilab01/test      isize=256    agcount=6, agsize=4267 blks
> data     =                       bsize=4096   blocks=25600, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> # mount /dev/nilab01/test /mnt
> # lvextend -L +10M /dev/nilab01/test
> lvextend
> lvextend -- rounding size to physical extent boundary
> lvextend -- extending logical volume "/dev/nilab01/test" to 112 MB
> lvextend -- doing automatic backup of volume group "nilab01"
> lvextend -- logical volume "/dev/nilab01/test" successfully extended
>
> # xfs_growfs /mnt
> meta-data=/mnt                   isize=256    agcount=6, agsize=4267 blks
> data     =                       bsize=4096   blocks=25600, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 25600 to 28672
> # df /mnt
> Filesystem    Type    Size  Used Avail Use% Mounted on
> /dev/nilab01/test
>                xfs    107M  128k  107M   1% /mnt
> # umount /mnt
> # lvremove  /dev/nilab01/test
> lvremove
> lvremove -- do you really want to remove "/dev/nilab01/test"? [y/n]: y
> lvremove -- doing automatic backup of volume group "nilab01"
> lvremove -- logical volume "/dev/nilab01/test" successfully removed
>
> #
>
> Austin Gonyou wrote:
> >
> > Is this in the works? Has anyone tried this? Can MD devices be used and
> > expanded if formatted with XFS?
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
>
> ------------------------------------------
> Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg
> Ringstr. 2, D-53567 Buchholz, Germany
> Phone: +49-2683-9793-20, fax: -29
> Mobile/GSM: +49-170-818-9793
> Email: dws@steinberg.dhs.org
>


From owner-linux-xfs@oss.sgi.com Tue May  8 14:30:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48LUbG00531
	for linux-xfs-outgoing; Tue, 8 May 2001 14:30:37 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48LUaF00528
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 14:30:37 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f48LUV116761;
	Tue, 8 May 2001 16:30:31 -0500 (CDT)
Message-ID: <3AF865F4.1150A210@sgi.com>
Date: Tue, 08 May 2001 16:32:36 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
CC: Russell Cattelan <cattelan@thebarn.com>, Ric Tibbetts <ric@chadera.net>,
   Linux XFS List <linux-xfs@oss.sgi.com>
Subject: Re: NFS Export problem
References: <3AF77BFB.5CE8F569@chadera.net> <3AF78EAB.EE871BC0@thebarn.com> <3AF81BCD.32FE3567@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, I can duplicate this w/ the mandrake kernel on a RH 7.1 box.  :) 
(but interestingly, not with TOT from CVS yesterday...?)

I'll see what I can find.

-Eric

Ric Tibbetts wrote:
> 
> Ok, I did some looking at this last night. It appears that the problem comes in
> trying to make the NFS support as a module. The kernel that I have that is
> failing the export, this is the case (NFS Server is a module). I built a "quick
> & dirty" version with the NFS server compiled in, and the export worked fine.
> Now I need to run the same test on my "good" kernel tonight.
> 
> I'll test this more tonight when I get home. But if any of the other folks out
> there that are experienceing this want to build a kernel today, check this area
> out. I'd be interested in seeing the results.
> 
>         Ric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 14:56:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Lur901298
	for linux-xfs-outgoing; Tue, 8 May 2001 14:56:53 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48LuqF01295
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 14:56:52 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id 335B8CE9; Tue,  8 May 2001 14:58:28 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP id A8E5EEB3
	for <linux-xfs@oss.sgi.com>; Tue,  8 May 2001 14:58:27 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSCKT9>; Tue, 8 May 2001 16:56:44 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: linux-xfs@oss.sgi.com
Subject: XFS install from ISO fails utterly
Date: Tue, 8 May 2001 16:56:27 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I tried installing Red Hat 7.1+XFS on a bare Compaq server, and when it was
all over, I got nothing that functioned.

The machine:
	ProLiant 6400 (4x PII Xeon 450 w. 2MB cache)
	4GB RAM
	SmartArray 3200 array controller (raid 5)
	Voodoo 5

The install process went smoothly, but there were numerous "no such file or
directory" errors on reboot. When it eventually hit a login prompt, none of
the filesystems which had been marked as XFS seemed to be present (/boot was
left as ext2).

I've heard that there might be a block size issue with XFS supporting only
4k blocks and the Compaq Array controller supporting only 1k blocks. But I
don't know if that's the issue here.


A couple of other questions:

1) according to the installer, you seem to be able to create a 100% XFS
system, but there's no mention of whether or not LILO has to go into the MBR
to support this. is this still true?
2) many people have recommended leaving /boot as ext2, is this still
advisable?

Thanks!

 michael


Michael J. Venables
Compaq Competitive Analysis
Industry Standard Server Group
20555 SH 249, MS 090803
Houston, Texas 77070-2698
tel:	281.514.9520
fax:	281.514.7450

Of course I use Microsoft. Setting up a stable
UNIX network is no challenge at all...



From owner-linux-xfs@oss.sgi.com Tue May  8 15:09:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48M9Ru01756
	for linux-xfs-outgoing; Tue, 8 May 2001 15:09:27 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48M9QF01753
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:09:26 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48LBf611923;
	Tue, 8 May 2001 16:11:41 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 16:11:41 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Tuning XFS for peak performance. (fwd) 
In-Reply-To: <200105081505.f48F57N08723@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105081611180.11209-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I saw this performance issue in both the sgi "stock: 2.4.2 and dev 2.4.4

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 8 May 2001, Steve Lord wrote:

>
> Are you running the released kernel or the development tree? There are some
> very distinct issues with memory consumption in the 2.4.4 tree right now.
>
> Steve
>
>
> > It's very possible that that's the case, pine, that is, but it's NOT only
> > pine which is slow. It is pretty much all operations, in X. This was NOT
> > the case before however. The only real difference right now, is the advent
> > of XFS. I did a full backup of my system, before reinstalling, and now
> > things are slower. I've tried some things here on the list, biosize,
> > logbuff, etc. I've DEFINITELY gained a noticable amount of speed. I need
> > to tweak something else now. My DMA settings are not an issue, I've got
> > everything turned up as high as my hardware allows. Not to mention, if
> > this was a scsi system, hdparm won't to crap for me. I'm experimenting
> > with this FS on my desktop to see if it's alright for oracle to run on.
> > That may give us some performance increase there, also, I'm trying to
> > tweak it so I know what to do in the event of a performance issue.
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
>


From owner-linux-xfs@oss.sgi.com Tue May  8 15:12:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MCHC01798
	for linux-xfs-outgoing; Tue, 8 May 2001 15:12:17 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f48MCGF01794
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:12:16 -0700
Received: (qmail 25371 invoked by uid 0); 8 May 2001 22:12:14 -0000
Received: from adsl-1-44.adsl.easynet.fr (HELO mail.gmx.de) (212.11.30.44)
  by mail.gmx.net (mail01) with SMTP; 8 May 2001 22:12:14 -0000
Message-ID: <200105090011550419.07A477D1@mail.gmx.de>
In-Reply-To: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Wed, 09 May 2001 00:11:55 +0200
From: "linux" <dahouet@gmx.net>
To: "Venables, Michael" <Michael.Venables@compaq.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f48MCGF01796
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Le 08/05/2001 à 16:56 Venables, Michael a écrit :

>1) according to the installer, you seem to be able to create a 100% XFS
>system, but there's no mention of whether or not LILO has to go into the
>MBR
>to support this. is this still true?
>2) many people have recommended leaving /boot as ext2, is this still
>advisable?

i'm using right now a fully xfs server
with a 2.4.4 kernel.

no /boot ext2, only one / with xfs.
nothing to change from lilo part....

i'm tracking some problem on anormal shutdown and startup
but i can't say if it's a xfs problem.
i'll post these results.

thanks
@++
o


From owner-linux-xfs@oss.sgi.com Tue May  8 15:16:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MGXY01887
	for linux-xfs-outgoing; Tue, 8 May 2001 15:16:33 -0700
Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MGWF01884
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:16:32 -0700
Received: from roujin.gargoylecc.com (IDENT:ringram@roujin.gargoylecc.com [65.100.85.34])
	by roujin.gargoylecc.com (8.9.3/8.9.3) with ESMTP id GAA10959;
	Wed, 9 May 2001 06:49:52 -0600
Date: Wed, 9 May 2001 06:49:52 -0600 (MDT)
From: Russel Ingram <ringram@gargoylecc.com>
To: J Landman <landman@mediaone.net>
cc: Eric Sandeen <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: Re: question on XFS+devfsd, and a quick suggestion
In-Reply-To: <Pine.LNX.4.32.0105081617260.28848-100000@dsl-squash.corp.sgi.com>
Message-ID: <Pine.LNX.4.33.0105090638340.10914-100000@roujin.gargoylecc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 8 May 2001, J Landman wrote:

> > Disk druid only handles partitioning, this is (mostly) unrelated to
> > filesystem selection.  Both XFS and ext2 _do_ live on the same type of
> > partition ("Linux Native").
>
> True, with the caveat that the usual course of most installers (the RedHat
> in particular) ask you the mount point and the file system type at the
> point of creation of the partition (the custom partitioner in particular).
> The RedHat tool (launched from the XFS install CD) lets you create a /
> mount point, as a Linux native file system.  It doesn't indicate XFS as an
> option.  If this option can be selected later, I would like to point out

You're still confusing partition types with filesystem types here.  Disk
Druid may ask you for a mount point but that is the only option that has
anything to do with filesystems.  The "Linux native" option listed is the
partition type and refers to 0x83 as opposed to 0x82 for "Linux swap" or
0x06 for "DOS FAT16".


-- 
Russ Ingram
Gargoyle Computer Consulting
(307)742-1361
www.gargoylecc.com



From owner-linux-xfs@oss.sgi.com Tue May  8 15:16:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MGuJ01898
	for linux-xfs-outgoing; Tue, 8 May 2001 15:16:56 -0700
Received: from carlo.dirksteinberg.de (pD95840DF.dip.t-dialin.net [217.88.64.223])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MGrF01895
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:16:53 -0700
Received: from steinberg.dhs.org (localhost [127.0.0.1])
	by carlo.dirksteinberg.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id f48MGpR13907
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:16:51 +0200
X-Authentication-Warning: carlo.dirksteinberg.de: Host localhost [127.0.0.1] claimed to be steinberg.dhs.org
Message-ID: <3AF87052.4724FD80@steinberg.dhs.org>
Date: Wed, 09 May 2001 00:16:50 +0200
From: Dirk Steinberg <dws@steinberg.dhs.org>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2-4GB i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
References: <Pine.LNX.4.33.0105081614240.11209-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f48MGtF01896
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

Yes. It really works. No cheating involved... :-)

BTW: Does anyone know if it is possible to shrink
an XFS filesystem? It's possible to shrink an
ext2 filesystem with resize2fs, and LVM volumes
can also be shrunk with lvreduce.

It would be a shame if XFS would be lacking this
feature...

Cheers,
	Dirk

------------------------------------------
Ingenieurbüro Dipl.-Ing. Dirk W. Steinberg
Ringstr. 2, D-53567 Buchholz, Germany
Phone: +49-2683-9793-20, fax: -29
Mobile/GSM: +49-170-818-9793
Email: dws@steinberg.dhs.org

# mount /dev/nilab01/test /mnt
# df /mnt
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/nilab01/test
               xfs     95M  112k   95M   1% /mnt
# lvextend -L +10M /dev/nilab01/test    
lvextend
lvextend -- rounding size to physical extent boundary
lvextend -- extending logical volume "/dev/nilab01/test" to 112 MB
lvextend -- doing automatic backup of volume group "nilab01"
lvextend -- logical volume "/dev/nilab01/test" successfully extended

# df /mnt
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/nilab01/test
               xfs     95M  112k   95M   1% /mnt
# xfs_growfs /mnt          
meta-data=/mnt                   isize=256    agcount=6, agsize=4267 blks
data     =                       bsize=4096   blocks=25600, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 25600 to 28672
# df /mnt        
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/nilab01/test
               xfs    107M  128k  107M   1% /mnt
# lvextend -L +100M /dev/nilab01/test 
lvextend
lvextend -- extending logical volume "/dev/nilab01/test" to 212 MB
lvextend -- doing automatic backup of volume group "nilab01"
lvextend -- logical volume "/dev/nilab01/test" successfully extended

# xfs_growfs /mnt                     
meta-data=/mnt                   isize=256    agcount=7, agsize=4267 blks
data     =                       bsize=4096   blocks=28672, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 28672 to 54272
# df /mnt
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/nilab01/test
               xfs    207M  224k  207M   1% /mnt
# 

Austin Gonyou wrote:
> 
> Dood!!! Thanks! Ok, so now that I see that it can work and seems to work
> well. I'd like to ask one more question..to be fare. I didn't see a df
> output after you created the first volume. Could we see that?, just to get
> the "before and after" snapshot?
> 
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Tue, 8 May 2001, Dirk Steinberg wrote:
> 
> > XFS + LVM works. Expanding works, too.
> >
> > Very easy. Convenient. Just try it. Running Redhat 7.1 + XFS 1.0.
> >
> > # lvcreate -n test -L 100M nilab01
> > lvcreate
> > lvcreate -- doing automatic backup of "nilab01"
> > lvcreate -- logical volume "/dev/nilab01/test" successfully created
> >
> > # mkfs.xfs /dev/nilab01/test
> > meta-data=/dev/nilab01/test      isize=256    agcount=6, agsize=4267 blks
> > data     =                       bsize=4096   blocks=25600, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal log           bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > # mount /dev/nilab01/test /mnt
> > # lvextend -L +10M /dev/nilab01/test
> > lvextend
> > lvextend -- rounding size to physical extent boundary
> > lvextend -- extending logical volume "/dev/nilab01/test" to 112 MB
> > lvextend -- doing automatic backup of volume group "nilab01"
> > lvextend -- logical volume "/dev/nilab01/test" successfully extended
> >
> > # xfs_growfs /mnt
> > meta-data=/mnt                   isize=256    agcount=6, agsize=4267 blks
> > data     =                       bsize=4096   blocks=25600, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > data blocks changed from 25600 to 28672
> > # df /mnt
> > Filesystem    Type    Size  Used Avail Use% Mounted on
> > /dev/nilab01/test
> >                xfs    107M  128k  107M   1% /mnt
> > # umount /mnt
> > # lvremove  /dev/nilab01/test
> > lvremove
> > lvremove -- do you really want to remove "/dev/nilab01/test"? [y/n]: y
> > lvremove -- doing automatic backup of volume group "nilab01"
> > lvremove -- logical volume "/dev/nilab01/test" successfully removed
> >
> > #
> >
> > Austin Gonyou wrote:
> > >
> > > Is this in the works? Has anyone tried this? Can MD devices be used and
> > > expanded if formatted with XFS?

From owner-linux-xfs@oss.sgi.com Tue May  8 15:25:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MPKW02078
	for linux-xfs-outgoing; Tue, 8 May 2001 15:25:20 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MPIF02072
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:25:19 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA956896
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:25:16 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1744777; Tue, 8 May 2001 17:23:53 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA65760; Tue, 8 May 2001 17:23:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f48MQXU18767; Tue, 8 May 2001 17:26:33 -0500
Message-Id: <200105082226.f48MQXU18767@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Venables, Michael" <Michael.Venables@compaq.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly 
In-Reply-To: Message from "Venables, Michael" <Michael.Venables@compaq.com> 
   of "Tue, 08 May 2001 16:56:27 CDT." <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net> 
Date: Tue, 08 May 2001 17:26:33 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> I tried installing Red Hat 7.1+XFS on a bare Compaq server, and when it was
> all over, I got nothing that functioned.

Ugh, I have to leave installer problems to Eric he has helped a number of
people through things like this. Do you know if a vanilla 7.1 install works
on this hardware setup? 

> 
> The machine:
> 	ProLiant 6400 (4x PII Xeon 450 w. 2MB cache)
> 	4GB RAM
> 	SmartArray 3200 array controller (raid 5)
> 	Voodoo 5
> 
> The install process went smoothly, but there were numerous "no such file or
> directory" errors on reboot. When it eventually hit a login prompt, none of
> the filesystems which had been marked as XFS seemed to be present (/boot was
> left as ext2).


> 
> I've heard that there might be a block size issue with XFS supporting only
> 4k blocks and the Compaq Array controller supporting only 1k blocks. But I
> don't know if that's the issue here.


Hmm, I will have to leave it up to other people on the list to comment
on this

> 
> 
> A couple of other questions:
> 
> 1) according to the installer, you seem to be able to create a 100% XFS
> system, but there's no mention of whether or not LILO has to go into the MBR
> to support this. is this still true?

Yes you have to use either the MBR, or a non xfs partition for lilo (swap
actually works), the issue is that xfs starts at block zero in a partition
and hence leaves no room for lilo within the partition itself.

> 2) many people have recommended leaving /boot as ext2, is this still
> advisable?

Lilo works just fine on xfs partitions, with the exception of the above
caveat.

> 
> Thanks!
> 
>  michael
> 
> 
> Michael J. Venables
> Compaq Competitive Analysis
> Industry Standard Server Group
> 20555 SH 249, MS 090803
> Houston, Texas 77070-2698
> tel:	281.514.9520
> fax:	281.514.7450
> 
> Of course I use Microsoft. Setting up a stable
> UNIX network is no challenge at all...
> 



From owner-linux-xfs@oss.sgi.com Tue May  8 15:27:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MRM002184
	for linux-xfs-outgoing; Tue, 8 May 2001 15:27:22 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MRLF02179
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:27:21 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id 10125162; Tue,  8 May 2001 15:28:58 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id 6B25C3B4; Tue,  8 May 2001 15:28:57 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSCNHD>; Tue, 8 May 2001 17:27:13 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88CF0@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: RE: XFS install from ISO fails utterly 
Date: Tue, 8 May 2001 17:26:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Sorry, I meant to say that after several failed XFS installs, I tried just a
standard RH install. That worked perfectly.


-----Original Message-----
From: Steve Lord [mailto:lord@sgi.com]
Sent: Tuesday, May 08, 2001 5:27 PM
To: Venables, Michael
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly 


> 
> I tried installing Red Hat 7.1+XFS on a bare Compaq server, and when it
was
> all over, I got nothing that functioned.

Ugh, I have to leave installer problems to Eric he has helped a number of
people through things like this. Do you know if a vanilla 7.1 install works
on this hardware setup? 

> 
> The machine:
> 	ProLiant 6400 (4x PII Xeon 450 w. 2MB cache)
> 	4GB RAM
> 	SmartArray 3200 array controller (raid 5)
> 	Voodoo 5
> 
> The install process went smoothly, but there were numerous "no such file
or
> directory" errors on reboot. When it eventually hit a login prompt, none
of
> the filesystems which had been marked as XFS seemed to be present (/boot
was
> left as ext2).


> 
> I've heard that there might be a block size issue with XFS supporting only
> 4k blocks and the Compaq Array controller supporting only 1k blocks. But I
> don't know if that's the issue here.


Hmm, I will have to leave it up to other people on the list to comment
on this

> 
> 
> A couple of other questions:
> 
> 1) according to the installer, you seem to be able to create a 100% XFS
> system, but there's no mention of whether or not LILO has to go into the
MBR
> to support this. is this still true?

Yes you have to use either the MBR, or a non xfs partition for lilo (swap
actually works), the issue is that xfs starts at block zero in a partition
and hence leaves no room for lilo within the partition itself.

> 2) many people have recommended leaving /boot as ext2, is this still
> advisable?

Lilo works just fine on xfs partitions, with the exception of the above
caveat.

> 
> Thanks!
> 
>  michael
> 
> 
> Michael J. Venables
> Compaq Competitive Analysis
> Industry Standard Server Group
> 20555 SH 249, MS 090803
> Houston, Texas 77070-2698
> tel:	281.514.9520
> fax:	281.514.7450
> 
> Of course I use Microsoft. Setting up a stable
> UNIX network is no challenge at all...
> 


From owner-linux-xfs@oss.sgi.com Tue May  8 15:35:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MZwd02347
	for linux-xfs-outgoing; Tue, 8 May 2001 15:35:58 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MZvF02340
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:35:57 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f48MZsf07561;
	Tue, 8 May 2001 17:35:54 -0500 (CDT)
Message-ID: <3AF87548.FC54D1AD@sgi.com>
Date: Tue, 08 May 2001 17:38:00 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi -

Somebody asked for the installer guy?  :)

"Venables, Michael" wrote:
> 
> I tried installing Red Hat 7.1+XFS on a bare Compaq server, and when it was
> all over, I got nothing that functioned.
> 
> The machine:
>         ProLiant 6400 (4x PII Xeon 450 w. 2MB cache)
>         4GB RAM
>         SmartArray 3200 array controller (raid 5)
>         Voodoo 5
> 
> The install process went smoothly, but there were numerous "no such file or
> directory" errors on reboot. When it eventually hit a login prompt, none of
> the filesystems which had been marked as XFS seemed to be present (/boot was
> left as ext2).

The "no such file" stuff sounds like it _might_ be another devfs thing,
but I'd suspect the raid controller, see below.

How did you configure your system - what mount points were XFS?

> I've heard that there might be a block size issue with XFS supporting only
> 4k blocks and the Compaq Array controller supporting only 1k blocks. But I
> don't know if that's the issue here.

Also, Martin checked in some raid changes for BLKBSZSET and BLKBSZGET
ioctls - I think that mount will fail without this change?  

Martin says:

> The ... driver didn't support the ioctl for setting the software
> blocksize, so our last superblock ends up at a wrong offset causing
> mount to fail

Maybe Martin can comment if he's around...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 15:38:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48McJq02467
	for linux-xfs-outgoing; Tue, 8 May 2001 15:38:19 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48McIF02464
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:38:18 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA00178
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:38:16 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1746892; Tue, 8 May 2001 17:36:59 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA80336; Tue, 8 May 2001 17:36:59 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f48MddS18787; Tue, 8 May 2001 17:39:39 -0500
Message-Id: <200105082239.f48MddS18787@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dirk Steinberg <dws@steinberg.dhs.org>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS + LVM + Epanding; shrinking XFS?? 
In-Reply-To: Message from Dirk Steinberg <dws@steinberg.dhs.org> 
   of "Wed, 09 May 2001 00:16:50 +0200." <3AF87052.4724FD80@steinberg.dhs.org> 
Content-Transfer-Encoding: 8bit
Date: Tue, 08 May 2001 17:39:39 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> Yes. It really works. No cheating involved... :-)
> 
> BTW: Does anyone know if it is possible to shrink
> an XFS filesystem? It's possible to shrink an
> ext2 filesystem with resize2fs, and LVM volumes
> can also be shrunk with lvreduce.
> 
> It would be a shame if XFS would be lacking this
> feature...
> 
> Cheers,
> 	Dirk

I answered this one a long time ago, unfortunately no, you cannot shrink xfs,
growing is really easy, shrink is a lot of work, and ext2 metadata is really
simple compared to XFS. However, if someone wants to take it on I would be
happy to offer suggestions on what needs doing.

Steve



From owner-linux-xfs@oss.sgi.com Tue May  8 15:43:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Mh4902541
	for linux-xfs-outgoing; Tue, 8 May 2001 15:43:04 -0700
Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48Mh3F02538
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:43:03 -0700
Received: by chiara.elte.hu (Postfix, from userid 17000)
	id 05C261FC7; Wed,  9 May 2001 00:43:00 +0200 (CEST)
Date: Wed, 9 May 2001 00:43:00 +0200
From: KELEMEN Peter <fuji@elte.hu>
To: Dirk Steinberg <dws@steinberg.dhs.org>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
Message-ID: <20010509004300.A13460@chiara.elte.hu>
Reply-To: KELEMEN Peter <fuji@elte.hu>
References: <Pine.LNX.4.33.0105081614240.11209-100000@UberGeek.coremetrics.com> <3AF87052.4724FD80@steinberg.dhs.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AF87052.4724FD80@steinberg.dhs.org>; from dws@steinberg.dhs.org on Wed, May 09, 2001 at 12:16:50AM +0200
Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary
X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20
X-GPG-Fingerprint: D402 4AF3 7488 165B CC34  4147 7F0C D922 EE4C 26E8
X-PGP-KeyID: 1024/45F83E45 1998/04/04
X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD  6D AA B5 8A D6 03 0F BF
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Dirk Steinberg (dws@steinberg.dhs.org) [20010509 00:16]:

> BTW: Does anyone know if it is possible to shrink an XFS
> filesystem? It's possible to shrink an ext2 filesystem with
> resize2fs, and LVM volumes can also be shrunk with lvreduce.

AFAIK due to internal fs layout, shrinking would involve major
pain to perform.  Better off dumping the filesystem to tape and
create a (smaller) new one.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \       /      fuji@elte.hu
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From owner-linux-xfs@oss.sgi.com Tue May  8 15:45:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MjYQ02585
	for linux-xfs-outgoing; Tue, 8 May 2001 15:45:34 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MjXF02582
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:45:33 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xGEU-0008Br-00; Wed, 09 May 2001 00:45:31 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f48Mibx11052;
	Tue, 8 May 2001 18:44:37 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: "Venables, Michael" <Michael.Venables@compaq.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 08 May 2001 18:44:37 -0400
In-Reply-To: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
Message-ID: <yq166fbihpm.fsf@jcb.mkp.net>
Lines: 19
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


MV> I tried installing Red Hat 7.1+XFS on a bare Compaq server, and
MV> when it was all over, I got nothing that functioned.

That's probably due to the BLKBSZSET ioctl issue I fixed a few days
ago.  We saw that on Mylex DAC controllers too (Insert rant about
drivers bypassing existing interfaces here).

It would be helpful if you could check the installer error message
console (Alt-F4, IIrc) for messages after the filesystems have been
formatted.  Chances are it will complain about bad ioctls.

If that's the case, please let us know.  And I guess you'll have to
hold your breath until we do a respin.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May  8 15:48:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MmXY02650
	for linux-xfs-outgoing; Tue, 8 May 2001 15:48:33 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MmWF02647
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:48:32 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id B7710EAB; Tue,  8 May 2001 15:50:08 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id 4F03A1E4; Tue,  8 May 2001 15:50:08 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSC3T2>; Tue, 8 May 2001 17:48:03 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88CF1@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: RE: XFS install from ISO fails utterly
Date: Tue, 8 May 2001 17:48:00 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


the mount points were as follows:

	/		256MB	XFS
	/boot		64	ext2 (also tried as XFS)
	/var		512	XFS
	/tmp		512	XFS
	/usr		4GB	XFS
	/home		20GB	XFS

	swap		256MB


-----Original Message-----
From: Eric Sandeen [mailto:sandeen@sgi.com]
Sent: Tuesday, May 08, 2001 5:38 PM
To: Venables, Michael
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly


Hi -

Somebody asked for the installer guy?  :)

"Venables, Michael" wrote:
> 
> I tried installing Red Hat 7.1+XFS on a bare Compaq server, and when it
was
> all over, I got nothing that functioned.
> 
> The machine:
>         ProLiant 6400 (4x PII Xeon 450 w. 2MB cache)
>         4GB RAM
>         SmartArray 3200 array controller (raid 5)
>         Voodoo 5
> 
> The install process went smoothly, but there were numerous "no such file
or
> directory" errors on reboot. When it eventually hit a login prompt, none
of
> the filesystems which had been marked as XFS seemed to be present (/boot
was
> left as ext2).

The "no such file" stuff sounds like it _might_ be another devfs thing,
but I'd suspect the raid controller, see below.

How did you configure your system - what mount points were XFS?

> I've heard that there might be a block size issue with XFS supporting only
> 4k blocks and the Compaq Array controller supporting only 1k blocks. But I
> don't know if that's the issue here.

Also, Martin checked in some raid changes for BLKBSZSET and BLKBSZGET
ioctls - I think that mount will fail without this change?  

Martin says:

> The ... driver didn't support the ioctl for setting the software
> blocksize, so our last superblock ends up at a wrong offset causing
> mount to fail

Maybe Martin can comment if he's around...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 15:50:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48MoYP02690
	for linux-xfs-outgoing; Tue, 8 May 2001 15:50:34 -0700
Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MoXF02687
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:50:33 -0700
Received: from burns.home.kernel.dk ([192.168.0.2] ident=root)
	by virtualhost.dk with esmtp (Exim 3.22 #4)
	id 14xGIk-0002qc-00; Wed, 09 May 2001 00:49:54 +0200
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 14xGIY-0000de-00; Wed, 09 May 2001 00:49:42 +0200
Date: Wed, 9 May 2001 00:49:42 +0200
From: Jens Axboe <axboe@suse.de>
To: "Martin K. Petersen" <mkp@linuxcare.com>
Cc: "Venables, Michael" <Michael.Venables@compaq.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
Message-ID: <20010509004942.G521@suse.de>
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net> <yq166fbihpm.fsf@jcb.mkp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <yq166fbihpm.fsf@jcb.mkp.net>; from mkp@linuxcare.com on Tue, May 08, 2001 at 06:44:37PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 08 2001, Martin K. Petersen wrote:
> That's probably due to the BLKBSZSET ioctl issue I fixed a few days
> ago.  We saw that on Mylex DAC controllers too (Insert rant about
> drivers bypassing existing interfaces here).

Bypassing what interfaces? I'm assuming you implemented BLKBSZSET as a
general block ioctl in blkpg, no? Which dac and cpq/cciss just had to
feed through?

-- 
Jens Axboe


From owner-linux-xfs@oss.sgi.com Tue May  8 15:54:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Msn702736
	for linux-xfs-outgoing; Tue, 8 May 2001 15:54:49 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48MslF02733
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 15:54:48 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA1037827
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:54:45 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA36953; Tue, 8 May 2001 17:53:28 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f48MqSe05652;
	Tue, 8 May 2001 18:52:28 -0400
Message-ID: <3AF878AA.F01E131C@thebarn.com>
Date: Tue, 08 May 2001 18:52:26 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>
>
> The install process went smoothly, but there were numerous "no such file or
> directory" errors on reboot. When it eventually hit a login prompt, none of
> the filesystems which had been marked as XFS seemed to be present (/boot was
> left as ext2).

What were the missing files?
/dev/tty?

you didn't happen to not install devfsd for some reason?


--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May  8 16:07:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48N7IX03436
	for linux-xfs-outgoing; Tue, 8 May 2001 16:07:18 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N7GF03433
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:07:16 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xGZX-0008DJ-00; Wed, 09 May 2001 01:07:15 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f48N6NE11090;
	Tue, 8 May 2001 19:06:23 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Jens Axboe <axboe@suse.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net>
	<yq166fbihpm.fsf@jcb.mkp.net> <20010509004942.G521@suse.de>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 08 May 2001 19:06:23 -0400
In-Reply-To: <20010509004942.G521@suse.de>
Message-ID: <yq1wv7rh24w.fsf@jcb.mkp.net>
Lines: 16
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Jens" == Jens Axboe <axboe@suse.de> writes:

Jens> Bypassing what interfaces? 

IDE and SCSI :)


Jens> I'm assuming you implemented BLKBSZSET as a general block ioctl
Jens> in blkpg, no? Which dac and cpq/cciss just had to feed through?

Indeed.  One liners (Well, two. But whatever).

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May  8 16:07:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48N7R803453
	for linux-xfs-outgoing; Tue, 8 May 2001 16:07:27 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N7RF03450
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:07:27 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f48N6FG12743;
	Tue, 8 May 2001 18:06:15 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 8 May 2001 18:06:15 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: KELEMEN Peter <fuji@elte.hu>
cc: Dirk Steinberg <dws@steinberg.dhs.org>, <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
In-Reply-To: <20010509004300.A13460@chiara.elte.hu>
Message-ID: <Pine.LNX.4.33.0105081805180.11209-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, here's a REALLY hard question then. How can you grow, with LVM, a XFS
filesystem, that is a LVM raid0? MD's maybe? Anyone?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 9 May 2001, KELEMEN Peter wrote:

> * Dirk Steinberg (dws@steinberg.dhs.org) [20010509 00:16]:
>
> > BTW: Does anyone know if it is possible to shrink an XFS
> > filesystem? It's possible to shrink an ext2 filesystem with
> > resize2fs, and LVM volumes can also be shrunk with lvreduce.
>
> AFAIK due to internal fs layout, shrinking would involve major
> pain to perform.  Better off dumping the filesystem to tape and
> create a (smaller) new one.
>
> Peter
>
>


From owner-linux-xfs@oss.sgi.com Tue May  8 16:08:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48N8kD03479
	for linux-xfs-outgoing; Tue, 8 May 2001 16:08:46 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N8jF03476
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:08:45 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1005009
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 01:08:42 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA25574; Tue, 8 May 2001 18:07:25 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f48N6Pe05698;
	Tue, 8 May 2001 19:06:25 -0400
Message-ID: <3AF87BF1.6FF99FFF@thebarn.com>
Date: Tue, 08 May 2001 19:06:25 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: lin rao <linrao@hotmail.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: cvs was refused.
References: <200105082146.f48Lk9l01124@oss.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

lin rao wrote:

> This message was sent from http://linux-xfs.sgi.com/projects/xfs/cvs_download.html
>
> ----
>
> I tried to cvs the source using a cvs client for NT. At the CVS password prompt, I used cvs as password as suggested by the cvs download instruction. I was refused for the connection.
> Here is the console display:
>
> E:\\cvs>set CVSROOT=:pserver:cvs@oss.sgi.com:/cvs
>
> E:\\cvs>cvs login
> \(Logging in to cvs@oss.sgi.com\)
> CVS password:
> cvs \[login aborted\]: connect to oss.sgi.com:2401 failed: Connection refused.
>
> Why the connection was refused\?
> Thans.

Sorry really don't have any idea.
Are you behind some sort of firewall?


gibble[6:01pm]-=>telnet oss.sgi.com 2401
Trying 216.32.174.190...
Connected to oss.sgi.com.
Escape character is '^]'.


--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May  8 16:09:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48N9uS03511
	for linux-xfs-outgoing; Tue, 8 May 2001 16:09:56 -0700
Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48N9tF03508
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:09:56 -0700
Received: from burns.home.kernel.dk ([192.168.0.2] ident=root)
	by virtualhost.dk with esmtp (Exim 3.22 #4)
	id 14xGc5-0002wY-00; Wed, 09 May 2001 01:09:53 +0200
Received: from axboe by burns.home.kernel.dk with local (Exim 3.13 #1 (Debian))
	id 14xGbt-0000ht-00; Wed, 09 May 2001 01:09:41 +0200
Date: Wed, 9 May 2001 01:09:41 +0200
From: Jens Axboe <axboe@suse.de>
To: "Martin K. Petersen" <mkp@linuxcare.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly
Message-ID: <20010509010941.I521@suse.de>
References: <8C91B010B3B7994C88A266E1A72184D3C88CED@cceexc19.americas.cpqcorp.net> <yq166fbihpm.fsf@jcb.mkp.net> <20010509004942.G521@suse.de> <yq1wv7rh24w.fsf@jcb.mkp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <yq1wv7rh24w.fsf@jcb.mkp.net>; from mkp@linuxcare.com on Tue, May 08, 2001 at 07:06:23PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 08 2001, Martin K. Petersen wrote:
> >>>>> "Jens" == Jens Axboe <axboe@suse.de> writes:
> 
> Jens> Bypassing what interfaces? 
> 
> IDE and SCSI :)

Bad, they are :-)

-- 
Jens Axboe


From owner-linux-xfs@oss.sgi.com Tue May  8 16:29:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48NTd903842
	for linux-xfs-outgoing; Tue, 8 May 2001 16:29:39 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48NTcF03839
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:29:38 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA10295
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:28:15 -0700 (PDT)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00764; Wed, 9 May 2001 09:28:20 +1000
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA99534; Wed, 9 May 2001 09:28:18 +1000 (EST)
Date: Wed, 9 May 2001 09:28:17 +1000
From: Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To: "Schincke, Keith" <kschin@lynx.unf.edu>
Cc: "Xfs (E-mail)" <linux-xfs@oss.sgi.com>
Subject: Re: chacl question
Message-ID: <20010509092817.A98491@fudge.melbourne.sgi.com>
References: <CFB7B892437FD21183DC0020484017EB0A7794CE@lynx.unf.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <CFB7B892437FD21183DC0020484017EB0A7794CE@lynx.unf.edu>; from kschin@lynx.unf.edu on Tue, May 08, 2001 at 04:22:14PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 08, 2001 at 04:22:14PM -0400, Schincke, Keith wrote:
> I have used the ACL support that Tru64 Unix uses in their file system. Their
> setacl command allows the setting of an individual ACL permission "setacl -d
> -u user:luser:rw-".
> 
> My question is is there any plans to implement chacl in this way? Unless I
> missed something, I have to type in the whole list of ACLs just to add a new
> one.  It would make it easier than having to retype a long acl entry just to
> add a new person to the list.
> 

No there are no plans to change chacl in the short term, probably the
easiest thing is to do a chacl -l foo and cut paste and edit. Alternatively
munge the output with sed and use a command alias (along the lines of
the example given in the man page).

Andrew

-- 
Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia
email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183

From owner-linux-xfs@oss.sgi.com Tue May  8 16:46:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48Nkwo04227
	for linux-xfs-outgoing; Tue, 8 May 2001 16:46:58 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48NkuF04224
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:46:56 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xHBv-0008Fy-00; Wed, 09 May 2001 01:46:55 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f48Nk1t11126;
	Tue, 8 May 2001 19:46:01 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
References: <Pine.LNX.4.33.0105081805180.11209-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 08 May 2001 19:46:01 -0400
In-Reply-To: <Pine.LNX.4.33.0105081805180.11209-100000@UberGeek.coremetrics.com>
Message-ID: <yq1eltzh0au.fsf@jcb.mkp.net>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> Ok, here's a REALLY hard question then. How can you grow, with
Austin> LVM, a XFS filesystem, that is a LVM raid0? 

Just do it<tm>

LVM stripes data across its allocation units (PEs/LEs), and when
you're extending you're just adding more extents to the pool.

The allocator will most likely round your specified size to a stripe
boundary.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May  8 16:58:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f48NwVB04655
	for linux-xfs-outgoing; Tue, 8 May 2001 16:58:31 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f48NwTF04648
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 16:58:29 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA07065
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 17:09:17 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00984; Wed, 9 May 2001 09:57:11 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA69927;
	Wed, 9 May 2001 09:57:10 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105090957.ZM72341@wobbly.melbourne.sgi.com>
Date: Wed, 9 May 2001 09:57:08 -0500
In-Reply-To: <marchuk@ee.washington.edu>
        "XFS 1.0/Quota" (May  8, 10:02am)
References: <Pine.LNX.4.21.0105081000470.11379-100000@darkstar.ee.washington.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: <marchuk@ee.washington.edu>, linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0/Quota
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.110105090957.ZM72341.melbourne.sgi.com"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

--
--PART-BOUNDARY=.110105090957.ZM72341.melbourne.sgi.com
Content-Type: text/plain; charset=us-ascii

hi,

On May 8, 10:02am, <marchuk@ee.washington.edu> wrote:
> Subject: XFS 1.0/Quota
> Does quota work on XFS 1.0? 

Yes, with a couple of caveats.

The first problem was that the XFS code and the Redhat patches
did not get merged correctly, so a system from the modified
installer will not work with quota currently.  A patch to fix
this was sent out a few days ago.

Secondly, the quota userspace interacts badly with some versions
of libc - a change to the quota-tools fixed this & this patch
was also sent out a few days ago, and has been incorporated into
the cvs tree at http://sourceforge.net/projects/linuxquota/ .

I've attached the two patches - the first is a patch to the
XFS1.0+Redhat7.1 kernel, the second is a patch to the 
quota-3.01-pre5 user tools.

Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
kernel patches, quota works without any patching at all.

cheers.

-- 
Nathan

--PART-BOUNDARY=.110105090957.ZM72341.melbourne.sgi.com
X-Zm-Content-Name: xfs1.0+redhat.patch
Content-Description: Text
Content-Type: text/plain ; name="xfs1.0+redhat.patch" ; charset=us-ascii

--- fs/dquot.c.orig	Fri May  4 10:17:40 2001
+++ fs/dquot.c	Fri May  4 11:02:13 2001
@@ -2001,7 +2001,7 @@
 	type = cmd & SUBCMDMASK;
 
 
-	if ((uint) type >= MAXQUOTAS || cmds > 0x0F00 || cmds < 0x100 || cmds == 0x0300 ||
+	if ((uint) type >= MAXQUOTAS || cmds < 0x100 || cmds == 0x0300 ||
 	    cmds == 0x0400 || cmds == 0x0500)
 		goto out;
 
@@ -2049,9 +2049,6 @@
 		unlock_kernel();
 		return sb->s_op->quotactl(sb, cmds, type, id, addr);
 	}
-
-	if (id & ~0xFFFF)
-		goto out;
 
 	ret = -EINVAL;
 	switch (cmds) {

--PART-BOUNDARY=.110105090957.ZM72341.melbourne.sgi.com
X-Zm-Content-Name: infinite.patch
Content-Description: Text
Content-Type: text/plain ; name="infinite.patch" ; charset=us-ascii

diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/convertquota.c cvs/quota-tools/convertquota.c
--- pre5/quota-tools/convertquota.c	Wed May  2 02:35:34 2001
+++ cvs/quota-tools/convertquota.c	Fri May  4 16:51:09 2001
@@ -72,7 +72,7 @@
 	mntpoint = argstr[optind];
 }
 
-int convert_dquot(struct dquot *dquot)
+int convert_dquot(struct dquot *dquot, char *name)
 {
 	struct dquot newdquot;
 
@@ -88,8 +88,8 @@
 	newdquot.dq_dqb.dqb_btime = dquot->dq_dqb.dqb_btime;
 	newdquot.dq_dqb.dqb_itime = dquot->dq_dqb.dqb_itime;
 	if (qn->qh_ops->commit_dquot(&newdquot) < 0) {
-		errstr(_("Can't commit dquot for id %u: %s\n"),
-			(uint)dquot->dq_id, strerror(errno));
+		errstr(_("Can't commit dquot for id %u (%s): %s\n"),
+			(uint)dquot->dq_id, name, strerror(errno));
 		return -1;
 	}
 	return 0;
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio.h cvs/quota-tools/quotaio.h
--- pre5/quota-tools/quotaio.h	Wed May  2 03:19:18 2001
+++ cvs/quota-tools/quotaio.h	Fri May  4 15:57:40 2001
@@ -122,7 +122,7 @@
 	int (*write_info) (struct quota_handle * h);	/* Write info about quotafile */
 	struct dquot *(*read_dquot) (struct quota_handle * h, qid_t id);	/* Read dquot into memory */
 	int (*commit_dquot) (struct dquot * dquot);	/* Write given dquot to disk */
-	int (*scan_dquots) (struct quota_handle * h, int (*process_dquot) (struct dquot * dquot));	/* Scan quotafile and call callback on every structure */
+	int (*scan_dquots) (struct quota_handle * h, int (*process_dquot) (struct dquot * dquot, char * dqname));	/* Scan quotafile and call callback on every structure */
 	int (*report) (struct quota_handle * h, int verbose);	/* Function called after 'repquota' to print format specific file information */
 };
 
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_v1.c cvs/quota-tools/quotaio_v1.c
--- pre5/quota-tools/quotaio_v1.c	Wed May  2 19:32:22 2001
+++ cvs/quota-tools/quotaio_v1.c	Fri May  4 15:59:43 2001
@@ -46,13 +46,14 @@
 #include "quotaio_v1.h"
 #include "dqblk_v1.h"
 #include "quotaio.h"
+#include "quotasys.h"
 
 static int v1_init_io(struct quota_handle *h);
 static int v1_new_io(struct quota_handle *h);
 static int v1_write_info(struct quota_handle *h);
 static struct dquot *v1_read_dquot(struct quota_handle *h, qid_t id);
 static int v1_commit_dquot(struct dquot *dquot);
-static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 
 struct quotafile_ops quotafile_ops_1 = {
 init_io:	v1_init_io,
@@ -281,9 +282,10 @@
 /*
  *	Scan all dquots in file and call callback on each
  */
-static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int v1_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *, char *))
 {
 	int rd;
+	char name[MAXNAMELEN];
 	struct v1_disk_dqblk ddqblk;
 	struct dquot *dquot = get_empty_dquot();
 	qid_t id = 0;
@@ -303,7 +305,8 @@
 			continue;
 		v1_disk2memdqblk(&dquot->dq_dqb, &ddqblk);
 		dquot->dq_id = id;
-		if ((rd = process_dquot(dquot)) < 0) {
+		id2name(dquot->dq_id, h->qh_type, name);
+		if ((rd = process_dquot(dquot, name)) < 0) {
 			free(dquot);
 			return rd;
 		}
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_v2.c cvs/quota-tools/quotaio_v2.c
--- pre5/quota-tools/quotaio_v2.c	Wed May  2 20:00:57 2001
+++ cvs/quota-tools/quotaio_v2.c	Fri May  4 15:59:20 2001
@@ -17,6 +17,7 @@
 #include "quotaio_v2.h"
 #include "dqblk_v2.h"
 #include "quotaio.h"
+#include "quotasys.h"
 
 typedef char *dqbuf_t;
 
@@ -25,7 +26,7 @@
 static int v2_write_info(struct quota_handle *h);
 static struct dquot *v2_read_dquot(struct quota_handle *h, qid_t id);
 static int v2_commit_dquot(struct dquot *dquot);
-static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 static int v2_report(struct quota_handle *h, int verbose);
 
 struct quotafile_ops quotafile_ops_2 = {
@@ -656,11 +657,12 @@
 #define get_bit(bmp, ind) ((bmp)[(ind) >> 3] & (1 << ((ind) & 7)))
 
 static int report_block(struct dquot *dquot, uint blk, char *bitmap,
-			int (*process_dquot) (struct dquot *))
+			int (*process_dquot) (struct dquot *, char *))
 {
 	dqbuf_t buf = getdqbuf();
 	struct v2_disk_dqdbheader *dh;
 	struct v2_disk_dqblk *ddata;
+	char name[MAXNAMELEN];
 	int entries, i;
 
 	set_bit(bitmap, blk);
@@ -672,7 +674,8 @@
 		if (!empty_dquot(ddata + i)) {
 			v2_disk2memdqblk(&dquot->dq_dqb, ddata + i);
 			dquot->dq_id = __le32_to_cpu(ddata[i].dqb_id);
-			if (process_dquot(dquot) < 0)
+			id2name(dquot->dq_id, dquot->dq_h->qh_type, name);
+			if (process_dquot(dquot, name) < 0)
 				break;
 		}
 	freedqbuf(buf);
@@ -680,7 +683,7 @@
 }
 
 static int report_tree(struct dquot *dquot, uint blk, int depth, char *bitmap,
-		       int (*process_dquot) (struct dquot *))
+		       int (*process_dquot) (struct dquot *, char *))
 {
 	int entries = 0, i;
 	dqbuf_t buf = getdqbuf();
@@ -714,7 +717,7 @@
 	return used;
 }
 
-static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int v2_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *, char *))
 {
 	char *bitmap;
 	struct v2_mem_dqinfo *info = &h->qh_info.u.v2_mdqi;
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/quotaio_xfs.c cvs/quota-tools/quotaio_xfs.c
--- pre5/quota-tools/quotaio_xfs.c	Wed Apr 11 20:06:06 2001
+++ cvs/quota-tools/quotaio_xfs.c	Fri May  4 15:38:40 2001
@@ -28,7 +28,7 @@
 static int xfs_write_info(struct quota_handle *h);
 static struct dquot *xfs_read_dquot(struct quota_handle *h, qid_t id);
 static int xfs_commit_dquot(struct dquot *dquot);
-static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot));
+static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname));
 static int xfs_report(struct quota_handle *h, int verbose);
 
 struct quotafile_ops quotafile_ops_xfs = {
@@ -166,7 +166,8 @@
  */
 static int xfs_scan_dquot(struct quota_handle *h,
 			  struct xfs_kern_dqblk *d,
-			  struct dquot *dq, int (*process_dquot) (struct dquot * dquot))
+			  char *name, struct dquot *dq,
+			  int (*process_dquot) (struct dquot *dquot, char *dqname))
 {
 	int qcmd = QCMD(Q_XFS_GETQUOTA, h->qh_type);
 
@@ -180,13 +181,13 @@
 	    d->d_ino_hardlimit == 0 &&
 	    d->d_ino_softlimit == 0 && d->d_bcount == 0 && d->d_icount == 0) return 0;
 	xfs_kern2utildqblk(&dq->dq_dqb, d);
-	return process_dquot(dq);
+	return process_dquot(dq, name);
 }
 
 /*
  *	Scan all known dquots and call callback on each
  */
-static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot * dquot))
+static int xfs_scan_dquots(struct quota_handle *h, int (*process_dquot) (struct dquot *dquot, char *dqname))
 {
 	struct dquot *dq;
 	struct xfs_kern_dqblk d;
@@ -203,7 +204,8 @@
 		setpwent();
 		while ((usr = getpwent()) != NULL) {
 			dq->dq_id = usr->pw_uid;
-			if ((rd = xfs_scan_dquot(h, &d, dq, process_dquot)) < 0)
+			rd = xfs_scan_dquot(h, &d, usr->pw_name, dq, process_dquot);
+			if (rd < 0)
 				break;
 		}
 		endpwent();
@@ -214,7 +216,8 @@
 		setgrent();
 		while ((grp = getgrent()) != NULL) {
 			dq->dq_id = grp->gr_gid;
-			if ((rd = xfs_scan_dquot(h, &d, dq, process_dquot)) < 0)
+			rd = xfs_scan_dquot(h, &d, grp->gr_name, dq, process_dquot);
+			if (rd < 0)
 				break;
 		}
 		endgrent();
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/repquota.c cvs/quota-tools/repquota.c
--- pre5/quota-tools/repquota.c	Wed May  2 03:16:07 2001
+++ cvs/quota-tools/repquota.c	Fri May  4 15:48:50 2001
@@ -97,15 +97,13 @@
 	return '-';
 }
 
-static int print(struct dquot *dquot)
+static int print(struct dquot *dquot, char *name)
 {
-	char name[MAXNAMELEN];
 	char time[MAXTIMELEN];
 	struct util_dqblk *entry = &dquot->dq_dqb;
 
 	if (!entry->dqb_curspace && !entry->dqb_curinodes && !(flags & FL_VERBOSE))
 		return 0;
-	id2name(dquot->dq_id, dquot->dq_h->qh_type, name);
 	difftime2str(entry->dqb_btime, time);
 	printf("%-10s%c%c%8Lu%8Lu%8Lu%7s", name,
 	       overlim(qb2kb(toqb(entry->dqb_curspace)), qb2kb(entry->dqb_bsoftlimit),
diff -Naur -xpo -xdoc -xCVS pre5/quota-tools/warnquota.c cvs/quota-tools/warnquota.c
--- pre5/quota-tools/warnquota.c	Wed May  2 19:32:22 2001
+++ cvs/quota-tools/warnquota.c	Fri May  4 16:56:14 2001
@@ -25,7 +25,6 @@
 #include <stdlib.h>
 #include <string.h>
 #include <errno.h>
-#include <pwd.h>
 
 #include "mntopt.h"
 #include "pot.h"
@@ -92,26 +91,22 @@
  */
 static struct offenderlist *offenders = (struct offenderlist *)0;
 
-struct offenderlist *add_offender(int id)
+struct offenderlist *add_offender(int id, char *name)
 {
-	struct passwd *pwd;
 	struct offenderlist *offender;
 
-	if ((pwd = getpwuid(id)) == (struct passwd *)0)
-		return ((struct offenderlist *)0);
-
 	offender = (struct offenderlist *)smalloc(sizeof(struct offenderlist));
 
 	offender->offender_id = id;
-	offender->offender_name = (char *)smalloc(strlen(pwd->pw_name) + 1);
+	offender->offender_name = (char *)smalloc(strlen(name) + 1);
 	offender->usage = (struct usage *)NULL;
-	strcpy(offender->offender_name, pwd->pw_name);
+	strcpy(offender->offender_name, name);
 	offender->next = offenders;
 	offenders = offender;
 	return offender;
 }
 
-void add_offence(struct dquot *dquot)
+void add_offence(struct dquot *dquot, char *name)
 {
 	struct offenderlist *lptr;
 	struct usage *usage;
@@ -121,7 +116,7 @@
 			break;
 
 	if (!lptr)
-		if (!(lptr = add_offender(dquot->dq_id)))
+		if (!(lptr = add_offender(dquot->dq_id, name)))
 			return;
 
 	usage = (struct usage *)smalloc(sizeof(struct usage));
@@ -135,13 +130,13 @@
 	lptr->usage = usage;
 }
 
-int check_offence(struct dquot *dquot)
+int check_offence(struct dquot *dquot, char *name)
 {
 	if (
 	    (dquot->dq_dqb.dqb_bsoftlimit
 	     && toqb(dquot->dq_dqb.dqb_curspace) >= dquot->dq_dqb.dqb_bsoftlimit)
 	    || (dquot->dq_dqb.dqb_isoftlimit
-		&& dquot->dq_dqb.dqb_curinodes >= dquot->dq_dqb.dqb_isoftlimit)) add_offence(dquot);
+		&& dquot->dq_dqb.dqb_curinodes >= dquot->dq_dqb.dqb_isoftlimit)) add_offence(dquot, name);
 	return 0;
 }
 

--PART-BOUNDARY=.110105090957.ZM72341.melbourne.sgi.com--


From owner-linux-xfs@oss.sgi.com Tue May  8 17:51:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f490p1b06266
	for linux-xfs-outgoing; Tue, 8 May 2001 17:51:01 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f490p0F06263
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 17:51:00 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id 5E82E14FE; Tue,  8 May 2001 17:52:36 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id 0AD393F6; Tue,  8 May 2001 17:52:36 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSC4VM>; Tue, 8 May 2001 19:50:54 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88CF2@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs@oss.sgi.com
Subject: RE: XFS install from ISO fails utterly
Date: Tue, 8 May 2001 19:50:44 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't think there were actually any missing files (in the conventional
sense). It looked as if it was trying to touch or reference files deep under
/var -- and since var (along with most everything else) didn't mount, it was
obviously going to choke.

re. the devfsd question... I didn't even see an option in the installer to
do that. I was under the impression that the SGI kernel had it active by
default.

the steps of install went smoothly. partitioning, user config, package
selection, X config (even though the configuration test is missing -- that's
RH's problem). the disk swaps seemed to be fine.

one of the errors I got (don't remember the particulars of which failed
install that was) said "fs type swap not supported by kernel". but the main
hangs seemed to be upon trying to activate system logger and ipchains (more
than other things).


-----Original Message-----
From: Russell Cattelan [mailto:cattelan@thebarn.com]
Sent: Tuesday, May 08, 2001 5:52 PM
To: Venables, Michael
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly


>
>
> The install process went smoothly, but there were numerous "no such file
or
> directory" errors on reboot. When it eventually hit a login prompt, none
of
> the filesystems which had been marked as XFS seemed to be present (/boot
was
> left as ext2).

What were the missing files?
/dev/tty?

you didn't happen to not install devfsd for some reason?


--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.



From owner-linux-xfs@oss.sgi.com Tue May  8 21:33:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f494XgO12447
	for linux-xfs-outgoing; Tue, 8 May 2001 21:33:42 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f494XfF12444
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 21:33:41 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f494Xff06878
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 23:33:41 -0500 (CDT)
Message-ID: <3AF8C924.9295C248@sgi.com>
Date: Tue, 08 May 2001 23:35:48 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: update driver disk for DAC960 etc - maybe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, this might solve problems people were having with the DAC960 and
other RAID controllers during the install.

Then again, it may not.  Brave souls wanted, inquire within.  :)

I made a "driver disk" containing updated modules for the DAC960,
cpqarray, and cciss drivers.  The only changes are the
BLKBSZSET/BLKBSZGET ioctls that Martin added.  This disk is ONLY for
i686 machines, I can make one for [3,5]86 if needed.  Hopefully everyone
is using i686.  :)

Lacking any real documentation about how to create one of these disks, I
just looked at an existing driver disk and tried to copy the format. 
The installer does accept it as a driver disk, but since I don't have
one of these raid controllers, I can't test it further.  I expect that
we may run into problems with module versioning/undefined symbols, but
we'll see.

The image is at http://lager.dyndns.org/raid-dd-i686.img

dd this to a floppy (dd if=raid-dd-i686.img of=/dev/fd0 bs=1440k) and
then type "linux dd" or "text dd" at the installer prompt, inserting the
disk when prompted.

If all goes well, it will use the drivers on this floppy during the
boot, and install them on your system as well.

If all does not go well, hopefully you're no worse off than before.  :)

Let me know how it goes...

Your fanatical yet humble servant,
-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May  8 22:39:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f495dFx13251
	for linux-xfs-outgoing; Tue, 8 May 2001 22:39:15 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f495dDF13248
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 22:39:13 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id HAA24726;
	Wed, 9 May 2001 07:39:11 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id HAA12082;
	Wed, 9 May 2001 07:39:11 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 1353357306; Wed,  9 May 2001 07:48:36 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id DA11625835; Wed,  9 May 2001 07:49:47 +0200 (CEST)
Message-ID: <3AF8D8E1.F0CF138F@ch.sauter-bc.com>
Date: Wed, 09 May 2001 07:42:57 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: XFS RedHat installer
References: <3AF63A3B.2C296D1A@ch.sauter-bc.com> <4.3.2.7.2.20010508101840.0377bfb8@pop.xs4all.nl>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos schrieb:
> 
> At 20:47 7-5-2001 -0700, Tom Duffy wrote:
> > > 1) Boot floppy:
> > > When doing a mkbootdisk 2.4.2-xxxxx I saw that the content couldn't
> > > fit on the disk. Then I tried the following:
> > > fdformat /dev/fd0u1722
> > > mkbootdisk --device /dev/fd0u1722 2.4.2-xxxxx
> > > The disk was created successfully but unfortunately it didn't boot
> > > anyway. I guess it is a problem with the used 'syslinux'. Did
> > > you try something like this ?
> >
> >unfortunately, you cannot boot off of a superformatted floppy...this is a
> >limitation of the BIOS.
> 
> What bios?? I can booted super formatted floppy's for my linuxrouter
> machine at home on a old 486PC which are 1680 I believe.
> I have encountered one machine with a external drives that would not boot
> these floppies. A toshiba with an external drive (portege 7800).
> 
> So I have good succes with that. I believe they also succeeded in making a
> 2.88MB bootable cdrom ;-) Information about that should be somewhere in the
> archives. I am not 100% sure though.

Well, I tried the same with other computers and it seems that
some systems support booting big disks, others don't. Bioses
vary in this point. So it is not good to include this into the
installer.

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Tue May  8 22:53:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f495rjP13431
	for linux-xfs-outgoing; Tue, 8 May 2001 22:53:45 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f495riF13428
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 22:53:44 -0700
Received: from boing.melbourne.sgi.com ([134.14.55.141]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id WAA08720
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 22:53:32 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA14274;
	Wed, 9 May 2001 15:52:14 +1000 (EST)
Date: Wed, 9 May 2001 15:52:13 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: dkleinh@phy.ucsf.edu
Cc: linux-xfs@oss.sgi.com
Subject: xfsdump/restore bug for rmt user@host
Message-ID: <20010509155213.J185975@boing.melbourne.sgi.com>
References: <200105081743.f48Hh4er010920@linux-xfs.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <200105081743.f48Hh4er010920@linux-xfs.sgi.com>; from httpd@linux-xfs.sgi.com on Tue, May 08, 2001 at 10:43:04AM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Dirk,

Dirk Kleinhesselink wrote:
> xfs seems to work great, but: xfsdump and xfsrestore do not work properly
> with a remote tape drive, at least if the rmt command on the remote system
> must run as a different user than the user running the xfsdump/xfsrestore
> command.  We have a couple of IRIX machines with xfs and xfsdump/xfsrestore
> does properly work with remote tape: we are using 
> the -f option with xfsdump/xfsrestore as: -f guest@remote:/dev/rmttapedev
> 
Sorry Dirk, a bug on my part.
We currently only test dumping to remote IRIX machines without
a login name (see cmd/xfstests/039 & 036).

The code is broken and I'll fix it in a check-in very shortly.

Cheers,
Tim.

From owner-linux-xfs@oss.sgi.com Tue May  8 23:25:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f496PD414073
	for linux-xfs-outgoing; Tue, 8 May 2001 23:25:13 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f496PCF14067
	for <linux-xfs@oss.sgi.com>; Tue, 8 May 2001 23:25:12 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA00874
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 08:25:10 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id IAA14858
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 08:25:09 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP id 5245D57306
	for <linux-xfs@oss.sgi.com>; Wed,  9 May 2001 08:34:53 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP id 40ED125835
	for <linux-xfs@oss.sgi.com>; Wed,  9 May 2001 08:36:05 +0200 (CEST)
Message-ID: <3AF8E3BA.1F2D9397@ch.sauter-bc.com>
Date: Wed, 09 May 2001 08:29:14 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: linux-xfs <linux-xfs@oss.sgi.com>
Subject: XFS on md (RAID1) with devfs fixed
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I did an install of XFS/RedHat on two IDE disks configured
as RAID 1 the following way:

/dev/md0  /
/dev/md1  /boot
/dev/md2  swap

The first problem was that with the installer you can not
create swap on RAID. Some time ago I read somewhere this can
make troubles but I never had any using it on different
servers for years (servers with very heavy swapping activity).
The way around this problem is to create the swap partitions as
swap when doing the install and later create the RAID with
something like:
swapoff -a
use fdisk/cfdisk to change the partition type to FD
edit /etc/raidtab and create the new entry fr the swap partition
mkraid /dev/md? (or/and was it raidstart /dev/md?, sorry...)
mkswap /dev/md?
edit /dev/fstab to reflect the changes on swap
swapon -a

The second thing is that booting the system wasn't possible when
the install was finished. Everybody knows now that with
devfs=nomount as boot parameter, the system will boot but without
devfs. I was wondering what really makes the troubles and I
found it in the initrd image. Then I did the following:
gunzip the initrd-XXXX.img
mount it somewhere as loop
edit the bootup script linuxrc:
raidautostart /dev/md0 to raidautostart /dev/md/0
unmounted initrd, gzipped it
important step: mkdir /dev/md ; cp -a /dev/md0 /dev/md/0
edit /etc/lilo.conf:  root=/dev/md0 to root=/dev/md/0
wrote new MBR with lilo
rmoved the device with rm -r /dev/md
rebooted the system

and voila, booting is fine with devfs enabled.

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Wed May  9 00:26:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f497Qld15229
	for linux-xfs-outgoing; Wed, 9 May 2001 00:26:47 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f497QiF15223
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:26:45 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f497QOK04149;
	Wed, 9 May 2001 09:26:24 +0200
Message-Id: <4.3.2.7.2.20010509092324.03775cc8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 May 2001 09:26:32 +0200
To: Simon Matter <simon.matter@ch.sauter-bc.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: XFS RedHat installer
Cc: linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <3AF8D8E1.F0CF138F@ch.sauter-bc.com>
References: <3AF63A3B.2C296D1A@ch.sauter-bc.com>
 <4.3.2.7.2.20010508101840.0377bfb8@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 07:42 9-5-2001 +0200, Simon Matter wrote:
> >
> > What bios?? I can booted super formatted floppy's for my linuxrouter
> > machine at home on a old 486PC which are 1680 I believe.
> > I have encountered one machine with a external drives that would not boot
> > these floppies. A toshiba with an external drive (portege 7800).
> >
> > So I have good succes with that. I believe they also succeeded in making a
> > 2.88MB bootable cdrom ;-) Information about that should be somewhere in the
> > archives. I am not 100% sure though.
>
>Well, I tried the same with other computers and it seems that
>some systems support booting big disks, others don't. Bioses
>vary in this point. So it is not good to include this into the
>installer.

Ok so make it a choice of getting a working floppy (on some/most machines) 
or no floppy at all. I choosse the first. If it works, great! If it doesn't 
I'll fiddle with the XFS install CD.
The one that get's generated now during install definitely won't work.

I'll have a go at making a larger bootfloppy (Heck I need one to sometimes).

Cheers
--
Seth
Every program has two purposes
one for which it was written and
another for which it wasn't
I make the last kind.


From owner-linux-xfs@oss.sgi.com Wed May  9 00:39:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f497dlV15496
	for linux-xfs-outgoing; Wed, 9 May 2001 00:39:47 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f497dkF15492
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:39:46 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id AAA03637
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 00:39:41 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA71418
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 17:38:20 +1000 (EST)
Date: Wed, 9 May 2001 17:38:20 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105090738.RAA71418@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - qa, commands (misc userspace stuff)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Flush out my growing backlog of stuff I've promised / been sent from,
various people.  Most importantly this slightly reworks all use of
byteswab.h so that it is works on more architectures, and adds define
for O_DIRECT for powerpc, where libc doesn't define it as yet.

cheers.


Date:  Tue May  8 22:32:28 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94357a
cmd/attr/include/builddefs.in - 1.2
	- remove -Wno-parentheses - compiles fine without it.


Date:  Tue May  8 22:39:03 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94358a
cmd/acl/libacl/acl.c - 1.7
cmd/acl/include/builddefs.in - 1.2
	- remove -Wno-parentheses - not needed now.


Date:  Tue May  8 22:48:30 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94359a
cmd/dmapi/include/builddefs.in - 1.2
	- remove -Wno-parentheses - compiles fine without it.


Date:  Tue May  8 23:56:06 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94367a
cmd/xfsprogs/Makefile - 1.2
cmd/xfsprogs/rtcp/xfs_rtcp.c - 1.1
cmd/xfsprogs/rtcp/Makefile - 1.1
cmd/xfsprogs/man/man8/xfs_rtcp.8 - 1.1
	- insert (experimental) rtcp binary - for eric/others working on
	  xfs realtime device support, this is a useful little tool.

cmd/xfsprogs/repair/sb.c - 1.4
cmd/xfsprogs/repair/phase6.c - 1.5
cmd/xfsprogs/growfs/xfs_growfs.c - 1.4
cmd/xfsprogs/db/io.c - 1.4
cmd/xfsprogs/repair/io.c - 1.2
cmd/xfsprogs/repair/attr_repair.c - 1.4
cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.11
cmd/xfsprogs/mkfs/proto.c - 1.3
cmd/xfsprogs/mkfile/xfs_mkfile.c - 1.4
cmd/xfsprogs/logprint/logprint.h - 1.4
cmd/xfsprogs/logprint/logprint.c - 1.3
cmd/xfsprogs/libxfs/rdwr.c - 1.4
cmd/xfsprogs/libxfs/init.c - 1.6
cmd/xfsprogs/bmap/xfs_bmap.c - 1.3
cmd/xfsprogs/libhandle/handle.c - 1.4
	- present fcntl.h and libxfs.h in the correct order, to ensure
	  O_DIRECT definition comes out correctly for all architectures.
	  audit headers, removed lots of dups, while I'm at it.

cmd/xfsprogs/include/platform_defs.h.in - 1.5
	- add a powerpc fix from the Debian powerpc porting folk - this
	  initiated the rework (fix) of libxfs/arch.c, __fswab*, etc.
	  move platform-specific stuff into here whenever we can.

cmd/xfsprogs/include/libxfs.h - 1.3
	- remove /* ick */ comment and all that the __fswab64 prototype
	  below it stands for - much cleaner now.

cmd/xfsprogs/include/builddefs.in - 1.5
	- move to -O1 by default, so that arch-specific code changes for
	  INT_GET and friends will always work.  nb: some gcc versions
	  miscompile xfs_db at -O2 so we cannot go there (xfs_check segv
	  immediately as test case).

cmd/xfsprogs/include/arch.h - 1.2
	- turns out this userspace-only include was never needed - nuke it.

cmd/xfsprogs/mkfs/mountinfo.c - 1.2
	- not always at error when this point reached, cannot unilaterally
	  call perror.

cmd/xfsprogs/man/man5/xfs.5 - 1.2
	- minor fixes.

cmd/xfsprogs/libxfs/arch.c - 1.2
cmd/xfsprogs/libxfs/Makefile - 1.4
	- removed arch.c - now redundant.  we really don't want these
	  routines in libxfs.

cmd/xfsprogs/doc/CHANGES - 1.18
cmd/xfsprogs/debian/changelog - 1.13
	- updates for 1.2.5 ... documented.

cmd/xfsprogs/configure.in - 1.5
	- update a comment.


Date:  Wed May  9 00:03:16 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94368a
cmd/xfstests/src/truncfile.c - 1.2
cmd/xfstests/src/randholes.c - 1.2
cmd/xfstests/src/nametest.c - 1.3
cmd/xfstests/src/loggen.c - 1.2
cmd/xfstests/src/ioctl.c - 1.2
cmd/xfstests/src/holes.c - 1.2
cmd/xfstests/src/global.h - 1.2
cmd/xfstests/src/fill2.c - 1.3
cmd/xfstests/src/fault.c - 1.2
cmd/xfstests/src/devzero.c - 1.2
cmd/xfstests/src/bstat.c - 1.2
	- fix warnings, remove unused headers, audit order of fcntl.h
	  & libxfs.h includes.

cmd/xfstests/configure.in - 1.6
	- update a comment.

cmd/xfstests/include/builddefs.in - 1.3
	- move to -O1 by default, so that arch-specific code changes for
	  INT_GET and friends will always work.


Date:  Wed May  9 00:05:17 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94369a
linux/fs/xfs_support/arch.h - 1.2
	- sync with userspace - we've never actually need this
	  userspace-conditional include (not for awhile anyway).


Date:  Wed May  9 00:18:58 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94370a
cmd/xfsdump/dump/content.c - 1.5
cmd/xfsdump/restore/content.c - 1.6
	- remove a few HIDDENs which don't need to be there - to do with
	  rt files, direct IO, dioinfo ioctl (not fcntl like irix).

cmd/xfsdump/common/arch_xlate.c - 1.3
	- remove byteswab routine hack, allowing compiles on other archs
	  (ppc).  reworks IXLATE, BXLATE slightly so they don't generate
	  squillions of warnings under some versions of gcc (esp. ia64).

cmd/xfsdump/VERSION - 1.8
	- bump minor version number.

cmd/xfsdump/configure.in - 1.5
	- update a comment.

cmd/xfsdump/debian/changelog - 1.4
	- update to 1.0.7 - document changes.

cmd/xfsdump/debian/rules - 1.4
	- remove now-redundant optimiser settings.

cmd/xfsdump/doc/CHANGES - 1.8
	- update to 1.0.7 - document changes.

cmd/xfsdump/include/builddefs.in - 1.2
	- use -O1 compiler flag so that we can handle the byte swabbing
	  routines in a more platform-independent manner.  thanks to the
	  debian ppc porting folk for their help on this one.



From owner-linux-xfs@oss.sgi.com Wed May  9 01:41:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f498f4E17303
	for linux-xfs-outgoing; Wed, 9 May 2001 01:41:04 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f498f3F17300
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 01:41:03 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id BAA08996
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 01:41:00 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA85064
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 18:39:42 +1000 (EST)
Date: Wed, 9 May 2001 18:39:42 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105090839.SAA85064@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - rmt xfsdump/xfsrestore
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Should get rmt dumping/restoring with given user to work.
Test 055 verifies it for our testing.

--Tim

Date:  Wed May  9 01:38:23 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94372a
cmd/xfstests/055 - 1.1
	- Test remote dumping with a user specified as well.

cmd/xfstests/055.out - 1.1
	- dump out for 055

cmd/xfsdump/librmt/rmtopen.c - 1.3
	- Get the rsh right for user and host. Oops.
	  On Linux we need to use the -l option.

cmd/xfstests/group - 1.8
	- Add 053, 054, 055.

cmd/xfstests/common.dump - 1.6
	- Handle tape specifications with user@host:dev,
	  that is, with a user specified as well.

cmd/xfstests/common.config - 1.7
	- Add RMT_TAPE_USER for specifying a user for remote dump/restores.



From owner-linux-xfs@oss.sgi.com Wed May  9 03:06:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49A6eo19461
	for linux-xfs-outgoing; Wed, 9 May 2001 03:06:40 -0700
Received: from core.devicen.de (root@core.devicen.de [62.159.186.206])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49A6cF19458
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 03:06:39 -0700
Received: from [62.159.186.228] (mactil.devicen.de [62.159.186.228])
	by core.devicen.de (8.11.0/8.11.0/SuSE Linux 8.9.3-0.1) with ESMTP id f49A6Zw28921
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 12:06:38 +0200
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106
Date: Wed, 09 May 2001 12:06:35 +0200
Subject: kupdate - excessive CPU usage
From: Tilman Kastner <kastner@devicen.de>
To: <linux-xfs@oss.sgi.com>
Message-ID: <B71EE34B.193D1%kastner@devicen.de>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

First of all, please allow me to send a big THANK YOU to all of you who made
XFS on linux a reality. Working with XFS on IRIX for quite some time, I am
convinced that the availability of XFS will be a big step forward for Linux
in mission-critical applications.

I recently switched a desktop machine to XFS-only. Patching the SuSE-2.4.2
kernel sources worked without a problem (to my surprise), compiling with gcc
2.95.2 was no problem, too. After reboot, everything works like a charm, but
after some hours of moderate or even low fs-activity, kupdate starts to eat
up CPU every time it is called - even the mouse on X freezes for approx.
1/2s.

I have not found postings regarding this problem in the archive yet, so any
hints would be appreciated. Should I try another (clean) kernel, a different
gcc, different settings for mkfs, etc...

Thanks in advance

Tilman


-- 
Tilman Kastner                 DEVICE/N GmbH
kastner@devicen.de             Ilse-ter-Meer-Weg 7
PGP key available              30449 Hannover, Germany



From owner-linux-xfs@oss.sgi.com Wed May  9 03:53:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49Ar7120100
	for linux-xfs-outgoing; Wed, 9 May 2001 03:53:07 -0700
Received: from smtp.intrinsec.com (doberman.INTRINsec.com [194.98.42.252])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f49Ar5F20097
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 03:53:06 -0700
Received: (qmail 8198 invoked from network); 9 May 2001 12:04:43 -0000
Received: from INTRINsec (HELO flic.corp.intrinsec.com) (INTRINsec@INTRINsec)
  by INTRINsec with SMTP; 9 May 2001 12:04:43 -0000
Received: by flic.corp.INTRINsec.com with Internet Mail Service (5.5.2650.21)
	id <K19B65JZ>; Wed, 9 May 2001 12:50:42 +0200
Message-ID: <BEC329079D7AD4119FA7000102A316EF0573FC@flic.corp.INTRINsec.com>
From: Gwenael.Letellier@INTRINsec.com
To: linux-xfs@oss.sgi.com
Subject: Apache and XFS ACLs
Date: Wed, 9 May 2001 12:50:32 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

This bug report is being submitted both to XFS and Apache bug reporting
systems.

First thank you all at SGI for the great work. RH-71 with XFS root installed
nicely on my laptop.

Now my problem : I have been taking a look at XFS ACLs, and there seem to be
a problem with apache not taking XFS ACLs into account.

Details :

Software versions : stock RH-71 with XFS-1.0 install disk, Apache-1.3.19

Problem : say I have a user called gwen, with home directory /home/gwen.
Apache is running under apache.apache and user home directories are
configured to be readable as ~gwen for /home/gwen/public_html. Apache
indexes on index.html.

If I set the following perms, without any ACLs, everything is working fine :
drwxr-xr-x	root	root	/home
drwx-----x	gwen	gwen	/home/gwen
drwx---r-x	gwen	gwen	/home/gwen/public_html
-rwx---r--	gwen	gwen	/home/gwen/public_html/index.html

I have access to index.html, which prints out a nice "Hello, World!" ;-).


If I want to be more restrictive, and use ACLs to allow access to this file
only to the user named apache, and/or (tried both) to the group named
apache, I get a 403 Forbidden error from apache.

Permissions are set the following way :
drwxr-xr-x	root	root	/home
drwx------	gwen	gwen	/home/gwen
drwx------	gwen	gwen	/home/gwen/public_html
-rwx------	gwen	gwen	/home/gwen/public_html/index.html

and the following ACLs are set too, for the user apache, group apache :
d--x--x---	apache	apache	/home/gwen
dr-xr-x---	apache	apache	/home/gwen/public_html
-r-xr-x---	apache	apache	/home/gwen/public_html/index.html

I don't know whether I did something wrong in ACL settings. I think it has
to do with the way Apache checks for perms.


From owner-linux-xfs@oss.sgi.com Wed May  9 04:34:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49BYG021025
	for linux-xfs-outgoing; Wed, 9 May 2001 04:34:16 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49BYEF21022
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 04:34:15 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f49BYCK05480
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:34:13 +0200
Message-Id: <4.3.2.7.2.20010509132758.02d5fb10@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 09 May 2001 13:34:21 +0200
To: linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Patch for mkbootdisk and large floppy support
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

This patch alters the behaviuor of the --device option of mkbootdisk.
If this option is set it will fdformat the floppy using the given device 
and run syslinux with the -s option.

I tested this with /dev/fd0u1680 and it boots on 3 kinds of dell optiplex 
machines and my Dell inspiron notebook.
YMMV using larger devices like /dev/fd0u1722 and the like. And make sure 
you use decent floppy's because they are not made for this. At least it 
proves the truth in my .sig

--- /sbin/mkbootdisk    Thu Feb  8 23:48:15 2001
+++ mkbootdisk  Wed May  9 11:34:16 2001
@@ -8,6 +8,7 @@
  unset kernel
  device=/dev/fd0
  unset verbose
+unset fdformat
  unset witheth
  unset mkinitrdargs
  unset compact
@@ -32,6 +33,7 @@
         --device)
             shift
             device=$1
+           fdformat=true
             ;;
         --mkinitrdargs)
             shift
@@ -141,12 +143,14 @@
  }

  [ -n "$verbose" ] && echo -n "Formatting $device... "
+[ -n "$fdformat" ] && fdformat $device
  mkdosfs -I $device > /dev/null || {
      echo "Failed to format $device" >&2
      exit 1
  }

-syslinux $device
+[ -n "$fdformat" ] && syslinux -s $device
+[ -z "$fdformat" ] && syslinux $device
  [ -n "$verbose" ] && echo "done."

  rm -rf $MOUNTDIR

Good luck with using it. I know I will.

Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Wed May  9 07:41:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49EfRL30249
	for linux-xfs-outgoing; Wed, 9 May 2001 07:41:27 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49EfRF30246
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 07:41:27 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA24918
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 07:40:04 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1752273 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:32:33 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA33174 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:32:33 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f49EZ6h24203; Wed, 9 May 2001 09:35:06 -0500
Message-Id: <200105091435.f49EZ6h24203@jen.americas.sgi.com>
Date: Wed, 9 May 2001 09:35:06 -0500
Subject: TAKE - some minor inode handling cleanup
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

minor code cleanup, fixes nothing on its own.

Date:  Wed May  9 07:31:43 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-base

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94385a
linux/fs/xfs/xfs_iget.c - 1.140
linux/fs/xfs/xfs_inode.h - 1.148
linux/fs/xfs/linux/xfs_vnode.c - 1.61


From owner-linux-xfs@oss.sgi.com Wed May  9 08:27:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49FRrO31391
	for linux-xfs-outgoing; Wed, 9 May 2001 08:27:53 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49FRqF31388
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 08:27:52 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f49FRoP20776
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:27:50 -0500 (CDT)
Message-ID: <3AF9627B.FE931812@sgi.com>
Date: Wed, 09 May 2001 10:30:03 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: update driver disk for DAC960 etc - maybe
References: <3AF8C924.9295C248@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, there is a problem with module versioning.  Hang on a while while I
look at it...

-Eric

Eric Sandeen wrote:

> I expect that
> we may run into problems with module versioning/undefined symbols, but
> we'll see.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 08:28:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49FSI431403
	for linux-xfs-outgoing; Wed, 9 May 2001 08:28:18 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49FSGF31400
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 08:28:16 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA1107597
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:28:05 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA82665; Wed, 9 May 2001 10:26:49 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f49FPme08379;
	Wed, 9 May 2001 11:25:48 -0400
Message-ID: <3AF9617C.37F1F1EE@thebarn.com>
Date: Wed, 09 May 2001 11:25:48 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Matter <simon.matter@ch.sauter-bc.com>
CC: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: XFS on md (RAID1) with devfs fixed
References: <3AF8E3BA.1F2D9397@ch.sauter-bc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Simon Matter wrote:

> I did an install of XFS/RedHat on two IDE disks configured
> as RAID 1 the following way:
>
> /dev/md0  /
> /dev/md1  /boot
> /dev/md2  swap
>
> The first problem was that with the installer you can not
> create swap on RAID. Some time ago I read somewhere this can
> make troubles but I never had any using it on different
> servers for years (servers with very heavy swapping activity).
> The way around this problem is to create the swap partitions as
> swap when doing the install and later create the RAID with
> something like:
> swapoff -a
> use fdisk/cfdisk to change the partition type to FD
> edit /etc/raidtab and create the new entry fr the swap partition
> mkraid /dev/md? (or/and was it raidstart /dev/md?, sorry...)
> mkswap /dev/md?
> edit /dev/fstab to reflect the changes on swap
> swapon -a
>
> The second thing is that booting the system wasn't possible when
> the install was finished. Everybody knows now that with
> devfs=nomount as boot parameter, the system will boot but without
> devfs. I was wondering what really makes the troubles and I
> found it in the initrd image. Then I did the following:
> gunzip the initrd-XXXX.img
> mount it somewhere as loop
> edit the bootup script linuxrc:
> raidautostart /dev/md0 to raidautostart /dev/md/0
> unmounted initrd, gzipped it
> important step: mkdir /dev/md ; cp -a /dev/md0 /dev/md/0
> edit /etc/lilo.conf:  root=/dev/md0 to root=/dev/md/0
> wrote new MBR with lilo
> rmoved the device with rm -r /dev/md
> rebooted the system

good catch...
You might want to try this patch to mkinitrd
it should rebuild your initrd correctly.
Check it before rebooting just to be sure.

--- mkinitrd~   Fri Mar 23 15:21:08 2001
+++ mkinitrd    Wed May  9 10:22:14 2001
@@ -396,8 +396,9 @@
 fi

 if [ -n "$startraid" ]; then
-    cp -a /dev/md0 $MNTIMAGE/dev
-    echo "raidautorun /dev/md0" >> $RCFILE
+    mkdir $MNTIMAGE/dev/md
+    cp -a /dev/md/0 $MNTIMAGE/dev/md
+    echo "raidautorun /dev/md/0" >> $RCFILE
 fi

 chmod +x $RCFILE


>
>
> and voila, booting is fine with devfs enabled.
>
> --
> Simon Matter              Tel:  +41 61 695 57 35
> Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
> Im Surinam 55
> CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  9 09:12:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49GChm32288
	for linux-xfs-outgoing; Wed, 9 May 2001 09:12:43 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49GCfF32283
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:12:41 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id SAA18169;
	Wed, 9 May 2001 18:12:36 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id SAA03414;
	Wed, 9 May 2001 18:12:35 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 4536A57306; Wed,  9 May 2001 18:21:44 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 1AE1A25835; Wed,  9 May 2001 18:22:55 +0200 (CEST)
Message-ID: <3AF96D44.51443824@ch.sauter-bc.com>
Date: Wed, 09 May 2001 18:16:04 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: XFS on md (RAID1) with devfs fixed
References: <3AF8E3BA.1F2D9397@ch.sauter-bc.com> <3AF9617C.37F1F1EE@thebarn.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sorry, I'm very confused by now. It seems we are going to have some
troubles because of the two different device file types.

Russell Cattelan schrieb:
> 
> Simon Matter wrote:
> 
> > I did an install of XFS/RedHat on two IDE disks configured
> > as RAID 1 the following way:
> >
> > /dev/md0  /
> > /dev/md1  /boot
> > /dev/md2  swap
> >
> > The second thing is that booting the system wasn't possible when
> > the install was finished. Everybody knows now that with
> > devfs=nomount as boot parameter, the system will boot but without
> > devfs. I was wondering what really makes the troubles and I
> > found it in the initrd image. Then I did the following:

Here I just changed the linuxrc script in the initrd. I did not
create a /dev/md/0 in the initrd. In your patch you are trying to
create , why? Why does it work for me anyway? Are you
creating /dev/md/0 as old device file so it will allways exist and
will be overwritten by devfs, if enabled. I'm confused...

> > gunzip the initrd-XXXX.img
> > mount it somewhere as loop
> > edit the bootup script linuxrc:
> > raidautostart /dev/md0 to raidautostart /dev/md/0
> > unmounted initrd, gzipped it

The /dev/md/0 hack is just to let lilo know we have the root device.
Otherwise it won't install the MBR. At the time I did this I was
running with devfs=nomount and therefore /dev/md/0 did not exist.
I couldn't find a way to force lilo to install anyway, am I blind?

> > important step: mkdir /dev/md ; cp -a /dev/md0 /dev/md/0
> > edit /etc/lilo.conf:  root=/dev/md0 to root=/dev/md/0
> > wrote new MBR with lilo
> > rmoved the device with rm -r /dev/md
> > rebooted the system
> 
> good catch...
> You might want to try this patch to mkinitrd
> it should rebuild your initrd correctly.
> Check it before rebooting just to be sure.
> 
> --- mkinitrd~   Fri Mar 23 15:21:08 2001
> +++ mkinitrd    Wed May  9 10:22:14 2001
> @@ -396,8 +396,9 @@
>  fi
> 
>  if [ -n "$startraid" ]; then
> -    cp -a /dev/md0 $MNTIMAGE/dev
> -    echo "raidautorun /dev/md0" >> $RCFILE
> +    mkdir $MNTIMAGE/dev/md

What are you doing here? Since we don't have devfs at this time, we
can't copy /dev/md/0 to the initrd???

> +    cp -a /dev/md/0 $MNTIMAGE/dev/md
> +    echo "raidautorun /dev/md/0" >> $RCFILE
>  fi
> 
>  chmod +x $RCFILE
> 
Maybe linuxrc solution could be easier:

raidautorun /dev/md/0
raidautorun /dev/md0

If we don't have devfs, the first line won't do anything but the
second statement should do the job. I'll try it later, maybe I'm
completely wrong...

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Wed May  9 09:14:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49GEPS32345
	for linux-xfs-outgoing; Wed, 9 May 2001 09:14:25 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49GENF32342
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:14:23 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA1112398
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 18:14:17 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1754500; Wed, 9 May 2001 11:12:59 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA78474; Wed, 9 May 2001 11:12:59 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49GFW229931; Wed, 9 May 2001 11:15:32 -0500
Message-Id: <200105091615.f49GFW229931@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Venables, Michael" <Michael.Venables@compaq.com>
cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly 
In-Reply-To: Message from "Venables, Michael" <Michael.Venables@compaq.com> 
   of "Tue, 08 May 2001 17:48:00 CDT." <8C91B010B3B7994C88A266E1A72184D3C88CF1@cceexc19.americas.cpqcorp.net> 
Date: Wed, 09 May 2001 11:15:31 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> the mount points were as follows:
> 
> 	/		256MB	XFS
> 	/boot		64	ext2 (also tried as XFS)
> 	/var		512	XFS
> 	/tmp		512	XFS
> 	/usr		4GB	XFS
> 	/home		20GB	XFS
> 
> 	swap		256MB
> 
> 


There is one other possibility, that due to the way xfs returns st_blksize 
as 64K by default, you actually filled the root or var partition during
install, could you look in the install log for signs of this. We have found
that some files managed by rpm and email systems are tending to get much
larger than normal. If this was the case then just bumping partition sizes
would be a way out for now.

I did have this very thing happen to me when installing the Ximian gnome
packages on my laptop.

I am looking into making the default behavior closer to ext2 in this area.

Steve



From owner-linux-xfs@oss.sgi.com Wed May  9 09:47:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49Glb500787
	for linux-xfs-outgoing; Wed, 9 May 2001 09:47:37 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49GlaF00784
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:47:36 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA29275
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 09:46:13 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA77261; Wed, 9 May 2001 11:46:19 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f49GjIe26806;
	Wed, 9 May 2001 12:45:18 -0400
Message-ID: <3AF9741B.5269578A@thebarn.com>
Date: Wed, 09 May 2001 12:45:16 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Simon Matter <simon.matter@ch.sauter-bc.com>
CC: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: XFS on md (RAID1) with devfs fixed
References: <3AF8E3BA.1F2D9397@ch.sauter-bc.com> <3AF9617C.37F1F1EE@thebarn.com> <3AF96D44.51443824@ch.sauter-bc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Simon Matter wrote:

>
> > --- mkinitrd~   Fri Mar 23 15:21:08 2001
> > +++ mkinitrd    Wed May  9 10:22:14 2001
> > @@ -396,8 +396,9 @@
> >  fi
> >
> >  if [ -n "$startraid" ]; then
> > -    cp -a /dev/md0 $MNTIMAGE/dev
> > -    echo "raidautorun /dev/md0" >> $RCFILE
> > +    mkdir $MNTIMAGE/dev/md
>
> What are you doing here? Since we don't have devfs at this time, we
> can't copy /dev/md/0 to the initrd???

Actually looking at this closer this would seem to be better...
--- /sbin/mkinitrd      Wed May  9 11:38:46 2001
+++ /sbin/mkinitrd.orig Wed May  9 11:37:19 2001
@@ -396,7 +396,7 @@
 fi

 if [ -n "$startraid" ]; then
+    mknod $MNTIMAGE/dev/md0 b 9 0
-    cp -a /dev/md0 $MNTIMAGE/dev
     echo "raidautorun /dev/md0" >> $RCFILE
 fi

at some point the rest of mkinitrd was changed to use mknod for all
the devices it needed, it would appear the raid portion got overlooked.


>
>
> > +    cp -a /dev/md/0 $MNTIMAGE/dev/md
> > +    echo "raidautorun /dev/md/0" >> $RCFILE
> >  fi
> >
> >  chmod +x $RCFILE
> >
> Maybe linuxrc solution could be easier:
>
> raidautorun /dev/md/0
> raidautorun /dev/md0
>
> If we don't have devfs, the first line won't do anything but the
> second statement should do the job. I'll try it later, maybe I'm
> completely wrong...

we just need to make sure initrd has a raid dev
devfs isn't in the picture yet when initrd is loaded.

lilo should work either way since once devfsd is running  /dev/md0
should
exist



>
>
> --
> Simon Matter              Tel:  +41 61 695 57 35
> Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
> Im Surinam 55
> CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  9 10:03:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49H3TK01289
	for linux-xfs-outgoing; Wed, 9 May 2001 10:03:29 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49H3SF01286
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:03:28 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f49H3JEZ002411;
	Wed, 9 May 2001 10:03:20 -0700
Date: Wed, 9 May 2001 10:03:19 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0/Quota
In-Reply-To: <10105090957.ZM72341@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0105090958430.12885-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> kernel patches, quota works without any patching at all.
> 
> cheers.
> 
> -- 
> Nathan
> 

I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
cvs quota tools.  Made sure that quota support and xfs quota support is
selected in kernel.  quotaon -av doesnt show anything.  my fstab has
rw,usrquota. 

[root@gauss quota-tools]# quotaon -v /users/raid2
quotaon: Enable XFS group quota during mount
quotaon: Enable XFS user quota during mount

[root@gauss quota-tools]# repquota /users/raid2
[root@gauss quota-tools]#

I have setup quota on ext2 quite few times before so Im pretty sure I am
not making any mistakes.  Please help.


From owner-linux-xfs@oss.sgi.com Wed May  9 10:31:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49HViZ01796
	for linux-xfs-outgoing; Wed, 9 May 2001 10:31:44 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49HVgF01793
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:31:43 -0700
Received: from [195.20.224.220] (helo=mrvdom04.kundenserver.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14xXoK-0003uC-00
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 19:31:40 +0200
Received: from pd901e293.dip.t-dialin.net ([217.1.226.147] helo=kernelpanix.aura.of.mankind)
	by mrvdom04.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14xXoF-0002q4-00
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 19:31:35 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f49GpbD15391
	for linux-xfs@oss.sgi.com; Wed, 9 May 2001 18:51:37 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 9 May 2001 18:51:37 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: linux-xfs@oss.sgi.com
Subject: xfs_check, xfs_repair should added to the xfs install iso
Message-ID: <20010509185137.A15348@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

I just tested the rescue mode of the RH 7.1 xfs install iso.
(I dont needed this time .-)

I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
should added. fsck for ext2 and ext3 are there.


cheers

utz

From owner-linux-xfs@oss.sgi.com Wed May  9 10:44:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49HiC502511
	for linux-xfs-outgoing; Wed, 9 May 2001 10:44:12 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49HiCF02508
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:44:12 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA14165
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:42:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1756362; Wed, 9 May 2001 12:42:53 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA17378; Wed, 9 May 2001 12:42:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49HjP100663; Wed, 9 May 2001 12:45:25 -0500
Message-Id: <200105091745.f49HjP100663@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: utz lehmann <xfs@s2y4n2c.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso 
In-Reply-To: Message from utz lehmann <xfs@s2y4n2c.de> 
   of "Wed, 09 May 2001 18:51:37 +0200." <20010509185137.A15348@s2y4n2c.de> 
Date: Wed, 09 May 2001 12:45:25 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi
> 
> I just tested the rescue mode of the RH 7.1 xfs install iso.
> (I dont needed this time .-)
> 
> I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> should added. fsck for ext2 and ext3 are there.
> 
> 
> cheers
> 
> utz

Hmmm, that was supposed to have happened, I discovered this problem a
few weeks ago and I thought the change was made to get them out there.
Russell, did this change go missing?

Steve



From owner-linux-xfs@oss.sgi.com Wed May  9 11:01:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49I1n002826
	for linux-xfs-outgoing; Wed, 9 May 2001 11:01:49 -0700
Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49I1lF02823
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:01:47 -0700
Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id SAA22361; Wed, 9 May 2001 18:59:14 +0200
Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4)
	id UAA25437; Wed, 9 May 2001 20:01:38 +0200 (MET DST)
Date: Wed, 9 May 2001 20:01:38 +0200 (MET DST)
From: fermin@eup.udl.es (Fermin Molina)
Message-Id: <200105091801.UAA25437@eup.udl.es>
To: marchuk@ee.washington.edu
Subject: Re: XFS 1.0/Quota
Cc: linux-xfs@oss.sgi.com
X-Sun-Charset: US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> > Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> > kernel patches, quota works without any patching at all.
> > 
> > cheers.
> > 
> > -- 
> > Nathan
> > 
> 
> I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
> cvs quota tools.  Made sure that quota support and xfs quota support is
> selected in kernel.  quotaon -av doesnt show anything.  my fstab has
> rw,usrquota. 
> 
> [root@gauss quota-tools]# quotaon -v /users/raid2
> quotaon: Enable XFS group quota during mount
> quotaon: Enable XFS user quota during mount
> 
> [root@gauss quota-tools]# repquota /users/raid2
> [root@gauss quota-tools]#
> 
> I have setup quota on ext2 quite few times before so Im pretty sure I am
> not making any mistakes.  Please help.
> 
> 


For me, doesn't works well, I think that I have "out-dated" quota-tools, but

quot /users/raid2

command works well for me. Try it.

/Fermin

From owner-linux-xfs@oss.sgi.com Wed May  9 11:19:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IJEc03187
	for linux-xfs-outgoing; Wed, 9 May 2001 11:19:14 -0700
Received: from dragon.vcu.edu (dragon.vcu.edu [128.172.65.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IJDF03184
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:19:13 -0700
Received: from comet.vcu.edu (comet.vcu.edu [128.172.1.33])
	by dragon.vcu.edu (8.9.3/8.9.3) with ESMTP id OAA7157281;
	Wed, 9 May 2001 14:19:22 -0400 (EDT)
Date: Wed, 9 May 2001 14:19:10 -0400 (EDT)
From: K Mitchell Russell <kmrussel@hsc.vcu.edu>
X-Sender: kmrussel@comet.vcu.edu
To: utz lehmann <xfs@s2y4n2c.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
In-Reply-To: <20010509185137.A15348@s2y4n2c.de>
Message-ID: <Pine.A41.4.10.10105091416040.12300-100000@comet.vcu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 9 May 2001, utz lehmann wrote:

> Hi
> 
> I just tested the rescue mode of the RH 7.1 xfs install iso.
> (I dont needed this time .-)
> 
> I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> should added. fsck for ext2 and ext3 are there.
> 

Interestingly, I booted into linux rescue off the RH7.1 XFS 1.0 iso a
couple days ago, and found xfs_check and xfs_repair to run fine.  Are
there two versions of the 1.0 iso released?

Regards,
Mitchell
________________________________________________________________________
K. Mitchell Russell, M.D.                        |  kmrussel@hsc.vcu.edu
Research Fellow, MedITAC Research Lab            |  www.meditac.com




From owner-linux-xfs@oss.sgi.com Wed May  9 11:24:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IOOj03332
	for linux-xfs-outgoing; Wed, 9 May 2001 11:24:24 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IOMF03329
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:24:23 -0700
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14xYdJ-0003GP-00; Wed, 9 May 2001 20:24:21 +0200
Received: from pd9007f1f.dip.t-dialin.net ([217.0.127.31] helo=kernelpanix.aura.of.mankind)
	by mrvdom00.schlund.de with esmtp (Exim 2.12 #2)
	id 14xYdE-0007By-00; Wed, 9 May 2001 20:24:16 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f49HiP016429;
	Wed, 9 May 2001 19:44:25 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 9 May 2001 19:44:25 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
Message-ID: <20010509194425.A16414@s2y4n2c.de>
References: <xfs@s2y4n2c.de> <200105091745.f49HjP100663@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105091745.f49HjP100663@jen.americas.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord [lord@sgi.com] wrote:
> > Hi
> > 
> > I just tested the rescue mode of the RH 7.1 xfs install iso.
> > (I dont needed this time .-)
> > 
> > I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> > should added. fsck for ext2 and ext3 are there.
> > 
> > 
> > cheers
> > 
> > utz
> 
> Hmmm, that was supposed to have happened, I discovered this problem a
> few weeks ago and I thought the change was made to get them out there.
> Russell, did this change go missing?
> 
> Steve
> 

opps. my fault.

This was a test release. I should label my CDRs better.

sorry.


utz

From owner-linux-xfs@oss.sgi.com Wed May  9 11:26:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IQcY03446
	for linux-xfs-outgoing; Wed, 9 May 2001 11:26:38 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IQcF03443
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:26:38 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA02092
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:37:28 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1756008; Wed, 9 May 2001 13:25:20 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA02193; Wed, 9 May 2001 13:25:16 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49IRlD02877; Wed, 9 May 2001 13:27:47 -0500
Message-Id: <200105091827.f49IRlD02877@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
cc: utz lehmann <xfs@s2y4n2c.de>, linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso 
In-Reply-To: Message from K Mitchell Russell <kmrussel@hsc.vcu.edu> 
   of "Wed, 09 May 2001 14:19:10 EDT." <Pine.A41.4.10.10105091416040.12300-100000@comet.vcu.edu> 
Date: Wed, 09 May 2001 13:27:47 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


OK, this maybe the problem - Utz are you sure you are using the official 1.0
iso, or an older one. I do not think these commands would be there in any of
the pre-release versions.

Steve

> On Wed, 9 May 2001, utz lehmann wrote:
> 
> > Hi
> > 
> > I just tested the rescue mode of the RH 7.1 xfs install iso.
> > (I dont needed this time .-)
> > 
> > I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> > should added. fsck for ext2 and ext3 are there.
> > 
> 
> Interestingly, I booted into linux rescue off the RH7.1 XFS 1.0 iso a
> couple days ago, and found xfs_check and xfs_repair to run fine.  Are
> there two versions of the 1.0 iso released?
> 
> Regards,
> Mitchell
> ________________________________________________________________________
> K. Mitchell Russell, M.D.                        |  kmrussel@hsc.vcu.edu
> Research Fellow, MedITAC Research Lab            |  www.meditac.com
> 
> 



From owner-linux-xfs@oss.sgi.com Wed May  9 11:27:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IR1903488
	for linux-xfs-outgoing; Wed, 9 May 2001 11:27:01 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IR0F03483
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:27:00 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f49IQul20266;
	Wed, 9 May 2001 13:26:56 -0500 (CDT)
Message-ID: <3AF98C76.4AA8D1FC@sgi.com>
Date: Wed, 09 May 2001 13:29:10 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
CC: utz lehmann <xfs@s2y4n2c.de>, linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
References: <Pine.A41.4.10.10105091416040.12300-100000@comet.vcu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

K Mitchell Russell wrote:
 
> Interestingly, I booted into linux rescue off the RH7.1 XFS 1.0 iso a
> couple days ago, and found xfs_check and xfs_repair to run fine.  Are
> there two versions of the 1.0 iso released?

No, although there are several -testX releases.

Utz, are you sure you have the REAL 1.0?  TRANS.TBL in the root dir
should be dated April 27.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 11:59:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IxEG05342
	for linux-xfs-outgoing; Wed, 9 May 2001 11:59:14 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IxEF05339
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:59:14 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05240
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 12:10:03 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1758850; Wed, 9 May 2001 13:57:56 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA73885; Wed, 9 May 2001 13:57:55 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49J0Rx04021; Wed, 9 May 2001 14:00:27 -0500
Message-Id: <200105091900.f49J0Rx04021@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS + RSBAC 
In-Reply-To: Message from K Mitchell Russell <kmrussel@hsc.vcu.edu> 
   of "Mon, 07 May 2001 19:44:04 EDT." <Pine.A41.4.10.10105071423320.42368-100000@comet.vcu.edu> 
Date: Wed, 09 May 2001 14:00:27 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Colleagues,
> 
> I have patched a kernel with XFS 1.0 and the Rule-Set Based Access
> Controls (www.rsbac.org). This is of particular importance to me for
> using Linux to power medical record repositories, requiring data
> integrity (journaled fs), performance, and security (mandatory access
> controls, role compatibility, ACLs, etc.)
> 
> The system seems to run fine even using RSBAC's 'check on init'
> function. This function caused problems with ReiserFS as ReiserFS works
> internally with 64 bit inode numbers, and RSBAC was removing entries for
> inode, which was making ReiserFS complain. Now my impression is that XFS
> uses 64 bit inodes, but somehow this is more compatible than the
> ReiserFS usage because I am not getting the same errors. Does XFS use 64
> bit inodes? Anyone care to comment?


Yes, XFS does use 64 bit inode numbers, but since the inode numbers are
really an encoded disk address, the top 32 bits of the inode number do not
get used unless you use really big filesystems, and the actual size is
a function of a number of factors, but at least 1 Tbyte, and usually
larger is required to move into the 33rd bit. I have some plans on how to
avoid this as well.

> 
> Finally, there is one part of the patch in RSBAC that is still FS
> dependent, a secure delete function that patches the fs/ext2/namei.c
> (for example) in ext2 by adding the following to ext2_unlink():
> 
> if(inode->i_nlink == 1)
>   rsbac_sec_del(dentry);
> 
> Now they have only implemented this into ext2, vfat, dos, and minix
> fs's, but would be nice for XFS integration as well. Where would such a
> patch work, or does XFS have an interface for this?

linvfs_unlink in fs/xfs/linux/xfs_iops.c, you need to do it after the
validate_fields() calls.

Steve

> 
> Anyone with further interest in both XFS and the RSBAC patches is
> welcome to cross post to the rsbac@rsbac.org mailing list.
> 
> Thanks in advance, and congratulations on creating an excellent product
> in XFS and supporting open source software!
> 
> Regards,
> Mitchell
> 
> 
> ________________________________________________________________________
> K. Mitchell Russell, M.D.                         | kmrussel@hsc.vcu.edu
> Research Fellow, MedITAC Research Lab             |   www.meditac.com
> 
> 
> 



From owner-linux-xfs@oss.sgi.com Wed May  9 12:09:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49J9uh06075
	for linux-xfs-outgoing; Wed, 9 May 2001 12:09:56 -0700
Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49J9sF06072
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 12:09:54 -0700
Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id UAA25086 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 20:07:21 +0200
Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4)
	id VAA26119; Wed, 9 May 2001 21:09:45 +0200 (MET DST)
Date: Wed, 9 May 2001 21:09:45 +0200 (MET DST)
From: fermin@eup.udl.es (Fermin Molina)
Message-Id: <200105091909.VAA26119@eup.udl.es>
To: linux-xfs@oss.sgi.com
Subject: Re: nfsd from kernel 2.4.4 oops
X-Sun-Charset: US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm get an Oops with cvs 2.4.4 XFS kernel. A patch for
NFS helps me to solve the oops, but the patch maker,
Neil Brown, thinks that is a XFS error, because
'XFS isn't finding ".." when asked'.

I include all the reply.

There is a bug in XFS code?

I see in this list some messages with
people that get similar oops.

/Fermin


----- Begin Included Message -----

>From neilb@cse.unsw.edu.au Wed May  9 03:41 MET 2001
From: Neil Brown <neilb@cse.unsw.edu.au>
To: fermin@eup.udl.es (Fermin Molina)
Date: Wed, 9 May 2001 10:57:42 +1000 (EST)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: linux-kernel@vger.kernel.org
Subject: Re: nfsd from kernel 2.4.4 oops
X-Mailer: VM 6.72 under Emacs 20.7.2
X-face: 	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD\ui5Fh?f
	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gldn~*FK9x
	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ

On Tuesday May 8, fermin@eup.udl.es wrote:
> Hi,
> 
> I'm using kernel 2.4.4 cvs from SGI, with xfs. I'm getting this Oops:
> 
> kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010
> kernel:  printing eip:
> kernel: c017bfd8
> kernel: *pde = 00000000
> kernel: Oops: 0000
> kernel: CPU:    0
> kernel: EIP:    0010:[nfsd_findparent+120/236]
> kernel: EIP:    0010:[<c017bfd8>]
> kernel: EFLAGS: 00010246
> kernel: eax: 00000000   ebx: 00000000   ecx: cff8d458   edx: 00000010
> kernel: esi: cb22c6a0   edi: cb22c720   ebp: cb22c720   esp: ce4c9e54
> kernel: ds: 0018   es: 0018   ss: 0018
> kernel: Process nfsd (pid: 592, stackpage=ce4c9000)
> kernel: Stack: 00000000 1802280f c017c416 cb22c720 00000000 ce4cf814 11270000 ce4cf804
> kernel:        c03c5740 cfe3b5c8 0000000e ffffff8c 00000000 c017c7c4 cfe3b400 1802280f
> kernel:        00000000 00000000 00000001 ce4cf804 00000008 cb1fc77c ce4cfc00 ceb7b000
> kernel: Call Trace: [find_fh_dentry+598/928] [fh_verify+612/1128] [nfsd_lookup+110/1368] [nfsd3_proc_lookup+314/332] [nfs3svc_decode_diropargs+152/268] [nfsd_dispatch+203/360] [svc_process+684/1348]
> kernel: Call Trace: [<c017c416>] [<c017c7c4>] [<c017cdde>] [<c0182cbe>] [<c018498c>] [<c017a663>] [<c02df688>]
> 

nfsd_findparent+120/236 corresponds to line 257 on fs/nfsd/nfsfh.h
and the condition of the "if" statement:
		if (aliases->next != aliases) {
just after the "spin_lock(&dcache_lock)".
eax == 0 implies that &tdentry->d_inode == NULL, and hence the oops.

d_inode being NULL here implies that the "lookup" of ".." failed
to find a ".." entry, which is very odd.

I find it hard to believe that ext2fs would ever do this unless the
filesystem was corrupt.  XFS might, I don't know.

I guess nfsd should be robust against this sort of behaviour in
filesystems.

Something like:

--- nfsfh.c	2001/05/09 00:54:56	1.1
+++ nfsfh.c	2001/05/09 00:56:01
@@ -244,6 +244,10 @@
 	 */
 	pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
 	d_drop(tdentry); /* we never want ".." hashed */
+	if (!pdentry && tdentry->d_inode == NULL) {
+		dput(tdentry);
+		pdentry = ERR_PTR(-EINVAL);
+	}
 	if (!pdentry) {
 		/* I don't want to return a ".." dentry.
 		 * I would prefer to return an unconnected "IS_ROOT" dentry,


Is probably the best fix for knfsd, but someone should find out why
XFS isn't finding ".." when asked (If that is indeed what is
happening).

NeilBrown


> 
> It's produced very randomly. Some people (readed in xfs list) get similar error and
> tested too with a clean 2.4.4 with ext2 filesystem, and oops too. I think this is
> related to nfsd code (maybe sunrpc code), and it's not related to xfs code.


----- End Included Message -----


From owner-linux-xfs@oss.sgi.com Wed May  9 13:07:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49K7Qc08225
	for linux-xfs-outgoing; Wed, 9 May 2001 13:07:26 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49K7NF08222
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:07:23 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1113430
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 22:07:21 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1758570; Wed, 9 May 2001 15:06:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24816; Wed, 9 May 2001 15:06:03 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49K8YF04962; Wed, 9 May 2001 15:08:34 -0500
Message-Id: <200105092008.f49K8YF04962@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: fermin@eup.udl.es (Fermin Molina)
cc: linux-xfs@oss.sgi.com
Subject: Re: nfsd from kernel 2.4.4 oops 
In-Reply-To: Message from fermin@eup.udl.es (Fermin Molina) 
   of "Wed, 09 May 2001 21:09:45 +0200." <200105091909.VAA26119@eup.udl.es> 
Date: Wed, 09 May 2001 15:08:34 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Yes it does look like xfs is not finding .. and at the moment I have no 
idea why, can you give us some more details of what it is you are doing
to produce this scenario. The only way I can see of xfs not finding .. is
that the passed in dcache entry and inode have something wrong with them.

Steve

> Hi,
> 
> I'm get an Oops with cvs 2.4.4 XFS kernel. A patch for
> NFS helps me to solve the oops, but the patch maker,
> Neil Brown, thinks that is a XFS error, because
> 'XFS isn't finding ".." when asked'.
> 
> I include all the reply.
> 
> There is a bug in XFS code?
> 
> I see in this list some messages with
> people that get similar oops.
> 
> /Fermin
> 
> 
> ----- Begin Included Message -----
> 
> >From neilb@cse.unsw.edu.au Wed May  9 03:41 MET 2001
> From: Neil Brown <neilb@cse.unsw.edu.au>
> To: fermin@eup.udl.es (Fermin Molina)
> Date: Wed, 9 May 2001 10:57:42 +1000 (EST)
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: nfsd from kernel 2.4.4 oops
> X-Mailer: VM 6.72 under Emacs 20.7.2
> X-face: 	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD
> \ui5Fh?f
> 	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gld
> n~*FK9x
> 	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ
> 
> On Tuesday May 8, fermin@eup.udl.es wrote:
> > Hi,
> > 
> > I'm using kernel 2.4.4 cvs from SGI, with xfs. I'm getting this Oops:
> > 
> > kernel: Unable to handle kernel NULL pointer dereference at virtual address
>  00000010
> > kernel:  printing eip:
> > kernel: c017bfd8
> > kernel: *pde = 00000000
> > kernel: Oops: 0000
> > kernel: CPU:    0
> > kernel: EIP:    0010:[nfsd_findparent+120/236]
> > kernel: EIP:    0010:[<c017bfd8>]
> > kernel: EFLAGS: 00010246
> > kernel: eax: 00000000   ebx: 00000000   ecx: cff8d458   edx: 00000010
> > kernel: esi: cb22c6a0   edi: cb22c720   ebp: cb22c720   esp: ce4c9e54
> > kernel: ds: 0018   es: 0018   ss: 0018
> > kernel: Process nfsd (pid: 592, stackpage=ce4c9000)
> > kernel: Stack: 00000000 1802280f c017c416 cb22c720 00000000 ce4cf814 112700
> 00 ce4cf804
> > kernel:        c03c5740 cfe3b5c8 0000000e ffffff8c 00000000 c017c7c4 cfe3b4
> 00 1802280f
> > kernel:        00000000 00000000 00000001 ce4cf804 00000008 cb1fc77c ce4cfc
> 00 ceb7b000
> > kernel: Call Trace: [find_fh_dentry+598/928] [fh_verify+612/1128] [nfsd_loo
> kup+110/1368] [nfsd3_proc_lookup+314/332] [nfs3svc_decode_diropargs+152/268] 
> [nfsd_dispatch+203/360] [svc_process+684/1348]
> > kernel: Call Trace: [<c017c416>] [<c017c7c4>] [<c017cdde>] [<c0182cbe>] [<c
> 018498c>] [<c017a663>] [<c02df688>]
> > 
> 
> nfsd_findparent+120/236 corresponds to line 257 on fs/nfsd/nfsfh.h
> and the condition of the "if" statement:
> 		if (aliases->next != aliases) {
> just after the "spin_lock(&dcache_lock)".
> eax == 0 implies that &tdentry->d_inode == NULL, and hence the oops.
> 
> d_inode being NULL here implies that the "lookup" of ".." failed
> to find a ".." entry, which is very odd.
> 
> I find it hard to believe that ext2fs would ever do this unless the
> filesystem was corrupt.  XFS might, I don't know.
> 
> I guess nfsd should be robust against this sort of behaviour in
> filesystems.
> 
> Something like:
> 
> --- nfsfh.c	2001/05/09 00:54:56	1.1
> +++ nfsfh.c	2001/05/09 00:56:01
> @@ -244,6 +244,10 @@
>  	 */
>  	pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
>  	d_drop(tdentry); /* we never want ".." hashed */
> +	if (!pdentry && tdentry->d_inode == NULL) {
> +		dput(tdentry);
> +		pdentry = ERR_PTR(-EINVAL);
> +	}
>  	if (!pdentry) {
>  		/* I don't want to return a ".." dentry.
>  		 * I would prefer to return an unconnected "IS_ROOT" dentry,
> 
> 
> Is probably the best fix for knfsd, but someone should find out why
> XFS isn't finding ".." when asked (If that is indeed what is
> happening).
> 
> NeilBrown
> 
> 
> > 
> > It's produced very randomly. Some people (readed in xfs list) get similar e
> rror and
> > tested too with a clean 2.4.4 with ext2 filesystem, and oops too. I think t
> his is
> > related to nfsd code (maybe sunrpc code), and it's not related to xfs code.
> 
> 
> ----- End Included Message -----



From owner-linux-xfs@oss.sgi.com Wed May  9 13:10:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49KA8Q08309
	for linux-xfs-outgoing; Wed, 9 May 2001 13:10:08 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KA7F08305
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:10:07 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1108247
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 22:10:05 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1758702 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:08:48 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA00595 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:08:48 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f49KBJr05010; Wed, 9 May 2001 15:11:19 -0500
Message-Id: <200105092011.f49KBJr05010@jen.americas.sgi.com>
Date: Wed, 9 May 2001 15:11:19 -0500
Subject: TAKE - make default st_blksize 4K
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This will change the default value returned for st_blksize by stat in XFS
to be 4K rather than 64K. This will help various programs which use database
files such as rpm and various mail programs keep their file size down.

The biosize mount option can still be used to increase the value.

Date:  Wed May  9 13:06:47 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-base

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94445a
linux/fs/xfs/xfs_mount.h - 1.126
	- change default biosize to 4K and change the minimum size to 4K

linux/fs/xfs/xfs_mount.c - 1.254
	- Make the default biosize independent of memory size



From owner-linux-xfs@oss.sgi.com Wed May  9 13:46:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49KkqR09247
	for linux-xfs-outgoing; Wed, 9 May 2001 13:46:52 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KkqF09244
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:52 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA13389
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:50 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA14751
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:50 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for linux-xfs@oss.sgi.com; Wed, 9 May 2001 13:46:37 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id NAA35644
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:36 -0700
Message-Id: <3AF9ACAC.E621337C@pipcws.ca.boeing.com>
Date: Wed, 09 May 2001 13:46:36 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Mystery Mouse
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All
I have an interesting conflict with my mouse, & kudzu.
It's a standard Logitech 3 button PS/2 Mouse. Nothing fancy. LM 8.0 & kudzu have
teamed up to make me miserable. 
Every time I boot, kudzu changes the state of the mouse. If it's connected &
happy, kudzu will claim that the mouse has been removed, and pop up the window
to confirm the removal of the device. On the next re-boot, it will detect the
mouse, and want to re-install it. This happens EVERY TIME I reboot. 
For now, I've removed kudzu fro the boot up procedure until I can figure this
out.

Does anyone have any suggestions?

	Thanks!

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Wed May  9 13:58:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49KwUt09579
	for linux-xfs-outgoing; Wed, 9 May 2001 13:58:30 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KwTF09575
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:58:29 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id NAA02990
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:58:17 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1758110 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:56:52 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA61307 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:56:52 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f49KxM009550; Wed, 9 May 2001 15:59:22 -0500
Message-Id: <200105092059.f49KxM009550@jen.americas.sgi.com>
Date: Wed, 9 May 2001 15:59:22 -0500
Subject: TAKE - remove the kiobuf from the pagebuf structure
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The fact that the size of the kiobuf was grown to be huge, and that
1024 buffer heads were automatically allocated for each one made them
somewhat untenable for use within pagebuf. Therefore I have removed
them and the kiobuf code in our tree reverts to the original version.

This should make XFS on a 2.4.4 kernel a more pleasant experience.


Date:  Wed May  9 13:54:27 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-base

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94460a
linux/mm/memory.c - 1.48
linux/kernel/ksyms.c - 1.88
linux/init/main.c - 1.53
	- revert to vanilla 2.4.4 code base as far as kiobufs are concerned.

linux/fs/iobuf.c - 1.20
linux/include/linux/iobuf.h - 1.14
	- revert to vanilla 2.4.4 code base - no longer need xfs specials in here

linux/include/linux/page_buf.h - 1.90
	- Change pagebuf structure to contain the parts of the kiobuf we actually
	  need.

linux/kdb/modules/kdbm_pg.c - 1.34
	- account for changes in pagebuf structure

linux/fs/pagebuf/page_buf.c - 1.80
	- We now allocate our own array of pages rather than using a kiobuf. The
	  kiobuf overhead was getting too great.

linux/fs/pagebuf/page_buf_io.c - 1.78
	- Change direct I/O path to allocate its own kiobuf and point the pagebuf
	  at it's list of pages.



From owner-linux-xfs@oss.sgi.com Wed May  9 15:29:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49MTGn12047
	for linux-xfs-outgoing; Wed, 9 May 2001 15:29:16 -0700
Received: from walt400.holman.net (aazpppdsl104.sttl.uswest.net [63.226.208.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49MTFF12044
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:29:15 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP
	id 8C675437481; Wed,  9 May 2001 15:38:00 -0700 (PDT)
Message-ID: <3AF9C6C8.9040009@uswest.net>
Date: Wed, 09 May 2001 15:38:00 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9+) Gecko/20010508
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mystery Mouse
References: <3AF9ACAC.E621337C@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Not sure if this is relevant and/or helpful, but I had a problem with my 
PS/2 mouse w/ Mandrake 7.2 due to the load order of gpm. I fixed it by 
changing the start number in the relevant runlevels in the 
/etc/rc.d/rcx.d directories. In my case, some other device (usb?) was 
attaching to IRQ 12 and screwing with the mouse. I just renamed the 
start file to make it startup prior to harddrake/kudzu. I don't have gpm 
installed on my system now and everything appears to work allright 
without it - hmmm.....

-Walt


Ric Tibbetts wrote:

>All
>I have an interesting conflict with my mouse, & kudzu.
>It's a standard Logitech 3 button PS/2 Mouse. Nothing fancy. LM 8.0 & kudzu have
>teamed up to make me miserable. 
>Every time I boot, kudzu changes the state of the mouse. If it's connected &
>happy, kudzu will claim that the mouse has been removed, and pop up the window
>to confirm the removal of the device. On the next re-boot, it will detect the
>mouse, and want to re-install it. This happens EVERY TIME I reboot. 
>For now, I've removed kudzu fro the boot up procedure until I can figure this
>out.
>
>Does anyone have any suggestions?
>
>	Thanks!
>



From owner-linux-xfs@oss.sgi.com Wed May  9 15:48:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49Mm1L12328
	for linux-xfs-outgoing; Wed, 9 May 2001 15:48:01 -0700
Received: from mulder.chinalake.navy.mil (mulder.chinalake.navy.mil [206.37.206.69])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Mm0F12325
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:48:01 -0700
Received: by mulder.chinalake.navy.mil; id PAA28174; Wed, 9 May 2001 15:47:42 -0700 (PDT)
Received: from nwim12.chinalake.navy.mil(199.211.228.55) by mulder.chinalake.navy.mil via smap (V4.2)
	id xma027968; Wed, 9 May 01 15:46:56 -0700
Received: by nwim12.chinalake.navy.mil with Internet Mail Service (5.5.2653.19)
	id <KS6ND63C>; Wed, 9 May 2001 15:46:55 -0700
Message-ID: <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil>
From: "McMechan, Jim" <McMechanJW@navair.navy.mil>
To: linux-xfs@oss.sgi.com
Subject: Browsing xfs-TEST
Date: Wed, 9 May 2001 15:46:54 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
examined the rejects
comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"

The "unsigned char s_posix_acl_flag" in "struct super_block" in
"include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
produces the worst packing of a structure is it intended to be in the same
cache line or some other reason? tucking it after "unsigned char s_dirt"
would have a better packing, I think.

The "unsigned long block[]" and "ulong block[]" declarations are back in
"drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
was it intended to return to local arrays?

The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
"kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
destroyed stacking devices made me leery in this section.

There also were files that may have been left over "merge#conflicts" and
"fs/iobuf.2.4.4.c"

From owner-linux-xfs@oss.sgi.com Wed May  9 16:03:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49N3Pc12566
	for linux-xfs-outgoing; Wed, 9 May 2001 16:03:25 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49N3OF12563
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:03:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1096461
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 01:03:22 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1758963; Wed, 9 May 2001 18:02:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA42061; Wed, 9 May 2001 18:02:04 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49N4Xb15688; Wed, 9 May 2001 18:04:33 -0500
Message-Id: <200105092304.f49N4Xb15688@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "McMechan, Jim" <McMechanJW@navair.navy.mil>
cc: linux-xfs@oss.sgi.com
Subject: Re: Browsing xfs-TEST 
In-Reply-To: Message from "McMechan, Jim" <McMechanJW@navair.navy.mil> 
   of "Wed, 09 May 2001 15:46:54 PDT." <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil> 
Date: Wed, 09 May 2001 18:04:33 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
> examined the rejects
> comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"
> 
> The "unsigned char s_posix_acl_flag" in "struct super_block" in
> "include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
> produces the worst packing of a structure is it intended to be in the same
> cache line or some other reason? tucking it after "unsigned char s_dirt"
> would have a better packing, I think.

yep that does appear to be a dumb place to put it.

> 
> The "unsigned long block[]" and "ulong block[]" declarations are back in
> "drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
> was it intended to return to local arrays?

Hmm, looks like the patch is out of date here, they are defined this way in
the tree now:

        unsigned long blocks[KIO_MAX_SECTORS];
        ulong blocks[1];



> 
> The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
> "kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
> destroyed stacking devices made me leery in this section.

Also changed in the development tree.

> 
> There also were files that may have been left over "merge#conflicts" and
> "fs/iobuf.2.4.4.c"


No comment - except it wasn't me!

One day we might get the patch process going fast enough, but for now,
the message remains that if you really want to follow the development
the only real way to do it is to usr the cvs tree.

Thanks for the comments, I will reorder the fields in the superblock.

Steve



From owner-linux-xfs@oss.sgi.com Wed May  9 16:09:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49N9fI12743
	for linux-xfs-outgoing; Wed, 9 May 2001 16:09:41 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49N9eF12740
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:09:40 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00972
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:20:30 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA29251; Wed, 9 May 2001 18:08:24 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f49N7Ne24683;
	Wed, 9 May 2001 19:07:23 -0400
Message-ID: <3AF9CDA9.A1190D4C@thebarn.com>
Date: Wed, 09 May 2001 19:07:21 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "McMechan, Jim" <McMechanJW@navair.navy.mil>
CC: linux-xfs@oss.sgi.com
Subject: Re: Browsing xfs-TEST
References: <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"McMechan, Jim" wrote:

> I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
> examined the rejects
> comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"
>
> The "unsigned char s_posix_acl_flag" in "struct super_block" in
> "include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
> produces the worst packing of a structure is it intended to be in the same
> cache line or some other reason? tucking it after "unsigned char s_dirt"
> would have a better packing, I think.

I could go along with that.

>
>
> The "unsigned long block[]" and "ulong block[]" declarations are back in
> "drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
> was it intended to return to local arrays?

>
>
> The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
> "kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
> destroyed stacking devices made me leery in this section.

The lvm files shouldn't have changed much,  what was there before.
The xfs tree is at 0.9 beta6 and 2.4.4 is at ... beta2 I believe...
But we'll give it a look no the less.

>
> There also were files that may have been left over "merge#conflicts" and
> "fs/iobuf.2.4.4.c"

That patch was a quick push for anybody wishing to play with 2.4.4,
since the devel tree has been bumped to 2.4.4 the patch has been removed
from oss.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  9 16:34:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49NYtX13420
	for linux-xfs-outgoing; Wed, 9 May 2001 16:34:55 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49NYrF13416
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:34:54 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f49NT7r19785;
	Wed, 9 May 2001 18:29:07 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 9 May 2001 18:29:07 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Tilman Kastner <kastner@devicen.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: kupdate - excessive CPU usage
In-Reply-To: <B71EE34B.193D1%kastner@devicen.de>
Message-ID: <Pine.LNX.4.33.0105091828150.17991-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Have you tried restarting your logging services? I've noticed something
similar to that as well, not recently though, but I would restart syslog,
which restarts klogd as well, and then kupdate seems to go back to normal.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 9 May 2001, Tilman Kastner wrote:

> Hello,
>
> First of all, please allow me to send a big THANK YOU to all of you who made
> XFS on linux a reality. Working with XFS on IRIX for quite some time, I am
> convinced that the availability of XFS will be a big step forward for Linux
> in mission-critical applications.
>
> I recently switched a desktop machine to XFS-only. Patching the SuSE-2.4.2
> kernel sources worked without a problem (to my surprise), compiling with gcc
> 2.95.2 was no problem, too. After reboot, everything works like a charm, but
> after some hours of moderate or even low fs-activity, kupdate starts to eat
> up CPU every time it is called - even the mouse on X freezes for approx.
> 1/2s.
>
> I have not found postings regarding this problem in the archive yet, so any
> hints would be appreciated. Should I try another (clean) kernel, a different
> gcc, different settings for mkfs, etc...
>
> Thanks in advance
>
> Tilman
>
>
>


From owner-linux-xfs@oss.sgi.com Wed May  9 16:36:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49NaSB13479
	for linux-xfs-outgoing; Wed, 9 May 2001 16:36:28 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49NaQF13476
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:36:27 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id QAA09486
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:36:10 -0700 (PDT)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10554; Thu, 10 May 2001 09:34:52 +1000
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA83126; Thu, 10 May 2001 09:34:49 +1000 (EST)
Date: Thu, 10 May 2001 09:34:49 +1000
From: Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To: Gwenael.Letellier@INTRINsec.com
Cc: linux-xfs@oss.sgi.com
Subject: Re: Apache and XFS ACLs
Message-ID: <20010510093449.G100812@fudge.melbourne.sgi.com>
References: <BEC329079D7AD4119FA7000102A316EF0573FC@flic.corp.INTRINsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <BEC329079D7AD4119FA7000102A316EF0573FC@flic.corp.INTRINsec.com>; from Gwenael.Letellier@INTRINsec.com on Wed, May 09, 2001 at 12:50:32PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 09, 2001 at 12:50:32PM +0200, Gwenael.Letellier@INTRINsec.com wrote:
> Hi,
> 
> This bug report is being submitted both to XFS and Apache bug reporting
> systems.
> 
> First thank you all at SGI for the great work. RH-71 with XFS root installed
> nicely on my laptop.
> 
> Now my problem : I have been taking a look at XFS ACLs, and there seem to be
> a problem with apache not taking XFS ACLs into account.
> 
> Details :
> 
> Software versions : stock RH-71 with XFS-1.0 install disk, Apache-1.3.19
> 
> Problem : say I have a user called gwen, with home directory /home/gwen.
> Apache is running under apache.apache and user home directories are
> configured to be readable as ~gwen for /home/gwen/public_html. Apache
> indexes on index.html.
> 
> If I set the following perms, without any ACLs, everything is working fine :
> drwxr-xr-x	root	root	/home
> drwx-----x	gwen	gwen	/home/gwen
> drwx---r-x	gwen	gwen	/home/gwen/public_html
> -rwx---r--	gwen	gwen	/home/gwen/public_html/index.html
> 
> I have access to index.html, which prints out a nice "Hello, World!" ;-).
> 
> 
> If I want to be more restrictive, and use ACLs to allow access to this file
> only to the user named apache, and/or (tried both) to the group named
> apache, I get a 403 Forbidden error from apache.
> 
> Permissions are set the following way :
> drwxr-xr-x	root	root	/home
> drwx------	gwen	gwen	/home/gwen
> drwx------	gwen	gwen	/home/gwen/public_html
> -rwx------	gwen	gwen	/home/gwen/public_html/index.html
> 
> and the following ACLs are set too, for the user apache, group apache :
> d--x--x---	apache	apache	/home/gwen
> dr-xr-x---	apache	apache	/home/gwen/public_html
> -r-xr-x---	apache	apache	/home/gwen/public_html/index.html

What's the output from chacl -l for each of these files?

> I don't know whether I did something wrong in ACL settings. I think it has
> to do with the way Apache checks for perms.

Well it's not Apache that's enforcing these permissions, it's the 
ACL code in the kernel. 

Andrew

-- 
Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia
email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183

From owner-linux-xfs@oss.sgi.com Wed May  9 16:41:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49Nf4s13595
	for linux-xfs-outgoing; Wed, 9 May 2001 16:41:04 -0700
Received: from scully.mugu.navy.mil (scully.mugu.navy.mil [199.211.225.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Nf3F13592
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:41:03 -0700
Received: by scully.mugu.navy.mil; id QAA11769; Wed, 9 May 2001 16:41:02 -0700 (PDT)
Received: from nwim02.mugu.navy.mil(143.113.102.22) by scully.mugu.navy.mil via smap (V4.2)
	id xma011278; Wed, 9 May 01 16:39:51 -0700
Received: by nwim02.mugu.navy.mil with Internet Mail Service (5.5.2653.19)
	id <KS6N3DL3>; Wed, 9 May 2001 16:39:37 -0700
Message-ID: <FF33C1948816D211A65300A0C9CF4536055705E0@nwms13.chinalake.navy.mil>
From: "McMechan, Jim" <McMechanJW@navair.navy.mil>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: RE: Browsing xfs-TEST 
Date: Wed, 9 May 2001 16:39:44 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

	<Big Snip>
> One day we might get the patch process going fast enough, but for now,
> the message remains that if you really want to follow the development
> the only real way to do it is to usr the cvs tree.
> 
> Thanks for the comments, I will reorder the fields in the superblock.
> 
> Steve
> 
Unfortunately my firewall at work wants my ip address the (fixed)
destination ip address and a justification for any connections like CVS;
This puts a dent in CVS update ease of use.

XFS is most useful for server systems and nicer on a T3 link rather than a
shared 56k modem.  At home I can't get WinCVS to handle multiple
repositories with any ease? (suggestions welcome)

Have you considered a automated (e.g. cron) snapshot procedure on the ftp
server. Like the nightly builds at Mozilla.org or sourceforge.net? This
would "get the patch process going fast enough" and limit the amount of
update needed since a snapshot could then be updated by CVS.


From owner-linux-xfs@oss.sgi.com Wed May  9 16:48:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49NmEv13694
	for linux-xfs-outgoing; Wed, 9 May 2001 16:48:14 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49NlwF13684
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:48:12 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Dx02444;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49MKpq00939
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:20:54 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49Mm9ob003399;
	Wed, 9 May 2001 15:48:09 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 15:48:02 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49Mm1AZ003375
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 15:48:02 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49Mm1L12328
	for linux-xfs-outgoing; Wed, 9 May 2001 15:48:01 -0700
Received: from mulder.chinalake.navy.mil (mulder.chinalake.navy.mil [206.37.206.69])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49Mm0F12325
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:48:01 -0700
Received: by mulder.chinalake.navy.mil; id PAA28174; Wed, 9 May 2001 15:47:42 -0700 (PDT)
Received: from nwim12.chinalake.navy.mil(199.211.228.55) by mulder.chinalake.navy.mil via smap (V4.2)
	id xma027968; Wed, 9 May 01 15:46:56 -0700
Received: by nwim12.chinalake.navy.mil with Internet Mail Service (5.5.2653.19)
	id <KS6ND63C>; Wed, 9 May 2001 15:46:55 -0700
Message-ID: <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil>
From: "McMechan, Jim" <McMechanJW@navair.navy.mil>
To: linux-xfs@oss.sgi.com
Subject: Browsing xfs-TEST
Date: Wed, 9 May 2001 15:46:54 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
examined the rejects
comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"

The "unsigned char s_posix_acl_flag" in "struct super_block" in
"include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
produces the worst packing of a structure is it intended to be in the same
cache line or some other reason? tucking it after "unsigned char s_dirt"
would have a better packing, I think.

The "unsigned long block[]" and "ulong block[]" declarations are back in
"drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
was it intended to return to local arrays?

The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
"kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
destroyed stacking devices made me leery in this section.

There also were files that may have been left over "merge#conflicts" and
"fs/iobuf.2.4.4.c"


From owner-linux-xfs@oss.sgi.com Wed May  9 17:08:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A08O314189
	for linux-xfs-outgoing; Wed, 9 May 2001 17:08:24 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A08OF14186
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:08:24 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA01684
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:07:00 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10832; Thu, 10 May 2001 10:07:01 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA56657;
	Thu, 10 May 2001 10:07:00 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105101006.ZM76263@wobbly.melbourne.sgi.com>
Date: Thu, 10 May 2001 10:06:59 -0500
In-Reply-To: marchuk@ee.washington.edu
        "Re: XFS 1.0/Quota" (May  9, 10:03am)
References: <Pine.LNX.4.21.0105090958430.12885-100000@darkstar.ee.washington.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: marchuk@ee.washington.edu
Subject: Re: XFS 1.0/Quota
Cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 9, 10:03am, marchuk@ee.washington.edu wrote:
> Subject: Re: XFS 1.0/Quota
> > Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> > kernel patches, quota works without any patching at all.
> > 
> > cheers.
> > 
> > -- 
> > Nathan
> > 
> 
> I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
> cvs quota tools.  Made sure that quota support and xfs quota support is
> selected in kernel.  quotaon -av doesnt show anything.  my fstab has
> rw,usrquota. 
> 

There is a "README.quota" file in the xfsprogs package -
read it & follow the instructions, that should get you up
and running with XFS quota.  The man page for quotaon(8)
has some relevent info here too.

> ...
> I have setup quota on ext2 quite few times before so Im pretty sure I am
> not making any mistakes.  Please help.

Quota under XFS is different to ext2 in a number of ways,
the above README describes the differences.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May  9 17:09:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A09Gn14214
	for linux-xfs-outgoing; Wed, 9 May 2001 17:09:16 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A09GF14211
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:09:16 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4A09DEZ027651;
	Wed, 9 May 2001 17:09:13 -0700
Date: Wed, 9 May 2001 17:09:13 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Fermin Molina <fermin@eup.udl.es>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0/Quota
In-Reply-To: <200105091801.UAA25437@eup.udl.es>
Message-ID: <Pine.LNX.4.21.0105091703080.16671-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I am still having problems with my quota.  raid2 is a 350Gb xfs
filesystem.  I've installed quota-3.01-pre5.tar.gz.  If I try setting a
quota on another disk(ext2 filesystem) it works fine but on xfs it
doesnt.  I've been at it back and forth and still quota doesnt work.


fstab entry:
# Raid
/dev/sdc1 /users/raid2 xfs rw,usrquota 0 0


[root@gauss doc]# quotaon /users/raid2
quotaon: Enable XFS group quota during mount
quotaon: Enable XFS user quota during mount

[root@gauss doc]# edquota temp1 -F xfs
No filesystems with quota detected.
[root@gauss doc]# edquota temp1
No filesystems with quota detected.

[root@gauss doc]# quot /users/raid2
/dev/sdc1 (/users/raid2) users:
30811212    root
 2978692    support

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Wed, 9 May 2001, Fermin Molina wrote:

> > > Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> > > kernel patches, quota works without any patching at all.
> > > 
> > > cheers.
> > > 
> > > -- 
> > > Nathan
> > > 
> > 
> > I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
> > cvs quota tools.  Made sure that quota support and xfs quota support is
> > selected in kernel.  quotaon -av doesnt show anything.  my fstab has
> > rw,usrquota. 
> > 
> > [root@gauss quota-tools]# quotaon -v /users/raid2
> > quotaon: Enable XFS group quota during mount
> > quotaon: Enable XFS user quota during mount
> > 
> > [root@gauss quota-tools]# repquota /users/raid2
> > [root@gauss quota-tools]#
> > 
> > I have setup quota on ext2 quite few times before so Im pretty sure I am
> > not making any mistakes.  Please help.
> > 
> > 
> 
> 
> For me, doesn't works well, I think that I have "out-dated" quota-tools, but
> 
> quot /users/raid2
> 
> command works well for me. Try it.
> 
> /Fermin
> 


From owner-linux-xfs@oss.sgi.com Wed May  9 17:22:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0Mo314619
	for linux-xfs-outgoing; Wed, 9 May 2001 17:22:50 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0MoF14616
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:22:50 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id RAA01744
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:33:38 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA10918; Thu, 10 May 2001 10:21:28 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA76255;
	Thu, 10 May 2001 10:21:26 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105101021.ZM76311@wobbly.melbourne.sgi.com>
Date: Thu, 10 May 2001 10:21:25 -0500
In-Reply-To: <marchuk@ee.washington.edu>
        "Re: XFS 1.0/Quota" (May  9,  5:09pm)
References: <Pine.LNX.4.21.0105091703080.16671-100000@darkstar.ee.washington.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: <marchuk@ee.washington.edu>, Fermin Molina <fermin@eup.udl.es>
Subject: Re: XFS 1.0/Quota
Cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 9,  5:09pm, <marchuk@ee.washington.edu> wrote:
> Subject: Re: XFS 1.0/Quota
> 
> fstab entry:
> # Raid
> /dev/sdc1 /users/raid2 xfs rw,usrquota 0 0
> 
> 
> [root@gauss doc]# quotaon /users/raid2
> quotaon: Enable XFS group quota during mount
> quotaon: Enable XFS user quota during mount
> 

quotaon is the wrong way to try to enable quota on this
XFS filesystem.  If your filesystem is mounted with the
above option, and the 3.01-pre5 quota tools are reporting
no quota for the filesystem, then the running kernel was
probably not compiled with XFS quota support.

If quota are enabled in the kernel, when you mount the
filesystem for the first time with the above options you
should see a console message along the lines "XFS doing
quotacheck..."

> 
> [root@gauss doc]# quot /users/raid2
> /dev/sdc1 (/users/raid2) users:
> 30811212    root
>  2978692    support
> 

The quot command will always work for any XFS filesystem,
independent of whether it has quota enabled or not.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May  9 17:29:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0Td014679
	for linux-xfs-outgoing; Wed, 9 May 2001 17:29:39 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0TcF14676
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:29:38 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4A0TPmZ052032;
	Wed, 9 May 2001 19:29:26 -0500 (CDT)
Message-ID: <3AF9E0DF.D7F36D98@thebarn.com>
Date: Wed, 09 May 2001 19:29:20 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "McMechan, Jim" <McMechanJW@navair.navy.mil>
CC: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Browsing xfs-TEST
References: <FF33C1948816D211A65300A0C9CF4536055705E0@nwms13.chinalake.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"McMechan, Jim" wrote:

>         <Big Snip>
> > One day we might get the patch process going fast enough, but for now,
> > the message remains that if you really want to follow the development
> > the only real way to do it is to usr the cvs tree.
> >
> > Thanks for the comments, I will reorder the fields in the superblock.
> >
> > Steve
> >
> Unfortunately my firewall at work wants my ip address the (fixed)
> destination ip address and a justification for any connections like CVS;
> This puts a dent in CVS update ease of use.

Not understanding your firewall setup I can't really comment on the
best  tunnel through it, but I'm sure your network guru could give you a
working setup.

>
>
> XFS is most useful for server systems and nicer on a T3 link rather than a
> shared 56k modem.  At home I can't get WinCVS to handle multiple
> repositories with any ease? (suggestions welcome)

Sorry know nothing of WinCVS, I assume it's a windows version of cvs?

Actually the two must faster methods of grabbing the devel tree
would be to either rsync a local copy of the cvs tree it self, or CVSup
which is the fastest and most efficient way of staying current.
http://linux-xfs.sgi.com/projects/xfs/cvsup.html

rsync -av oss.sgi.com::cvs/linux-2.4-xfs .

Note there is also a cvs "seed" patch in the "patches" directory on oss,
this is  rarely current but can take a 2.4.x tree and patch it
into a CVS capable tree that can be make current with
cvs update -d


>
> Have you considered a automated (e.g. cron) snapshot procedure on the ftp
> server. Like the nightly builds at Mozilla.org or sourceforge.net? This
> would "get the patch process going fast enough" and limit the amount of
> update needed since a snapshot could then be updated by CVS.

Given the numerous methods of staying current with the devel tree all
of which are  much less of a headache than nightly patches, no probably not.

Patches have their place but they lack any sort of revision tracking.
When tracking  down bugs it is crucial for the developer to know which
version of what the user is working with.

Also as a follow up to the 2.4.4-*TEST* patch.
Occasionally I will make patches available for "testing" purposes as
such they are placed in the testing directory as an indication of  it's
early unstable status.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hMr14907
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:22 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hKF14903
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:20 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4De02460;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49Mc2q01283
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:03 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49Kl8l0002032;
	Wed, 9 May 2001 13:47:08 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 13:46:53 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49KkqAZ002000
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 13:46:53 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49KkqR09247
	for linux-xfs-outgoing; Wed, 9 May 2001 13:46:52 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49KkqF09244
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:52 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA13389
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:50 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA14751
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:50 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP for linux-xfs@oss.sgi.com; Wed, 9 May 2001 13:46:37 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id NAA35644
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:46:36 -0700
Message-Id: <3AF9ACAC.E621337C@pipcws.ca.boeing.com>
Date: Wed, 09 May 2001 13:46:36 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Mystery Mouse
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All
I have an interesting conflict with my mouse, & kudzu.
It's a standard Logitech 3 button PS/2 Mouse. Nothing fancy. LM 8.0 & kudzu have
teamed up to make me miserable. 
Every time I boot, kudzu changes the state of the mouse. If it's connected &
happy, kudzu will claim that the mouse has been removed, and pop up the window
to confirm the removal of the device. On the next re-boot, it will detect the
mouse, and want to re-install it. This happens EVERY TIME I reboot. 
For now, I've removed kudzu fro the boot up procedure until I can figure this
out.

Does anyone have any suggestions?

	Thanks!

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________


From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hO314915
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:24 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hMF14906
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:22 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4DS02465;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McBq01304
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:11 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49JA2lF000680;
	Wed, 9 May 2001 12:10:02 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 12:09:56 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49J9uAZ000649
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 12:09:56 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49J9uh06075
	for linux-xfs-outgoing; Wed, 9 May 2001 12:09:56 -0700
Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49J9sF06072
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 12:09:54 -0700
Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id UAA25086 for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 20:07:21 +0200
Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4)
	id VAA26119; Wed, 9 May 2001 21:09:45 +0200 (MET DST)
Date: Wed, 9 May 2001 21:09:45 +0200 (MET DST)
From: fermin@eup.udl.es (Fermin Molina)
Message-Id: <200105091909.VAA26119@eup.udl.es>
To: linux-xfs@oss.sgi.com
Subject: Re: nfsd from kernel 2.4.4 oops
X-Sun-Charset: US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm get an Oops with cvs 2.4.4 XFS kernel. A patch for
NFS helps me to solve the oops, but the patch maker,
Neil Brown, thinks that is a XFS error, because
'XFS isn't finding ".." when asked'.

I include all the reply.

There is a bug in XFS code?

I see in this list some messages with
people that get similar oops.

/Fermin


----- Begin Included Message -----

>From neilb@cse.unsw.edu.au Wed May  9 03:41 MET 2001
From: Neil Brown <neilb@cse.unsw.edu.au>
To: fermin@eup.udl.es (Fermin Molina)
Date: Wed, 9 May 2001 10:57:42 +1000 (EST)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: linux-kernel@vger.kernel.org
Subject: Re: nfsd from kernel 2.4.4 oops
X-Mailer: VM 6.72 under Emacs 20.7.2
X-face: 	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD\ui5Fh?f
	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gldn~*FK9x
	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ

On Tuesday May 8, fermin@eup.udl.es wrote:
> Hi,
> 
> I'm using kernel 2.4.4 cvs from SGI, with xfs. I'm getting this Oops:
> 
> kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010
> kernel:  printing eip:
> kernel: c017bfd8
> kernel: *pde = 00000000
> kernel: Oops: 0000
> kernel: CPU:    0
> kernel: EIP:    0010:[nfsd_findparent+120/236]
> kernel: EIP:    0010:[<c017bfd8>]
> kernel: EFLAGS: 00010246
> kernel: eax: 00000000   ebx: 00000000   ecx: cff8d458   edx: 00000010
> kernel: esi: cb22c6a0   edi: cb22c720   ebp: cb22c720   esp: ce4c9e54
> kernel: ds: 0018   es: 0018   ss: 0018
> kernel: Process nfsd (pid: 592, stackpage=ce4c9000)
> kernel: Stack: 00000000 1802280f c017c416 cb22c720 00000000 ce4cf814 11270000 ce4cf804
> kernel:        c03c5740 cfe3b5c8 0000000e ffffff8c 00000000 c017c7c4 cfe3b400 1802280f
> kernel:        00000000 00000000 00000001 ce4cf804 00000008 cb1fc77c ce4cfc00 ceb7b000
> kernel: Call Trace: [find_fh_dentry+598/928] [fh_verify+612/1128] [nfsd_lookup+110/1368] [nfsd3_proc_lookup+314/332] [nfs3svc_decode_diropargs+152/268] [nfsd_dispatch+203/360] [svc_process+684/1348]
> kernel: Call Trace: [<c017c416>] [<c017c7c4>] [<c017cdde>] [<c0182cbe>] [<c018498c>] [<c017a663>] [<c02df688>]
> 

nfsd_findparent+120/236 corresponds to line 257 on fs/nfsd/nfsfh.h
and the condition of the "if" statement:
		if (aliases->next != aliases) {
just after the "spin_lock(&dcache_lock)".
eax == 0 implies that &tdentry->d_inode == NULL, and hence the oops.

d_inode being NULL here implies that the "lookup" of ".." failed
to find a ".." entry, which is very odd.

I find it hard to believe that ext2fs would ever do this unless the
filesystem was corrupt.  XFS might, I don't know.

I guess nfsd should be robust against this sort of behaviour in
filesystems.

Something like:

--- nfsfh.c	2001/05/09 00:54:56	1.1
+++ nfsfh.c	2001/05/09 00:56:01
@@ -244,6 +244,10 @@
 	 */
 	pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
 	d_drop(tdentry); /* we never want ".." hashed */
+	if (!pdentry && tdentry->d_inode == NULL) {
+		dput(tdentry);
+		pdentry = ERR_PTR(-EINVAL);
+	}
 	if (!pdentry) {
 		/* I don't want to return a ".." dentry.
 		 * I would prefer to return an unconnected "IS_ROOT" dentry,


Is probably the best fix for knfsd, but someone should find out why
XFS isn't finding ".." when asked (If that is indeed what is
happening).

NeilBrown


> 
> It's produced very randomly. Some people (readed in xfs list) get similar error and
> tested too with a clean 2.4.4 with ext2 filesystem, and oops too. I think this is
> related to nfsd code (maybe sunrpc code), and it's not related to xfs code.


----- End Included Message -----


From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hRl14924
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:27 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hOF14921
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:24 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Dq02468;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McHq01310
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:17 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49IJPoC031397;
	Wed, 9 May 2001 11:19:25 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 11:19:14 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49IJEAZ031372
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 11:19:14 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IJEc03187
	for linux-xfs-outgoing; Wed, 9 May 2001 11:19:14 -0700
Received: from dragon.vcu.edu (dragon.vcu.edu [128.172.65.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IJDF03184
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:19:13 -0700
Received: from comet.vcu.edu (comet.vcu.edu [128.172.1.33])
	by dragon.vcu.edu (8.9.3/8.9.3) with ESMTP id OAA7157281;
	Wed, 9 May 2001 14:19:22 -0400 (EDT)
Date: Wed, 9 May 2001 14:19:10 -0400 (EDT)
From: K Mitchell Russell <kmrussel@hsc.vcu.edu>
X-Sender: kmrussel@comet.vcu.edu
To: utz lehmann <xfs@s2y4n2c.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
In-Reply-To: <20010509185137.A15348@s2y4n2c.de>
Message-ID: <Pine.A41.4.10.10105091416040.12300-100000@comet.vcu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 9 May 2001, utz lehmann wrote:

> Hi
> 
> I just tested the rescue mode of the RH 7.1 xfs install iso.
> (I dont needed this time .-)
> 
> I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> should added. fsck for ext2 and ext3 are there.
> 

Interestingly, I booted into linux rescue off the RH7.1 XFS 1.0 iso a
couple days ago, and found xfs_check and xfs_repair to run fine.  Are
there two versions of the 1.0 iso released?

Regards,
Mitchell
________________________________________________________________________
K. Mitchell Russell, M.D.                        |  kmrussel@hsc.vcu.edu
Research Fellow, MedITAC Research Lab            |  www.meditac.com




From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hSq14936
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:28 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hRF14930
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:27 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Ed02475;
                               Thu, 10 May 2001 01:04:14 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McTq01325
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:29 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49H3ZqF029969;
	Wed, 9 May 2001 10:03:35 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 10:03:29 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49H3TAZ029945
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 10:03:29 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49H3TK01289
	for linux-xfs-outgoing; Wed, 9 May 2001 10:03:29 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49H3SF01286
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 10:03:28 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f49H3JEZ002411;
	Wed, 9 May 2001 10:03:20 -0700
Date: Wed, 9 May 2001 10:03:19 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0/Quota
In-Reply-To: <10105090957.ZM72341@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0105090958430.12885-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> kernel patches, quota works without any patching at all.
> 
> cheers.
> 
> -- 
> Nathan
> 

I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
cvs quota tools.  Made sure that quota support and xfs quota support is
selected in kernel.  quotaon -av doesnt show anything.  my fstab has
rw,usrquota. 

[root@gauss quota-tools]# quotaon -v /users/raid2
quotaon: Enable XFS group quota during mount
quotaon: Enable XFS user quota during mount

[root@gauss quota-tools]# repquota /users/raid2
[root@gauss quota-tools]#

I have setup quota on ext2 quite few times before so Im pretty sure I am
not making any mistakes.  Please help.


From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hUx14945
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:30 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hTF14942
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:29 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4EG02474;
                               Thu, 10 May 2001 01:04:14 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McRq01322
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:27 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49I1rmG031021;
	Wed, 9 May 2001 11:01:53 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 11:01:49 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49I1nAZ030996
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 11:01:49 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49I1n002826
	for linux-xfs-outgoing; Wed, 9 May 2001 11:01:49 -0700
Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49I1lF02823
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:01:47 -0700
Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id SAA22361; Wed, 9 May 2001 18:59:14 +0200
Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4)
	id UAA25437; Wed, 9 May 2001 20:01:38 +0200 (MET DST)
Date: Wed, 9 May 2001 20:01:38 +0200 (MET DST)
From: fermin@eup.udl.es (Fermin Molina)
Message-Id: <200105091801.UAA25437@eup.udl.es>
To: marchuk@ee.washington.edu
Subject: Re: XFS 1.0/Quota
Cc: linux-xfs@oss.sgi.com
X-Sun-Charset: US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> > Using the latest cvs quota tools, with the base 2.4.2 XFS 1.0
> > kernel patches, quota works without any patching at all.
> > 
> > cheers.
> > 
> > -- 
> > Nathan
> > 
> 
> I've used kernel 2.4.3, installed xfs patch to kernel.  installed latest
> cvs quota tools.  Made sure that quota support and xfs quota support is
> selected in kernel.  quotaon -av doesnt show anything.  my fstab has
> rw,usrquota. 
> 
> [root@gauss quota-tools]# quotaon -v /users/raid2
> quotaon: Enable XFS group quota during mount
> quotaon: Enable XFS user quota during mount
> 
> [root@gauss quota-tools]# repquota /users/raid2
> [root@gauss quota-tools]#
> 
> I have setup quota on ext2 quite few times before so Im pretty sure I am
> not making any mistakes.  Please help.
> 
> 


For me, doesn't works well, I think that I have "out-dated" quota-tools, but

quot /users/raid2

command works well for me. Try it.

/Fermin


From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hXX14956
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:33 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hVF14950
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:31 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4EN02471;
                               Thu, 10 May 2001 01:04:14 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McMq01316
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:23 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49IORCP031684;
	Wed, 9 May 2001 11:24:27 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 11:24:24 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49IOOAZ031660
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 11:24:24 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IOOj03332
	for linux-xfs-outgoing; Wed, 9 May 2001 11:24:24 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IOMF03329
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:24:23 -0700
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 14xYdJ-0003GP-00; Wed, 9 May 2001 20:24:21 +0200
Received: from pd9007f1f.dip.t-dialin.net ([217.0.127.31] helo=kernelpanix.aura.of.mankind)
	by mrvdom00.schlund.de with esmtp (Exim 2.12 #2)
	id 14xYdE-0007By-00; Wed, 9 May 2001 20:24:16 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.0/8.11.0) id f49HiP016429;
	Wed, 9 May 2001 19:44:25 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Wed, 9 May 2001 19:44:25 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
Message-ID: <20010509194425.A16414@s2y4n2c.de>
References: <xfs@s2y4n2c.de> <200105091745.f49HjP100663@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105091745.f49HjP100663@jen.americas.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord [lord@sgi.com] wrote:
> > Hi
> > 
> > I just tested the rescue mode of the RH 7.1 xfs install iso.
> > (I dont needed this time .-)
> > 
> > I dont found xfs_check and xfs_repair binaries in rescue mode. I think they
> > should added. fsck for ext2 and ext3 are there.
> > 
> > 
> > cheers
> > 
> > utz
> 
> Hmmm, that was supposed to have happened, I discovered this problem a
> few weeks ago and I thought the change was made to get them out there.
> Russell, did this change go missing?
> 
> Steve
> 

opps. my fault.

This was a test release. I should label my CDRs better.

sorry.


utz


From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hZE14967
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:35 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hXF14962
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:33 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Dw02446;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49MKxq00945
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:20:59 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49MTgqd003076;
	Wed, 9 May 2001 15:29:42 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 15:29:17 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49MTGAZ003046
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 15:29:17 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49MTGn12047
	for linux-xfs-outgoing; Wed, 9 May 2001 15:29:16 -0700
Received: from walt400.holman.net (aazpppdsl104.sttl.uswest.net [63.226.208.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49MTFF12044
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 15:29:15 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP
	id 8C675437481; Wed,  9 May 2001 15:38:00 -0700 (PDT)
Message-ID: <3AF9C6C8.9040009@uswest.net>
Date: Wed, 09 May 2001 15:38:00 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9+) Gecko/20010508
X-Accept-Language: en
MIME-Version: 1.0
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mystery Mouse
References: <3AF9ACAC.E621337C@pipcws.ca.boeing.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Not sure if this is relevant and/or helpful, but I had a problem with my 
PS/2 mouse w/ Mandrake 7.2 due to the load order of gpm. I fixed it by 
changing the start number in the relevant runlevels in the 
/etc/rc.d/rcx.d directories. In my case, some other device (usb?) was 
attaching to IRQ 12 and screwing with the mouse. I just renamed the 
start file to make it startup prior to harddrake/kudzu. I don't have gpm 
installed on my system now and everything appears to work allright 
without it - hmmm.....

-Walt


Ric Tibbetts wrote:

>All
>I have an interesting conflict with my mouse, & kudzu.
>It's a standard Logitech 3 button PS/2 Mouse. Nothing fancy. LM 8.0 & kudzu have
>teamed up to make me miserable. 
>Every time I boot, kudzu changes the state of the mouse. If it's connected &
>happy, kudzu will claim that the mouse has been removed, and pop up the window
>to confirm the removal of the device. On the next re-boot, it will detect the
>mouse, and want to re-install it. This happens EVERY TIME I reboot. 
>For now, I've removed kudzu fro the boot up procedure until I can figure this
>out.
>
>Does anyone have any suggestions?
>
>	Thanks!
>



From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hao14981
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:36 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hZF14971
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:35 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4DM02451;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49MRdq01131
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:27:39 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49N9hKX004079;
	Wed, 9 May 2001 16:09:43 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 16:09:41 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49N9fAZ004055
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 16:09:41 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49N9fI12743
	for linux-xfs-outgoing; Wed, 9 May 2001 16:09:41 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49N9eF12740
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:09:40 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA00972
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:20:30 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA29251; Wed, 9 May 2001 18:08:24 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f49N7Ne24683;
	Wed, 9 May 2001 19:07:23 -0400
Message-ID: <3AF9CDA9.A1190D4C@thebarn.com>
Date: Wed, 09 May 2001 19:07:21 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "McMechan, Jim" <McMechanJW@navair.navy.mil>
CC: linux-xfs@oss.sgi.com
Subject: Re: Browsing xfs-TEST
References: <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"McMechan, Jim" wrote:

> I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
> examined the rejects
> comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"
>
> The "unsigned char s_posix_acl_flag" in "struct super_block" in
> "include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
> produces the worst packing of a structure is it intended to be in the same
> cache line or some other reason? tucking it after "unsigned char s_dirt"
> would have a better packing, I think.

I could go along with that.

>
>
> The "unsigned long block[]" and "ulong block[]" declarations are back in
> "drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
> was it intended to return to local arrays?

>
>
> The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
> "kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
> destroyed stacking devices made me leery in this section.

The lvm files shouldn't have changed much,  what was there before.
The xfs tree is at 0.9 beta6 and 2.4.4 is at ... beta2 I believe...
But we'll give it a look no the less.

>
> There also were files that may have been left over "merge#conflicts" and
> "fs/iobuf.2.4.4.c"

That patch was a quick push for anybody wishing to play with 2.4.4,
since the devel tree has been bumped to 2.4.4 the patch has been removed
from oss.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hdR14990
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:39 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hbF14985
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:37 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Dx02449;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49MNJq01069
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:23:20 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49N3Zae003798;
	Wed, 9 May 2001 16:03:35 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 16:03:26 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49N3PAZ003771
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 16:03:25 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49N3Pc12566
	for linux-xfs-outgoing; Wed, 9 May 2001 16:03:25 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49N3OF12563
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 16:03:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1096461
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 01:03:22 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1758963; Wed, 9 May 2001 18:02:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA42061; Wed, 9 May 2001 18:02:04 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49N4Xb15688; Wed, 9 May 2001 18:04:33 -0500
Message-Id: <200105092304.f49N4Xb15688@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "McMechan, Jim" <McMechanJW@navair.navy.mil>
cc: linux-xfs@oss.sgi.com
Subject: Re: Browsing xfs-TEST 
In-Reply-To: Message from "McMechan, Jim" <McMechanJW@navair.navy.mil> 
   of "Wed, 09 May 2001 15:46:54 PDT." <FF33C1948816D211A65300A0C9CF453605570597@nwms13.chinalake.navy.mil> 
Date: Wed, 09 May 2001 18:04:33 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I had previously applied the linux "patch-2.4.4" to a 2.4.3-xfs tree and
> examined the rejects
> comparing it to the recent patch "linux-2.4.4-xfs-TEST.patch"
> 
> The "unsigned char s_posix_acl_flag" in "struct super_block" in
> "include/linux/fs.h" is between two longs "s_flags" and "s_magic" this
> produces the worst packing of a structure is it intended to be in the same
> cache line or some other reason? tucking it after "unsigned char s_dirt"
> would have a better packing, I think.

yep that does appear to be a dumb place to put it.

> 
> The "unsigned long block[]" and "ulong block[]" declarations are back in
> "drivers/md/lvm-snap.c" "lvm_snapshot_COW" and "lvm_write_COW_table_block"
> was it intended to return to local arrays?

Hmm, looks like the patch is out of date here, they are defined this way in
the tree now:

        unsigned long blocks[KIO_MAX_SECTORS];
        ulong blocks[1];



> 
> The b_dev vs b_rdev in drivers/md/lvm.c 1111 "MINOR(bh->b_rdev) and 1140
> "kdevname(bh->b_rdev)" also have disapeared Jens Axboe's comment about
> destroyed stacking devices made me leery in this section.

Also changed in the development tree.

> 
> There also were files that may have been left over "merge#conflicts" and
> "fs/iobuf.2.4.4.c"


No comment - except it wasn't me!

One day we might get the patch process going fast enough, but for now,
the message remains that if you really want to follow the development
the only real way to do it is to usr the cvs tree.

Thanks for the comments, I will reorder the fields in the superblock.

Steve



From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hfM14999
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:41 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hdF14994
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:40 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4Dw02467;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McEq01307
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:14 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49IxXlI000339;
	Wed, 9 May 2001 11:59:33 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 11:59:15 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49IxEAZ000308
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 11:59:14 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IxEG05342
	for linux-xfs-outgoing; Wed, 9 May 2001 11:59:14 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IxEF05339
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:59:14 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA05240
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 12:10:03 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1758850; Wed, 9 May 2001 13:57:56 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA73885; Wed, 9 May 2001 13:57:55 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49J0Rx04021; Wed, 9 May 2001 14:00:27 -0500
Message-Id: <200105091900.f49J0Rx04021@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS + RSBAC 
In-Reply-To: Message from K Mitchell Russell <kmrussel@hsc.vcu.edu> 
   of "Mon, 07 May 2001 19:44:04 EDT." <Pine.A41.4.10.10105071423320.42368-100000@comet.vcu.edu> 
Date: Wed, 09 May 2001 14:00:27 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Colleagues,
> 
> I have patched a kernel with XFS 1.0 and the Rule-Set Based Access
> Controls (www.rsbac.org). This is of particular importance to me for
> using Linux to power medical record repositories, requiring data
> integrity (journaled fs), performance, and security (mandatory access
> controls, role compatibility, ACLs, etc.)
> 
> The system seems to run fine even using RSBAC's 'check on init'
> function. This function caused problems with ReiserFS as ReiserFS works
> internally with 64 bit inode numbers, and RSBAC was removing entries for
> inode, which was making ReiserFS complain. Now my impression is that XFS
> uses 64 bit inodes, but somehow this is more compatible than the
> ReiserFS usage because I am not getting the same errors. Does XFS use 64
> bit inodes? Anyone care to comment?


Yes, XFS does use 64 bit inode numbers, but since the inode numbers are
really an encoded disk address, the top 32 bits of the inode number do not
get used unless you use really big filesystems, and the actual size is
a function of a number of factors, but at least 1 Tbyte, and usually
larger is required to move into the 33rd bit. I have some plans on how to
avoid this as well.

> 
> Finally, there is one part of the patch in RSBAC that is still FS
> dependent, a secure delete function that patches the fs/ext2/namei.c
> (for example) in ext2 by adding the following to ext2_unlink():
> 
> if(inode->i_nlink == 1)
>   rsbac_sec_del(dentry);
> 
> Now they have only implemented this into ext2, vfat, dos, and minix
> fs's, but would be nice for XFS integration as well. Where would such a
> patch work, or does XFS have an interface for this?

linvfs_unlink in fs/xfs/linux/xfs_iops.c, you need to do it after the
validate_fields() calls.

Steve

> 
> Anyone with further interest in both XFS and the RSBAC patches is
> welcome to cross post to the rsbac@rsbac.org mailing list.
> 
> Thanks in advance, and congratulations on creating an excellent product
> in XFS and supporting open source software!
> 
> Regards,
> Mitchell
> 
> 
> ________________________________________________________________________
> K. Mitchell Russell, M.D.                         | kmrussel@hsc.vcu.edu
> Research Fellow, MedITAC Research Lab             |   www.meditac.com
> 
> 
> 



From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hhv15008
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:43 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hfF15000
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:41 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4D602463;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49Mc8q01295
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:09 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49K7hc7001165;
	Wed, 9 May 2001 13:07:43 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 13:07:26 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49K7QAZ001137
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 13:07:26 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49K7Qc08225
	for linux-xfs-outgoing; Wed, 9 May 2001 13:07:26 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49K7NF08222
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 13:07:23 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1113430
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 22:07:21 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1758570; Wed, 9 May 2001 15:06:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA24816; Wed, 9 May 2001 15:06:03 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f49K8YF04962; Wed, 9 May 2001 15:08:34 -0500
Message-Id: <200105092008.f49K8YF04962@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: fermin@eup.udl.es (Fermin Molina)
cc: linux-xfs@oss.sgi.com
Subject: Re: nfsd from kernel 2.4.4 oops 
In-Reply-To: Message from fermin@eup.udl.es (Fermin Molina) 
   of "Wed, 09 May 2001 21:09:45 +0200." <200105091909.VAA26119@eup.udl.es> 
Date: Wed, 09 May 2001 15:08:34 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Yes it does look like xfs is not finding .. and at the moment I have no 
idea why, can you give us some more details of what it is you are doing
to produce this scenario. The only way I can see of xfs not finding .. is
that the passed in dcache entry and inode have something wrong with them.

Steve

> Hi,
> 
> I'm get an Oops with cvs 2.4.4 XFS kernel. A patch for
> NFS helps me to solve the oops, but the patch maker,
> Neil Brown, thinks that is a XFS error, because
> 'XFS isn't finding ".." when asked'.
> 
> I include all the reply.
> 
> There is a bug in XFS code?
> 
> I see in this list some messages with
> people that get similar oops.
> 
> /Fermin
> 
> 
> ----- Begin Included Message -----
> 
> >From neilb@cse.unsw.edu.au Wed May  9 03:41 MET 2001
> From: Neil Brown <neilb@cse.unsw.edu.au>
> To: fermin@eup.udl.es (Fermin Molina)
> Date: Wed, 9 May 2001 10:57:42 +1000 (EST)
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: nfsd from kernel 2.4.4 oops
> X-Mailer: VM 6.72 under Emacs 20.7.2
> X-face: 	[Gw_3E*Gng}4rRrKRYotwlE?.2|**#s9D<ml'fY1Vw+@XfR[fRCsUoP?K6bt3YD
> \ui5Fh?f
> 	LONpR';(ql)VM_TQ/<l_^D3~B:z$\YC7gUCuC=sYm/80G=$tt"98mr8(l))QzVKCk$6~gld
> n~*FK9x
> 	8`;pM{3S8679sP+MbP,72<3_PIH-$I&iaiIb|hV1d%cYg))BmI)AZ
> 
> On Tuesday May 8, fermin@eup.udl.es wrote:
> > Hi,
> > 
> > I'm using kernel 2.4.4 cvs from SGI, with xfs. I'm getting this Oops:
> > 
> > kernel: Unable to handle kernel NULL pointer dereference at virtual address
>  00000010
> > kernel:  printing eip:
> > kernel: c017bfd8
> > kernel: *pde = 00000000
> > kernel: Oops: 0000
> > kernel: CPU:    0
> > kernel: EIP:    0010:[nfsd_findparent+120/236]
> > kernel: EIP:    0010:[<c017bfd8>]
> > kernel: EFLAGS: 00010246
> > kernel: eax: 00000000   ebx: 00000000   ecx: cff8d458   edx: 00000010
> > kernel: esi: cb22c6a0   edi: cb22c720   ebp: cb22c720   esp: ce4c9e54
> > kernel: ds: 0018   es: 0018   ss: 0018
> > kernel: Process nfsd (pid: 592, stackpage=ce4c9000)
> > kernel: Stack: 00000000 1802280f c017c416 cb22c720 00000000 ce4cf814 112700
> 00 ce4cf804
> > kernel:        c03c5740 cfe3b5c8 0000000e ffffff8c 00000000 c017c7c4 cfe3b4
> 00 1802280f
> > kernel:        00000000 00000000 00000001 ce4cf804 00000008 cb1fc77c ce4cfc
> 00 ceb7b000
> > kernel: Call Trace: [find_fh_dentry+598/928] [fh_verify+612/1128] [nfsd_loo
> kup+110/1368] [nfsd3_proc_lookup+314/332] [nfs3svc_decode_diropargs+152/268] 
> [nfsd_dispatch+203/360] [svc_process+684/1348]
> > kernel: Call Trace: [<c017c416>] [<c017c7c4>] [<c017cdde>] [<c0182cbe>] [<c
> 018498c>] [<c017a663>] [<c02df688>]
> > 
> 
> nfsd_findparent+120/236 corresponds to line 257 on fs/nfsd/nfsfh.h
> and the condition of the "if" statement:
> 		if (aliases->next != aliases) {
> just after the "spin_lock(&dcache_lock)".
> eax == 0 implies that &tdentry->d_inode == NULL, and hence the oops.
> 
> d_inode being NULL here implies that the "lookup" of ".." failed
> to find a ".." entry, which is very odd.
> 
> I find it hard to believe that ext2fs would ever do this unless the
> filesystem was corrupt.  XFS might, I don't know.
> 
> I guess nfsd should be robust against this sort of behaviour in
> filesystems.
> 
> Something like:
> 
> --- nfsfh.c	2001/05/09 00:54:56	1.1
> +++ nfsfh.c	2001/05/09 00:56:01
> @@ -244,6 +244,10 @@
>  	 */
>  	pdentry = child->d_inode->i_op->lookup(child->d_inode, tdentry);
>  	d_drop(tdentry); /* we never want ".." hashed */
> +	if (!pdentry && tdentry->d_inode == NULL) {
> +		dput(tdentry);
> +		pdentry = ERR_PTR(-EINVAL);
> +	}
>  	if (!pdentry) {
>  		/* I don't want to return a ".." dentry.
>  		 * I would prefer to return an unconnected "IS_ROOT" dentry,
> 
> 
> Is probably the best fix for knfsd, but someone should find out why
> XFS isn't finding ".." when asked (If that is indeed what is
> happening).
> 
> NeilBrown
> 
> 
> > 
> > It's produced very randomly. Some people (readed in xfs list) get similar e
> rror and
> > tested too with a clean 2.4.4 with ext2 filesystem, and oops too. I think t
> his is
> > related to nfsd code (maybe sunrpc code), and it's not related to xfs code.
> 
> 
> ----- End Included Message -----



From owner-linux-xfs@oss.sgi.com Wed May  9 17:43:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0hqW15018
	for linux-xfs-outgoing; Wed, 9 May 2001 17:43:52 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0hoF15015
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:43:50 -0700
Received: [(from root@localhost)
                               by ima.pl with  id f49N4DW02469;
                               Thu, 10 May 2001 01:04:13 +0200]
Received: [from linux-xfs.sgi.com (linux-xfs.sgi.com [216.32.174.192])
                               by ima.pl with ESMTP id f49McKq01313
                               for <blizbor@ima.pl>; Thu, 10 May 2001 00:38:21 +0200]
Received: from localhost (mail@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f49IR219031939;
	Wed, 9 May 2001 11:27:02 -0700
X-Authentication-Warning: linux-xfs.sgi.com: mail owned process doing -bs
Received: by linux-xfs.sgi.com (bulk_mailer v1.13); Wed, 9 May 2001 11:27:01 -0700
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f49IR1AZ031915
	for <linux-xfs-outgoing@linux-xfs.sgi.com>; Wed, 9 May 2001 11:27:01 -0700
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f49IR1903488
	for linux-xfs-outgoing; Wed, 9 May 2001 11:27:01 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f49IR0F03483
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 11:27:00 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f49IQul20266;
	Wed, 9 May 2001 13:26:56 -0500 (CDT)
Message-ID: <3AF98C76.4AA8D1FC@sgi.com>
Date: Wed, 09 May 2001 13:29:10 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: K Mitchell Russell <kmrussel@hsc.vcu.edu>
CC: utz lehmann <xfs@s2y4n2c.de>, linux-xfs@oss.sgi.com
Subject: Re: xfs_check, xfs_repair should added to the xfs install iso
References: <Pine.A41.4.10.10105091416040.12300-100000@comet.vcu.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

K Mitchell Russell wrote:
 
> Interestingly, I booted into linux rescue off the RH7.1 XFS 1.0 iso a
> couple days ago, and found xfs_check and xfs_repair to run fine.  Are
> there two versions of the 1.0 iso released?

No, although there are several -testX releases.

Utz, are you sure you have the REAL 1.0?  TRANS.TBL in the root dir
should be dated April 27.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May  9 17:49:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0nul15516
	for linux-xfs-outgoing; Wed, 9 May 2001 17:49:56 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0ntF15510
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:49:55 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id C1B181422; Wed,  9 May 2001 17:51:26 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP id 54F9814CA
	for <linux-xfs@oss.sgi.com>; Wed,  9 May 2001 17:51:26 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSGJA8>; Wed, 9 May 2001 19:49:43 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88D5F@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: "'=SMTP:mkp@linuxcare.com'"@oss.sgi.com
Cc: linux-xfs@oss.sgi.com
Subject: RE: XFS install from ISO fails utterly -- STILL
Date: Wed, 9 May 2001 19:49:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


did another install. failed again. as requested, I checked log output(s) and
got the following:

F3:
Detected 880M of memory
Swap attempt of 880M to 1760M
Maximum cylinder is 26
Making XFS filesystem for ida/c0d0p8
Making XFS filesystem for ida/c0d0p1
Making XFS filesystem for ida/c0d0p10
Making XFS filesystem for ida/c0d0p9
Making XFS filesystem for ida/c0d0p5
Making XFS filesystem for ida/c0d0p6

F4:
<6>page_buf cache Copyright (c) 2000 Silicon Graphics, Inc.
<6>XFS filesystem Copyright (c) 2000 Silicon Graphics, Inc.
<6>Adding Swap: 526296k swap-space (priority -1)
<4>Start mounting filesystem: ida0(72,8)
<4>Ending clean XFS mount for filesystem: ida0(72,8)
<4>Start mounting filesystem: ida0(72,1)
<4>Ending clean XFS mount for filesystem: ida0(72,1)
<4>Start mounting filesystem: ida0(72,10)
<4>Ending clean XFS mount for filesystem: ida0(72,10)
<4>Start mounting filesystem: ida0(72,9)
<4>Ending clean XFS mount for filesystem: ida0(72,9)
<4>Start mounting filesystem: ida0(72,5)
<4>Ending clean XFS mount for filesystem: ida0(72,5)
<4>Start mounting filesystem: ida0(72,6)
<4>Ending clean XFS mount for filesystem: ida0(72,6)
<7>ISO 9660 Extensions: RRIP_1991A

F5:
mkfs.xfs: warning - cannot set blocksize on block device /tmp/ida/c0d0p8:
Invalid argument
meta-data=/tmp/ida/c0d0p1	isize=256	agcount=4, agsize=4335 blks
data		=			bsize=4096	blocks=17340,
imaxpct=25
		=			sunit=0	swidth=0 blks, unwritten=0
naming	=version 2		bsize=4096
log		=internal log	bsize=4096	blocks=1200
realtime	=none			extsz=65536	blocks=0,
rtextents=0

[the same info was repeated for the other mount points, too.]


on reboot, same failures as before. since it hung at the syslogger, I was
able to make note of some of the problems:

swap on: cannot stat /dev/ida/c0d0p7: No such file or directory
Enabling swap space:	[OK]
/etc/rc.sysinit: /var/log/dmesg: No such file or directory
INIT: Entering runlevel: 5
Updating /etc/fstab execvp: No such file or directory		[FAILED]
Checking for new hardware/etc/rc5.dS05kudzu: /usr/sbin/kudzu: No such file
or directory
touch: creating '/var/lock/subsys/kudzu': No such file or directory



-----Original Message-----
From: Martin K. Petersen [mailto:mkp@linuxcare.com]
Sent: Wednesday, May 09, 2001 12:58 PM
To: Venables, Michael
Subject: Re: XFS install from ISO fails utterly


>>>>> "Michael" == Venables, Michael <Michael.Venables@COMPAQ.com> writes:

Michael> 1) begin the install process
Michael> 2) after the partitioning completes (before package
Michael>    selection, etc.), access the console error log via Alt-F4.
Michael> 3) if there are references to ioctl problems, then it's an
Michael>    issue with the driver for the array controller (which
Michael>    you've since fixed).

Michael> if 3, wait for a new respin.  if not 3, report any info and
Michael> see where that takes us.

Correct.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Wed May  9 17:55:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0t1Z15805
	for linux-xfs-outgoing; Wed, 9 May 2001 17:55:01 -0700
Received: from femail9.sdc1.sfba.home.com (femail9.sdc1.sfba.home.com [24.0.95.89])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0t1F15802
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:55:01 -0700
Received: from slave1.bounty.host ([24.180.71.113])
          by femail9.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010510005456.DWQU17191.femail9.sdc1.sfba.home.com@slave1.bounty.host>
          for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:54:56 -0700
Content-Type: text/plain;
  charset="iso-8859-1"
From: James <brojohnson@home.com>
To: linux-xfs@oss.sgi.com
Subject: missing cdrom drive
Date: Wed, 9 May 2001 20:56:32 -0400
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01050920563200.01279@slave1.bounty.host>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just upgrade my router and workstation to Redhat 7.1 with XFS, from redhat 
7.0. I notice that sometimes I have /dev/hdb or any of the other ones that 
dmesg gives me. (for the cdrom) then I will loose it, within a second. None 
of my cdrom drives (3 IDE) seem to work all the time. Is it related to XFS ? 
Could it be a kernel issue? besides that everything seem to work good, real 
good (so far)
Thanks in advance
James

From owner-linux-xfs@oss.sgi.com Wed May  9 17:55:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0trj15841
	for linux-xfs-outgoing; Wed, 9 May 2001 17:55:53 -0700
Received: from femail10.sdc1.sfba.home.com (femail10.sdc1.sfba.home.com [24.0.95.106])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0trF15838
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:55:53 -0700
Received: from slave1.bounty.host ([24.180.71.113])
          by femail10.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010510005548.QVSA6845.femail10.sdc1.sfba.home.com@slave1.bounty.host>
          for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:55:48 -0700
Content-Type: text/plain;
  charset="iso-8859-1"
From: James <brojohnson@home.com>
To: linux-xfs@oss.sgi.com
Subject: Blender
Date: Wed, 9 May 2001 20:57:24 -0400
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01050920572401.01279@slave1.bounty.host>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Will XFS have any great effect on Blender and other graphic apps?
James

From owner-linux-xfs@oss.sgi.com Wed May  9 17:59:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A0xEh16006
	for linux-xfs-outgoing; Wed, 9 May 2001 17:59:14 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A0x9F15992
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 17:59:09 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xenJ-000136-00; Thu, 10 May 2001 02:59:07 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4A0wBY11887;
	Wed, 9 May 2001 20:58:11 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: "Venables, Michael" <Michael.Venables@compaq.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly -- STILL
References: <8C91B010B3B7994C88A266E1A72184D3C88D5F@cceexc19.americas.cpqcorp.net>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 09 May 2001 20:58:10 -0400
In-Reply-To: <8C91B010B3B7994C88A266E1A72184D3C88D5F@cceexc19.americas.cpqcorp.net>
Message-ID: <yq166faggv1.fsf@jcb.mkp.net>
Lines: 12
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Michael" == Venables, Michael <Michael.Venables@compaq.com> writes:

Michael> mkfs.xfs: warning - cannot set blocksize on block device

Ding, ding.  That's the one.

Eric, what's the status on the driver floppy?

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Wed May  9 18:02:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A126416122
	for linux-xfs-outgoing; Wed, 9 May 2001 18:02:06 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A125F16119
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 18:02:05 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f4A122L16446;
	Wed, 9 May 2001 20:02:02 -0500 (CDT)
Message-ID: <3AF9E912.B6EB3724@sgi.com>
Date: Wed, 09 May 2001 20:04:18 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>
CC: mkp@linuxcare.com, linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly -- STILL
References: <8C91B010B3B7994C88A266E1A72184D3C88D5F@cceexc19.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Venables, Michael" wrote:
 
> F5:
> mkfs.xfs: warning - cannot set blocksize on block device /tmp/ida/c0d0p8:

Hi Michael - this does look like the ioctl problem Martin was talking
about.

I made an (as yet untested) driver update disk for this with updated
DAC960, cpqarray, and cciss drivers that include the necessary ioctl at:

http://lager.dyndns.org/raid-dd-i686-0509.img

dd that to a disk and type "linux dd" or "text dd" at the installer
prompt.

If you feel like experimenting a bit, you might give it a shot.  Easier
than downloading another 300MB+ iso at some point in the future.  :)

Thanks,

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 18:13:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A1DiP16431
	for linux-xfs-outgoing; Wed, 9 May 2001 18:13:44 -0700
Received: from digitaltux.com (cs83577-b.mtnk1.on.wave.home.com [24.68.91.162])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A1DhF16428
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 18:13:44 -0700
Received: from digitaltux.com (localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with SMTP id f4A1DgDX001313
        for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 21:13:42 -0400
Message-Id: <200105100113.f4A1DgDX001313@digitaltux.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From: "NORMAL" <zoltan@digitaltux.com>
To: linux-xfs@oss.sgi.com
Subject: Mount Options
X-Mailer: Pronto v2.2.5 On linux/CSV
Date: 09 May 2001 21:13:40 EDT
Reply-To: "NORMAL" <zoltan@digitaltux.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Could someone tell me the mount options for a /var partition running qmail. I
remember some discusstion about it, and someone mentioning biosize=13. Please
enlightenment =)
BTW, im working on the menu integration of the debian install so it will be
easier to make a xfs partition.

- Zoltan Kraus

From owner-linux-xfs@oss.sgi.com Wed May  9 18:18:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A1IJg16521
	for linux-xfs-outgoing; Wed, 9 May 2001 18:18:19 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A1IIF16518
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 18:18:18 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f4A1I6v03163;
	Wed, 9 May 2001 20:18:06 -0500 (CDT)
Message-ID: <3AF9ECD7.19DDCE4D@sgi.com>
Date: Wed, 09 May 2001 20:20:23 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: NORMAL <zoltan@digitaltux.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Mount Options
References: <200105100113.f4A1DgDX001313@digitaltux.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

NORMAL wrote:
> 
> Could someone tell me the mount options for a /var partition running qmail. I
> remember some discusstion about it, and someone mentioning biosize=13. Please
> enlightenment =)

Anything using "db" databases (so far, pine, sendmail, and rpm) would
likely benefit from using the "-o biosize=13" option.

The behavior caused by the above option (actually, better than that) is
now the default in the development tree.

> BTW, im working on the menu integration of the debian install so it will be
> easier to make a xfs partition.

Great!  Let us know when it's ready...  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 19:01:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A213n17260
	for linux-xfs-outgoing; Wed, 9 May 2001 19:01:03 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A212F17257
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 19:01:02 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f4A20xv09803;
	Wed, 9 May 2001 21:00:59 -0500 (CDT)
Message-ID: <3AF9F6E5.AEE16E68@sgi.com>
Date: Wed, 09 May 2001 21:03:17 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: James <brojohnson@home.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: missing cdrom drive
References: <01050920563200.01279@slave1.bounty.host>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

James wrote:

> None
> of my cdrom drives (3 IDE) seem to work all the time. Is it related to XFS ?

It's devfs, and has been discussed ad nauseum on this list... :)

Archives at http://linux-xfs.sgi.com/projects/xfs/ml.html

devfs faq at http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 19:55:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A2tkf18834
	for linux-xfs-outgoing; Wed, 9 May 2001 19:55:46 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A2tjF18831
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 19:55:45 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id 31734DC2; Wed,  9 May 2001 19:57:22 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id C35CCD00; Wed,  9 May 2001 19:57:21 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFSG32C>; Wed, 9 May 2001 21:55:39 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C88D61@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: mkp@linuxcare.com, linux-xfs@oss.sgi.com
Subject: RE: XFS install from ISO fails utterly -- STILL
Date: Wed, 9 May 2001 21:55:37 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I tried giving the image a shot, but got the following error:

	error 2 cpio: bad magic

It doesn't take more than about five minutes for my to pull the installer
ISO. You might want to look and see if you can find a more current version
of the installer. One thing I noticed is that when you get to the X config,
there's supposed to be a "test configuration" button, but there isn't. it's
not present in the Red Hat installer I've got, either (we're probably
working off the same original images); however, I have seen screenshots that
have the button. someone must have caught and fixed that glitch. who knows
how much more of that sort of thing there is.

Thanks for all your help,

 michael


-----Original Message-----
From: Eric Sandeen [mailto:sandeen@sgi.com]
Sent: Wednesday, May 09, 2001 8:04 PM
To: Venables, Michael
Cc: mkp@linuxcare.com; linux-xfs@oss.sgi.com
Subject: Re: XFS install from ISO fails utterly -- STILL


"Venables, Michael" wrote:
 
> F5:
> mkfs.xfs: warning - cannot set blocksize on block device /tmp/ida/c0d0p8:

Hi Michael - this does look like the ioctl problem Martin was talking
about.

I made an (as yet untested) driver update disk for this with updated
DAC960, cpqarray, and cciss drivers that include the necessary ioctl at:

http://lager.dyndns.org/raid-dd-i686-0509.img

dd that to a disk and type "linux dd" or "text dd" at the installer
prompt.

If you feel like experimenting a bit, you might give it a shot.  Easier
than downloading another 300MB+ iso at some point in the future.  :)

Thanks,

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May  9 23:13:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A6DF223179
	for linux-xfs-outgoing; Wed, 9 May 2001 23:13:15 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A6DDF23176
	for <linux-xfs@oss.sgi.com>; Wed, 9 May 2001 23:13:13 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA01852;
	Thu, 10 May 2001 08:13:11 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id IAA20078;
	Thu, 10 May 2001 08:13:10 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 37A5A57306; Thu, 10 May 2001 08:22:04 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 4F81825835; Thu, 10 May 2001 08:23:14 +0200 (CEST)
Message-ID: <3AFA3237.DD6CA9F3@ch.sauter-bc.com>
Date: Thu, 10 May 2001 08:16:23 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
Cc: linux-xfs@oss.sgi.com, tduffy@engr.sgi.com
Subject: Re: Patch for mkbootdisk and large floppy support
References: <4.3.2.7.2.20010509132758.02d5fb10@pop.xs4all.nl>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Seth,

Sorry, this was my fault. I did not use the -s parameter on syslinux.
Now I changed /sbin/mkbootdisk as you mentioned and everything works
perfect! I tried it on different machines and they are all booting well.

Greetings
Simon

Seth Mos schrieb:
> 
> Hi,
> 
> This patch alters the behaviuor of the --device option of mkbootdisk.
> If this option is set it will fdformat the floppy using the given device
> and run syslinux with the -s option.
> 
> I tested this with /dev/fd0u1680 and it boots on 3 kinds of dell optiplex
> machines and my Dell inspiron notebook.
> YMMV using larger devices like /dev/fd0u1722 and the like. And make sure
> you use decent floppy's because they are not made for this. At least it
> proves the truth in my .sig
> 
> --- /sbin/mkbootdisk    Thu Feb  8 23:48:15 2001
> +++ mkbootdisk  Wed May  9 11:34:16 2001
> @@ -8,6 +8,7 @@
>   unset kernel
>   device=/dev/fd0
>   unset verbose
> +unset fdformat
>   unset witheth
>   unset mkinitrdargs
>   unset compact
> @@ -32,6 +33,7 @@
>          --device)
>              shift
>              device=$1
> +           fdformat=true
>              ;;
>          --mkinitrdargs)
>              shift
> @@ -141,12 +143,14 @@
>   }
> 
>   [ -n "$verbose" ] && echo -n "Formatting $device... "
> +[ -n "$fdformat" ] && fdformat $device
>   mkdosfs -I $device > /dev/null || {
>       echo "Failed to format $device" >&2
>       exit 1
>   }
> 
> -syslinux $device
> +[ -n "$fdformat" ] && syslinux -s $device
> +[ -z "$fdformat" ] && syslinux $device
>   [ -n "$verbose" ] && echo "done."
> 
>   rm -rf $MOUNTDIR
> 
> Good luck with using it. I know I will.
> 
> Cheers
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Thu May 10 00:21:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A7Lea25489
	for linux-xfs-outgoing; Thu, 10 May 2001 00:21:40 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A7LcF25486
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 00:21:38 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id JAA143368
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:21:32 +0200
Message-Id: <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Thu, 10 May 2001 09:21:31 +0200
To: linux-xfs@oss.sgi.com
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: fileutils patches?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

	
	Hello,

I installed XFS using the RH 7.1 installer.
I tried working with acl and this works but I was wondering where
I can find the patch to enable the fileutils commands (ls, rm, mv, cp,...) 
to recognize ACL's.
In the ISO for RH 7.1 there's a special kernel and the xfsprogs but I can't
seem to find these patched fileutils.

Does somebody has more information?

Kind regards,

Werner Maes




From owner-linux-xfs@oss.sgi.com Thu May 10 00:58:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A7wIn26051
	for linux-xfs-outgoing; Thu, 10 May 2001 00:58:18 -0700
Received: from magnolia.wanadoo.fr (smtp-rt-11.wanadoo.fr [193.252.19.62])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A7wFF26048
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 00:58:16 -0700
Received: from mahonia.wanadoo.fr (193.252.19.58) by magnolia.wanadoo.fr; 10 May 2001 09:58:08 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by mahonia.wanadoo.fr; 10 May 2001 09:57:55 +0200
Subject: Benchmark
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: linux-xfs <linux-xfs@oss.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 10 May 2001 09:58:56 +0200
Message-Id: <989481537.4638.0.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

What to think of these results ?

http://bulma.lug.net/body.phtml?nIdNoticia=626

compared to the comment of Alan Cox concerning file deletion ?

http://marc.theaimsgroup.com/?l=linux-kernel&m=98941976516596&w=2

>XFS is very fast most of the time (deleting a file is sooooo slow its
>like using old BSD systems). Im not familiar enough with its behaviour
>under Linux yet.

Do you have plan (SGI guys) to work on improve performances concerning
file deletion since it is obviously about the only case where XFS lose ?

-David



From owner-linux-xfs@oss.sgi.com Thu May 10 02:02:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A926427487
	for linux-xfs-outgoing; Thu, 10 May 2001 02:02:06 -0700
Received: from core.devicen.de (root@core.devicen.de [62.159.186.206])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A925F27483
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 02:02:05 -0700
Received: from [62.159.186.228] (mactil.devicen.de [62.159.186.228])
	by core.devicen.de (8.11.0/8.11.0/SuSE Linux 8.9.3-0.1) with ESMTP id f4A91jw06977;
	Thu, 10 May 2001 11:01:52 +0200
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106
Date: Thu, 10 May 2001 11:01:46 +0200
Subject: Re: kupdate - excessive CPU usage
From: Tilman Kastner <kastner@devicen.de>
To: Austin Gonyou <austin@coremetrics.com>
CC: <linux-xfs@oss.sgi.com>
Message-ID: <B720259A.194BF%kastner@devicen.de>
In-Reply-To: <Pine.LNX.4.33.0105091828150.17991-100000@UberGeek.coremetrics.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

am 10.05.2001 1:29 Uhr schrieb Austin Gonyou:

> Have you tried restarting your logging services? I've noticed something
> similar to that as well, not recently though, but I would restart syslog,
> which restarts klogd as well, and then kupdate seems to go back to normal.

Thanks for the suggestion, unfortunately, the problem remains. I will try a
new kernel as soon as possible.

> On Wed, 9 May 2001, Tilman Kastner wrote:
> 
>> I recently switched a desktop machine to XFS-only. Patching the SuSE-2.4.2
>> kernel sources worked without a problem (to my surprise), compiling with gcc
>> 2.95.2 was no problem, too. After reboot, everything works like a charm, but
>> after some hours of moderate or even low fs-activity, kupdate starts to eat
>> up CPU every time it is called - even the mouse on X freezes for approx.
>> 1/2s.
>> 

Regards,

Tilman

-- 
Tilman Kastner                 DEVICE/N GmbH
kastner@devicen.de             Ilse-ter-Meer-Weg 7
PGP key available              30449 Hannover, Germany



From owner-linux-xfs@oss.sgi.com Thu May 10 02:26:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A9QM628070
	for linux-xfs-outgoing; Thu, 10 May 2001 02:26:22 -0700
Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4A9QKF28067
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 02:26:20 -0700
Received: (from ragnark@localhost)
	by stine.vestdata.no (8.9.3/8.9.3) id LAA07433;
	Thu, 10 May 2001 11:26:07 +0200
Date: Thu, 10 May 2001 11:26:06 +0200
From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <xfs@ragnark.vestdata.no>
To: Tilman Kastner <kastner@devicen.de>
Cc: Austin Gonyou <austin@coremetrics.com>, linux-xfs@oss.sgi.com
Subject: Re: kupdate - excessive CPU usage
Message-ID: <20010510112606.A6933@vestdata.no>
References: <Pine.LNX.4.33.0105091828150.17991-100000@UberGeek.coremetrics.com> <B720259A.194BF%kastner@devicen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.5i
In-Reply-To: <B720259A.194BF%kastner@devicen.de>; from Tilman Kastner on Thu, May 10, 2001 at 11:01:46AM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 10, 2001 at 11:01:46AM +0200, Tilman Kastner wrote:
> am 10.05.2001 1:29 Uhr schrieb Austin Gonyou:
> > Have you tried restarting your logging services? I've noticed something
> > similar to that as well, not recently though, but I would restart syslog,
> > which restarts klogd as well, and then kupdate seems to go back to normal.
> 
> Thanks for the suggestion, unfortunately, the problem remains. I will try a
> new kernel as soon as possible.

We had simular problems on linux-2.4.4, but they seem to be solved in
2.4.5pre1 with Andreia's highmem-patches from pre1aa2.


-- 
Ragnar Kjørstad
Big Storage

From owner-linux-xfs@oss.sgi.com Thu May 10 02:30:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4A9U9V28130
	for linux-xfs-outgoing; Thu, 10 May 2001 02:30:09 -0700
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4A9U8F28127
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 02:30:08 -0700
Received: (qmail 22722 invoked by uid 0); 10 May 2001 09:30:02 -0000
Date: Thu, 10 May 2001 11:30:02 +0200 (MEST)
From: Oliver Siegmar <Oliver.Siegmar@gmx.de>
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Subject: XFS in the standard kernel
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0002123540@gmx.net
X-Authenticated-IP: [192.35.17.232]
Message-ID: <7544.989487002@www45.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

thanks for your great job on XFS (1.0) !

Will XFS be included in the standard linux-kernel? Is it possible to
convince linus to do this in 2.4.x ? :-)


Bye,
Oliver

PS: Sorry about my terrible english - I'm from Germany...

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net


From owner-linux-xfs@oss.sgi.com Thu May 10 04:21:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ABLLU30992
	for linux-xfs-outgoing; Thu, 10 May 2001 04:21:21 -0700
Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ABLKF30989
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 04:21:20 -0700
Received: (from sct@localhost)
	by devserv.devel.redhat.com (8.11.0/8.11.0) id f4ABKhS02620;
	Thu, 10 May 2001 07:20:43 -0400
Date: Thu, 10 May 2001 12:18:38 +0100
From: "Stephen C. Tweedie" <sct@redhat.com>
To: "Patrick J. LoPresti" <patl@cag.lcs.mit.edu>
Cc: linux-xfs@oss.sgi.com, Stephen Tweedie <sct@redhat.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010510121838.A14611@redhat.com>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506105300.84C50125E6@rebutia.sweeney.demon.co.uk> <mit.lcs.mail.linux-xfs/20010506105300.84C50125E6@rebutia.sweeney.demon.co.uk> <s5gbsp6a46o.fsf@egghead.curl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <s5gbsp6a46o.fsf@egghead.curl.com>; from patl@cag.lcs.mit.edu on Sun, May 06, 2001 at 11:27:11AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

On Sun, May 06, 2001 at 11:27:11AM -0400, Patrick J. LoPresti wrote:
> Keith Matthews <keith_m@sweeney.demon.co.uk> writes:
> 
> > The other difference from what I have read is that ext3 allows journalling
> > of the file content data as well as the metadata, the other three (as far
> > as I can see) only journal metadata. This may be important to you.
> 
> I apologize if this is a stupid question, but how could data
> journalling possibly matter to anybody?
> 
> I mean, as long as the data are written to disk before the metadata
> are written to the journal, there is no reliability to be gained by
> journalling the data.  What am I missing?

Performance.  There are certain applications, including mail and NFS
serving, where processes want data written synchronously to disk in
very small chunks (the size of a page in NFSv2, or the size of an
email for sendmail).  That translates to a _lot_ of disk seeks.

If you can do the synchronous writes to a single journal instead, then
the synchronous part of the filesystem update becomes a matter of
streaming sequentially to a log file instead (and the filesystem can
do its normal writeback caching when updating the primary copy of the
files, reordering those writes to go as quickly as possible in the
background at some later point).  Put the log on a separate disk from
the main filesystem and it goes even faster.

Cheers,
 Stephen

From owner-linux-xfs@oss.sgi.com Thu May 10 04:21:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ABLrX31005
	for linux-xfs-outgoing; Thu, 10 May 2001 04:21:53 -0700
Received: from devserv.devel.redhat.com (nat-pool-meridian.redhat.com [199.183.24.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ABLqF31002
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 04:21:53 -0700
Received: (from sct@localhost)
	by devserv.devel.redhat.com (8.11.0/8.11.0) id f4ABKiG02623;
	Thu, 10 May 2001 07:20:44 -0400
Date: Thu, 10 May 2001 12:20:22 +0100
From: "Stephen C. Tweedie" <sct@redhat.com>
To: CaT <cat@zip.com.au>
Cc: GCS <gcs@agentsinside.com>, linux-xfs@oss.sgi.com,
   Stephen Tweedie <sct@redhat.com>
Subject: Re: Comparing XFS with ext3 and ReiserFS
Message-ID: <20010510122022.B14611@redhat.com>
References: <Pine.LNX.4.21.0105061818500.10780-100000@kalapati.jijo.local> <20010506162223.A29723@sisinteli07.udg.es> <20010507003457.A478@zip.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010507003457.A478@zip.com.au>; from cat@zip.com.au on Mon, May 07, 2001 at 12:34:57AM +1000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

On Mon, May 07, 2001 at 12:34:57AM +1000, CaT wrote:
> On Sun, May 06, 2001 at 04:22:23PM +0200, GCS wrote:
> 
> Small note: ext3 is being ported to 2.4.x by a few folks. SCT is currently
> AFK I believe

Not entirely AFK, just buried in VM stuff.  2.4 can _badly_ under
load on large memory machines, and having a solid 2.4 base is somewhat
a prerequisite for a stable filesystem!

> (if I remember things correctly). I believe the folks doing the port
> are attempting to make SCT's life easier. :)

Yes, there are a number of people helping out here, and the port is
going well.

Cheers,
 Stephen

From owner-linux-xfs@oss.sgi.com Thu May 10 04:58:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ABwvZ32244
	for linux-xfs-outgoing; Thu, 10 May 2001 04:58:57 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ABwsF32241
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 04:58:56 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA05460
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 04:58:46 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA976302; Thu, 10 May 2001 06:57:29 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA11410; Thu, 10 May 2001 06:57:29 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4ABxnO17545; Thu, 10 May 2001 06:59:49 -0500
Message-Id: <200105101159.f4ABxnO17545@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "redhat.angus" <redhat.angus@wanadoo.fr>
cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: Benchmark 
In-Reply-To: Message from "redhat.angus" <redhat.angus@wanadoo.fr> 
   of "10 May 2001 09:58:56 +0200." <989481537.4638.0.camel@adslgw> 
Date: Thu, 10 May 2001 06:59:49 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> What to think of these results ?
> 
> http://bulma.lug.net/body.phtml?nIdNoticia=626

Thanks for the pointer,

That's in Spanish right? We used to have a Spanish speaking developer,
it would be interesting to read the text, if I can remember how to use
babelfish.... OK, interesting. 

> 
> compared to the comment of Alan Cox concerning file deletion ?
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=98941976516596&w=2
> 
> >XFS is very fast most of the time (deleting a file is sooooo slow its
> >like using old BSD systems). Im not familiar enough with its behaviour
> >under Linux yet.
> 
> Do you have plan (SGI guys) to work on improve performances concerning
> file deletion since it is obviously about the only case where XFS lose ?

If there were about 20 days in a week and 48 hours in a day we might
just have time to do everything. There has been a design for speeding
this up for several years (yes years) but there has never been the
bandwidth to implement it. It involves major structural changes in XFS
and there are probably half a dozen people in the world with enough
understanding of the code to attempt it (and only two of us work for SGI
anymore).

So yes I would like to, but it is still way way down the list (not ordered):

   o Fix NFS problems in linux xfs which some people have reported
   o support block sizes other then the page size
   o rework some vm code usage which will be hard to get into Linus's tree
   o complete realtime subvolume support
   o get a standard acl/extended attribute api
   o get code accepted by Linus
   o keep up with this email list!

+ the internal list of other things you do not get to see and which contains
  some MUCH larger work items than the above.

So yes, I would like to do this, but....

Steve

> 
> -David
> 



From owner-linux-xfs@oss.sgi.com Thu May 10 05:21:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ACLeL00308
	for linux-xfs-outgoing; Thu, 10 May 2001 05:21:40 -0700
Received: from lantana.wanadoo.fr (smtp-rt-8.wanadoo.fr [193.252.19.51])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ACLcF00305
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 05:21:38 -0700
Received: from andira.wanadoo.fr (193.252.19.152) by lantana.wanadoo.fr; 10 May 2001 14:21:31 +0200
Received: from ARennes-201-2-1-32.abo.wanadoo.fr (193.253.176.32) by andira.wanadoo.fr; 10 May 2001 14:20:54 +0200
Subject: Re: Benchmark
From: "redhat.angus" <redhat.angus@wanadoo.fr>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <200105101159.f4ABxnO17545@jen.americas.sgi.com>
References: <200105101159.f4ABxnO17545@jen.americas.sgi.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Evolution/0.10 (Preview Release)
Date: 10 May 2001 14:17:36 +0200
Message-Id: <989497057.5470.0.camel@adslgw>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Le 10 May 2001 06:59:49 -0500, Steve Lord a écrit :
> That's in Spanish right? We used to have a Spanish speaking developer,
> it would be interesting to read the text, if I can remember how to use
> babelfish.... OK, interesting.

I just read the result and XFS is the best except in file deletion.
That why I ask this question but I have probably badly translated my
question, I am very satisfied with the XFS performances, I questioned
myself simply on Alan Cox.

>    o Fix NFS problems in linux xfs which some people have reported
>    o support block sizes other then the page size
>    o rework some vm code usage which will be hard to get into Linus's tree
>    o complete realtime subvolume support
>    o get a standard acl/extended attribute api
>    o get code accepted by Linus
>    o keep up with this email list!
> 
> + the internal list of other things you do not get to see and which contains
>   some MUCH larger work items than the above.

I precisely wanted to know the TODO list. Thanks.

-David




From owner-linux-xfs@oss.sgi.com Thu May 10 05:33:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ACX9x00593
	for linux-xfs-outgoing; Thu, 10 May 2001 05:33:09 -0700
Received: from dns.tricord.com (dns.tricord.com [64.240.27.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ACX4F00590
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 05:33:08 -0700
Received: by dns.tricord.com with Internet Mail Service (5.5.2448.0)
	id <KPQ7V4QN>; Thu, 10 May 2001 07:34:40 -0500
Message-ID: <6DEE94132593D41182D200508BDCA59045F6AE@mail.tricord.com>
From: "Mostek, Jim" <JMostek@tricord.com>
To: "'Steve Lord'" <lord@sgi.com>, "redhat.angus" <redhat.angus@wanadoo.fr>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: RE: Benchmark 
Date: Thu, 10 May 2001 07:32:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hey Steve, I took a quick look at the Spanish page.

The page compares XFS, ext2, reiser, and FAT32 with some basic tests.
You can see the tables and understand them if you realize that the smaller
numbers are better (number of seconds per op). He did writes, reads, deletes
of a few things
and XFS was faster for everything except the delete of a tar tree (which we
expect
because of the sync transaction on remove, right?).

Jim

-----Original Message-----
From: Steve Lord [mailto:lord@sgi.com]
Sent: Thursday, May 10, 2001 7:00 AM
To: redhat.angus
Cc: linux-xfs
Subject: Re: Benchmark 


> What to think of these results ?
> 
> http://bulma.lug.net/body.phtml?nIdNoticia=626

Thanks for the pointer,

That's in Spanish right? We used to have a Spanish speaking developer,
it would be interesting to read the text, if I can remember how to use
babelfish.... OK, interesting. 

> 
> compared to the comment of Alan Cox concerning file deletion ?
> 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=98941976516596&w=2
> 
> >XFS is very fast most of the time (deleting a file is sooooo slow its
> >like using old BSD systems). Im not familiar enough with its behaviour
> >under Linux yet.
> 
> Do you have plan (SGI guys) to work on improve performances concerning
> file deletion since it is obviously about the only case where XFS lose ?

If there were about 20 days in a week and 48 hours in a day we might
just have time to do everything. There has been a design for speeding
this up for several years (yes years) but there has never been the
bandwidth to implement it. It involves major structural changes in XFS
and there are probably half a dozen people in the world with enough
understanding of the code to attempt it (and only two of us work for SGI
anymore).

So yes I would like to, but it is still way way down the list (not ordered):

   o Fix NFS problems in linux xfs which some people have reported
   o support block sizes other then the page size
   o rework some vm code usage which will be hard to get into Linus's tree
   o complete realtime subvolume support
   o get a standard acl/extended attribute api
   o get code accepted by Linus
   o keep up with this email list!

+ the internal list of other things you do not get to see and which contains
  some MUCH larger work items than the above.

So yes, I would like to do this, but....

Steve

> 
> -David
> 


From owner-linux-xfs@oss.sgi.com Thu May 10 05:43:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AChQL00836
	for linux-xfs-outgoing; Thu, 10 May 2001 05:43:26 -0700
Received: from mail.processbiz.co.in ([202.144.112.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AChLF00829
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 05:43:24 -0700
Received: from processbiz.co.in (gateway.processbiz.co.in [202.144.112.73])
 by mail.processbiz.co.in
 (iPlanet Messaging Server 5.0 Patch 3 (built Mar 23 2001))
 with ESMTPA id <0GD40054VE00LL@mail.processbiz.co.in> for
 linux-xfs@oss.sgi.com; Thu, 10 May 2001 18:13:12 +0530 (IST)
Date: Thu, 10 May 2001 18:13:13 +0530
From: Binny Raphael <binny.raphael@processbiz.co.in>
Subject: Re: Benchmark
To: "Mostek, Jim" <JMostek@tricord.com>
Cc: "'Steve Lord'" <lord@sgi.com>, "redhat.angus" <redhat.angus@wanadoo.fr>,
   linux-xfs <linux-xfs@oss.sgi.com>
Reply-to: binny.raphael@processbiz.co.in
Message-id: <3AFA8CE0.196937@processbiz.co.in>
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
References: <6DEE94132593D41182D200508BDCA59045F6AE@mail.tricord.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi:
These links  might help...

http://babelfish.altavista.com/translate.dyn
http://www.systransoft.com/


"Mostek, Jim" wrote:

> Hey Steve, I took a quick look at the Spanish page.
>
> The page compares XFS, ext2, reiser, and FAT32 with some basic tests.
> You can see the tables and understand them if you realize that the smaller
> numbers are better (number of seconds per op). He did writes, reads, deletes
> of a few things
> and XFS was faster for everything except the delete of a tar tree (which we
> expect
> because of the sync transaction on remove, right?).
>
> Jim
>
> -----Original Message-----
> From: Steve Lord [mailto:lord@sgi.com]
> Sent: Thursday, May 10, 2001 7:00 AM
> To: redhat.angus
> Cc: linux-xfs
> Subject: Re: Benchmark
>
> > What to think of these results ?
> >
> > http://bulma.lug.net/body.phtml?nIdNoticia=626
>
> Thanks for the pointer,
>
> That's in Spanish right? We used to have a Spanish speaking developer,
> it would be interesting to read the text, if I can remember how to use
> babelfish.... OK, interesting.
>
> >
> > compared to the comment of Alan Cox concerning file deletion ?
> >
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=98941976516596&w=2
> >
> > >XFS is very fast most of the time (deleting a file is sooooo slow its
> > >like using old BSD systems). Im not familiar enough with its behaviour
> > >under Linux yet.
> >
> > Do you have plan (SGI guys) to work on improve performances concerning
> > file deletion since it is obviously about the only case where XFS lose ?
>
> If there were about 20 days in a week and 48 hours in a day we might
> just have time to do everything. There has been a design for speeding
> this up for several years (yes years) but there has never been the
> bandwidth to implement it. It involves major structural changes in XFS
> and there are probably half a dozen people in the world with enough
> understanding of the code to attempt it (and only two of us work for SGI
> anymore).
>
> So yes I would like to, but it is still way way down the list (not ordered):
>
>    o Fix NFS problems in linux xfs which some people have reported
>    o support block sizes other then the page size
>    o rework some vm code usage which will be hard to get into Linus's tree
>    o complete realtime subvolume support
>    o get a standard acl/extended attribute api
>    o get code accepted by Linus
>    o keep up with this email list!
>
> + the internal list of other things you do not get to see and which contains
>   some MUCH larger work items than the above.
>
> So yes, I would like to do this, but....
>
> Steve
>
> >
> > -David
> >


From owner-linux-xfs@oss.sgi.com Thu May 10 07:20:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AEKhi02686
	for linux-xfs-outgoing; Thu, 10 May 2001 07:20:43 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AEKfF02682
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:20:41 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA1150763
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:20:38 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1762990 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:19:19 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA96037 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:19:19 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4AELcd17979; Thu, 10 May 2001 09:21:38 -0500
Message-Id: <200105101421.f4AELcd17979@jen.americas.sgi.com>
Date: Thu, 10 May 2001 09:21:38 -0500
Subject: TAKE - move added super block field to a better location
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May 10 07:18:58 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94510a
linux/include/linux/fs.h - 1.92
	- reorder added field for posix acls - it was not in a good place alignment
	  wise.



From owner-linux-xfs@oss.sgi.com Thu May 10 07:33:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AEX0O02923
	for linux-xfs-outgoing; Thu, 10 May 2001 07:33:00 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AEWxF02919
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:32:59 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4AEW7024662;
	Thu, 10 May 2001 09:32:08 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 10 May 2001 09:32:06 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
In-Reply-To: <yq1eltzh0au.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105100931190.24470-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>From the man page it says LVM only performs concatenation. This is NOT
striping. Can someone who knows more about LVM than I and has been using
it for a while state what the practiced useability of LVM is?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 8 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> Ok, here's a REALLY hard question then. How can you grow, with
> Austin> LVM, a XFS filesystem, that is a LVM raid0?
>
> Just do it<tm>
>
> LVM stripes data across its allocation units (PEs/LEs), and when
> you're extending you're just adding more extents to the pool.
>
> The allocator will most likely round your specified size to a stripe
> boundary.
>
>


From owner-linux-xfs@oss.sgi.com Thu May 10 07:42:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AEg9O03109
	for linux-xfs-outgoing; Thu, 10 May 2001 07:42:09 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AEg8F03106
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:42:08 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xrdm-0001bS-00; Thu, 10 May 2001 16:42:07 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4AEf9L12474;
	Thu, 10 May 2001 10:41:09 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
References: <Pine.LNX.4.33.0105100931190.24470-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 10 May 2001 10:41:09 -0400
In-Reply-To: <Pine.LNX.4.33.0105100931190.24470-100000@UberGeek.coremetrics.com>
Message-ID: <yq1lmo5fere.fsf@jcb.mkp.net>
Lines: 13
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> From the man page it says LVM only performs
Austin> concatenation. This is NOT striping.

Where does it say that?

man lvcreate.  Take a look at the -i and -I options.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Thu May 10 07:48:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AEmdR03248
	for linux-xfs-outgoing; Thu, 10 May 2001 07:48:39 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AEmdF03244
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:48:39 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail15.jump.net (8.10.2/) with ESMTP id f4AEm7L12630;
	Thu, 10 May 2001 09:48:07 -0500 (CDT)
Message-ID: <3AFAAAB8.AD96BF86@sgi.com>
Date: Thu, 10 May 2001 09:50:32 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: binny.raphael@processbiz.co.in
CC: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: Benchmark
References: <6DEE94132593D41182D200508BDCA59045F6AE@mail.tricord.com> <3AFA8CE0.196937@processbiz.co.in>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Binny Raphael wrote:
> 
> Hi:
> These links  might help...
> 
> http://babelfish.altavista.com/translate.dyn
> http://www.systransoft.com/

This might take you right there, unless babelfish is sneaky...

http://babelfish.altavista.com/urltrurl?url=http%3A%2F%2Fbulma.lug.net%2Fbody.phtml%3FnIdNoticia%3D626&lp=es_en&tt=url&urltext=&doit=done

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 07:56:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AEu0v03385
	for linux-xfs-outgoing; Thu, 10 May 2001 07:56:00 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AEtwF03382
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:55:58 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA01905
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 07:55:28 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1767174 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:54:12 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA64610 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:54:12 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4AEuWC21740; Thu, 10 May 2001 09:56:32 -0500
Message-Id: <200105101456.f4AEuWC21740@jen.americas.sgi.com>
Date: Thu, 10 May 2001 09:56:32 -0500
Subject: TAKE - rework pagebuf metadata lookup path
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Been sitting on this for about a month, time to check it in.

The original architecture, implemented by someone who will remain
nameless, for the cache lookup has bugged me from day one. Two
levels of lookup were involved, one of which was not really needed,
the top one was just an encapsulation to avoid putting an extra
field into an inode. The real problem was that it should not have
been an inode in the first place, all we needed from the inode
was an address space. This replaces the magic metadata inode with
a special structure which xfs passes around where it used to pass
around that inode and removes the need for a lookup to map from the
inode to the pagebuf cache. No significant speedup, but should shrink
the kernel a bit, reduce cpu usage a bit, and reduce contention
on some locks.


Date:  Thu May 10 07:44:32 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94513a
linux/fs/xfs/xfsidbg.c - 1.161
	- Change xbuf idbg function to deal with change in target structure

linux/fs/xfs/xfs_buf.h - 1.73
	- Change more macros to call pagebuf directly rather than a wrapper
	  function.

linux/fs/xfs/xfs_vfsops.c - 1.316
	- Change names of functions used to release caches during failed mount.

linux/fs/xfs/xfs_mount.c - 1.255
	- change names of functions used to release caches at end of unmount.

linux/fs/xfs/linux/xfs_lrw.c - 1.96
	- remove some wrapper functions which were basically one liners, call the
	  pagebuf functions directly instead. Also deal with the change to the
	  target object for metadata no longer being an inode. Use new pagebuf_lookup
	  function.

linux/fs/xfs/linux/xfs_super.h - 1.9
	- change the prototypes for metadata cache creation functions.

linux/fs/xfs/linux/xfs_super.c - 1.121
	- change the structures we create to hold the metadata cache.

linux/include/linux/page_buf.h - 1.91
	- mucho prototype changes

linux/fs/pagebuf/page_buf.c - 1.81
	- Change object used for metadata handle from an inode to a special
	  structure containing an address space and the pagebuf cache for
	  the filesystem. This is passed around directly from xfs to pagebuf
	  rather than every pagebuf_get operation involving a search to map
	  from the inode to the pagebuf cache - that was just dumb. 

linux/fs/pagebuf/page_buf_locking.c - 1.10
	- Remove one level of indirection in looking up a pagebuf, gets rid of 
	  lots of complexity in the code.

linux/fs/pagebuf/page_buf_io.c - 1.79
	- Use new pagebuf_lookup function from one place in I/O path



From owner-linux-xfs@oss.sgi.com Thu May 10 08:00:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AF0iN03542
	for linux-xfs-outgoing; Thu, 10 May 2001 08:00:44 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AF0hF03539
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:00:43 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4AF0BG25909;
	Thu, 10 May 2001 10:00:12 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 10 May 2001 10:00:10 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
In-Reply-To: <yq1lmo5fere.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105100950540.24470-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, I see that, but what about the lvm manpage? I was incorrect in
stating lvcreate. My apologies. Do a man on lvm and this is what you get.
Now reading this, it just tells me that to create a disk group or pool, it
"concatenates" these disks. Not at the logical level however, but rather
to create a "pool" or "group". I think concatenate here is a bad word to
use. But, here's what it says.

DESCRIPTION
       lvm is a logical volume manager for Linux.  It enables you
       to concatenate several physical volumes (hard disks  etc.)
       into  a  so  called  volume group (VG, see pvcreate(8) and
       vgcreate(8) ) forming a storage pool, like a virtual disk.
       ...

Seems a bit odd here if I want to create a striped set, it seems that you
must create several "groups" of single disks and then when using lvcreate
stripe those "Groups". Thoughts?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 10 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> From the man page it says LVM only performs
> Austin> concatenation. This is NOT striping.
>
> Where does it say that?
>
> man lvcreate.  Take a look at the -i and -I options.
>
>



From owner-linux-xfs@oss.sgi.com Thu May 10 08:12:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AFCfW03881
	for linux-xfs-outgoing; Thu, 10 May 2001 08:12:41 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AFCeF03878
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:12:40 -0700
Received: from sgi.com (aus-dsl-dhcp6-198.customer.jump.net [63.163.173.198])
	by mail11.jump.net (8.10.2/) with ESMTP id f4AFCcv10783
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 10:12:38 -0500 (CDT)
Message-ID: <3AFAB076.5AE3C60C@sgi.com>
Date: Thu, 10 May 2001 10:15:02 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Mandrake/SuSE NFS update
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi all - 

Regarding the "invalid argument" problem on Mandrake and SuSE boxes, I
think I've found the problem.

Mandrake applies a patch from Neil Brown that adds an "nfsd_operations"
interface between knfsd and each filesystem.  I can't find a kernel
source RPM for SuSE 7.1, but I assume that it's the same issue.

If this interface doesn't exist for a filesystem (and at this point, it
does not for XFS), this patched version of nfs deems the filesystem
"invalid" and will not export it.

I think it's pretty quick fix, I'll be looking into it today.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 08:21:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AFLX404079
	for linux-xfs-outgoing; Thu, 10 May 2001 08:21:33 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AFLVF04076
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:21:31 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14xsFu-0001dI-00; Thu, 10 May 2001 17:21:30 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4AFKY317556;
	Thu, 10 May 2001 11:20:34 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
References: <Pine.LNX.4.33.0105100950540.24470-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 10 May 2001 11:20:33 -0400
In-Reply-To: <Pine.LNX.4.33.0105100950540.24470-100000@UberGeek.coremetrics.com>
Message-ID: <yq1heytfcxq.fsf@jcb.mkp.net>
Lines: 47
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> Seems a bit odd here if I want to create a striped set, it
Austin> seems that you must create several "groups" of single disks
Austin> and then when using lvcreate stripe those "Groups". Thoughts?

Nope.  A volume group is a set of disks that you decide to put
together for administrative purposes.  Usually a either the internal
disks or an external disk array.  Grouping disks makes it easier to
move them between machines.  And you might have different requirements
for different types of data.

A volume group consists of physical volumes (PVs) which are physical
disk partitions in most cases.

Each PV is chopped into fixed-size chunks (Physical Extents).  Default
is 4MB.  See the vgcreate manpage for more info.

When you create a logical volume you have two choices:

If you don't specify striping parameters, the allocator will pick
whatever free PEs it feels like and use those.  It will round the size
you specify for your partition to a PE boundary.

If you do specify striping parameters, the allocator will interleave
the PEs spreading out your logical volume over the available PVs.  And
it will do striping with your preferred stripe size on top of those
chunks.


I suggest you read the LVM Howto:

        http://sistina.com/lvm/doc/lvm_howto/index.html


And for a brief hands-on striping setup, there's the blurb I wrote for
use with XFS way back.  Note that this was written before I
implemented the LVM interface, so you can't see mkfs.xfs extract
stripe info from the logical volume in that document.  But that works
without user intervention these days.

        /usr/share/doc/xfsprogs/README.LVM

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Thu May 10 08:23:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AFNj704143
	for linux-xfs-outgoing; Thu, 10 May 2001 08:23:45 -0700
Received: from sith.mimuw.edu.pl (qmailr@sith.mimuw.edu.pl [193.0.97.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4AFNhF04138
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:23:44 -0700
Received: (qmail 5147 invoked by uid 1645); 10 May 2001 17:27:02 -0000
Date: Thu, 10 May 2001 19:27:02 +0200
From: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mandrake/SuSE NFS update
Message-ID: <20010510192702.A4433@sith.mimuw.edu.pl>
References: <3AFAB076.5AE3C60C@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AFAB076.5AE3C60C@sgi.com>; from sandeen@sgi.com on Thu, May 10, 2001 at 10:15:02AM -0500
X-Operating-System: Linux 2.4.2-xfs i586
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 10 May 2001, Eric Sandeen wrote:

> Mandrake applies a patch from Neil Brown that adds an "nfsd_operations"
> interface between knfsd and each filesystem.  I can't find a kernel
> source RPM for SuSE 7.1, but I assume that it's the same issue.
> 
> If this interface doesn't exist for a filesystem (and at this point, it
> does not for XFS), this patched version of nfs deems the filesystem
> "invalid" and will not export it.
> 
> I think it's pretty quick fix, I'll be looking into it today.

Eric,
I made such patch for XFS, the only thing I need is clarification
from you if it's correct. Here it goes.

--- linux/fs/xfs/linux/xfs_iops.c.orig	Wed May  2 01:10:46 2001
+++ linux/fs/xfs/linux/xfs_iops.c	Fri May  4 01:33:05 2001
@@ -174,8 +174,55 @@
 		linvfs_set_inode_ops(ip);
 		error = linvfs_revalidate_core(ip, ATTR_COMM);
 	}
+
+	if (ip)
+		return d_splice_alias(ip, dentry);
+
 	d_add(dentry, ip);	/* Negative entry goes in if ip is NULL */
 	return NULL;
+}
+
+
+struct dentry * linvfs_get_parent(struct dentry *child)
+{
+	int		error;
+	vnode_t		*vp, *cvp;
+	pathname_t	pn;
+	pathname_t      *pnp = &pn;
+	struct inode	*ip = NULL;
+	struct dentry	*parent;
+
+	vp = LINVFS_GET_VP(child->d_inode);
+	ASSERT(vp);
+
+	/*
+	 * Initialize a pathname_t to pass down.
+	 */
+	bzero(pnp, sizeof(pathname_t));
+	pnp->pn_complen = 2;
+	pnp->pn_path = "..";
+
+	cvp = NULL;
+
+	VOP_LOOKUP(vp, "..", &cvp, pnp, 0, NULL, NULL, error);
+	if (!error) {
+		ASSERT(cvp);
+		ip = LINVFS_GET_IP(cvp);
+		if (!ip) {
+			VN_RELE(cvp);
+			return ERR_PTR(-EACCES);
+		}
+		linvfs_set_inode_ops(ip);
+		error = linvfs_revalidate_core(ip, ATTR_COMM);
+	}
+
+	parent = d_make_alias(ip);
+	if (!parent) {
+		VN_RELE(cvp);
+		parent = ERR_PTR(-ENOMEM);
+	}
+
+	return parent;
 }
 
 
--- linux/fs/xfs/linux/xfs_super.c.orig	Wed May  2 01:10:46 2001
+++ linux/fs/xfs/linux/xfs_super.c	Fri May  4 01:35:49 2001
@@ -38,6 +38,7 @@
 #include <linux/blkdev.h>
 #include <linux/init.h>
 #include <linux/page_buf.h>
+#include <linux/nfsd/interface.h>
 
 /* xfs_vfs[ops].c */
 extern void vfsinit(void);
@@ -49,6 +50,12 @@
 
 static struct super_operations linvfs_sops;
 
+extern struct dentry *linvfs_get_parent(struct dentry *child);
+
+static struct nfsd_operations xfs_nfsd_operations = {
+	get_parent:     linvfs_get_parent,
+};
+
 
 #define	MS_DATA		0x04
 
@@ -414,6 +421,7 @@
 	set_blocksize(sb->s_dev, 512);
 
 	sb->s_op = &linvfs_sops;
+	sb->s_nfsd_op = &xfs_nfsd_operations;
 	sb->dq_op = NULL;
 
 	LINVFS_SET_VFS(sb, vfsp);

Jan
-- 
Jan Rêkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio

From owner-linux-xfs@oss.sgi.com Thu May 10 08:25:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AFPTp04196
	for linux-xfs-outgoing; Thu, 10 May 2001 08:25:29 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AFPSF04193
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:25:28 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA09556
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:36:19 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1768319 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 10:24:11 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA73244; Thu, 10 May 2001 10:24:11 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4AFQUc21781; Thu, 10 May 2001 10:26:30 -0500
Message-Id: <200105101526.f4AFQUc21781@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Eric Sandeen <sandeen@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Mandrake/SuSE NFS update 
In-Reply-To: Message from Eric Sandeen <sandeen@sgi.com> 
   of "Thu, 10 May 2001 10:15:02 CDT." <3AFAB076.5AE3C60C@sgi.com> 
Date: Thu, 10 May 2001 10:26:30 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi all - 
> 
> Regarding the "invalid argument" problem on Mandrake and SuSE boxes, I
> think I've found the problem.
> 
> Mandrake applies a patch from Neil Brown that adds an "nfsd_operations"
> interface between knfsd and each filesystem.  I can't find a kernel
> source RPM for SuSE 7.1, but I assume that it's the same issue.
> 
> If this interface doesn't exist for a filesystem (and at this point, it
> does not for XFS), this patched version of nfs deems the filesystem
> "invalid" and will not export it.
> 
> I think it's pretty quick fix, I'll be looking into it today.
> 
> -Eric
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.

I think someone posted a patch for XFS and this in the last week or so. The 
Neil Brown patch was for reiserfs NFS support.

Steve




From owner-linux-xfs@oss.sgi.com Thu May 10 08:34:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AFY9604380
	for linux-xfs-outgoing; Thu, 10 May 2001 08:34:09 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AFY8F04377
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 08:34:08 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4AFY4L17088;
	Thu, 10 May 2001 10:34:04 -0500 (CDT)
Message-ID: <3AFAB57A.E44D424@sgi.com>
Date: Thu, 10 May 2001 10:36:26 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Mandrake/SuSE NFS update
References: <3AFAB076.5AE3C60C@sgi.com> <20010510192702.A4433@sith.mimuw.edu.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jan Rekorajski wrote:
 
> Eric,
> I made such patch for XFS, the only thing I need is clarification
> from you if it's correct. Here it goes.

Oops, sorry - too much mail flying by.  :)

I'll look into this today, thanks.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 09:12:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AGCpR05021
	for linux-xfs-outgoing; Thu, 10 May 2001 09:12:51 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AGCoF05017
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:12:50 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4AGBURe004794;
	Thu, 10 May 2001 09:11:30 -0700
Date: Thu, 10 May 2001 09:11:30 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc: Fermin Molina <fermin@eup.udl.es>, linux-xfs@oss.sgi.com
Subject: Re: XFS 1.0/Quota
In-Reply-To: <10105101021.ZM76311@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0105100906050.17385-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've recompiled kernel, this time making sure XFS quota is selected.  When
the machine starts up it does say "XFS doing quotacheck.. Please wait."  I
wait 5 minutes or so and then the machine freezes (by freezing I mean no
more hard drive activity and machine does not respond).  

I booted into a single user mode.  did a mount -a, got the "doing
quotacheck... Please wait."  After awhile I get a funny error "Run out of
memory.. Cancelling processs (sh)"  The error is not in exact words but
something like that.  

The machine has 256MB memory with 658MB disk cache. The xfs filesystem is
a hardware raid with 8 disks totalling 350MB.  Does anyone have experience
running xfs on large partitions?  

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Thu, 10 May 2001, Nathan Scott wrote:

> hi,
> 
> On May 9,  5:09pm, <marchuk@ee.washington.edu> wrote:
> > Subject: Re: XFS 1.0/Quota
> > 
> > fstab entry:
> > # Raid
> > /dev/sdc1 /users/raid2 xfs rw,usrquota 0 0
> > 
> > 
> > [root@gauss doc]# quotaon /users/raid2
> > quotaon: Enable XFS group quota during mount
> > quotaon: Enable XFS user quota during mount
> > 
> 
> quotaon is the wrong way to try to enable quota on this
> XFS filesystem.  If your filesystem is mounted with the
> above option, and the 3.01-pre5 quota tools are reporting
> no quota for the filesystem, then the running kernel was
> probably not compiled with XFS quota support.
> 
> If quota are enabled in the kernel, when you mount the
> filesystem for the first time with the above options you
> should see a console message along the lines "XFS doing
> quotacheck..."
> 
> > 
> > [root@gauss doc]# quot /users/raid2
> > /dev/sdc1 (/users/raid2) users:
> > 30811212    root
> >  2978692    support
> > 
> 
> The quot command will always work for any XFS filesystem,
> independent of whether it has quota enabled or not.
> 
> cheers.
> 
> -- 
> Nathan
> 


From owner-linux-xfs@oss.sgi.com Thu May 10 09:24:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AGOis05206
	for linux-xfs-outgoing; Thu, 10 May 2001 09:24:44 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AGOhF05203
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:24:43 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4AGO8F27892;
	Thu, 10 May 2001 11:24:08 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 10 May 2001 11:24:06 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + LVM + Epanding; shrinking XFS??
In-Reply-To: <yq1heytfcxq.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105101122280.24470-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok. I understand this in its entirety. This is what I believed to be the
proper behaviour, but someone I had working on doing some of this kept
saying that he couldn't do it. I think he wasn't doing nearly enough work
and just wanted everything done with 1 command. I know it's not so, we use
Veritas currently, and at the command line, it's just as much work. Thanks
for all the help. It will go a long way in our proof of concept!

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 10 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> Seems a bit odd here if I want to create a striped set, it
> Austin> seems that you must create several "groups" of single disks
> Austin> and then when using lvcreate stripe those "Groups". Thoughts?
>
> Nope.  A volume group is a set of disks that you decide to put
> together for administrative purposes.  Usually a either the internal
> disks or an external disk array.  Grouping disks makes it easier to
> move them between machines.  And you might have different requirements
> for different types of data.
>
> A volume group consists of physical volumes (PVs) which are physical
> disk partitions in most cases.
>
> Each PV is chopped into fixed-size chunks (Physical Extents).  Default
> is 4MB.  See the vgcreate manpage for more info.
>
> When you create a logical volume you have two choices:
>
> If you don't specify striping parameters, the allocator will pick
> whatever free PEs it feels like and use those.  It will round the size
> you specify for your partition to a PE boundary.
>
> If you do specify striping parameters, the allocator will interleave
> the PEs spreading out your logical volume over the available PVs.  And
> it will do striping with your preferred stripe size on top of those
> chunks.
>
>
> I suggest you read the LVM Howto:
>
>         http://sistina.com/lvm/doc/lvm_howto/index.html
>
>
> And for a brief hands-on striping setup, there's the blurb I wrote for
> use with XFS way back.  Note that this was written before I
> implemented the LVM interface, so you can't see mkfs.xfs extract
> stripe info from the logical volume in that document.  But that works
> without user intervention these days.
>
>         /usr/share/doc/xfsprogs/README.LVM
>
>


From owner-linux-xfs@oss.sgi.com Thu May 10 09:42:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AGgLx05752
	for linux-xfs-outgoing; Thu, 10 May 2001 09:42:21 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AGgJF05749
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 09:42:19 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id SAA03284;
	Thu, 10 May 2001 18:42:10 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id SAA12471;
	Thu, 10 May 2001 18:42:09 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 7CC4B57306; Thu, 10 May 2001 18:51:15 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 5BE2D25835; Thu, 10 May 2001 18:52:25 +0200 (CEST)
Message-ID: <3AFAC5AE.6F8FF894@ch.sauter-bc.com>
Date: Thu, 10 May 2001 18:45:34 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: XFS on md (RAID1) with devfs fixed
References: <3AF8E3BA.1F2D9397@ch.sauter-bc.com> <3AF9617C.37F1F1EE@thebarn.com> <3AF96D44.51443824@ch.sauter-bc.com> <3AF9741B.5269578A@thebarn.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Your patch did not work... I want to create a initrd which
is able to boot with or without devfs. Believe it or not, the
following patch is the only way it works.

--- mkinitrd.orig       Thu May 10 18:16:05 2001
+++ mkinitrd    Thu May 10 18:16:05 2001
@@ -396,8 +396,9 @@
 fi
 
 if [ -n "$startraid" ]; then
-    cp -a /dev/md0 $MNTIMAGE/dev
+    mknod $MNTIMAGE/dev/md0 b 9 0
     echo "raidautorun /dev/md0" >> $RCFILE
+    echo "raidautorun /dev/md/0" >> $RCFILE
 fi
 
 chmod +x $RCFILE

Can somebody explain?
Can somebody else try this?

Russell Cattelan schrieb:
> 
> Simon Matter wrote:
> 
> >
> > > --- mkinitrd~   Fri Mar 23 15:21:08 2001
> > > +++ mkinitrd    Wed May  9 10:22:14 2001
> > > @@ -396,8 +396,9 @@
> > >  fi
> > >
> > >  if [ -n "$startraid" ]; then
> > > -    cp -a /dev/md0 $MNTIMAGE/dev
> > > -    echo "raidautorun /dev/md0" >> $RCFILE
> > > +    mkdir $MNTIMAGE/dev/md
> >
> > What are you doing here? Since we don't have devfs at this time, we
> > can't copy /dev/md/0 to the initrd???
> 
> Actually looking at this closer this would seem to be better...
> --- /sbin/mkinitrd      Wed May  9 11:38:46 2001
> +++ /sbin/mkinitrd.orig Wed May  9 11:37:19 2001
> @@ -396,7 +396,7 @@
>  fi
> 
>  if [ -n "$startraid" ]; then
> +    mknod $MNTIMAGE/dev/md0 b 9 0
> -    cp -a /dev/md0 $MNTIMAGE/dev
>      echo "raidautorun /dev/md0" >> $RCFILE
>  fi
> 
> at some point the rest of mkinitrd was changed to use mknod for all
> the devices it needed, it would appear the raid portion got overlooked.
> 
> >
> >
> > > +    cp -a /dev/md/0 $MNTIMAGE/dev/md
> > > +    echo "raidautorun /dev/md/0" >> $RCFILE
> > >  fi
> > >
> > >  chmod +x $RCFILE
> > >
> > Maybe linuxrc solution could be easier:
> >
> > raidautorun /dev/md/0
> > raidautorun /dev/md0
> >
> > If we don't have devfs, the first line won't do anything but the
> > second statement should do the job. I'll try it later, maybe I'm
> > completely wrong...
> 
> we just need to make sure initrd has a raid dev
> devfs isn't in the picture yet when initrd is loaded.
> 
> lilo should work either way since once devfsd is running  /dev/md0
> should
> exist
> 
> >
> >
> > --
> > Simon Matter              Tel:  +41 61 695 57 35
> > Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
> > Im Surinam 55
> > CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]
> 
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Thu May 10 10:21:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AHLP806836
	for linux-xfs-outgoing; Thu, 10 May 2001 10:21:25 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AHLOF06833
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 10:21:24 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2E5FA1E0FB; Thu, 10 May 2001 19:21:23 +0200 (MEST)
Date: Thu, 10 May 2001 19:21:09 +0200
From: Andi Kleen <ak@suse.de>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mandrake/SuSE NFS update
Message-ID: <20010510192109.A22776@gruyere.muc.suse.de>
References: <3AFAB076.5AE3C60C@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AFAB076.5AE3C60C@sgi.com>; from sandeen@sgi.com on Thu, May 10, 2001 at 10:15:02AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 10, 2001 at 10:15:02AM -0500, Eric Sandeen wrote:
> Hi all - 
> 
> Regarding the "invalid argument" problem on Mandrake and SuSE boxes, I
> think I've found the problem.
> 
> Mandrake applies a patch from Neil Brown that adds an "nfsd_operations"
> interface between knfsd and each filesystem.  I can't find a kernel
> source RPM for SuSE 7.1, but I assume that it's the same issue.

The SuSE 7.1 2.4 kernel doesn't use the nfsd_operations patch.

-Andi

From owner-linux-xfs@oss.sgi.com Thu May 10 11:29:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AITnQ10235
	for linux-xfs-outgoing; Thu, 10 May 2001 11:29:49 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AITmF10232
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 11:29:49 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA09677
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 11:29:47 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1745573 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 13:28:10 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA68060 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 13:28:10 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4AIUPH22942; Thu, 10 May 2001 13:30:25 -0500
Message-Id: <200105101830.f4AIUPH22942@jen.americas.sgi.com>
Date: Thu, 10 May 2001 13:30:25 -0500
Subject: TAKE - fix module build
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks to Andi Kleen for finding this.

Date:  Thu May 10 11:27:40 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94546a
linux/fs/pagebuf/page_buf.c - 1.82
	- fix module version of pagebuf - new symbol pagebuf_lookup needs exporting



From owner-linux-xfs@oss.sgi.com Thu May 10 12:28:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AJS7212078
	for linux-xfs-outgoing; Thu, 10 May 2001 12:28:07 -0700
Received: from mail11.svr.pol.co.uk (mail11.svr.pol.co.uk [195.92.193.23])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AJS0F12070
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 12:28:06 -0700
Received: from modem-756.harrier.dialup.pol.co.uk ([62.25.94.244] helo=jupiter)
	by mail11.svr.pol.co.uk with smtp (Exim 3.13 #0)
	id 14xw6M-0001uY-00
	for linux-xfs@oss.sgi.com; Thu, 10 May 2001 20:27:55 +0100
Message-ID: <000a01c0d987$0cc19740$0300000a@jupiter>
From: "James Lyon" <james@ly0n.com>
To: <linux-xfs@oss.sgi.com>
Subject: Broken kernel-2.4.2-SGI_XFS_1.0.i686.rpm pakage
Date: Thu, 10 May 2001 20:25:24 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I have just downloaded the RedHat 7.1 XFS kernel RPM
(kernel-2.4.2-SGI_XFS_1.0.i686.rpm). I installed the kernel with rpm -Uvh,
reran lilo and rebooted.

None of the kernel modules would load, and depmod complained of missing
kernel symbols. I examined /proc/ksyms and it seems that all of the missing
kernel symbols do exist but have a different version number on the end.

It seems that this package is broken and so I hope you can rebuild it and
put up a fixed one soon.


From owner-linux-xfs@oss.sgi.com Thu May 10 12:34:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AJYMg12247
	for linux-xfs-outgoing; Thu, 10 May 2001 12:34:22 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AJYKF12243
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 12:34:21 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4AJXbu28970;
	Thu, 10 May 2001 14:33:37 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 10 May 2001 14:33:36 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: James Lyon <james@ly0n.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Broken kernel-2.4.2-SGI_XFS_1.0.i686.rpm pakage
In-Reply-To: <000a01c0d987$0cc19740$0300000a@jupiter>
Message-ID: <Pine.LNX.4.33.0105101433170.24470-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sounds like the System.map didn't get symlinked.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 10 May 2001, James Lyon wrote:

> I have just downloaded the RedHat 7.1 XFS kernel RPM
> (kernel-2.4.2-SGI_XFS_1.0.i686.rpm). I installed the kernel with rpm -Uvh,
> reran lilo and rebooted.
>
> None of the kernel modules would load, and depmod complained of missing
> kernel symbols. I examined /proc/ksyms and it seems that all of the missing
> kernel symbols do exist but have a different version number on the end.
>
> It seems that this package is broken and so I hope you can rebuild it and
> put up a fixed one soon.
>


From owner-linux-xfs@oss.sgi.com Thu May 10 13:22:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AKMT113437
	for linux-xfs-outgoing; Thu, 10 May 2001 13:22:29 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AKMSF13432
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 13:22:28 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4AKMP908821
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 15:22:25 -0500 (CDT)
Message-ID: <3AFAF912.FC401D3C@sgi.com>
Date: Thu, 10 May 2001 15:24:50 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Problem with 2.4.3, xfs, knfsd: "getfh failed: Operation not 
 permitted"
References: <3AF65085.31E3B94B@educators.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Felix Ide wrote:
> 
> Hi everybody,
> 
> first thanks to everyone involved in this project, xfs is great for
> (mostly) all our needs...!
> 
> Except for a NFS problem:
> We're useing SuSE 7.1, plain 2.4.3 kernel, patches 1.0 from sgi's
> website, nfsutils updated to 0.3.1.
> When I start the nfsserver I get the following messages:
> ...
> woodstock.educators.de:/nfs: Invalid argument

Hi Felix - so this is just a stock kernel 2.4.3 tarball with our
patches, and nothing else?

I found a similar problem in Mandrake, but it was related to NFS kernel
patches...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 13:38:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AKct513785
	for linux-xfs-outgoing; Thu, 10 May 2001 13:38:55 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AKcrF13781
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 13:38:53 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4AKcn919595;
	Thu, 10 May 2001 15:38:49 -0500 (CDT)
Message-ID: <3AFAFCEB.AF67125F@sgi.com>
Date: Thu, 10 May 2001 15:41:15 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: James Lyon <james@ly0n.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Broken kernel-2.4.2-SGI_XFS_1.0.i686.rpm pakage
References: <000a01c0d987$0cc19740$0300000a@jupiter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

James Lyon wrote:
> 
> I have just downloaded the RedHat 7.1 XFS kernel RPM
> (kernel-2.4.2-SGI_XFS_1.0.i686.rpm). I installed the kernel with rpm -Uvh,
> reran lilo and rebooted.
> 
> None of the kernel modules would load, and depmod complained of missing
> kernel symbols. I examined /proc/ksyms and it seems that all of the missing
> kernel symbols do exist but have a different version number on the end.

Hm..

[root@lite RPMS]# rpm -ivh kernel-2.4.2-SGI_XFS_1.0.i686.rpm
Preparing...                ###########################################
[100%]
   1:kernel                 ###########################################
[100%]

<edit lilo, reboot...>

[root@lite sandeen]# uname -a
Linux lite 2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i686
unknown
[root@lite sandeen]# /sbin/depmod -a
[root@lite sandeen]#

No problems here...

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 14:16:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ALGbp14987
	for linux-xfs-outgoing; Thu, 10 May 2001 14:16:37 -0700
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ALGZF14983
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 14:16:36 -0700
Received: from fwd02.sul.t-online.de 
	by mailout06.sul.t-online.com with smtp 
	id 14xxnc-0000FW-05; Thu, 10 May 2001 23:16:40 +0200
Received: from t-online.de (340024412816-0001@[217.81.141.30]) by fwd02.sul.t-online.com
	with esmtp id 14xxnj-1QXTKyC; Thu, 10 May 2001 23:16:47 +0200
Message-ID: <3AFB0529.BFCF0FE@t-online.de>
Date: Thu, 10 May 2001 23:16:25 +0200
From: Hasch@t-online.de (Juergen Hasch)
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Windows NT 5.0; U)
X-Accept-Language: de
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: fileutils patches?
References: <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: 340024412816-0001@t-dialin.net
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


werner maes schrieb:
> 
> 
>         Hello,
> 
> I installed XFS using the RH 7.1 installer.
> I tried working with acl and this works but I was wondering where
> I can find the patch to enable the fileutils commands (ls, rm, mv, cp,...)
> to recognize ACL's.
> In the ISO for RH 7.1 there's a special kernel and the xfsprogs but I can't
> seem to find these patched fileutils.
> 
> Does somebody has more information?

I am using patched fileutils with XFS. You can use the patch from
acl.bestbits.at
together with fileutils-4.0.43, but you will need to add a few lines to
permission.c
because the XFS implementation doesn't match the one from Andreas
Gruenbacher
(see patch below).

The autoconf stuff is broken for most versions right now, so you have to
do some hand editing after configure.
In config.h add:
#define USE_ACL 1
#define HAVE_ACL 1
#define HAVE_ACL_GET_FILE 1
#define HAVE_ACL_TO_TEXT 1
#define HAVE_ACL_FREE 1
#define HAVE_ACL_SET_FILE 1

In src/Makefile add -lacl in the LIBS line:
LIBS = -lacl

This works for me.
  ...Juergen

--- permissions.orig	Thu May 10 22:24:35 2001
+++ permissions.c	Thu May 10 22:34:27 2001
@@ -32,6 +32,11 @@
 # define ENOTSUP ENOSYS
 #endif
 
 #ifndef errno
 extern int errno;
 #endif
@@ -288,7 +293,7 @@
 
   if ((acl = acl_get_file(path, ACL_TYPE_ACCESS)) == NULL)
     {
-      if (errno == ENOSYS || errno == ENOTSUP)
+      if (errno == EINVAL || errno == ENOSYS || errno == ENOTSUP)
         {
           return 0;
         }
@@ -298,6 +303,10 @@
           return -1;
         }
    }
+
+  if (acl->acl_cnt == ACL_NOT_PRESENT) /* XFS */
+	return 0;
+
   return_val = count_acl_entries(acl);
   acl_free(acl);
   if (return_val < 0)
@@ -323,6 +332,9 @@
 	      return -1;
 	    }
 	}
+    if (acl->acl_cnt == ACL_NOT_PRESENT) /* XFS */
+	return 0;
+
       return_val = count_acl_entries(acl);
       acl_free(acl);
       if (return_val < 0)

From owner-linux-xfs@oss.sgi.com Thu May 10 14:40:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ALeI615792
	for linux-xfs-outgoing; Thu, 10 May 2001 14:40:18 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ALeHF15789
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 14:40:17 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA07275
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 14:40:11 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA04245
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 14:40:06 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 10 May 2001 14:40:03 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA20848;
	Thu, 10 May 2001 14:40:02 -0700
Message-Id: <3AFB0AB2.89DCB6EC@pipcws.ca.boeing.com>
Date: Thu, 10 May 2001 14:40:02 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: James Lyon <james@ly0n.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Broken kernel-2.4.2-SGI_XFS_1.0.i686.rpm pakage
References: <000a01c0d987$0cc19740$0300000a@jupiter>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

James Lyon wrote:
> 
> I have just downloaded the RedHat 7.1 XFS kernel RPM
> (kernel-2.4.2-SGI_XFS_1.0.i686.rpm). I installed the kernel with rpm -Uvh,
> reran lilo and rebooted.
> 
> None of the kernel modules would load, and depmod complained of missing
> kernel symbols. I examined /proc/ksyms and it seems that all of the missing
> kernel symbols do exist but have a different version number on the end.
> 
> It seems that this package is broken and so I hope you can rebuild it and
> put up a fixed one soon.

Look in /boot, and check the System.map. Make sure it's the right one, and not a
link to the old one.
Maybe some one on the list running that kernel, can send along what the time &
date stamps should be (to verify), and the size. It sounds like you have the
wrong one.


-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Thu May 10 15:34:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AMYlv17993
	for linux-xfs-outgoing; Thu, 10 May 2001 15:34:47 -0700
Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMYkF17990
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 15:34:46 -0700
Received: from zipperii.zip.com.au (dsainty@zipperii.zip.com.au [61.8.0.87])
	by vasquez.zip.com.au (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA23404
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 08:34:44 +1000
Date: Fri, 11 May 2001 08:34:44 +1000 (EST)
From: IFIX Computer Solutions <dsainty@zip.com.au>
To: <linux-xfs@oss.sgi.com>
Subject: Long Term Commitment to Linux XFS, 
Message-ID: <Pine.LNX.4.30.0105110752470.18660-100000@zipperii.zip.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've heard some bad rumours about SGI's possible long term commitment to
XFS on Linux....  Do you have any sort of statement or position with
respect to the commitment to support Linux XFS into the future?

My colleagues and I are currently evaluating the use of either XFS or
Reiser FS on Linux, and we require as much of a commitment as possible
that SGI will continue to actively support Linux XFS into the future.
Unfortunately, whilst XFS is a superior journalling FS for Linux, its
development has not yet been very actively worked on by people other
than SGI employees, so its usefulness could be affected by any SGI cuts
in open source development (which would be a great shame).

Please give me some good news or positive response so I can re-assure a
few people I know. :-)  Anyway, fantastic work on getting 1.0 out. I've
heard only good things and plan to test it in the next week...

Best Regards and TIA,


DS..


From owner-linux-xfs@oss.sgi.com Thu May 10 15:41:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4AMfti18181
	for linux-xfs-outgoing; Thu, 10 May 2001 15:41:55 -0700
Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4AMfXF18176
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 15:41:50 -0700
Received: by bobas.nowytarg.top.pl with BSMTP id <S189058AbREJWgK>;
	Fri, 11 May 2001 00:36:10 +0200
Received: by witch.underley.eu.org id <S5297735AbREJWcF>;
	Fri, 11 May 2001 00:32:05 +0200
Date:   Fri, 11 May 2001 00:32:05 +0200
From: Daniel Podlejski <underley@underley.eu.org>
To: linux-xfs@oss.sgi.com
Subject: What is ugly in xfs code ?
Message-ID: <20010511003205.A28141@witch.underley.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9  66 AD F6 EA C9 17 CD 82
X-GPG-Fingerprint: 299F 1820 582B 283A 5F50  37D9 AA0B 6E10 03D4 EA5D
X-Homepage: http://www.underley.eu.org/
X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I think, that includes should be in include/linux or
include/linux/xfs directory. Current location is incompatible
with rest of kernel source tree. There is any problem to keep
this kernel source policy ?

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... Runaway train never going back
   Wrong way on a one way track ...

From owner-linux-xfs@oss.sgi.com Thu May 10 16:13:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANDrA18908
	for linux-xfs-outgoing; Thu, 10 May 2001 16:13:53 -0700
Received: from mgw01.swol.de (mgw01.swol.de [195.238.142.134])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ANDqF18903
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:13:52 -0700
Received: (qmail 5846 invoked from network); 11 May 2001 00:50:23 -0000
Received: from stut15.swol.de (HELO swol.de) (195.238.130.143)
  by mgw01.swol.de with SMTP; 11 May 2001 00:50:23 -0000
Message-ID: <3AFB04B2.D4F75523@swol.de>
Date: Thu, 10 May 2001 23:14:27 +0200
From: "a. heidenreich" <heid.a@swol.de>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3-XFS i586)
X-Accept-Language: de, en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: xfs 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

it seems to me that using the same external logdevice for two different
xfs filesystems doesn't work! are there any restrictions? (sorry, i
don't find anything in your man pages or online papers)

thx in advance.

andre



From owner-linux-xfs@oss.sgi.com Thu May 10 16:21:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANLHA19093
	for linux-xfs-outgoing; Thu, 10 May 2001 16:21:17 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ANL8F19088
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:21:09 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1213762
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 01:21:03 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA14106; Thu, 10 May 2001 18:19:47 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4ANIle05491;
	Thu, 10 May 2001 19:18:47 -0400
Message-ID: <3AFB21D6.ABDFF2FC@thebarn.com>
Date: Thu, 10 May 2001 19:18:46 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Daniel Podlejski <underley@underley.eu.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: What is ugly in xfs code ?
References: <20010511003205.A28141@witch.underley.eu.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Daniel Podlejski wrote:

> I think, that includes should be in include/linux or
> include/linux/xfs directory. Current location is incompatible
> with rest of kernel source tree. There is any problem to keep
> this kernel source policy ?

Maybe you could be a bit more specific about which include files  you
are referring to?
XFS already adds a dozen or so files to include/linux.

Note much of the code structure in fs/xfs is keep intentionally similar
to the irix
code base so the  merges from the irix tree isn't a complete brain
bender.


>

>
>
> --
> Daniel Podlejski <underley@underley.eu.org>
>    ... Runaway train never going back
>    Wrong way on a one way track ...

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May 10 16:23:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANN0Y19189
	for linux-xfs-outgoing; Thu, 10 May 2001 16:23:00 -0700
Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ANMsF19182
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:22:58 -0700
Received: from fosi (203-79-83-162.cable.paradise.net.nz [203.79.83.162])
	by deborah.paradise.net.nz (Postfix) with SMTP id CC3301FA225
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:22:51 +1200 (NZST)
From: "Steve Wray" <steve.wray@the.net.nz>
To: <linux-xfs@oss.sgi.com>
Subject: clean install of sgi/xfs/redhat 7.1 and rernel mods won't compile
Date: Fri, 11 May 2001 11:19:41 +1200
Message-ID: <NBBBKLKHMJHIJLHOGAOJEEJEIOAA.steve.wray@the.net.nz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok,
After installing from the SGI CD (from the image I d/l'd),
and making sure I'd picked the "kernel development"
packages,
make xconfig, selecting options, quit and save,
then make dep clean bzImage modules
gets to modules and chokes on:

(NOTE: I did not edit the toplevel Makefile or *anything*; this is
out of the box and by the book (as near as I can tell).

cd /usr/src/linux/
make modules
make -C  kernel CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall
- -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
- -Wno-unused -pipe  -march=i586 -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/linux-2.4.2/kernel'
make[1]: Nothing to be done for `modules'.
make[1]: Leaving directory `/usr/src/linux-2.4.2/kernel'
make -C  drivers CFLAGS="-D__KERNEL__ -I/usr/src/linux/include -Wall
- -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
- -Wno-unused -pipe  -march=i586 -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h" MAKING_MODULES=1 modules
make[1]: Entering directory `/usr/src/linux-2.4.2/drivers'
make -C block modules
make[2]: Entering directory `/usr/src/linux-2.4.2/drivers/block'
kgcc  -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes
- -O2 -fomit-frame-pointer -fno-strict-aliasing -Wno-unused -pipe 
- -march=i586 -DMODULE -DMODVERSIONS -include
/usr/src/linux/include/linux/modversions.h   -c -o floppy.o floppy.c
In file included from floppy.c:137:
/usr/src/linux/include/linux/module.h:173: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:173: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:173: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:173: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:173: parse error before
`62dada05'
/usr/src/linux/include/linux/module.h:173:
`inter_module_register_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:173: warning: function
declaration isn't a prototype
/usr/src/linux/include/linux/module.h:174: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:174: missing white space after
number `7a9e845'
/usr/src/linux/include/linux/module.h:174: parse error before
`7a9e845'
/usr/src/linux/include/linux/module.h:174:
`inter_module_unregister_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:174: warning: function
declaration isn't a prototype
/usr/src/linux/include/linux/module.h:175:
`inter_module_get_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:175: warning: parameter names
(without types) in function declaration
/usr/src/linux/include/linux/module.h:176:
`inter_module_get_request_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:176: warning: parameter names
(without types) in function declaration
/usr/src/linux/include/linux/module.h:177: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:177: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:177: nondigits in number and
not hexadecimal
/usr/src/linux/include/linux/module.h:177: parse error before
`6b99f7d8'
/usr/src/linux/include/linux/module.h:177:
`inter_module_put_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:177: warning: function
declaration isn't a prototype
/usr/src/linux/include/linux/module.h:186:
`try_inc_mod_count_R_ver_str' declared as function returning a
function
/usr/src/linux/include/linux/module.h:186: warning: parameter names
(without types) in function declaration
make[2]: *** [floppy.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.2/drivers/block'
make[1]: *** [_modsubdir_block] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.2/drivers'
make: *** [_mod_drivers] Error 2

Compilation exited abnormally with code 2 at Fri May 11 11:18:42

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA+AwUBOvsiDAhKySqSS+rVEQL3HwCXYtvO92jj13vZc03bvreGXRZ8RQCgzDhJ
3Ch+UeMWshOJr2WWihtE1Gc=
=oZHo
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Thu May 10 16:29:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANTAP19310
	for linux-xfs-outgoing; Thu, 10 May 2001 16:29:10 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ANT9F19307
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:29:09 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4ANT2u13648;
	Thu, 10 May 2001 18:29:02 -0500 (CDT)
Message-ID: <3AFB24D0.E2538BC9@sgi.com>
Date: Thu, 10 May 2001 18:31:28 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Wray <steve.wray@the.net.nz>
CC: linux-xfs@oss.sgi.com
Subject: Re: clean install of sgi/xfs/redhat 7.1 and rernel mods won't compile
References: <NBBBKLKHMJHIJLHOGAOJEEJEIOAA.steve.wray@the.net.nz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hard to believe, I know, but I think this is inherited from some Red Hat
strangeness.  There was a similar thread on the Seawolf list.  RH had a
reason for shipping the kernel source tree in it's current state, but I
didn't quite grasp it.  :)

Try a "make mrproper" first, and all should be well...

-Eric

Steve Wray wrote:
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ok,
> After installing from the SGI CD (from the image I d/l'd),
> and making sure I'd picked the "kernel development"
> packages,
> make xconfig, selecting options, quit and save,
> then make dep clean bzImage modules
> gets to modules and chokes on:
> 
> (NOTE: I did not edit the toplevel Makefile or *anything*; this is
> out of the box and by the book (as near as I can tell).
--END PGP SIGNATURE-----

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 10 16:33:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANXN019377
	for linux-xfs-outgoing; Thu, 10 May 2001 16:33:23 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ANXMF19374
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:33:22 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA00607
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:33:15 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA29475; Thu, 10 May 2001 18:32:00 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4ANUxe05517;
	Thu, 10 May 2001 19:30:59 -0400
Message-ID: <3AFB24B2.FDAEAF95@thebarn.com>
Date: Thu, 10 May 2001 19:30:58 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IFIX Computer Solutions <dsainty@zip.com.au>
CC: linux-xfs@oss.sgi.com
Subject: Re: Long Term Commitment to Linux XFS,
References: <Pine.LNX.4.30.0105110752470.18660-100000@zipperii.zip.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

IFIX Computer Solutions wrote:

> Hi,
>

Not sure what rumor mill you are listening to but I'm sure as all rumors
they
are mostly wild speculation. We have had no indications of the plug being
pulled on XFS in terms of an open source project.

Will it would be impossible and inappropriate for me to comment on what
upper management will decide as far as funding for open source projects. in
the future ,
bug what is clear is that SGI is committed and relying linux for their ia64
based machines.

Which means XFS will be alive and kicking  on linux for as long as ia64
lives as SGI.

I wouldn't worry about XFS not having being supported in the future, I
would say that
even for some very obscure reason SGI drops the ball, somebody will
recognize the
value of XFS and pick it up.



>
> I've heard some bad rumours about SGI's possible long term commitment to
> XFS on Linux....  Do you have any sort of statement or position with
> respect to the commitment to support Linux XFS into the future?
>
> My colleagues and I are currently evaluating the use of either XFS or
> Reiser FS on Linux, and we require as much of a commitment as possible
> that SGI will continue to actively support Linux XFS into the future.
> Unfortunately, whilst XFS is a superior journalling FS for Linux, its
> development has not yet been very actively worked on by people other
> than SGI employees, so its usefulness could be affected by any SGI cuts
> in open source development (which would be a great shame).
>
> Please give me some good news or positive response so I can re-assure a
> few people I know. :-)  Anyway, fantastic work on getting 1.0 out. I've
> heard only good things and plan to test it in the next week...
>
> Best Regards and TIA,
>
> DS..

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May 10 16:39:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ANdGP19481
	for linux-xfs-outgoing; Thu, 10 May 2001 16:39:16 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ANdEF19478
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 16:39:14 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 14y01O-00065Z-00; Fri, 11 May 2001 11:39:02 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Russell Cattelan" <cattelan@thebarn.com>,
   "IFIX Computer Solutions" <dsainty@zip.com.au>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Long Term Commitment to Linux XFS,
Date: Fri, 11 May 2001 11:38:33 +1200
Message-ID: <KPECIILENDDLPCNIMLOFCEBCCEAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <3AFB24B2.FDAEAF95@thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Adding to that, if the commitment I've seen from XFS developers like Russell
and Eric is anything to go by, the future looks assured to me... :-)

-- Juha

:: -----Original Message-----
:: From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On
:: Behalf Of Russell Cattelan
:: Sent: Friday, 11 May 2001 11:31
:: To: IFIX Computer Solutions
:: Cc: linux-xfs@oss.sgi.com
:: Subject: Re: Long Term Commitment to Linux XFS,
::
::
:: IFIX Computer Solutions wrote:
::
:: > Hi,
:: >
::
:: Not sure what rumor mill you are listening to but I'm sure as all rumors
:: they
:: are mostly wild speculation. We have had no indications of the plug being
:: pulled on XFS in terms of an open source project.
::
:: Will it would be impossible and inappropriate for me to comment on what
:: upper management will decide as far as funding for open source
:: projects. in
:: the future ,
:: bug what is clear is that SGI is committed and relying linux for
:: their ia64
:: based machines.
::
:: Which means XFS will be alive and kicking  on linux for as long as ia64
:: lives as SGI.
::
:: I wouldn't worry about XFS not having being supported in the future, I
:: would say that
:: even for some very obscure reason SGI drops the ball, somebody will
:: recognize the
:: value of XFS and pick it up.
::
::
::


From owner-linux-xfs@oss.sgi.com Thu May 10 17:28:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B0S9W20713
	for linux-xfs-outgoing; Thu, 10 May 2001 17:28:09 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B0S9F20710
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:28:09 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA03486
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:39:00 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA69472 for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:31:48 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 991A615A216
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:26:53 -0700 (PDT)
Subject: RE: Benchmark
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <6DEE94132593D41182D200508BDCA59045F6AE@mail.tricord.com>
References: <6DEE94132593D41182D200508BDCA59045F6AE@mail.tricord.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 10 May 2001 17:26:53 -0700
Message-Id: <989540813.3070.4.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 10 May 2001 07:32:56 -0500, Mostek, Jim wrote:
> 
> and XFS was faster for everything except the delete of a tar tree (which we
> expect
> because of the sync transaction on remove, right?).

Oh, BTW, can someone detail on this, please?

I saw that XFS is slow when erasing huge file trees (for ex.: when
emptying a Squid cache :-) ). Why is it so?
I'm not saying it's a bug, i'm just asking why...

-- 
Florin Andrei

"Imagine working in a secure environment and finding the string
_NSAKEY in the OS binaries without a good explanation." - Alan Cox


From owner-linux-xfs@oss.sgi.com Thu May 10 17:29:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B0Th320753
	for linux-xfs-outgoing; Thu, 10 May 2001 17:29:43 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B0TgF20749
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:29:42 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id RAA09594
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 17:29:35 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19474; Fri, 11 May 2001 10:28:16 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA79537;
	Fri, 11 May 2001 10:28:15 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105111028.ZM79068@wobbly.melbourne.sgi.com>
Date: Fri, 11 May 2001 10:28:13 -0500
In-Reply-To: "a. heidenreich" <heid.a@swol.de>
        "xfs" (May 10, 11:14pm)
References: <3AFB04B2.D4F75523@swol.de>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "a. heidenreich" <heid.a@swol.de>, linux-xfs@oss.sgi.com
Subject: Re: xfs
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 10, 11:14pm, a. heidenreich wrote:
> Subject: xfs
> hi,
> 
> it seems to me that using the same external logdevice for two different
> xfs filesystems doesn't work! are there any restrictions? (sorry, i
> don't find anything in your man pages or online papers)
> 

By design you cannot have two filesystems sharing the
same log device.

The xfs(5) man page has an explanation on what each of
the different sections of an XFS filesystem are for...

  The log section (or area, if it is internal  to  the  data
  section)  is  used to store changes to filesystem metadata
  while the filesystem is running until  those  changes  are
  made to the data section.  It is written sequentially dur-
  ing normal operation and read  only  during  mount.   When
  mounting  a  filesystem  after a crash, the log is read to
  complete operations that were in progress at the  time  of
  the crash.


cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May 10 18:45:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B1jef22368
	for linux-xfs-outgoing; Thu, 10 May 2001 18:45:40 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B1jdF22365
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 18:45:39 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA02051
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 18:56:29 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20346; Fri, 11 May 2001 11:44:15 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA60562;
	Fri, 11 May 2001 11:44:13 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105111144.ZM79481@wobbly.melbourne.sgi.com>
Date: Fri, 11 May 2001 11:44:11 -0500
In-Reply-To: marchuk@ee.washington.edu
        "Re: XFS 1.0/Quota" (May 10,  9:11am)
References: <Pine.LNX.4.21.0105100906050.17385-100000@darkstar.ee.washington.edu>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: marchuk@ee.washington.edu
Subject: Re: XFS 1.0/Quota
Cc: Fermin Molina <fermin@eup.udl.es>, linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi there,

On May 10,  9:11am, marchuk@ee.washington.edu wrote:
> Subject: Re: XFS 1.0/Quota
> I've recompiled kernel, this time making sure XFS quota is selected.  When
> the machine starts up it does say "XFS doing quotacheck.. Please wait."  I

Well, at least we know for sure quota are enabled now. ;-)

> wait 5 minutes or so and then the machine freezes (by freezing I mean no
> more hard drive activity and machine does not respond).  
> 
> I booted into a single user mode.  did a mount -a, got the "doing
> quotacheck... Please wait."  After awhile I get a funny error "Run out of
> memory.. Cancelling processs (sh)"  The error is not in exact words but
> something like that.  
> 

Can you capture some output & send to me (offlist, it'll
probably amount to alot of data):

- cat /proc/meminfo
- "quot -ug" on the filesystem (mounted without quota
option(s) obviously);
- xqmstats, before & during the quotacheck if possible;
- cat /proc/slabinfo, also before & during if possible;

Also, are you enabling both user and group quota on this
filesystem?  That would likely increase the dquot memory
pressure - still shouldn't fail, but could try just one
or the other & see if that helps (or one at a time might
work as a temporary workaround, to reduce the number of
incore dquots required during quotacheck).

> The machine has 256MB memory with 658MB disk cache. The xfs filesystem is
> a hardware raid with 8 disks totalling 350MB.  Does anyone have experience
           
That doesn't sound right - did you mean 350GB?  During a
quotacheck its shouldn't be the size of the filesystem
that matters, but the number of unique uids/gids in use,
as each of these must map to a unique incore dquot (hmm -
which has just tickled a distant memory & I may know what
the problem is... I need to think about it a bit though,
and I'll need to see your data from above to confirm).

> running xfs on large partitions?  
> 

This is largely based on the IRIX/XFS quota implementation,
so I'd imagine something has been lost in the translation to
Linux (my bad).  IRIX quota works with enormous filesystems,
so large should be easy.  :^)

thanks.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Thu May 10 18:58:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B1wCC22593
	for linux-xfs-outgoing; Thu, 10 May 2001 18:58:12 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B1wAF22590
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 18:58:10 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA1216519
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 03:58:07 +0200 (CEST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20450; Fri, 11 May 2001 11:56:47 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Steve Wray" <steve.wray@the.net.nz>
cc: linux-xfs@oss.sgi.com
Subject: Re: clean install of sgi/xfs/redhat 7.1 and rernel mods won't compile 
In-reply-to: Your message of "Fri, 11 May 2001 11:19:41 +1200."
             <NBBBKLKHMJHIJLHOGAOJEEJEIOAA.steve.wray@the.net.nz> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 11 May 2001 11:56:46 +1000
Message-ID: <28805.989546206@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 11 May 2001 11:19:41 +1200, 
"Steve Wray" <steve.wray@the.net.nz> wrote:
>make xconfig, selecting options, quit and save,
>then make dep clean bzImage modules
>gets to modules and chokes on:
>/usr/src/linux/include/linux/modversions.h   -c -o floppy.o floppy.c

Broken kernel Makefile system.  http://www.tux.org/lkml/#s8-8

This is not an XFS problem, it is a generic kernel build problem.
Which is why the entire kernel build system will be redesigned in 2.5.


From owner-linux-xfs@oss.sgi.com Thu May 10 19:26:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B2QMo23107
	for linux-xfs-outgoing; Thu, 10 May 2001 19:26:22 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B2QJF23101
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 19:26:19 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA1225556
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 04:26:17 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA1747171; Thu, 10 May 2001 21:24:59 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA99606; Thu, 10 May 2001 21:24:59 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4B2Rtl11780; Thu, 10 May 2001 21:27:55 -0500
Message-Id: <200105110227.f4B2Rtl11780@jen.americas.sgi.com>
To: IFIX Computer Solutions <dsainty@zip.com.au>
cc: linux-xfs@oss.sgi.com
Subject: Re: Long Term Commitment to Linux XFS, 
References: <Pine.LNX.4.30.0105110752470.18660-100000@zipperii.zip.com.au>
Comments: In-reply-to IFIX Computer Solutions <dsainty@zip.com.au>
   message dated "Fri, 11 May 2001 08:34:44 +1000."
Date: Thu, 10 May 2001 21:27:55 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> I've heard some bad rumours about SGI's possible long term commitment to
> XFS on Linux....  Do you have any sort of statement or position with
> respect to the commitment to support Linux XFS into the future?
> 
> My colleagues and I are currently evaluating the use of either XFS or
> Reiser FS on Linux, and we require as much of a commitment as possible
> that SGI will continue to actively support Linux XFS into the future.
> Unfortunately, whilst XFS is a superior journalling FS for Linux, its
> development has not yet been very actively worked on by people other
> than SGI employees, so its usefulness could be affected by any SGI cuts
> in open source development (which would be a great shame).
> 
> Please give me some good news or positive response so I can re-assure a
> few people I know. :-)  Anyway, fantastic work on getting 1.0 out. I've
> heard only good things and plan to test it in the next week...
> 
> Best Regards and TIA,
> 
> 
> DS..

Three answers to this, one of which has already been mentioned:

	SN-IA64 (Itaniam based cpus in an O3000 architecture box) running
	linux. We need XFS on linux for this for customer filesystem 
	migration.

	CXFS - distributed filesystem running on top of XFS, we need
	a Linux version of this for the above reason and more.

	I personally have been using Linux since 0.97 and I am not going
	to stop even if SGI goes down the tubes.

So don't listen to everything you hear.

Steve


From owner-linux-xfs@oss.sgi.com Thu May 10 20:21:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B3LS324182
	for linux-xfs-outgoing; Thu, 10 May 2001 20:21:28 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B3LMF24179
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 20:21:22 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id UAA00316
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 20:21:19 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA21110; Fri, 11 May 2001 13:19:43 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "James Lyon" <james@ly0n.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Broken kernel-2.4.2-SGI_XFS_1.0.i686.rpm pakage 
In-reply-to: Your message of "Thu, 10 May 2001 20:25:24 +0100."
             <000a01c0d987$0cc19740$0300000a@jupiter> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 11 May 2001 13:19:43 +1000
Message-ID: <1509.989551183@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 10 May 2001 20:25:24 +0100, 
"James Lyon" <james@ly0n.com> wrote:
>I have just downloaded the RedHat 7.1 XFS kernel RPM
>(kernel-2.4.2-SGI_XFS_1.0.i686.rpm). I installed the kernel with rpm -Uvh,
>reran lilo and rebooted.
>
>None of the kernel modules would load, and depmod complained of missing
>kernel symbols. I examined /proc/ksyms and it seems that all of the missing
>kernel symbols do exist but have a different version number on the end.

Probably user error, I just installed that rpm and it boots fine.  You
either booted the wrong kernel or you are using modules from an old
kernel.  Are you pointing lilo at an initrd, this rpm does not use
initrd?



From owner-linux-xfs@oss.sgi.com Thu May 10 21:34:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B4YiB25275
	for linux-xfs-outgoing; Thu, 10 May 2001 21:34:44 -0700
Received: from dashka.gaz.ru (ns.gaz.ru [195.122.229.69])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4B4YgF25272
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 21:34:43 -0700
Received: from gaz.ru (unverified [192.168.61.220]) by dashka.gaz.ru
 (EMWAC SMTPRS 0.83) with SMTP id <B0000955786@dashka.gaz.ru>;
 Fri, 11 May 2001 08:35:05 +0400
Message-ID: <3AFB6D39.985F8E6C@gaz.ru>
Date: Fri, 11 May 2001 08:40:25 +0400
From: =?koi8-r?Q?C=C5=D2=C7=C5=CA=20=EB=D5=DA=CF=D7=CB=CF=D7?= 
	<sergeyk@gaz.ru>
Organization: N.Novgorod Linux Team
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: ru
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Patch for kern 2.2.x (actually for 2.2.19)
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Where %subject%? Kernel 2.4.x is wasted,
why you develop XFS for this?
Kernel 2.2.19 is stable and it worked 
really. 

With best regards,
Sergey Kuzovkov.

P.S. Sorry for my bad English - it's
no my native language (I'm Russian).

From owner-linux-xfs@oss.sgi.com Thu May 10 21:42:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B4gMj25414
	for linux-xfs-outgoing; Thu, 10 May 2001 21:42:22 -0700
Received: from deborah.paradise.net.nz (deborah.paradise.net.nz [203.96.152.32])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B4gLF25411
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 21:42:21 -0700
Received: from fosi (203-79-83-162.cable.paradise.net.nz [203.79.83.162])
	by deborah.paradise.net.nz (Postfix) with SMTP
	id BF3271FA321; Fri, 11 May 2001 16:42:17 +1200 (NZST)
From: "Steve Wray" <steve.wray@the.net.nz>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: clean install of sgi/xfs/redhat 7.1 and rernel mods won't compile
Date: Fri, 11 May 2001 16:39:07 +1200
Message-ID: <NBBBKLKHMJHIJLHOGAOJEEJGIOAA.steve.wray@the.net.nz>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3AFB24D0.E2538BC9@sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Well make mrproper worked!
I can't imagine why redhat (or anyone else, except maybe microsoft)
would distribute kernel sourcecode that won't compile out of the box!





From owner-linux-xfs@oss.sgi.com Thu May 10 22:59:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B5x7K27043
	for linux-xfs-outgoing; Thu, 10 May 2001 22:59:07 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B5x6F27039
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 22:59:06 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id WAA05429
	for <linux-xfs@oss.sgi.com>; Thu, 10 May 2001 22:59:05 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id WAA56593;
	Thu, 10 May 2001 22:57:48 -0700 (PDT)
Date: Thu, 10 May 2001 22:57:13 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: =?koi8-r?Q?C=C5=D2=C7=C5=CA=20=EB=D5=DA=CF=D7=CB=CF=D7?= <sergeyk@gaz.ru>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Patch for kern 2.2.x (actually for 2.2.19)
In-Reply-To: <3AFB6D39.985F8E6C@gaz.ru>
Message-ID: <Pine.LNX.4.33.0105102256370.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

there is no 2.2.x xfs kernel patch nor is there plans to produce on...only
patches for 2.4.x kernels.

sorry.

-tduffy

On Fri, 11 May 2001, [koi8-r] CÅÒÇÅÊ ëÕÚÏ×ËÏ× wrote:

> Where %subject%? Kernel 2.4.x is wasted,
> why you develop XFS for this?
> Kernel 2.2.19 is stable and it worked
> really.
>
> With best regards,
> Sergey Kuzovkov.
>
> P.S. Sorry for my bad English - it's
> no my native language (I'm Russian).
>


From owner-linux-xfs@oss.sgi.com Fri May 11 01:26:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B8QCB30856
	for linux-xfs-outgoing; Fri, 11 May 2001 01:26:12 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B8QAF30852
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 01:26:10 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id KAA1291810;
	Fri, 11 May 2001 10:26:07 +0200
Message-Id: <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 11 May 2001 10:26:06 +0200
To: Hasch@t-online.de (Juergen Hasch)
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: fileutils patches?
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3AFB0529.BFCF0FE@t-online.de>
References: <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

I tried to do it this way.

fileutils-4.1:

xdelta patch fileutils+acl-4.1-0.7.12.xdelta fileutils-4.1.tar.gz
fileutils+acl-4.1-0.7.12.tar.gz
Then I added your code to permissions.c
./configure
changed src/Makefile and config.h

I got these errors when doing "make":

/usr/bin/ld: cannot find -lacl
collect2: ld returned 1 exit status

What's the meaning of lacl?

Thanks alot for your reply,

Wenrer Maes

At 23:16 10/05/2001 +0200, Juergen Hasch wrote:
>
>werner maes schrieb:
>> 
>> 
>>         Hello,
>> 
>> I installed XFS using the RH 7.1 installer.
>> I tried working with acl and this works but I was wondering where
>> I can find the patch to enable the fileutils commands (ls, rm, mv, cp,...)
>> to recognize ACL's.
>> In the ISO for RH 7.1 there's a special kernel and the xfsprogs but I can't
>> seem to find these patched fileutils.
>> 
>> Does somebody has more information?
>
>I am using patched fileutils with XFS. You can use the patch from
>acl.bestbits.at
>together with fileutils-4.0.43, but you will need to add a few lines to
>permission.c
>because the XFS implementation doesn't match the one from Andreas
>Gruenbacher
>(see patch below).
>
>The autoconf stuff is broken for most versions right now, so you have to
>do some hand editing after configure.
>In config.h add:
>#define USE_ACL 1
>#define HAVE_ACL 1
>#define HAVE_ACL_GET_FILE 1
>#define HAVE_ACL_TO_TEXT 1
>#define HAVE_ACL_FREE 1
>#define HAVE_ACL_SET_FILE 1
>
>In src/Makefile add -lacl in the LIBS line:
>LIBS = -lacl
>
>This works for me.
>  ...Juergen
>
>--- permissions.orig	Thu May 10 22:24:35 2001
>+++ permissions.c	Thu May 10 22:34:27 2001
>@@ -32,6 +32,11 @@
> # define ENOTSUP ENOSYS
> #endif
> 
> #ifndef errno
> extern int errno;
> #endif
>@@ -288,7 +293,7 @@
> 
>   if ((acl = acl_get_file(path, ACL_TYPE_ACCESS)) == NULL)
>     {
>-      if (errno == ENOSYS || errno == ENOTSUP)
>+      if (errno == EINVAL || errno == ENOSYS || errno == ENOTSUP)
>         {
>           return 0;
>         }
>@@ -298,6 +303,10 @@
>           return -1;
>         }
>    }
>+
>+  if (acl->acl_cnt == ACL_NOT_PRESENT) /* XFS */
>+	return 0;
>+
>   return_val = count_acl_entries(acl);
>   acl_free(acl);
>   if (return_val < 0)
>@@ -323,6 +332,9 @@
> 	      return -1;
> 	    }
> 	}
>+    if (acl->acl_cnt == ACL_NOT_PRESENT) /* XFS */
>+	return 0;
>+
>       return_val = count_acl_entries(acl);
>       acl_free(acl);
>       if (return_val < 0)
>


From owner-linux-xfs@oss.sgi.com Fri May 11 02:13:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4B9Due31964
	for linux-xfs-outgoing; Fri, 11 May 2001 02:13:56 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4B9DrF31960
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 02:13:53 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id CAA19633
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 02:12:27 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA23260; Fri, 11 May 2001 19:12:29 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA80513;
	Fri, 11 May 2001 19:12:27 +1000 (EST)
Date: Fri, 11 May 2001 19:12:27 +1000
From: Nathan Scott <nathans@sgi.com>
To: werner maes <werner.maes@cc.kuleuven.ac.be>
Cc: linux-xfs@oss.sgi.com
Subject: Re: fileutils patches?
Message-ID: <20010511191226.A74933@wobbly.melbourne.sgi.com>
References: <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be> <3AFB0529.BFCF0FE@t-online.de> <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be>; from werner.maes@cc.kuleuven.ac.be on Fri, May 11, 2001 at 10:26:06AM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On Fri, May 11, 2001 at 10:26:06AM +0200, werner maes wrote:
> Hello,
> 
> I tried to do it this way.
> 
> fileutils-4.1:
> 
> xdelta patch fileutils+acl-4.1-0.7.12.xdelta fileutils-4.1.tar.gz
> fileutils+acl-4.1-0.7.12.tar.gz
> Then I added your code to permissions.c
> ./configure
> changed src/Makefile and config.h
> 
> I got these errors when doing "make":
> 
> /usr/bin/ld: cannot find -lacl
> collect2: ld returned 1 exit status
> 
> What's the meaning of lacl?
> 

It means "link with libacl" - you'll need to install the acl-devel
package which has /usr/lib/libacl.a.

cheers.

From owner-linux-xfs@oss.sgi.com Fri May 11 03:21:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BALiB01047
	for linux-xfs-outgoing; Fri, 11 May 2001 03:21:44 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BALgF01044
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 03:21:42 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4BALbL22023
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 18:21:37 +0800
Received: from kalapati ([203.167.1.156]) by sisa.i-manila.com.ph ; Fri, 11 May 2001 18:21:43 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id C78091D55
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 18:21:31 +0800 (PHT)
Date: Fri, 11 May 2001 18:21:31 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Benchmark
In-Reply-To: <989540813.3070.4.camel@stantz.corp.sgi.com>
Message-ID: <Pine.LNX.4.21.0105111820370.2957-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 10 May 2001 at 17:26, Florin Andrei wrote:
> I saw that XFS is slow when erasing huge file trees (for ex.: when
> emptying a Squid cache :-) ). Why is it so? I'm not saying it's a bug,
> i'm just asking why...

I'm not an expert on XFS, but I do recall someone on the list posting a
message recently saying that it had something to do with the fact that XFS
does synchronous file deletions, hence the speed issue.

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Fri May 11 03:29:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BATgV01129
	for linux-xfs-outgoing; Fri, 11 May 2001 03:29:42 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BATfF01126
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 03:29:41 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id MAA55570;
	Fri, 11 May 2001 12:29:36 +0200
Message-Id: <3.0.6.32.20010511122935.00818b10@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 11 May 2001 12:29:35 +0200
To: Nathan Scott <nathans@sgi.com>
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: fileutils patches?
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010511191226.A74933@wobbly.melbourne.sgi.com>
References: <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be>
 <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be>
 <3AFB0529.BFCF0FE@t-online.de>
 <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I see, but there's a catch. I installed XFS and they (sgi) provided an adapted
kernel with the kernel patches for ACL support included.

With this kernel source the compilation of the ACL-library does not seem to
work.
I tried (in /usr/src/acl-0.7.10):  KERNEL_SOURCE=/usr/src/linux-2.4.2
./configure

with this result:

Checking for kernel headers in `/usr/src/linux-2.4.2/include'
checking for /usr/src/linux-2.4.2/include/linux/ext_attr.h... no
checking for /usr/src/linux-2.4.2/include/linux/acl_ea.h... no
checking for msgfmt... msgfmt

Please specify the location of the patched linux kernel sources:

        KERNEL_SOURCE=<path> ./configure

So it seems that there is no ext_attr.h file in this patched kernel from SGI.
Or am I getting too confused??

Any ideas,

Werner Maes

At 19:12 11/05/2001 +1000, Nathan Scott wrote:
>hi,
>
>On Fri, May 11, 2001 at 10:26:06AM +0200, werner maes wrote:
>> Hello,
>> 
>> I tried to do it this way.
>> 
>> fileutils-4.1:
>> 
>> xdelta patch fileutils+acl-4.1-0.7.12.xdelta fileutils-4.1.tar.gz
>> fileutils+acl-4.1-0.7.12.tar.gz
>> Then I added your code to permissions.c
>> ./configure
>> changed src/Makefile and config.h
>> 
>> I got these errors when doing "make":
>> 
>> /usr/bin/ld: cannot find -lacl
>> collect2: ld returned 1 exit status
>> 
>> What's the meaning of lacl?
>> 
>
>It means "link with libacl" - you'll need to install the acl-devel
>package which has /usr/lib/libacl.a.
>
>cheers.
>


From owner-linux-xfs@oss.sgi.com Fri May 11 03:37:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BAbCi01269
	for linux-xfs-outgoing; Fri, 11 May 2001 03:37:12 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BAbBF01266
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 03:37:11 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP id 8F93D1E22A
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:30:01 +0200 (MEST)
Date: Fri, 11 May 2001 12:29:45 +0200
From: Andi Kleen <ak@suse.de>
To: linux-xfs@oss.sgi.com
Subject: xfsdump safe?
Message-ID: <20010511122945.A5907@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Regarding xfsdump:

The qlock functions seem to be dummied out (inside #ifdef HIDDEN), but
it still seems to create threads in some circumstances, which probably need
locking. Is it really safe to use? 

-Andi

From owner-linux-xfs@oss.sgi.com Fri May 11 05:33:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BCX6W03604
	for linux-xfs-outgoing; Fri, 11 May 2001 05:33:06 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BCX5F03601
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 05:33:05 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id FAA01289
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 05:43:56 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA24071; Fri, 11 May 2001 22:31:46 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id WAA46122;
	Fri, 11 May 2001 22:31:46 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Fri, 11 May 2001 22:31:46 +1000
To: Andi Kleen <ak@suse.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump safe?
In-Reply-To: <20010511122945.A5907@gruyere.muc.suse.de>
Message-ID: <Pine.SGI.4.32.0105112222550.48503-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 11 May 2001, Andi Kleen wrote:

> Regarding xfsdump:
>
> The qlock functions seem to be dummied out (inside #ifdef HIDDEN), but
> it still seems to create threads in some circumstances, which probably need
> locking. Is it really safe to use?

I think you'll find that the linux version of xfsdump runs in single
threaded mode.  This is controlled by the 'miniroot' flag which is set to
true on Linux - the key bits are around line 604 in cmd/xfsdump/common/main.c.


Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com


From owner-linux-xfs@oss.sgi.com Fri May 11 05:55:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BCt6203954
	for linux-xfs-outgoing; Fri, 11 May 2001 05:55:06 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BCt4F03951
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 05:55:04 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 741E41E20F; Fri, 11 May 2001 14:55:03 +0200 (MEST)
Date: Fri, 11 May 2001 14:54:53 +0200
From: Andi Kleen <ak@suse.de>
To: Ivan Rayner <ivanr@melbourne.sgi.com>
Cc: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: xfsdump safe?
Message-ID: <20010511145453.A10184@gruyere.muc.suse.de>
References: <20010511122945.A5907@gruyere.muc.suse.de> <Pine.SGI.4.32.0105112222550.48503-100000@omen.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.SGI.4.32.0105112222550.48503-100000@omen.melbourne.sgi.com>; from ivanr@melbourne.sgi.com on Fri, May 11, 2001 at 10:31:46PM +1000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 11, 2001 at 10:31:46PM +1000, Ivan Rayner wrote:
> On Fri, 11 May 2001, Andi Kleen wrote:
> 
> > Regarding xfsdump:
> >
> > The qlock functions seem to be dummied out (inside #ifdef HIDDEN), but
> > it still seems to create threads in some circumstances, which probably need
> > locking. Is it really safe to use?
> 
> I think you'll find that the linux version of xfsdump runs in single
> threaded mode.  This is controlled by the 'miniroot' flag which is set to
> true on Linux - the key bits are around line 604 in cmd/xfsdump/common/main.c.

As far as I can see common/drive_{scsitape,minrmt}.c do not check that 
flag before calling cldmgr_create()


-Andi

From owner-linux-xfs@oss.sgi.com Fri May 11 06:35:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BDZmd04942
	for linux-xfs-outgoing; Fri, 11 May 2001 06:35:48 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BDZlF04939
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 06:35:47 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id PAA48484;
	Fri, 11 May 2001 15:35:44 +0200
Message-Id: <3.0.6.32.20010511153543.007f98e0@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 11 May 2001 15:35:43 +0200
To: Hasch@t-online.de (Juergen Hasch)
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: fileutils patches?
Cc: linux-xfs@oss.sgi.com, nathans@sgi.com
In-Reply-To: <3AFB0529.BFCF0FE@t-online.de>
References: <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sorry to bother you again, but I still have some remarks.

I installed the acl-devel-1.0.1-0.i386.rpm which included the acl library
(/usr/lib/libacl.a)

When compiling I received errors (ACL_TYPE_ACCESS undeclared) that I solved
doing this:

* changes proposed by Juergen Hash
* added "#define HAVE_SYS_ACL_H 1" to config.h
* changed the following in permissions.c and ls.c

I replaced

#if HAVE_SYS_ACL_H
# include <sys/acl.h>

with:

#if HAVE_SYS_ACL_H
# include <acl/acl.h>

Why?
because I only have /usr/include/acl/acl.h (file created by acl-devel.rpm)

==> make
==> make install 
ok

But now I'm wondering how I can find out whether I have fileutils which are
ACL enabled?

from acl.bestbits.at: ls -l' displays a `+' character after the file mode
string for files with an ACL.
I don't see this when I do 'ls -l aclfile'.

Thanks again for your time,

Werner Maes



From owner-linux-xfs@oss.sgi.com Fri May 11 06:37:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BDbRo04994
	for linux-xfs-outgoing; Fri, 11 May 2001 06:37:27 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BDbNF04991
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 06:37:23 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id PAA1239641
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 15:37:13 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA24370; Fri, 11 May 2001 23:35:54 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id XAA80856;
	Fri, 11 May 2001 23:35:53 +1000 (EST)
Date: Fri, 11 May 2001 23:35:52 +1000
From: Nathan Scott <nathans@sgi.com>
To: werner maes <werner.maes@cc.kuleuven.ac.be>
Cc: linux-xfs@oss.sgi.com
Subject: Re: fileutils patches?
Message-ID: <20010511233552.A81087@wobbly.melbourne.sgi.com>
References: <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be> <3.0.6.32.20010510092131.007cc370@mail.cc.kuleuven.ac.be> <3AFB0529.BFCF0FE@t-online.de> <3.0.6.32.20010511102606.0083e3a0@mail.cc.kuleuven.ac.be> <20010511191226.A74933@wobbly.melbourne.sgi.com> <3.0.6.32.20010511122935.00818b10@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <3.0.6.32.20010511122935.00818b10@mail.cc.kuleuven.ac.be>; from werner.maes@cc.kuleuven.ac.be on Fri, May 11, 2001 at 12:29:35PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On Fri, May 11, 2001 at 12:29:35PM +0200, werner maes wrote:
> I see, but there's a catch. I installed XFS and they (sgi) provided an adapted
> kernel with the kernel patches for ACL support included.

yes.  some userspace code is also provided.

> 
> With this kernel source the compilation of the ACL-library does not seem to
> work.
> I tried (in /usr/src/acl-0.7.10):  KERNEL_SOURCE=/usr/src/linux-2.4.2
> ./configure
> 

I think this is the problem - at the moment there are two
versions of libacl, & you're trying to use Andreas' version
here, whereas you need to be using the version that comes
with XFS (in order to use the XFS ACL support).

If you're using the prepackages rpms from sgi, then acl-devel
is the package you'll want to install.  Otherwise, you can get
the code from cmd/acl in the cvs tree, compile & install that.

Once you have the XFS libacl installed, then you can move on
to patching the fileutil code.  At least, I assume this is what
was suggested - I haven't tried the fileutil patch myself.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Fri May 11 07:06:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BE6j405885
	for linux-xfs-outgoing; Fri, 11 May 2001 07:06:45 -0700
Received: from c012.sfo.cp.net (c012-h011.c012.sfo.cp.net [209.228.13.211])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4BE6iF05882
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:06:44 -0700
Received: (cpmta 714 invoked from network); 11 May 2001 07:06:38 -0700
Date: 11 May 2001 07:06:38 -0700
Message-ID: <20010511140638.713.cpmta@c012.sfo.cp.net>
X-Sent: 11 May 2001 14:06:38 GMT
Received: from [195.123.255.250] by mail.altavista.com with HTTP;
    11 May 2001 07:06:38 PDT
Content-Type: multipart/mixed; boundary="----------=_989589998-634-0"
Mime-Version: 1.0
To: linux-xfs@oss.sgi.com
From: Oleg Kodak <olegkodak@altavista.com>
Cc: gfs-devel@sistina.com
X-Mailer: Web Mail 3.9.1.6
Subject: Can I use XFS and GFS simultaneous?
X-Sent-From: olegkodak@altavista.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format...

------------=_989589998-634-0
Content-Type: text/plain
Content-Disposition: inline

 I try to use XFS on the system disk and GFS on the shared disks.
 I have fresh source of GFS (from CVS) and
kernel v244 (from .kernel.org) and
linux-2.4.4-xfs-cvs-05022001.patch (from ftp://oss.sgi.com/projects/xfs/download/patches).

 When I apply GFS kernel patches (patching - OK.
Than I try to apply linux-2.4.4-xfs-cvs-05022001.patch 
and have some rejects:
                      fs.h.rej
                      vmscan.c.rej
                      ksyms.c.rej
(See attachments)

 Could You say me any about this, Please.


                


Find the best deals on the web at AltaVista Shopping!
http://www.shopping.altavista.com

------------=_989589998-634-0
Content-Type: application/octet-stream; name="fs.h.rej"
Content-Disposition: attachment; filename="fs.h.rej"
Content-Transfer-Encoding: base64

KioqKioqKioqKioqKioqCioqKiAyMTMsMjE4ICoqKioKICAjZGVmaW5lIEJI
X01hcHBlZAk0CS8qIDEgaWYgdGhlIGJ1ZmZlciBoYXMgYSBkaXNrIG1hcHBp
bmcgKi8KICAjZGVmaW5lIEJIX05ldwkJNQkvKiAxIGlmIHRoZSBidWZmZXIg
aXMgbmV3IGFuZCBub3QgeWV0IHdyaXR0ZW4gb3V0ICovCiAgI2RlZmluZSBC
SF9Qcm90ZWN0ZWQJNgkvKiAxIGlmIHRoZSBidWZmZXIgaXMgcHJvdGVjdGVk
ICovCiAgCiAgLyoKICAgKiBUcnkgdG8ga2VlcCB0aGUgbW9zdCBjb21tb25s
eSB1c2VkIGZpZWxkcyBpbiBzaW5nbGUgY2FjaGUgbGluZXMgKDE2Ci0tLSAy
MjIsMjI5IC0tLS0KICAjZGVmaW5lIEJIX01hcHBlZAk0CS8qIDEgaWYgdGhl
IGJ1ZmZlciBoYXMgYSBkaXNrIG1hcHBpbmcgKi8KICAjZGVmaW5lIEJIX05l
dwkJNQkvKiAxIGlmIHRoZSBidWZmZXIgaXMgbmV3IGFuZCBub3QgeWV0IHdy
aXR0ZW4gb3V0ICovCiAgI2RlZmluZSBCSF9Qcm90ZWN0ZWQJNgkvKiAxIGlm
IHRoZSBidWZmZXIgaXMgcHJvdGVjdGVkICovCisgI2RlZmluZSBCSF9EZWxh
eQk3CS8qIGRpc2sgbWFwcGluZyBpcyBkZWxheWVkICovCisgCiAgCiAgLyoK
ICAgKiBUcnkgdG8ga2VlcCB0aGUgbW9zdCBjb21tb25seSB1c2VkIGZpZWxk
cyBpbiBzaW5nbGUgY2FjaGUgbGluZXMgKDE2CioqKioqKioqKioqKioqKgoq
KiogMzY5LDM3NCAqKioqCiAgCWludCAoKmNvbW1pdF93cml0ZSkoc3RydWN0
IGZpbGUgKiwgc3RydWN0IHBhZ2UgKiwgdW5zaWduZWQsIHVuc2lnbmVkKTsK
ICAJLyogVW5mb3J0dW5hdGVseSB0aGlzIGtsdWRnZSBpcyBuZWVkZWQgZm9y
IEZJQk1BUC4gRG9uJ3QgdXNlIGl0ICovCiAgCWludCAoKmJtYXApKHN0cnVj
dCBhZGRyZXNzX3NwYWNlICosIGxvbmcpOwogIH07CiAgCiAgc3RydWN0IGFk
ZHJlc3Nfc3BhY2UgewotLS0gMzgyLDM5MSAtLS0tCiAgCWludCAoKmNvbW1p
dF93cml0ZSkoc3RydWN0IGZpbGUgKiwgc3RydWN0IHBhZ2UgKiwgdW5zaWdu
ZWQsIHVuc2lnbmVkKTsKICAJLyogVW5mb3J0dW5hdGVseSB0aGlzIGtsdWRn
ZSBpcyBuZWVkZWQgZm9yIEZJQk1BUC4gRG9uJ3QgdXNlIGl0ICovCiAgCWlu
dCAoKmJtYXApKHN0cnVjdCBhZGRyZXNzX3NwYWNlICosIGxvbmcpOworIAor
IAl2b2lkICgqdG9zc19wYWdlKShzdHJ1Y3QgcGFnZSAqKTsKKyAJaW50ICgq
d3JpdGVwYWdlX25vdW5sb2NrKShzdHJ1Y3QgcGFnZSAqKTsKKyAKICB9Owog
IAogIHN0cnVjdCBhZGRyZXNzX3NwYWNlIHsK

------------=_989589998-634-0
Content-Type: application/octet-stream; name="ksyms.c.rej"
Content-Disposition: attachment; filename="ksyms.c.rej"
Content-Transfer-Encoding: base64

KioqKioqKioqKioqKioqCioqKiAxMTIsMTE3ICoqKioKICBFWFBPUlRfU1lN
Qk9MKF9fdm1hbGxvYyk7CiAgRVhQT1JUX1NZTUJPTChtZW1fbWFwKTsKICBF
WFBPUlRfU1lNQk9MKHJlbWFwX3BhZ2VfcmFuZ2UpOwogIEVYUE9SVF9TWU1C
T0wobWF4X21hcG5yKTsKICBFWFBPUlRfU1lNQk9MKGhpZ2hfbWVtb3J5KTsK
ICBFWFBPUlRfU1lNQk9MKHZtdHJ1bmNhdGUpOwotLS0gMTI2LDEzMiAtLS0t
CiAgRVhQT1JUX1NZTUJPTChfX3ZtYWxsb2MpOwogIEVYUE9SVF9TWU1CT0wo
bWVtX21hcCk7CiAgRVhQT1JUX1NZTUJPTChyZW1hcF9wYWdlX3JhbmdlKTsK
KyBFWFBPUlRfU1lNQk9MKHJlbWFwX3BhZ2VfYXJyYXkpOwogIEVYUE9SVF9T
WU1CT0wobWF4X21hcG5yKTsKICBFWFBPUlRfU1lNQk9MKGhpZ2hfbWVtb3J5
KTsKICBFWFBPUlRfU1lNQk9MKHZtdHJ1bmNhdGUpOwo=

------------=_989589998-634-0
Content-Type: application/octet-stream; name="vmscan.c.rej"
Content-Disposition: attachment; filename="vmscan.c.rej"
Content-Transfer-Encoding: base64

KioqKioqKioqKioqKioqCioqKiA0ODIsNDg4ICoqKioKICAJCQkJZ290byBw
YWdlX2FjdGl2ZTsKICAKICAJCQkvKiBGaXJzdCB0aW1lIHRocm91Z2g/IE1v
dmUgaXQgdG8gdGhlIGJhY2sgb2YgdGhlIGxpc3QgKi8KLSAJCQlpZiAoIWxh
dW5kZXJfbG9vcCkgewogIAkJCQlsaXN0X2RlbChwYWdlX2xydSk7CiAgCQkJ
CWxpc3RfYWRkKHBhZ2VfbHJ1LCAmaW5hY3RpdmVfZGlydHlfbGlzdCk7CiAg
CQkJCVVubG9ja1BhZ2UocGFnZSk7Ci0tLSA0ODMsNDg5IC0tLS0KICAJCQkJ
Z290byBwYWdlX2FjdGl2ZTsKICAKICAJCQkvKiBGaXJzdCB0aW1lIHRocm91
Z2g/IE1vdmUgaXQgdG8gdGhlIGJhY2sgb2YgdGhlIGxpc3QgKi8KKyAJCQlp
ZiAoIWxhdW5kZXJfbG9vcCB8fCAhY2FuX2dldF9pb19sb2NrcykgewogIAkJ
CQlsaXN0X2RlbChwYWdlX2xydSk7CiAgCQkJCWxpc3RfYWRkKHBhZ2VfbHJ1
LCAmaW5hY3RpdmVfZGlydHlfbGlzdCk7CiAgCQkJCVVubG9ja1BhZ2UocGFn
ZSk7Cg==

------------=_989589998-634-0--

From owner-linux-xfs@oss.sgi.com Fri May 11 07:15:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BEFCT06317
	for linux-xfs-outgoing; Fri, 11 May 2001 07:15:12 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BEFCF06313
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:15:12 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA12318
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:13:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1780267; Fri, 11 May 2001 09:13:54 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA13153; Fri, 11 May 2001 09:13:54 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4BEGfP15556; Fri, 11 May 2001 09:16:41 -0500
Message-Id: <200105111416.f4BEGfP15556@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "a. heidenreich" <heid.a@swol.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs 
In-Reply-To: Message from "a. heidenreich" <heid.a@swol.de> 
   of "Thu, 10 May 2001 23:14:27 +0200." <3AFB04B2.D4F75523@swol.de> 
Date: Fri, 11 May 2001 09:16:41 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> hi,
> 
> it seems to me that using the same external logdevice for two different
> xfs filesystems doesn't work! are there any restrictions? (sorry, i
> don't find anything in your man pages or online papers)
> 
> thx in advance.
> 
> andre
> 

To add a second response here - the Irix implementation does not truly
support external logs, Irix volume managers support volumes which have
seperate subvolumes for file data and the log - it looks like a single
device to everything but the volume manager and the filesystem. Since
Linux volume managers have no similar concept this was mapped to explicitly
specifying separate devices on the mkfs and mount command lines.

This however is a totally different implementation from ext3's ability to
share a log device between filesystems. Getting xfs to use a shared
journal device across several filesystem is not a realistic proposition
without major code surgery and breaking compatibility with existing
filesystems.

Steve



From owner-linux-xfs@oss.sgi.com Fri May 11 07:19:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BEJOC06554
	for linux-xfs-outgoing; Fri, 11 May 2001 07:19:24 -0700
Received: from mx.in-addr.de (gate.in-addr.de [212.8.193.158])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BEJNF06551
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:19:23 -0700
Received: from hermes.marowsky-bree.de (localhost [127.0.0.1])
	by mx.in-addr.de (mail.in-addr.de) with ESMTP
	id EC81C37AF0; Fri, 11 May 2001 16:19:21 +0200 (CEST)
Received: by hermes.marowsky-bree.de (Postfix, from userid 500)
	id BD765ACBFD; Fri, 11 May 2001 16:19:19 +0200 (CEST)
Date: Fri, 11 May 2001 16:19:19 +0200
From: Lars Marowsky-Bree <lmb@suse.de>
To: gfs-devel@sistina.com
Cc: linux-xfs@oss.sgi.com
Subject: Re: [gfs-devel] Can I use XFS and GFS simultaneous?
Message-ID: <20010511161919.Y1698@marowsky-bree.de>
References: <20010511140638.713.cpmta@c012.sfo.cp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.3i
In-Reply-To: <20010511140638.713.cpmta@c012.sfo.cp.net>; from "Oleg Kodak" on 2001-05-11T07:06:38
X-Ctuhulu: HASTUR
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 2001-05-11T07:06:38,
   Oleg Kodak <olegkodak@altavista.com> said:

>  Could You say me any about this, Please.

The diffs look fairly minor, you should be able to merge them manually.

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl


From owner-linux-xfs@oss.sgi.com Fri May 11 07:23:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BEN7006696
	for linux-xfs-outgoing; Fri, 11 May 2001 07:23:07 -0700
Received: from sistina.com (hermes.sistina.com [208.210.145.141])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4BEN7F06693
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:23:07 -0700
Received: (qmail 23523 invoked from network); 11 May 2001 14:21:00 -0000
Received: from fry.sistina.com (HELO ununquadium.sistina.com) (208.210.145.138)
  by hermes.sistina.com with SMTP; 11 May 2001 14:21:00 -0000
Received: by ununquadium.sistina.com (sSMTP sendmail emulation); Fri, 11 May 2001 09:23:06 -0500
Date: Fri, 11 May 2001 09:23:06 -0500
From: Adam Manthei <manthei@sistina.com>
To: gfs-devel@sistina.com
Cc: linux-xfs@oss.sgi.com
Subject: Re: [gfs-devel] Can I use XFS and GFS simultaneous?
Message-ID: <20010511092306.J28526@sistina.com>
References: <20010511140638.713.cpmta@c012.sfo.cp.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <20010511140638.713.cpmta@c012.sfo.cp.net>; from olegkodak@altavista.com on Fri, May 11, 2001 at 07:06:38AM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've never tested XFS and GFS on the system, so I can't guarantee that 
the two will work together.  Since you are adding other patches to the
kernel, all bets are off.  However, if these are the only patch rejects,
you may be in luck.  You should be able to patch the files by hand since
there are only a few added functions and #defines.  

On Fri, May 11, 2001 at 07:06:38AM -0700, Oleg Kodak wrote:
>  I try to use XFS on the system disk and GFS on the shared disks.
>  I have fresh source of GFS (from CVS) and
> kernel v244 (from .kernel.org) and
> linux-2.4.4-xfs-cvs-05022001.patch (from ftp://oss.sgi.com/projects/xfs/download/patches).
> 
>  When I apply GFS kernel patches (patching - OK.
> Than I try to apply linux-2.4.4-xfs-cvs-05022001.patch 
> and have some rejects:
>                       fs.h.rej
>                       vmscan.c.rej
>                       ksyms.c.rej
> (See attachments)
> 
>  Could You say me any about this, Please.

-- 
Adam Manthei  <manthei@sistina.com>

From owner-linux-xfs@oss.sgi.com Fri May 11 07:28:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BESvT06881
	for linux-xfs-outgoing; Fri, 11 May 2001 07:28:57 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BESsF06877
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:28:55 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA1269445
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 16:28:52 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1782250; Fri, 11 May 2001 09:27:34 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA98541; Fri, 11 May 2001 09:27:34 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4BEUK715911; Fri, 11 May 2001 09:30:21 -0500
Message-Id: <200105111430.f4BEUK715911@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Oleg Kodak <olegkodak@altavista.com>
cc: linux-xfs@oss.sgi.com, gfs-devel@sistina.com
Subject: Re: Can I use XFS and GFS simultaneous? 
In-Reply-To: Message from Oleg Kodak <olegkodak@altavista.com> 
   of "11 May 2001 07:06:38 PDT." <20010511140638.713.cpmta@c012.sfo.cp.net> 
Date: Fri, 11 May 2001 09:30:20 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> This is a multi-part message in MIME format...
> 
> ------------=_989589998-634-0
> Content-Type: text/plain
> Content-Disposition: inline
> 
>  I try to use XFS on the system disk and GFS on the shared disks.
>  I have fresh source of GFS (from CVS) and
> kernel v244 (from .kernel.org) and
> linux-2.4.4-xfs-cvs-05022001.patch (from ftp://oss.sgi.com/projects/xfs/downl
> oad/patches).
> 
>  When I apply GFS kernel patches (patching - OK.
> Than I try to apply linux-2.4.4-xfs-cvs-05022001.patch 
> and have some rejects:
>                       fs.h.rej
>                       vmscan.c.rej
>                       ksyms.c.rej


Without looking at the gfs code, I cannot give you definite answers, but:

In fs.h:

You need to define BH_Delay as some value not already used - I presume
GFS adds a new buffer flag.

You need to add the writepage_nounlock and toss_page methods to the
address_space operations vector, just do it, no other change would
be needed.

In vmscan.c:

Hard to say, what does the code look like at this location?

In ksyms.c

Just add in the line

EXPORT_SYMBOL(remap_page_array);

Steve



From owner-linux-xfs@oss.sgi.com Fri May 11 07:45:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BEjpQ07285
	for linux-xfs-outgoing; Fri, 11 May 2001 07:45:51 -0700
Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BEjfF07275
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 07:45:41 -0700
Received: from astro.wisc.edu (jansen@voodoo.astro.wisc.edu [144.92.179.132])
	by uwast.astro.wisc.edu (8.11.3/8.11.3) with ESMTP id f4BEjYO110502
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:45:34 -0500 (CDT)
Message-ID: <3AFBFB0E.15591498@astro.wisc.edu>
Date: Fri, 11 May 2001 09:45:34 -0500
From: jansen <jansen@astro.wisc.edu>
X-Mailer: Mozilla 4.77C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Bigmem problems on XFS Release 1.0?
Content-Type: multipart/mixed;
 boundary="------------18B2192F2416B51C3606113C"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------18B2192F2416B51C3606113C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I recently installed XFS Release 1.0 on an ASL Merlin C120A machine
with 2x1GHz PIII and 2GB or RAM.  I noticed after the install that
it installed the SMP kernel instead of the enterprise kernel which I
thought was a little odd but it recognized all the RAM and one of 
the people using the machine has a job which is using 1.6GB RSS without
apparent problems for about two days.  Now after about a week of uptime 
I'm starting to see some errors in syslog and some X hangs.  I first
saw quite a few (~ 100) messages of this sort:

May  8 05:54:29 6A:nemesis kernel: __alloc_pages: 0-order allocation failed.
May  8 05:54:50 6A:nemesis kernel: failed.
May  8 05:54:50 6A:nemesis kernel: __alloc_pages: 0-order allocation failed.

That has stopped happening but now I got a long kernel trace in syslog
which I will attach to this message (sorry, it's rather large) along with the
output from "cat /proc/meminfo".  It's not clear that this is directly
related to XFS but I did see some XFS routines mentioned in the kernel trace.
The machine has not exhibited any outward signs of problems other then the
X hangs, it continues to run.

So my question is: could this be caused by the fact that I don't have the
enterprise kernel installed or is this an XFS or generic 2.4.2 kernel problem?
Let me know if there is any additional information you'd like me to provide.

Thanks for any help.


-- 


------- Stephan
--------------18B2192F2416B51C3606113C
Content-Type: text/plain; charset=us-ascii;
 name="nemesis.errors2"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="nemesis.errors2"

May 11 08:54:52 4A:nemesis kernel: 
May 11 08:54:52 4A:nemesis kernel:                          free                        sibling
May 11 08:54:52 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:54:52 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:54:52 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:52 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:54:52 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:54:52 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:54:52 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:54:52 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:54:52 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:54:52 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:54:52 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:54:52 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:54:52 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:54:52 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:54:52 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:54:52 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:54:52 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:54:52 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:54:53 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:54:53 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:54:53 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:54:53 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:54:53 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:54:53 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:54:53 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:54:53 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:54:53 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:54:53 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:54:53 4A:nemesis kernel: syslogd   S 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: klogd     R F6D62000    16   654      1        (NOTLB)     668   649
May 11 08:54:53 4A:nemesis kernel: Call Trace: [sock_sendmsg+129/164] [do_syslog+181/888] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c024182d>] [<c0118925>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:54:53 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:54:53 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:54:53 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:54:53 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:54:53 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:54:53 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:54:53 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:54:53 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:54:53 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:54:53 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:54:53 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:53 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:53 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:53 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:54:53 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:54 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:54:54 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:54:54 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:54:54 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:54:54 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel:        [stext+43/203] 
May 11 08:54:54 4A:nemesis kernel:        [<c010002b>] 
May 11 08:54:54 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:54:54 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:54:54 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:54:54 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:54:54 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:54 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:54:54 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:54 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:54:54 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:54 6A:nemesis kernel: 1090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:54 4A:nemesis kernel: runsc     R C011CDD5     0 29379      1        (NOTLB)    1823 18321
May 11 08:54:54 4A:nemesis kernel: Call Trace: [tasklet_hi_action+81/124] [do_softirq+90/136] [do_IRQ+218/236] [ret_from_intr+0/32] [stext+43/203] 
May 11 08:54:54 4A:nemesis kernel: Call Trace: [<c011cdd5>] [<c011cc7a>] [<c010a97a>] [<c010918c>] [<c010002b>] 
May 11 08:54:54 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:54:54 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:54:55 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:54:55 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:54:55 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:55 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:54:55 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:54:55 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: 
May 11 08:54:55 4A:nemesis kernel:                          free                        sibling
May 11 08:54:55 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:54:55 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:54:55 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:55 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:54:55 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:54:55 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:54:55 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:54:55 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:54:55 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:54:55 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:54:55 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:54:55 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:54:55 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:54:55 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:54:55 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:54:55 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:54:55 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:54:55 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:54:55 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:54:55 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:54:55 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:54:55 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:54:55 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:54:55 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:54:55 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:54:55 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:54:55 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:54:56 4A:nemesis kernel: syslogd   R 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:54:56 4A:nemesis kernel: klogd     R 7FFFFFFF    16   654      1        (NOTLB)     668   649
May 11 08:54:56 4A:nemesis kernel: Call Trace: [net_tx_action+93/296] [alloc_skb+262/456] [memcpy_fromiovec+58/104] [sock_def_readable+54/96] [unix_dgram_sendmsg+1009/1116] [unix_dgram_sendmsg+0/1116] [sock_sendmsg+129/164] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0248b95>] [<c0244826>] [<c0246402>] [<c0244472>] [<c0284eb5>] [<c0284ac4>] [<c024182d>] 
May 11 08:54:56 4A:nemesis kernel:        [unix_dgram_sendmsg+0/1116] [sock_write+163/172] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel:        [<c0284ac4>] [<c0241a4b>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:54:56 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:54:56 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:54:56 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:54:56 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:54:56 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:54:56 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:54:56 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:54:56 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:54:56 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 6A:nemesis kernel: ] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:54:56 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:56 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:56 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:54:56 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:54:57 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:54:57 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:54:57 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel:        [stext+43/203] 
May 11 08:54:57 4A:nemesis kernel:        [<c010002b>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:54:57 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:54:57 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:54:57 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:54:57 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:57 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:54:57 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:57 4A:nemesis kernel: runsc     R current      0 29379      1        (NOTLB)    1823 18321
May 11 08:54:57 4A:nemesis kernel: Call Trace: [keyboard_interrupt+28/40] [handle_IRQ_event+78/120] [do_IRQ+153/236] [ret_from_intr+0/32] [stext+43/203] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0210f84>] [<c010a746>] [<c010a939>] [<c010918c>] [<c010002b>] 
May 11 08:54:57 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:54:57 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:54:57 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:54:57 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:54:57 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:54:57 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:57 6A:nemesis kernel: 120bed>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:54:57 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:57 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:57 4A:nemesis kernel: 
May 11 08:54:57 4A:nemesis kernel:                          free                        sibling
May 11 08:54:57 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:54:57 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:54:58 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:58 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:54:58 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:54:58 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:54:58 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:54:58 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:54:58 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:54:58 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:54:58 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:54:58 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:54:58 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:54:58 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:54:58 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:54:58 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:54:58 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:54:58 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:54:58 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:54:58 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:54:58 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:54:58 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:54:58 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:54:58 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:54:58 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:54:58 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:54:58 4A:nemesis kernel: syslogd   R 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:54:58 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:54:58 4A:nemesis kernel: klogd     R 7FFFFFFF    16   654      1        (NOTLB)     668   649
May 11 08:54:58 4A:nemesis kernel: Call Trace: [add_to_page_cache_locked+196/212] [sock_def_readable+54/96] [unix_dgram_sendmsg+1009/1116] [unix_dgram_sendmsg+0/1116] [sock_sendmsg+129/164] [unix_dgram_sendmsg+0/1116] [sock_write+163/172] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c01294b8>] [<c0244472>] [<c0284eb5>] [<c0284ac4>] [<c024182d>] [<c0284ac4>] [<c0241a4b>] 
May 11 08:54:58 4A:nemesis kernel:        [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] 
May 11 08:54:58 4A:nemesis kernel:        [<c015b6e5>] [<c0139af6>] [<c01090cb>] 
May 11 08:54:58 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:54:58 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:58 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:58 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:54:58 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:54:59 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:54:59 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:54:59 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:54:59 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:54:59 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:54:59 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:54:59 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:54:59 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:54:59 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:54:59 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:54:59 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:54:59 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:54:59 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:54:59 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:54:59 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:54:59 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:00 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:00 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:00 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:00 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:00 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:00 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:00 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:00 4A:nemesis kernel: runsc     R current      0 29379      1        (NOTLB)    1823 18321
May 11 08:55:00 4A:nemesis kernel: Call Trace: [keyboard_interrupt+28/40] [handle_IRQ_event+78/120] [do_IRQ+153/236] [ret_from_intr+0/32] [stext+43/203] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0210f84>] [<c010a746>] [<c010a939>] [<c010918c>] [<c010002b>] 
May 11 08:55:00 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:00 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:00 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:00 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:00 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:00 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: 
May 11 08:55:00 4A:nemesis kernel:                          free                        sibling
May 11 08:55:00 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:55:00 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:00 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:55:00 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:55:00 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:55:00 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:55:00 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:55:00 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:55:00 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:55:00 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:55:00 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:55:01 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:55:01 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:55:01 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:55:01 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:55:01 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:55:01 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:55:01 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:55:01 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:55:01 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:55:01 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:01 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:01 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:55:01 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:55:01 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:55:01 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:55:01 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:01 4A:nemesis kernel: syslogd   R 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:01 4A:nemesis kernel: klogd     R 7FFFFFFF    16   654      1        (NOTLB)     668   649
May 11 08:55:01 4A:nemesis kernel: Call Trace: [add_to_page_cache_locked+196/212] [alloc_skb+262/456] [memcpy_fromiovec+58/104] [sock_def_readable+54/96] [unix_dgram_sendmsg+1009/1116] [unix_dgram_sendmsg+0/1116] [sock_sendmsg+129/164] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c01294b8>] [<c0244826>] [<c0246402>] [<c0244472>] [<c0284eb5>] [<c0284ac4>] [<c024182d>] 
May 11 08:55:01 4A:nemesis kernel:        [unix_dgram_sendmsg+0/1116] [sock_write+163/172] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:01 4A:nemesis kernel:        [<c0284ac4>] [<c0241a4b>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:01 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:55:01 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:01 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:01 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:55:01 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:55:01 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:55:01 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:55:01 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:01 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:55:01 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:01 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:01 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:55:02 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:55:02 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:55:02 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:55:02 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:55:02 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 6A:nemesis kernel: ] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:02 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:55:02 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:55:02 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:55:02 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:55:02 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:02 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:02 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:02 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:02 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:02 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:03 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:03 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:03 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:03 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:03 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:03 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:03 4A:nemesis kernel: runsc     R current      0 29379      1        (NOTLB)    1823 18321
May 11 08:55:03 4A:nemesis kernel: Call Trace: [keyboard_interrupt+28/40] [handle_IRQ_event+78/120] [do_IRQ+153/236] [ret_from_intr+0/32] [stext+43/203] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0210f84>] [<c010a746>] [<c010a939>] [<c010918c>] [<c010002b>] 
May 11 08:55:03 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:03 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:03 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:03 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:03 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:03 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:03 6A:nemesis kernel: 120bed>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: 
May 11 08:55:03 4A:nemesis kernel:                          free                        sibling
May 11 08:55:03 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:55:03 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:03 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:55:03 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:55:03 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:55:03 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:55:03 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:55:03 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:55:03 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:55:03 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:55:03 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:55:03 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:55:04 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:55:04 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:55:04 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:55:04 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:55:04 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:55:04 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:55:04 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:04 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:04 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:55:04 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:55:04 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:55:04 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:55:04 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:55:04 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:04 4A:nemesis kernel: syslogd   S 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:04 4A:nemesis kernel: klogd     R F6D62000    16   654      1        (NOTLB)     668   649
May 11 08:55:04 4A:nemesis kernel: Call Trace: [sock_sendmsg+129/164] [do_syslog+181/888] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c024182d>] [<c0118925>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:55:04 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:55:04 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:55:04 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:55:04 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:55:04 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:55:04 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:55:04 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:55:04 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:55:04 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:04 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:04 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:55:05 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:55:05 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:05 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:55:05 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:55:05 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:55:05 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:55:05 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:05 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:05 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:05 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:05 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:05 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:05 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:06 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:06 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:06 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:06 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:06 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:06 6A:nemesis kernel: 1090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:06 4A:nemesis kernel: runsc     R E8F1A000     0 29379      1        (NOTLB)    1823 18321
May 11 08:55:06 4A:nemesis kernel: Call Trace: [reschedule+5/12] [stext+43/203] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c01091bd>] [<c010002b>] 
May 11 08:55:06 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:06 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:06 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:06 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:06 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:06 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:06 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:06 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: 
May 11 08:55:06 4A:nemesis kernel:                          free                        sibling
May 11 08:55:06 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:55:06 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:55:06 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:06 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:55:06 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:55:06 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:55:06 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:55:06 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:55:06 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:55:06 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:55:06 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:55:06 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:55:06 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:55:06 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:55:06 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:55:06 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:55:06 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:55:06 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:55:06 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:55:06 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:55:07 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:07 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:07 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:55:07 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:55:07 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:55:07 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:55:07 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:55:07 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:07 4A:nemesis kernel: syslogd   S 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:07 4A:nemesis kernel: klogd     R F6D62000    16   654      1        (NOTLB)     668   649
May 11 08:55:07 4A:nemesis kernel: Call Trace: [sock_sendmsg+129/164] [do_syslog+181/888] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c024182d>] [<c0118925>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:55:07 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:55:07 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:55:07 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:55:07 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:55:07 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:55:07 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:55:07 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:55:07 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:55:07 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:55:07 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:07 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:07 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:55:07 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:07 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:08 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:55:08 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:55:08 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:55:08 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:55:08 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:08 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:08 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:08 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:08 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:08 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:08 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:08 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:08 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:08 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:08 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:08 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:08 6A:nemesis kernel: 1090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:08 4A:nemesis kernel: runsc     R 00000020     0 29379      1        (NOTLB)    1823 18321
May 11 08:55:09 4A:nemesis kernel: Call Trace: [timer_interrupt+277/412] [run_local_timers+143/248] [smp_apic_timer_interrupt+270/276] [call_apic_timer_interrupt+5/13] [stext+43/203] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c010d9e9>] [<c01208c7>] [<c0113bce>] [<c029f154>] [<c010002b>] 
May 11 08:55:09 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:09 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:09 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:09 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:09 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:09 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:09 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:09 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: 
May 11 08:55:09 4A:nemesis kernel:                          free                        sibling
May 11 08:55:09 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:55:09 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:55:09 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:09 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:55:09 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:55:09 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:55:09 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:55:09 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:55:09 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:55:09 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:55:09 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:55:09 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:55:09 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:55:09 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:55:09 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:55:09 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:55:09 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:55:09 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:55:09 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:55:09 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:55:09 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:09 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:09 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:55:09 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:55:10 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:55:10 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:55:10 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:55:10 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:10 4A:nemesis kernel: syslogd   S 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:10 4A:nemesis kernel: klogd     R F6D62000    16   654      1        (NOTLB)     668   649
May 11 08:55:10 4A:nemesis kernel: Call Trace: [sock_sendmsg+129/164] [do_syslog+181/888] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c024182d>] [<c0118925>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:10 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:55:10 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:55:10 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:55:10 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:55:10 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:55:10 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:55:10 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:55:10 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:55:10 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:55:10 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:55:10 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:10 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:55:10 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:10 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:10 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:11 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:55:11 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:55:11 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:55:11 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:55:11 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:11 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:11 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:11 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:11 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:11 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:11 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:11 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:11 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:11 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:11 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:11 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:11 6A:nemesis kernel: 11bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:12 4A:nemesis kernel: runsc     R 00000000     0 29379      1        (NOTLB)    1823 18321
May 11 08:55:12 4A:nemesis kernel: Call Trace: [__run_timers+204/272] [run_local_timers+143/248] [smp_apic_timer_interrupt+270/276] [call_apic_timer_interrupt+5/13] [stext+43/203] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c012028c>] [<c01208c7>] [<c0113bce>] [<c029f154>] [<c010002b>] 
May 11 08:55:12 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:12 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:12 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:12 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:12 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:12 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:12 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:12 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: 
May 11 08:55:12 4A:nemesis kernel:                          free                        sibling
May 11 08:55:12 4A:nemesis kernel:   task             PC    stack   pid father child younger older
May 11 08:55:12 4A:nemesis kernel: init      S C325FF0C  2788     1      0 20718  (NOTLB)        
May 11 08:55:12 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:12 4A:nemesis kernel: keventd   S 00000000  6040     2      1        (L-TLB)       3
May 11 08:55:12 4A:nemesis kernel: Call Trace: [context_thread+296/460] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0124a18>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: kswapd    S C326FFA0  3880     3      1        (L-TLB)       4     2
May 11 08:55:12 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [interruptible_sleep_on_timeout+82/124] [error_table+41778/64664] [kswapd+241/296] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c01167fe>] [<c02ad82e>] [<c0132415>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: kreclaimd  S 00000286  5432     4      1        (L-TLB)       5     3
May 11 08:55:12 4A:nemesis kernel: Call Trace: [interruptible_sleep_on+77/112] [kreclaimd+102/252] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0116789>] [<c01324fa>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: bdflush   S C326A000  3928     5      1        (L-TLB)       6     4
May 11 08:55:12 4A:nemesis kernel: Call Trace: [error_table+52082/64664] [bdflush+238/252] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c02b006e>] [<c013e5ee>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: kupdated  S C3269FC0  3736     6      1        (L-TLB)       7     5
May 11 08:55:12 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [kupdate+168/292] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c013e6a4>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: mdrecoveryd  S F7CA8000  6304     7      1        (L-TLB)       8     6
May 11 08:55:12 4A:nemesis kernel: Call Trace: [md_thread+329/428] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c023fe39>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: pagebuf_daemon  S 00000286  4920     8      1        (L-TLB)      14     7
May 11 08:55:12 4A:nemesis kernel: Call Trace: [ide_do_request+672/756] [interruptible_sleep_on+77/112] [pagebuf_daemon+228/604] [pb_daemon_wakeup+0/24] [kernel_thread+35/48] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c0215dd8>] [<c0116789>] [<c016fa0c>] [<c016f910>] [<c01075e3>] 
May 11 08:55:12 4A:nemesis kernel: devfsd    S F718A000  4716    14      1        (NOTLB)      68     8
May 11 08:55:12 4A:nemesis kernel: Call Trace: [devfsd_read+278/1104] [avl_remove+205/220] [_pagebuf_find_lockable_buffer+468/516] [xlog_state_do_callback+692/764] [xlog_state_do_callback+692/764] [xfs_trans_tail_ail+30/64] [xlog_assign_tail_lsn+23/180] 
May 11 08:55:12 4A:nemesis kernel: Call Trace: [<c016c486>] [<c016d8d9>] [<c01723d0>] [<c01c5c44>] [<c01c5c44>] [<c01d202e>] [<c01c4883>] 
May 11 08:55:12 4A:nemesis kernel:        [xlog_state_release_iclog+34/180] [xlog_write+988/1000] [xlog_commit_record+49/76] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2861/3552] [xfs_attr_fetch+118/240] [dmattr_prefix+2848/3552] 
May 11 08:55:12 4A:nemesis kernel:        [<c01c66e6>] [<c01c57bc>] [<c01c4ddd>] [<c02bf009>] [<c018c756>] [<c02bf009>] [<c018c756>] [<c02beffc>] 
May 11 08:55:12 4A:nemesis kernel:        [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_acl_iaccess+44/144] [dmattr_prefix+2848/3552] [xfs_setattr+3633/3956] [xfs_setattr+0/3956] [xfs_setattr+0/3956] 
May 11 08:55:12 4A:nemesis kernel:        [<c02beffc>] [<c018351c>] [<c02beffc>] [<c018351c>] [<c02beffc>] [<c01d6e25>] [<c01d5ff4>] [<c01d5ff4>] 
May 11 08:55:12 4A:nemesis kernel:        [neigh_update+284/1052] [inode_setattr+170/180] [xfs_setattr+0/3956] [xfs_getattr+64/636] [xfs_ilock_ra+138/148] [xfs_trans_unlocked_item+34/60] [xfs_iunlock+95/104] [xfs_getattr+622/636] 
May 11 08:55:12 4A:nemesis kernel:        [<c024bfe8>] [<c015101e>] [<c01d5ff4>] [<c01d5db8>] [<c01bd7d6>] [<c01d2292>] [<c01bd91b>] [<c01d5fe6>] 
May 11 08:55:12 4A:nemesis kernel:        [vn_revalidate+56/232] [dput+59/412] [path_release+13/64] [sys_lstat64+100/112] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:12 4A:nemesis kernel:        [<c01e78a8>] [<c014e54b>] [<c0145371>] [<c0142c24>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:12 4A:nemesis kernel: khubd     S 00000286     0    68      1        (L-TLB)     583    14
May 11 08:55:12 4A:nemesis kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428664/96] [interruptible_sleep_on+77/112] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-435289/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-428660/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-461761/96] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<f890d588>] [<c0116789>] [<f890bba7>] [<f890d58c>] [<f890d58c>] [<f890543f>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-479232/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-467764/96] 
May 11 08:55:13 4A:nemesis kernel:        [<f8901000>] [<f8903ccc>] 
May 11 08:55:13 4A:nemesis kernel: pump      S F6DD1F0C     0   583      1        (NOTLB)     649    68
May 11 08:55:13 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:13 4A:nemesis kernel: syslogd   S 7FFFFFFF     0   649      1        (NOTLB)     654   583
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] [stext+43/203] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] [<c010002b>] 
May 11 08:55:13 4A:nemesis kernel: klogd     R F6D62000    16   654      1        (NOTLB)     668   649
May 11 08:55:13 4A:nemesis kernel: Call Trace: [sock_sendmsg+129/164] [do_syslog+181/888] [kmsg_read+17/24] [sys_read+146/200] [system_call+51/56] [stext+43/203] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c024182d>] [<c0118925>] [<c015b6e5>] [<c0139af6>] [<c01090cb>] [<c010002b>] 
May 11 08:55:13 4A:nemesis kernel: portmap   S 7FFFFFFF  2416   668      1        (NOTLB)     683   654
May 11 08:55:13 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: rpc.statd  S 7FFFFFFF     0   683      1        (NOTLB)     758   668
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: rpciod    S F6D02000     0   757      1        (L-TLB)     778   758
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<f8987e12>] [<f8980310>] [<f8980e4b>] [<f8980c6c>] [<f898acc4>] [<f898acbc>] [<f898acbc>] 
May 11 08:55:13 4A:nemesis kernel:        [kernel_thread+35/48] [<f898acc4>] [<f898acc4>] 
May 11 08:55:13 4A:nemesis kernel:        [<c01075e3>] [<f898acc4>] [<f898acc4>] 
May 11 08:55:13 4A:nemesis kernel: lockd     S 7FFFFFFF  5160   758      1  2076  (L-TLB)     757   683
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f898fca4>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f898fca4>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: ntpd      S 7FFFFFFF     0   778      1        (NOTLB)     894   757
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: atd       S F6CAFF78  2416   894      1        (NOTLB)     919   778
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: sshd      S 7FFFFFFF  3972   919      1        (NOTLB)     998   894
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [sock_poll+35/40] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0241c7f>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: runbb.sh  S 00000000  1392   998      1   999  (NOTLB)    1032   919
May 11 08:55:13 4A:nemesis kernel: Call Trace: [do_sigaction+106/284] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c01220e6>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: bbrun     S 00000000  4200   999    998 20600  (NOTLB)        
May 11 08:55:13 4A:nemesis kernel: Call Trace: [do_fork+1743/1924] [sys_wait4+982/1036] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c01183a7>] [<c011bfd6>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: xinetd    S F6C07FB0     0  1032      1        (NOTLB)    1155   998
May 11 08:55:13 4A:nemesis kernel: Call Trace: [sys_rt_sigaction+129/224] [sys_rt_sigsuspend+243/272] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c01224dd>] [<c010827b>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: lpd       S 7FFFFFFF     0  1155      1        (NOTLB)    1179  1032
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: rpc.rquotad  S 7FFFFFFF     0  1179      1        (NOTLB)    1184  1155
May 11 08:55:13 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [sock_poll+35/40] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0241c7f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: rpc.mountd  S 7FFFFFFF  4540  1184      1        (NOTLB)    1196  1179
May 11 08:55:13 4A:nemesis kernel: Call Trace: [tcp_poll+47/348] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c025e99f>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1189      1        (L-TLB)    1229  1190
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1190      1        (L-TLB)    1189  1191
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  5052  1191      1        (L-TLB)    1190  1192
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  4932  1192      1        (L-TLB)    1191  1193
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  4844  1193      1        (L-TLB)    1192  1194
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  5244  1194      1        (L-TLB)    1193  1195
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:13 4A:nemesis kernel: nfsd      S 7FFFFFFF  5232  1195      1        (L-TLB)    1194  1196
May 11 08:55:13 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [kernel_thread+35/48] 
May 11 08:55:13 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<c01075e3>] 
May 11 08:55:14 4A:nemesis kernel: nfsd      S 7FFFFFFF  5236  1196      1        (L-TLB)    1195  1184
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [kernel_thread+35/48] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<f8983cfe>] [<f89d6449>] [<f89e6e00>] [<c01075e3>] 
May 11 08:55:14 4A:nemesis kernel: sendmail  S F6A2FF0C     0  1229      1        (NOTLB)    1242  1189
May 11 08:55:14 4A:nemesis kernel: Call Trace: [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: gpm       S F6A27F0C     0  1242      1        (NOTLB)    1257  1229
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] [stext+43/203] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] [<c010002b>] 
May 11 08:55:14 4A:nemesis kernel: cannaserver  S F6A07F0C  2416  1257      1        (NOTLB)    1269  1242
May 11 08:55:14 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [__pollwait+142/148] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c013308b>] [<c014aa8e>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: crond     S F69F3F78  4720  1269      1        (NOTLB)    1305  1257
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: xfs       S F6857F0C     0  1305      1        (NOTLB)    1331  1269
May 11 08:55:14 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [filp_close+176/188] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c0139660>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel:        [stext+43/203] 
May 11 08:55:14 4A:nemesis kernel:        [<c010002b>] 
May 11 08:55:14 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200  1331      1        (NOTLB)    1332  1305
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1332      1        (NOTLB)    1333  1331
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: mingetty  S 7FFFFFFF     0  1333      1        (NOTLB)    1334  1332
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1334      1        (NOTLB)    1335  1333
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: mingetty  S 7FFFFFFF  4764  1335      1        (NOTLB)    1336  1334
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [do_page_fault+351/1100] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0115433>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: gdm       S 7FFFFFFF  4200  1336      1        (NOTLB)   15765  1335
May 11 08:55:14 4A:nemesis kernel: Call Trace: [pipe_poll+39/108] [schedule_timeout+23/164] [do_poll+171/232] [do_poll+55/232] [sys_poll+563/848] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c01449f7>] [<c0115e67>] [<c014b4b3>] [<c014b43f>] [<c014b723>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: ssh-agent  S F67E3F0C     0 15765      1        (NOTLB)   18321  1336
May 11 08:55:14 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: ssh-agent  S EDB91F0C  1500 18321      1        (NOTLB)   29379 15765
May 11 08:55:14 4A:nemesis kernel: Call Trace: [__alloc_pages+143/700] [schedule_timeout+129/164] [process_timeout+0/92] [do_select+188/568] [sys_select+1078/1448] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c013308b>] [<c0115ed1>] [<c0115df4>] [<c014ac08>] [<c014b1e2>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: lockd     Z E1BE6000  1392 22579    758        (L-TLB)    6089
May 11 08:55:14 4A:nemesis kernel: Call Trace: [call_reschedule_interrupt+5/12] [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c029f0e5>] [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:14 4A:nemesis kernel: lockd     Z EE7D6000     4  6089    758        (L-TLB)    2076 22579
May 11 08:55:14 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:14 6A:nemesis kernel: 11bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:14 4A:nemesis kernel: runsc     R 00000000     0 29379      1        (NOTLB)    1823 18321
May 11 08:55:14 4A:nemesis kernel: Call Trace: [run_local_timers+143/248] [smp_apic_timer_interrupt+270/276] [call_apic_timer_interrupt+5/13] [stext+43/203] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c01208c7>] [<c0113bce>] [<c029f154>] [<c010002b>] 
May 11 08:55:14 4A:nemesis kernel: automount  S D11E8000     0  1823      1        (NOTLB)    1844 29379
May 11 08:55:14 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: automount  S EA3F4000     0  1844      1        (NOTLB)    1866  1823
May 11 08:55:14 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: automount  S E10B4000     0  1866      1        (NOTLB)   20718  1844
May 11 08:55:14 4A:nemesis kernel: Call Trace: [pipe_wait+125/164] [pipe_read+181/568] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c01443ed>] [<c01444c9>] [<c0139af6>] [<c01090cb>] 
May 11 08:55:14 4A:nemesis kernel: lockd     Z E2D94000     0  2076    758        (L-TLB)          6089
May 11 08:55:14 4A:nemesis kernel: Call Trace: [do_exit+661/692] [sys_exit+14/16] [system_call+51/56] [<f8999e30>] [kernel_thread+42/48] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c011bbb5>] [<c011bbfe>] [<c01090cb>] [<f8999e30>] [<c01075ea>] 
May 11 08:55:14 4A:nemesis kernel: sleep     S F601DF78     0 20600    999        (NOTLB)        
May 11 08:55:14 4A:nemesis kernel: Call Trace: [schedule_timeout+129/164] [process_timeout+0/92] [sys_nanosleep+257/388] [system_call+51/56] 
May 11 08:55:14 4A:nemesis kernel: Call Trace: [<c0115ed1>] [<c0115df4>] [<c0120bed>] [<c01090cb>] 
May 11 08:55:15 4A:nemesis kernel: mingetty  S 7FFFFFFF  4200 20718      1        (NOTLB)          1866
May 11 08:55:15 4A:nemesis kernel: Call Trace: [schedule_timeout+23/164] [set_cursor+110/128] [read_chan+941/1816] [tty_read+217/312] [sys_read+146/200] [system_call+51/56] 
May 11 08:55:15 4A:nemesis kernel: Call Trace: [<c0115e67>] [<c0205eee>] [<c01fd36d>] [<c01f910d>] [<c0139af6>] [<c01090cb>] 

--------------18B2192F2416B51C3606113C
Content-Type: text/plain; charset=us-ascii;
 name="nemesis.meminfo"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="nemesis.meminfo"

        total:    used:    free:  shared: buffers:  cached:
Mem:  2108268544 1851944960 256323584        0     8192 601124864
Swap: 2146754560 537608192 1609146368
MemTotal:      2058856 kB
MemFree:        250316 kB
MemShared:           0 kB
Buffers:             8 kB
Cached:         587036 kB
Active:         586356 kB
Inact_dirty:       240 kB
Inact_clean:       448 kB
Inact_target:      980 kB
HighTotal:     1179632 kB
HighFree:       147968 kB
LowTotal:       879224 kB
LowFree:        102348 kB
SwapTotal:     2096440 kB
SwapFree:      1571432 kB

--------------18B2192F2416B51C3606113C--


From owner-linux-xfs@oss.sgi.com Fri May 11 09:13:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BGDr609785
	for linux-xfs-outgoing; Fri, 11 May 2001 09:13:53 -0700
Received: from euler.intranet (IDENT:root@B12b5.pppool.de [213.7.18.181])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGDpF09780
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:13:51 -0700
Received: from gmx.de (lagrange.intranet [192.168.1.12])
	by euler.intranet (8.11.3/8.11.3) with ESMTP id f4BGIPH03213
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 18:18:25 +0200
Message-ID: <3AFC109F.E29D0581@gmx.de>
Date: Fri, 11 May 2001 18:17:35 +0200
From: Dominik Epple <Dominik.Epple@gmx.de>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: xfsdump, xfsrestore and SUID files
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I just did a xfsdump/xfsrestore of a filesystem:

xfsdump -J -F -f /tmp/opt.xfsdump /opt
[ ... shutdown of system, added new disk, mkfs.xfs etc... ]
xfsrestore -f /tmp/opt.xfsdump -J .

All went fine except that SUID files of the source file system were no
SUID files after the dump/restore cycle anymore.

I did not find any hints in the man pages about that. I guess it is a
security feature, but how can i turn this off? I mean, I want the
restored filesystem to be an exact copy of the source...

I dont think it is of importance, but let me note however that I am
using lvm.

TIA, Dominik

From owner-linux-xfs@oss.sgi.com Fri May 11 09:21:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BGLN509968
	for linux-xfs-outgoing; Fri, 11 May 2001 09:21:23 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGLLF09964
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:21:21 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA20286
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:21:20 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA09111
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:21:18 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Fri, 11 May 2001 09:21:11 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id JAA27108;
	Fri, 11 May 2001 09:21:11 -0700
Message-Id: <3AFC1177.28388A5A@pipcws.ca.boeing.com>
Date: Fri, 11 May 2001 09:21:11 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: Jan Rekorajski <baggins@sith.mimuw.edu.pl>
CC: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Mandrake/SuSE NFS update
References: <3AFAB076.5AE3C60C@sgi.com> <20010510192702.A4433@sith.mimuw.edu.pl>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All;
I applied this patch to my system last night, and it solved the NFS Export
problem that was being experienced with the Mandrake kernels.

Excelent work Jan!!!

	Ric


Jan Rekorajski wrote:
> 
> On Thu, 10 May 2001, Eric Sandeen wrote:
> 
> > Mandrake applies a patch from Neil Brown that adds an "nfsd_operations"
> > interface between knfsd and each filesystem.  I can't find a kernel
> > source RPM for SuSE 7.1, but I assume that it's the same issue.
> >
> > If this interface doesn't exist for a filesystem (and at this point, it
> > does not for XFS), this patched version of nfs deems the filesystem
> > "invalid" and will not export it.
> >
> > I think it's pretty quick fix, I'll be looking into it today.
> 
> Eric,
> I made such patch for XFS, the only thing I need is clarification
> from you if it's correct. Here it goes.
> 
> --- linux/fs/xfs/linux/xfs_iops.c.orig  Wed May  2 01:10:46 2001
> +++ linux/fs/xfs/linux/xfs_iops.c       Fri May  4 01:33:05 2001
> @@ -174,8 +174,55 @@
>                 linvfs_set_inode_ops(ip);
>                 error = linvfs_revalidate_core(ip, ATTR_COMM);
>         }
> +
> +       if (ip)
> +               return d_splice_alias(ip, dentry);
> +
>         d_add(dentry, ip);      /* Negative entry goes in if ip is NULL */
>         return NULL;
> +}
> +
> +
> +struct dentry * linvfs_get_parent(struct dentry *child)
> +{
> +       int             error;
> +       vnode_t         *vp, *cvp;
> +       pathname_t      pn;
> +       pathname_t      *pnp = &pn;
> +       struct inode    *ip = NULL;
> +       struct dentry   *parent;
> +
> +       vp = LINVFS_GET_VP(child->d_inode);
> +       ASSERT(vp);
> +
> +       /*
> +        * Initialize a pathname_t to pass down.
> +        */
> +       bzero(pnp, sizeof(pathname_t));
> +       pnp->pn_complen = 2;
> +       pnp->pn_path = "..";
> +
> +       cvp = NULL;
> +
> +       VOP_LOOKUP(vp, "..", &cvp, pnp, 0, NULL, NULL, error);
> +       if (!error) {
> +               ASSERT(cvp);
> +               ip = LINVFS_GET_IP(cvp);
> +               if (!ip) {
> +                       VN_RELE(cvp);
> +                       return ERR_PTR(-EACCES);
> +               }
> +               linvfs_set_inode_ops(ip);
> +               error = linvfs_revalidate_core(ip, ATTR_COMM);
> +       }
> +
> +       parent = d_make_alias(ip);
> +       if (!parent) {
> +               VN_RELE(cvp);
> +               parent = ERR_PTR(-ENOMEM);
> +       }
> +
> +       return parent;
>  }
> 
> 
> --- linux/fs/xfs/linux/xfs_super.c.orig Wed May  2 01:10:46 2001
> +++ linux/fs/xfs/linux/xfs_super.c      Fri May  4 01:35:49 2001
> @@ -38,6 +38,7 @@
>  #include <linux/blkdev.h>
>  #include <linux/init.h>
>  #include <linux/page_buf.h>
> +#include <linux/nfsd/interface.h>
> 
>  /* xfs_vfs[ops].c */
>  extern void vfsinit(void);
> @@ -49,6 +50,12 @@
> 
>  static struct super_operations linvfs_sops;
> 
> +extern struct dentry *linvfs_get_parent(struct dentry *child);
> +
> +static struct nfsd_operations xfs_nfsd_operations = {
> +       get_parent:     linvfs_get_parent,
> +};
> +
> 
>  #define        MS_DATA         0x04
> 
> @@ -414,6 +421,7 @@
>         set_blocksize(sb->s_dev, 512);
> 
>         sb->s_op = &linvfs_sops;
> +       sb->s_nfsd_op = &xfs_nfsd_operations;
>         sb->dq_op = NULL;
> 
>         LINVFS_SET_VFS(sb, vfsp);
> 
> Jan
> --
> Jan Rêkorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
> baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
> BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Fri May 11 09:27:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BGRwP10259
	for linux-xfs-outgoing; Fri, 11 May 2001 09:27:58 -0700
Received: from mail.innovation-tk.com (mail.innovation-tk.com [62.49.246.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGRtF10248
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:27:56 -0700
Received: from mark (mark.innovation-tk.com [192.168.0.15])
	by mail.innovation-tk.com (8.9.3/8.9.3) with SMTP id RAA23153
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 17:27:54 +0100
From: "Mark Wolforth" <mark@innovation-tk.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS mkfs problem.
Date: Fri, 11 May 2001 17:27:51 +0100
Message-ID: <000001c0da37$53365520$0f00a8c0@mark.innovation-tk.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hello,

I am trying to create a XFS file system on a Storage Concepts FibreBlock
Fibre Channel disk array.  I create a Linux partition with fdisk, with the
following parameters:

------------

Disk /dev/sda: 255 heads, 63 sectors, 9345 cylinders
Units = cylinders of 16065 * 2048 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/sda1             1      9345 300254724   83  Linux

------------

When I subsequently try to create the XFS file system I get:

------------

mkfs -t xfs -f /dev/sda1

meta-data=/dev/sda1              isize=256    agcount=287, agsize=261546
blks
data     =                       bsize=4096   blocks=75063681, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=9163
realtime =none                   extsz=65536  blocks=0, rtextents=0
mkfs.xfs: read failed: Input/output error
mkfs.xfs: data size check failed
mkfs.xfs: mount initialization failed

------------

Although this fails, I can successfully create a Linux ext2 file system on
the same partition, so I am confident that the physical hardware works.
Additionally, I can successfully create a XFS file system on a local IDE
hard disk, so I am fairly confident that the XFS stuff is correctly
installed.

cat /proc/filesystems suggests that XFS is supported by the kernel I am
using, and I downloaded the latest XFS tools from the OSS SGI web site.

Any idea why I cannot create the file system?

Best regards,
Mark.

====================================================
Mark Wolforth               Email: mark@innovation-tk.com
Senior Design Engineer      Voice: +44(0)1992 553533
Innovation TK Limited       Fax  : +44(0)1992 558979



From owner-linux-xfs@oss.sgi.com Fri May 11 09:43:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BGhns10745
	for linux-xfs-outgoing; Fri, 11 May 2001 09:43:49 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGhmF10742
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:43:48 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA07844
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:42:25 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA79374 for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:42:31 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4BGfBe08064;
	Fri, 11 May 2001 12:41:31 -0400
Message-ID: <3AFC1625.44E539C8@thebarn.com>
Date: Fri, 11 May 2001 12:41:10 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Marc Jauvin <marc@register4less.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
References: <200105111625.f4BGP9u10062@oss.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Marc Jauvin wrote:

> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
>
> ----
>
> I installed XFS 1.0 for RedHat 7.1 and everything is great... until I did the following:
>
> make modification to /etc/fstab, and IMMEDIATELY after saving the modifications, I hit the reset button; when the system reboots, the /etc/fstab is baddly corrupted and XFS does not fix it \(end up using the linux rescue disk to fix fstab manually\)
>
> I could reproduce the bug 2 times;

> Any idea\?

Yes don't do that.
XFS uses delayed allocation / delayed write by default any data written immediacy before a crash probably won't be on
disk, this is known behavior and isn't considered a bug, it's a trade off.
Full sync mode on file systems is much safer and gives more likely hood of data integrity. caches gives much better
performance but has the potential of losing cached data in the event of a crash.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Fri May 11 09:47:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BGlne10970
	for linux-xfs-outgoing; Fri, 11 May 2001 09:47:49 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BGlmF10967
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:47:48 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA09097
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 09:46:25 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA72449; Fri, 11 May 2001 11:46:32 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4BGjVe08071;
	Fri, 11 May 2001 12:45:31 -0400
Message-ID: <3AFC172B.E2AEB8D6@thebarn.com>
Date: Fri, 11 May 2001 12:45:31 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Wolforth <mark@innovation-tk.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS mkfs problem.
References: <000001c0da37$53365520$0f00a8c0@mark.innovation-tk.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mark Wolforth wrote:

Did you try rebooting after partitioning the disk?
Sometime when creating primary dos partitions
the system needs to be rebooted so the bios find  the updated size.

Since ext2 finds the correct size we may need to look at how it
does size discovery.

> Hello,
>
> I am trying to create a XFS file system on a Storage Concepts FibreBlock
> Fibre Channel disk array.  I create a Linux partition with fdisk, with the
> following parameters:
>
> ------------
>
> Disk /dev/sda: 255 heads, 63 sectors, 9345 cylinders
> Units = cylinders of 16065 * 2048 bytes
>
>    Device Boot    Start       End    Blocks   Id  System
> /dev/sda1             1      9345 300254724   83  Linux
>
> ------------
>
> When I subsequently try to create the XFS file system I get:
>
> ------------
>
> mkfs -t xfs -f /dev/sda1
>
> meta-data=/dev/sda1              isize=256    agcount=287, agsize=261546
> blks
> data     =                       bsize=4096   blocks=75063681, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=9163
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> mkfs.xfs: read failed: Input/output error
> mkfs.xfs: data size check failed
> mkfs.xfs: mount initialization failed
>
> ------------
>
> Although this fails, I can successfully create a Linux ext2 file system on
> the same partition, so I am confident that the physical hardware works.
> Additionally, I can successfully create a XFS file system on a local IDE
> hard disk, so I am fairly confident that the XFS stuff is correctly
> installed.
>
> cat /proc/filesystems suggests that XFS is supported by the kernel I am
> using, and I downloaded the latest XFS tools from the OSS SGI web site.
>
> Any idea why I cannot create the file system?
>
> Best regards,
> Mark.
>
> ====================================================
> Mark Wolforth               Email: mark@innovation-tk.com
> Senior Design Engineer      Voice: +44(0)1992 553533
> Innovation TK Limited       Fax  : +44(0)1992 558979

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Fri May 11 10:18:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BHIlO11692
	for linux-xfs-outgoing; Fri, 11 May 2001 10:18:47 -0700
Received: from e4isrv.webmail4less.com (g57-187.citenet.net [207.183.41.187])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BHIkF11689
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 10:18:46 -0700
Received: by e4isrv.webmail4less.com (Postfix, from userid 99)
	id 89AE81CE87F; Fri, 11 May 2001 13:18:40 -0400 (EDT)
To: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug... 
Message-ID: <989601520.3afc1ef08242d@jauvin.com.webmail4less.com>
Date: Fri, 11 May 2001 13:18:40 -0400 (EDT)
From: Marc Jauvin <marc@register4less.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: IMP/PHP IMAP webmail program 2.2.3
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I understand, but the file should have been kept to its original state, no? I
had garbage all over the file after the reset...


Russell Cattelan wrote:

> Marc Jauvin wrote:

>> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
>>
>> ----
>>
>> I installed XFS 1.0 for RedHat 7.1 and everything is great... until I did the
>> following:
>>
>> make modification to /etc/fstab, and IMMEDIATELY after saving the
>> modifications, I hit the reset button; when the system reboots, the
>> /etc/fstab is baddly corrupted and XFS does not fix it (end up using the
>> linux rescue disk to fix fstab manually\)
>>
>> I could reproduce the bug 2 times;

>> Any idea\?

> Yes don't do that.
> XFS uses delayed allocation / delayed write by default any data written
> immediacy before a crash probably won't be on
> disk, this is known behavior and isn't considered a bug, it's a trade off.
> Full sync mode on file systems is much safer and gives more likely hood of
> data integrity. caches gives much better
> performance but has the potential of losing cached data in the event of a
> crash.



--
marc.

3 out of 4 Americans make up 75% of the population.

From owner-linux-xfs@oss.sgi.com Fri May 11 11:24:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BIORE12912
	for linux-xfs-outgoing; Fri, 11 May 2001 11:24:27 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BIOQF12909
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:24:26 -0700
Received: from crom.corp.sgi.com ([130.62.63.32]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA05119
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:24:15 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA70510 for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:27:55 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 77CAF15A21B
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:22:57 -0700 (PDT)
Subject: Re: Benchmark
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <Pine.LNX.4.21.0105111820370.2957-100000@kalapati.jijo.local>
References: <Pine.LNX.4.21.0105111820370.2957-100000@kalapati.jijo.local>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 11 May 2001 11:22:57 -0700
Message-Id: <989605377.13414.3.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 11 May 2001 18:21:31 +0800, Federico Sevilla III wrote:
> 
> I'm not an expert on XFS, but I do recall someone on the list posting a
> message recently saying that it had something to do with the fact that XFS
> does synchronous file deletions, hence the speed issue.

Is it possible to mount an XFS partition so that deletes are NOT
synchronous?

-- 
Florin Andrei

"Remember, son:
if you never try, you never fail" - Homer Simpson


From owner-linux-xfs@oss.sgi.com Fri May 11 11:32:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BIWKh13111
	for linux-xfs-outgoing; Fri, 11 May 2001 11:32:20 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BIWBF13108
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:32:11 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA03471
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:43:01 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA83964; Fri, 11 May 2001 13:30:36 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4BITZe10379;
	Fri, 11 May 2001 14:29:36 -0400
Message-ID: <3AFC2F8F.D0530FFD@thebarn.com>
Date: Fri, 11 May 2001 14:29:35 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Rounds <markr@netsync.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Feedback
References: <200105111803.f4BI3Se12421@oss.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mark Rounds wrote:

> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
>
> ----
>
> I have noticed that the xfs kernels reconfigure the entire /dev directory.  Is the permanant\? If not, then when will the xfs linux kernel have a standard /dev directory. Was this to speed a version 1.0 with minimal porting to linux\?   I am concerned with this because of the dac960 driver and it's inability to react with the new /dev structure.

devfs is enabled by default.
Check the mail archives for numerous discussions of this.
devfs may be turned off by adding
append="denfs=nomount "
to lilo.

What is the problem your driver is having?



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Fri May 11 11:37:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BIb4u13192
	for linux-xfs-outgoing; Fri, 11 May 2001 11:37:04 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BIb3F13189
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:37:03 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA03803
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 11:35:40 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1785392; Fri, 11 May 2001 13:35:45 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA28166; Fri, 11 May 2001 13:35:45 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4BIcUt20833; Fri, 11 May 2001 13:38:30 -0500
Message-Id: <200105111838.f4BIcUt20833@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Florin Andrei <florin@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Benchmark 
In-Reply-To: Message from Florin Andrei <florin@sgi.com> 
   of "11 May 2001 11:22:57 PDT." <989605377.13414.3.camel@stantz.corp.sgi.com> 
Date: Fri, 11 May 2001 13:38:30 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On 11 May 2001 18:21:31 +0800, Federico Sevilla III wrote:
> > 
> > I'm not an expert on XFS, but I do recall someone on the list posting a
> > message recently saying that it had something to do with the fact that XFS
> > does synchronous file deletions, hence the speed issue.
> 
> Is it possible to mount an XFS partition so that deletes are NOT
> synchronous?

No, but you can make all the other transactions synchronous too so that the
deletes do not look as bad when compared to other operations ;-) This is
the wsync option.

The only way to experiment with this is to start commenting out
xfs_trans_set_sync calls in xfs. Can people either have a little
patience on this, or try stuff themselves, this is not going to
get changed from within SGI anytime soon, as I said the other day,
the todo list from this end is LONG.

If you want to experiment with XFS with a low latency log then try this
trick:

	o create a loop device on a file
	o make an xfs filesystem with an external log on the loop device

The writes to the log will still happen, but the disk will not be in the
picture in a synchronous manner since the loop device just copies into
pages in the page cache and flushing happens asynchronously.

> 
> -- 
> Florin Andrei
> 


Steve



From owner-linux-xfs@oss.sgi.com Fri May 11 12:06:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BJ6MG14505
	for linux-xfs-outgoing; Fri, 11 May 2001 12:06:22 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BJ6LF14502
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:06:21 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1276467
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 21:06:19 +0200 (CEST)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA94726 for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:09:58 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id A3D3915A21B
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:05:00 -0700 (PDT)
Subject: Re: Benchmark
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
In-Reply-To: <200105111838.f4BIcUt20833@jen.americas.sgi.com>
References: <200105111838.f4BIcUt20833@jen.americas.sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 11 May 2001 12:05:00 -0700
Message-Id: <989607900.13402.5.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 11 May 2001 13:38:30 -0500, Steve Lord wrote:
> > 
> > Is it possible to mount an XFS partition so that deletes are NOT
> > synchronous?
> 
> No, but you can make all the other transactions synchronous too so that the
> deletes do not look as bad when compared to other operations ;-) This is
> the wsync option.

mwaaahahahahahaha!!!

> The only way to experiment with this is to start commenting out
> xfs_trans_set_sync calls in xfs. Can people either have a little

It would be extremely cool and useful to have a mount option like, for
example, "-o delayed_write_tansactions" (you got the idea...).

It's arguable, yes, but sometimes it makes sense to have non-synchr.
write transactions. Since i installed and i'm taking care of Squid on
www-proxy.sgi.com :-) i'm thinking of situations like this one: imagine
a high-performance web proxy, with lots of requests, and the disk caches
full. Now, because the disks are full, you will have lots of removals
among the objects stored there (since new objects are forced into the
cache, and the old ones must die to make room). If delete is slow, the
whole thing will become extremely I/O bound.
Now, Squid is already I/O bound, so sync writes only make things worse.
Right now, the only place where i see ReiserFS as better than XFS is
Squid's cache. With non-sync write transactions, this will not be an
issue anymore.

I'm not sure about that, but i think this is the way Soft Updates from
FreeBSD is doing things. Maybe someone will correct me if i'm wrong.

And not to mention benchmarks. Now that XFS is becoming more and more
popular, people will start to compare it more often with other FSs. The
only way that XFS is clearly slower than others is deleting large trees.
>From the advertisement p.o.v. ;-) it's good to have a simple way to
avoid that.

> If you want to experiment with XFS with a low latency log then try this
> trick:
> 
>       o create a loop device on a file
>       o make an xfs filesystem with an external log on the loop device

Heh... Clever workaround... ;-)

-- 
Florin Andrei

"Remember, son:
if you never try, you never fail" - Homer Simpson


From owner-linux-xfs@oss.sgi.com Fri May 11 12:11:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BJBq615145
	for linux-xfs-outgoing; Fri, 11 May 2001 12:11:52 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BJBqF15142
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:11:52 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA06997
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 12:22:43 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA991055; Fri, 11 May 2001 14:10:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA97333; Fri, 11 May 2001 14:10:32 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4BJDGv21203; Fri, 11 May 2001 14:13:16 -0500
Message-Id: <200105111913.f4BJDGv21203@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dominik Epple <Dominik.Epple@gmx.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfsdump, xfsrestore and SUID files 
In-Reply-To: Message from Dominik Epple <Dominik.Epple@gmx.de> 
   of "Fri, 11 May 2001 18:17:35 +0200." <3AFC109F.E29D0581@gmx.de> 
Date: Fri, 11 May 2001 14:13:16 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> I just did a xfsdump/xfsrestore of a filesystem:
> 
> xfsdump -J -F -f /tmp/opt.xfsdump /opt
> [ ... shutdown of system, added new disk, mkfs.xfs etc... ]
> xfsrestore -f /tmp/opt.xfsdump -J .
> 
> All went fine except that SUID files of the source file system were no
> SUID files after the dump/restore cycle anymore.
> 
> I did not find any hints in the man pages about that. I guess it is a
> security feature, but how can i turn this off? I mean, I want the
> restored filesystem to be an exact copy of the source...
> 
> I dont think it is of importance, but let me note however that I am
> using lvm.
> 
> TIA, Dominik

Hmm, I am informed that restore should create the file, write the data
into it, and then restore the mode flags - including suid. A quick test
shows that this is the case, but that the suid bit is not coming back, using
strace it is not even getting set. I suspect the problem may be in the dump
phase not the restore phase.

Steve



From owner-linux-xfs@oss.sgi.com Fri May 11 13:20:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BKK6L03664
	for linux-xfs-outgoing; Fri, 11 May 2001 13:20:06 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BKK4F03653
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 13:20:04 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA1285016
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 22:20:01 +0200 (CEST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA16989; Fri, 11 May 2001 15:18:44 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f4BKHiY12082;
	Fri, 11 May 2001 16:17:44 -0400
Date: Fri, 11 May 2001 16:17:44 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105112017.f4BKHiY12082@gibble.americas.sgi.com>
Subject: TAKE - 822884 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Fri May 11 13:16:24 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94715a
linux/fs/xfs/linux/xfs_ioctl.c - 1.36
	- When doing and open_by_handle. Look in dcache for an existing inode entry,
	  if exists drop the inode count and do not create a new dcache entry.
	  The i_count was then to high and not part of a parent tree, 
	  therefore it wasn't being cleaned up at umount time.
	  Consistency change: use xfs_iget (which does all the necessary setup on
	  vnode) rather than iget.

linux/kdb/modules/kdbm_pg.c - 1.35
	- Added printing of inode flags.



From owner-linux-xfs@oss.sgi.com Fri May 11 14:09:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4BL96M18328
	for linux-xfs-outgoing; Fri, 11 May 2001 14:09:06 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4BL94F18317
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 14:09:04 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 820B5CAC50A
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 17:09:03 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 14yK8Q-0004wp-00
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 17:07:38 -0400
Date: Fri, 11 May 2001 17:07:38 -0400
To: linux-xfs@oss.sgi.com
Subject: XFS + Oracle Install
Message-ID: <20010511170738.B24494@chimesnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

When using the oracle(81701) install on a xfs filesystem, the install fails
as it attempts to read/write state files.  

Oracle installs readily on reiser and ext2 fs

Pertinent info:
linux-xfs (11 05 2001)

using lvm and xfs
parition is 4GB

info from installActions.log

Unable to read /oracle/oraInventory/Contents/CompsList0.ser. Some inventory information may be lost.
Unable to read /oracle/oraInventory/Contents/PatchesList0.ser. Some inventory information may be lost.

Miscellaneous problem
Unable to read /oracle/oraInventory/Contents/OracleHomesList.ser. Some inventory information may be lost.
Unable to read /oracle/oraInventory/Contents/LibsList.ser. Some inventory information may be lost.

The workaround is to install oracle on ext2 fs, and then cpio over to the xfs fs.

From owner-linux-xfs@oss.sgi.com Fri May 11 19:23:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4C2Nlc28603
	for linux-xfs-outgoing; Fri, 11 May 2001 19:23:47 -0700
Received: from front1.netvisao.pt ([213.228.128.56])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4C2NkF28600
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 19:23:46 -0700
Received: (qmail 28065 invoked from network); 12 May 2001 02:24:52 -0000
Received: from unknown (HELO netvisao.pt) (217.129.179.243)
  by front1.netvisao.pt with SMTP; 12 May 2001 02:24:52 -0000
Message-ID: <3AFCA08B.FBD465DA@netvisao.pt>
Date: Sat, 12 May 2001 03:31:39 +0100
From: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: ACLs vs. umask question
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I'm considering using XFS mainly because of ACL support.
But since i read the following quoatation in URL...

http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00368.html

"The 1.0 release, however, applies default ACLs which are
affected by the umask. This has been fixed in the CVS tree
so that default ACLs are used in preference to the umask.
(the fix didn't make it in time to 1.0)."

...i have a question:
Does this mean that ACL is *really* not working because is overrided by
umask, or is it just the default behaviour which in turn can be
overrided by means of some configuration?

Thanks in advance.

Mário Gamito
pt is for Portugal

From owner-linux-xfs@oss.sgi.com Fri May 11 20:06:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4C36DO29080
	for linux-xfs-outgoing; Fri, 11 May 2001 20:06:13 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C36CF29077
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 20:06:12 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA18336
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 20:04:48 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA28811; Sat, 12 May 2001 13:04:54 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA49991;
	Sat, 12 May 2001 13:04:53 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Sat, 12 May 2001 13:04:53 +1000
To: Andi Kleen <ak@suse.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump safe?
In-Reply-To: <20010511145453.A10184@gruyere.muc.suse.de>
Message-ID: <Pine.SGI.4.32.0105121257590.48937-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 11 May 2001, Andi Kleen wrote:

> On Fri, May 11, 2001 at 10:31:46PM +1000, Ivan Rayner wrote:
> > On Fri, 11 May 2001, Andi Kleen wrote:
> >
> > > Regarding xfsdump:
> > >
> > > The qlock functions seem to be dummied out (inside #ifdef HIDDEN), but
> > > it still seems to create threads in some circumstances, which probably need
> > > locking. Is it really safe to use?
> >
> > I think you'll find that the linux version of xfsdump runs in single
> > threaded mode.  This is controlled by the 'miniroot' flag which is set to
> > true on Linux - the key bits are around line 604 in cmd/xfsdump/common/main.c.
>
> As far as I can see common/drive_{scsitape,minrmt}.c do not check that
> flag before calling cldmgr_create()

Looking at drive_scsitape.c (should be the same for minrmt)
cldmgr_create() is called from ring_thread() which is called by
ring_create() as a callback. ring_create() should not be called in
singlethreaded mode - see the lines around 658 in drive_scsitape.c.

(You'll note that the miniroot flag I mentioned earlier becomes the
'singlethreaded' flag in the drive*.c files.)

Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com


From owner-linux-xfs@oss.sgi.com Fri May 11 20:31:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4C3V1J29445
	for linux-xfs-outgoing; Fri, 11 May 2001 20:31:01 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C3UwF29442
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 20:30:59 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4C3Usv18239
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 11:30:54 +0800
Received: from kalapati ([203.167.1.119]) by sisa.i-manila.com.ph ; Sat, 12 May 2001 11:30:56 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 97F5919484
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 11:30:37 +0800 (PHT)
Date: Sat, 12 May 2001 11:30:36 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Patches needed when using the cvs patch
Message-ID: <Pine.LNX.4.21.0105121121480.10829-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I'm just wondering, when using a patch like:

ftp://oss.sgi.com/projects/xfs/download/patches/linux-2.4.4-xfs-cvs-05022001.patch.gz

do I still need the core XFS support for Linux that comes in the form of
patches like:

ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/linux-2.4.3-core-xfs-1.0.patch.gz

or is core support built into the CVS patches? I'm thinking of giving
Linux 2.4.4 with XFS a shot ("a grain of salt"), but I don't know which
patches to get and which I can skip. :)

Thanks a lot in advance!

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Fri May 11 20:46:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4C3k6L29638
	for linux-xfs-outgoing; Fri, 11 May 2001 20:46:06 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C3k5F29635
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 20:46:06 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4C3jvk06918;
	Fri, 11 May 2001 22:45:57 -0500 (CDT)
Message-ID: <3AFCB276.CF502489@sgi.com>
Date: Fri, 11 May 2001 22:48:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Sevilla III <jijo@i-manila.com.ph>
CC: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Patches needed when using the cvs patch
References: <Pine.LNX.4.21.0105121121480.10829-100000@kalapati.jijo.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The CVS patches are all-in-one, everything you need, including all the
CVS tags etc.

-Eric

Federico Sevilla III wrote:
> 
> Hi everyone,
> 
> I'm just wondering, when using a patch like:

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May 11 20:48:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4C3mq629671
	for linux-xfs-outgoing; Fri, 11 May 2001 20:48:52 -0700
Received: from www.scenespot.org (IDENT:root@scenespot.org [216.254.101.223])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4C3moF29668
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 20:48:51 -0700
Received: from localhost (IDENT:ranger@localhost [127.0.0.1])
	by www.scenespot.org (8.10.1/8.10.1) with ESMTP id f4C3mon11073
	for <linux-xfs@oss.sgi.com>; Fri, 11 May 2001 23:48:51 -0400
Date: Fri, 11 May 2001 23:48:50 -0400 (EDT)
From: Benjamin Reed <ranger@befunk.com>
X-Sender: ranger@www.scenespot.org
To: linux-xfs@oss.sgi.com
Subject: masochism (software RAID5 XFS root)
Message-ID: <Pine.LNX.4.21.0105112345160.10913-100000@www.scenespot.org>
X-URL: http://defiance.dyndns.org/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm attempting to do a software RAID bootstrap with redhat 7.1 and a
custom-compiled (from CVS, as of about 20 minutes ago) kernel.

it is on a software raid5 root, formatted XFS, and it refuses to boot.  :(

I get:

EXT2-fs: unable to read superblock
XFS: SB read failed
Kernel panic: VFS: Unable to mount root fs on 09:01

...so before I try to go any further, is this even possible?  Or is it not
supported...

-- 
Ben Reed a.k.a. Ranger Rick (ranger@befunk.com)
http://defiance.dyndns.org/ / http://radio.scenespot.org/
A preposition is something one should never end a sentence with.
Now playing on Defiance Radio: Somebody by Depeche Mode


From owner-linux-xfs@oss.sgi.com Sat May 12 03:44:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CAiul02303
	for linux-xfs-outgoing; Sat, 12 May 2001 03:44:56 -0700
Received: from hotmail.com (f115.law7.hotmail.com [216.33.237.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CAitF02300
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 03:44:55 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Sat, 12 May 2001 03:44:50 -0700
Received: from 207.217.38.78 by lw7fd.law7.hotmail.msn.com with HTTP;	Sat, 12 May 2001 10:44:49 GMT
X-Originating-IP: [207.217.38.78]
From: "Mr Lancealot" <mrlancealot@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: Expanding XFS with DAC960
Date: Sat, 12 May 2001 03:44:49 -0700
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F1157tXjs5FGJziWwSo00004864@hotmail.com>
X-OriginalArrivalTime: 12 May 2001 10:44:50.0214 (UTC) FILETIME=[91E52460:01C0DAD0]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  What do you have to do to make use of a new harddrive added to a RAID 
setup with a DAC960 device.  I think Mylex has something in their software 
to do this (I think they call their online raid expansion M.O.R.E).  I was 
wondering if I just add the harddrive and then use the grow_fs (or was it 
expand_fs) utility to expand the filesystem to take up the new drive?  I 
have yet to grow my RAID with the Mylex controller, and want to make sure 
the process is the same for XFS as it would be with a EXT2 setup.  Thanks.

PS: Sorry for any advertisements this damn hotmail account sends out.  Its 
just that my hotmail account is the easiest thing to access from anywhere. 
Hopfully it doesn't send it in HTML format again (I think I turned it off). 
Thanks all.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-linux-xfs@oss.sgi.com Sat May 12 06:40:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CDeQM04238
	for linux-xfs-outgoing; Sat, 12 May 2001 06:40:26 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CDePF04235
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 06:40:26 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA21244
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 06:39:02 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1793832; Sat, 12 May 2001 08:39:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA93682; Sat, 12 May 2001 08:39:07 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4CDfiE10139; Sat, 12 May 2001 08:41:44 -0500
Message-Id: <200105121341.f4CDfiE10139@jen.americas.sgi.com>
To: "Mr Lancealot" <mrlancealot@hotmail.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Expanding XFS with DAC960 
References: <F1157tXjs5FGJziWwSo00004864@hotmail.com>
Comments: In-reply-to "Mr Lancealot" <mrlancealot@hotmail.com>
   message dated "Sat, 12 May 2001 03:44:49 -0700."
Date: Sat, 12 May 2001 08:41:44 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>   What do you have to do to make use of a new harddrive added to a RAID 
> setup with a DAC960 device.  I think Mylex has something in their software 
> to do this (I think they call their online raid expansion M.O.R.E).  I was 
> wondering if I just add the harddrive and then use the grow_fs (or was it 
> expand_fs) utility to expand the filesystem to take up the new drive?  I 
> have yet to grow my RAID with the Mylex controller, and want to make sure 
> the process is the same for XFS as it would be with a EXT2 setup.  Thanks.
> 
> PS: Sorry for any advertisements this damn hotmail account sends out.  Its 
> just that my hotmail account is the easiest thing to access from anywhere. 
> Hopfully it doesn't send it in HTML format again (I think I turned it off). 
> Thanks all.

There are usually two steps in this type of process, one with the controller
or volume manager telling it where the new disk should go (which device
it becomes part of). I have no experience with the DAC960, so I cannot
help with this.

Then, with the xfs filesystem mounted, you use xfs_growfs to expand the
filesystem to use the space.

Steve


From owner-linux-xfs@oss.sgi.com Sat May 12 08:07:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CF7tK04955
	for linux-xfs-outgoing; Sat, 12 May 2001 08:07:55 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CF7sF04952
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 08:07:54 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 94894CE65; Sat, 12 May 2001 17:05:24 +0100 (BST)
To: "linux" <dahouet@gmx.net>
Cc: Andriy.Bilous@satama.de, linux-xfs@oss.sgi.com
Subject: Re: Problem compliling kernel
References: <Pine.LNX.4.21.0105052343370.1042-100000@bellapc.satama>
	<200105060100330924.019315D3@mail.gmx.de>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 12 May 2001 17:05:24 +0100
In-Reply-To: <200105060100330924.019315D3@mail.gmx.de> ("linux"'s message of "Sun, 06 May 2001 01:00:33 +0200")
Message-ID: <m3r8xu364b.fsf@giants.mandrakesoft.com>
Lines: 17
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"linux" <dahouet@gmx.net> writes:

> i tried this once but it was complaining about not finding cpp0
> [root@bretagne linux-xfs]# make bzImage
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/split-include scripts/split-include.c
> scripts/split-include include/linux/autoconf.h include/config
> gcc -V egcs-2.91.66 -D__KERNEL__ -I/usr/src/linux-xfs/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe  -march=i686 -malign-functions=4    -c -o init/main.o init/main.c
> gcc: installation problem, cannot exec `cpp0': Aucun fichier ou r?pertoire de ce type
> make: *** [init/main.o] Erreur 1
> [root@bretagne linux-xfs]# locate cpp0
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/cpp0
> /usr/lib/gcc-lib/i586-mandrake-linux/2.96/tradcpp0
> 
> cpp0 is not at the right place ? where do i put it  ?

upgrade your egcs package, seems like you have installed a gcc-2.96 of
8.0 with egcs package of 7.2.

From owner-linux-xfs@oss.sgi.com Sat May 12 08:39:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CFdhk05240
	for linux-xfs-outgoing; Sat, 12 May 2001 08:39:43 -0700
Received: from io.cox-internet.com (io-cox.cox-internet.com [208.180.118.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CFdgF05237
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 08:39:42 -0700
Received: from cdm-193-4-vict.cox-internet.com ([206.96.193.4])
          by io.cox-internet.com
          (InterMail vK.4.02.00.10 201-232-116-110 license d1ebd4f8b91132ed01cf0e3e933da025)
          with ESMTP
          id <20010512153829.LFSF19428.io@cdm-193-4-vict.cox-internet.com>
          for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 10:38:29 -0500
Subject: xfsdump gui
From: Michael Vanderford <michaelv@cox-internet.com>
To: linux-xfs@oss.sgi.com
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 12 May 2001 10:51:22 -0500
Message-Id: <989682683.24235.0.camel@cdm-193-4-vict.cox-internet.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is there a GUI for xfsdump:xfsrestore
Thanks.


From owner-linux-xfs@oss.sgi.com Sat May 12 08:51:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CFpPo05381
	for linux-xfs-outgoing; Sat, 12 May 2001 08:51:25 -0700
Received: from egghead.curl.com (egghead.curl.com [216.230.83.4])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4CFpPF05377
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 08:51:25 -0700
Received: (qmail 10043 invoked by uid 10171); 12 May 2001 11:51:14 -0400
From: patl@cag.lcs.mit.edu (Patrick J. LoPresti)
To: Russell Cattelan <cattelan@thebarn.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
Distribution: local
References: <200105111625.f4BGP9u10062@oss.sgi.com> <a3AFC1625.44E539C8@thebarn.com>
Date: 12 May 2001 11:51:14 -0400
In-Reply-To: <mit.lcs.mail.linux-xfs/3AFC1625.44E539C8@thebarn.com>
Message-ID: <s5gheyq8t1p.fsf@egghead.curl.com>
Lines: 15
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

> XFS uses delayed allocation / delayed write by default any data
> written immediacy before a crash probably won't be on disk, this is
> known behavior and isn't considered a bug, it's a trade off.

Is this true even if I call fsync() or fdatasync() on the file?

I am wondering about this because some applications (e.g., qmail)
create a temp file, call fsync() to flush it to stable storage, use
rename() to "commit" the file to its final home.

With XFS, is this a reliable way to update a file on disk, or not?

 - Pat

From owner-linux-xfs@oss.sgi.com Sat May 12 09:16:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4CGGGC05678
	for linux-xfs-outgoing; Sat, 12 May 2001 09:16:16 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4CGGFF05675
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 09:16:15 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4CGGCmZ089877;
	Sat, 12 May 2001 11:16:12 -0500 (CDT)
Message-ID: <3AFD61C6.15877F7E@thebarn.com>
Date: Sat, 12 May 2001 11:16:07 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Patrick J. LoPresti" <patl@cag.lcs.mit.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
References: <200105111625.f4BGP9u10062@oss.sgi.com> <a3AFC1625.44E539C8@thebarn.com> <s5gheyq8t1p.fsf@egghead.curl.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Patrick J. LoPresti" wrote:

> Russell Cattelan <cattelan@thebarn.com> writes:
>
> > XFS uses delayed allocation / delayed write by default any data
> > written immediacy before a crash probably won't be on disk, this is
> > known behavior and isn't considered a bug, it's a trade off.
>
> Is this true even if I call fsync() or fdatasync() on the file?
>
> I am wondering about this because some applications (e.g., qmail)
> create a temp file, call fsync() to flush it to stable storage, use
> rename() to "commit" the file to its final home.
>
> With XFS, is this a reliable way to update a file on disk, or not?

Yes that is exactly what an application should do to ensure the
data has been written to disk.


>
>
>  - Pat

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat May 12 17:06:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D067013550
	for linux-xfs-outgoing; Sat, 12 May 2001 17:06:07 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D066F13547
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 17:06:06 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4D04gL13735;
	Sat, 12 May 2001 19:04:43 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sat, 12 May 2001 19:04:41 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Tom Carroll <tcarroll@chimesnet.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS + Oracle Install
In-Reply-To: <20010511170738.B24494@chimesnet.com>
Message-ID: <Pine.LNX.4.33.0105121901400.13692-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Well, here's a better thought. Install your oracle to Reiser only, leave
it there, put all the things which matter more on xfs, rollback, redo,
archive, data, index, etc. That way you aren't having too many issues with
moving oracle around. Less work I think. Anyway, it's a thought.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 11 May 2001, Tom Carroll wrote:

> When using the oracle(81701) install on a xfs filesystem, the install fails
> as it attempts to read/write state files.
>
> Oracle installs readily on reiser and ext2 fs
>
> Pertinent info:
> linux-xfs (11 05 2001)
>
> using lvm and xfs
> parition is 4GB
>
> info from installActions.log
>
> Unable to read /oracle/oraInventory/Contents/CompsList0.ser. Some inventory information may be lost.
> Unable to read /oracle/oraInventory/Contents/PatchesList0.ser. Some inventory information may be lost.
>
> Miscellaneous problem
> Unable to read /oracle/oraInventory/Contents/OracleHomesList.ser. Some inventory information may be lost.
> Unable to read /oracle/oraInventory/Contents/LibsList.ser. Some inventory information may be lost.
>
> The workaround is to install oracle on ext2 fs, and then cpio over to the xfs fs.
>


From owner-linux-xfs@oss.sgi.com Sat May 12 17:08:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D08po13581
	for linux-xfs-outgoing; Sat, 12 May 2001 17:08:51 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D08oF13578
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 17:08:50 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4D06AJ13747;
	Sat, 12 May 2001 19:06:10 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sat, 12 May 2001 19:06:10 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Marc Jauvin <marc@register4less.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Might have found a bug... 
In-Reply-To: <989601520.3afc1ef08242d@jauvin.com.webmail4less.com>
Message-ID: <Pine.LNX.4.33.0105121905420.13692-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is there anyway to mount with less latency on the writes?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 11 May 2001, Marc Jauvin wrote:

> I understand, but the file should have been kept to its original state, no? I
> had garbage all over the file after the reset...
>
>
> Russell Cattelan wrote:
>
> > Marc Jauvin wrote:
>
> >> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
> >>
> >> ----
> >>
> >> I installed XFS 1.0 for RedHat 7.1 and everything is great... until I did the
> >> following:
> >>
> >> make modification to /etc/fstab, and IMMEDIATELY after saving the
> >> modifications, I hit the reset button; when the system reboots, the
> >> /etc/fstab is baddly corrupted and XFS does not fix it (end up using the
> >> linux rescue disk to fix fstab manually\)
> >>
> >> I could reproduce the bug 2 times;
>
> >> Any idea\?
>
> > Yes don't do that.
> > XFS uses delayed allocation / delayed write by default any data written
> > immediacy before a crash probably won't be on
> > disk, this is known behavior and isn't considered a bug, it's a trade off.
> > Full sync mode on file systems is much safer and gives more likely hood of
> > data integrity. caches gives much better
> > performance but has the potential of losing cached data in the event of a
> > crash.
>
>
>
> --
> marc.
>
> 3 out of 4 Americans make up 75% of the population.
>


From owner-linux-xfs@oss.sgi.com Sat May 12 17:10:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D0AEu13621
	for linux-xfs-outgoing; Sat, 12 May 2001 17:10:14 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D0ADF13617
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 17:10:14 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4D07Qa13756;
	Sat, 12 May 2001 19:07:26 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sat, 12 May 2001 19:07:26 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: IFIX Computer Solutions <dsainty@zip.com.au>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Long Term Commitment to Linux XFS, 
In-Reply-To: <Pine.LNX.4.30.0105110752470.18660-100000@zipperii.zip.com.au>
Message-ID: <Pine.LNX.4.33.0105121906510.13692-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm in the same boat on this one. Perhaps also a matrix of possible
hardware/software combinations that will yield maximum performance?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 11 May 2001, IFIX Computer Solutions wrote:

> Hi,
>
> I've heard some bad rumours about SGI's possible long term commitment to
> XFS on Linux....  Do you have any sort of statement or position with
> respect to the commitment to support Linux XFS into the future?
>
> My colleagues and I are currently evaluating the use of either XFS or
> Reiser FS on Linux, and we require as much of a commitment as possible
> that SGI will continue to actively support Linux XFS into the future.
> Unfortunately, whilst XFS is a superior journalling FS for Linux, its
> development has not yet been very actively worked on by people other
> than SGI employees, so its usefulness could be affected by any SGI cuts
> in open source development (which would be a great shame).
>
> Please give me some good news or positive response so I can re-assure a
> few people I know. :-)  Anyway, fantastic work on getting 1.0 out. I've
> heard only good things and plan to test it in the next week...
>
> Best Regards and TIA,
>
>
> DS..
>


From owner-linux-xfs@oss.sgi.com Sat May 12 17:42:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D0gO913888
	for linux-xfs-outgoing; Sat, 12 May 2001 17:42:24 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D0gNF13885
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 17:42:23 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4D0gF022860;
	Sat, 12 May 2001 19:42:15 -0500 (CDT)
Message-ID: <3AFDD8EE.4D54AFF9@sgi.com>
Date: Sat, 12 May 2001 19:44:30 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Carroll <tcarroll@chimesnet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS + Oracle Install
References: <20010511170738.B24494@chimesnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Carroll wrote:

> When using the oracle(81701) install on a xfs filesystem, the install fails
> as it attempts to read/write state files. 

...

> info from installActions.log
> 
> Unable to read /oracle/oraInventory/Contents/CompsList0.ser. Some inventory information may be lost.
> Unable to read /oracle/oraInventory/Contents/PatchesList0.ser. Some inventory information may be lost.

Hi Tom - We'll probably need a little more info on that one... "Unable
to read" is a little vague!  Are there any other error messages in the
system logs?

I can see if anyone in Mtn. View or Eagan has Oracle to test this with -
I don't have it here.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May 12 18:59:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D1xCp14788
	for linux-xfs-outgoing; Sat, 12 May 2001 18:59:12 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D1xBF14785
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 18:59:11 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id DAA1286628
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 03:59:07 +0200 (CEST)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA07728
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 18:57:48 -0700 (PDT)
Date: Sat, 12 May 2001 18:57:08 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: <linux-xfs@oss.sgi.com>
Subject: xfs on small memory
Message-ID: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I was wondering what the smallest memory system somebody has tried XFS
on.  The webpage says 64MB minimum and I know that I have seen XFS working
on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?

Ananth told me that the recovery was the most memory intensive part...so,
I would like to know if anybody has gone through a recovery on a low
memory system and things have been OK...or not?

thanks,

-tduffy


From owner-linux-xfs@oss.sgi.com Sat May 12 19:33:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D2XQN15175
	for linux-xfs-outgoing; Sat, 12 May 2001 19:33:26 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D2XPF15172
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 19:33:25 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA04878
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 19:44:19 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA82208;
	Sat, 12 May 2001 19:32:08 -0700 (PDT)
Date: Sat, 12 May 2001 19:31:28 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Michael Vanderford <michaelv@cox-internet.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump gui
In-Reply-To: <989682683.24235.0.camel@cdm-193-4-vict.cox-internet.com>
Message-ID: <Pine.LNX.4.33.0105121930240.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 12 May 2001, Michael Vanderford wrote:

> Is there a GUI for xfsdump:xfsrestore

no, not on linux AFAIK...wanna write one?

-tduffy

ps, gui's shmui's


From owner-linux-xfs@oss.sgi.com Sat May 12 19:44:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D2iUc15285
	for linux-xfs-outgoing; Sat, 12 May 2001 19:44:30 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D2iSF15282
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 19:44:29 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA1311667
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 04:44:24 +0200 (CEST)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA18279;
	Sat, 12 May 2001 19:43:06 -0700 (PDT)
Date: Sat, 12 May 2001 19:42:26 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Benjamin Reed <ranger@befunk.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: masochism (software RAID5 XFS root)
In-Reply-To: <Pine.LNX.4.21.0105112345160.10913-100000@www.scenespot.org>
Message-ID: <Pine.LNX.4.33.0105121939250.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

yes, raid 5 works fine on xfs...although, I have not tried a root
device...

-tduffy

ps, I have tried a 180GB 12disk md RAID5 system with xfs (for serving
porn^H^H^H^Hmp3s^H^H^H^Hdata...)

On Fri, 11 May 2001, Benjamin Reed wrote:

> I'm attempting to do a software RAID bootstrap with redhat 7.1 and a
> custom-compiled (from CVS, as of about 20 minutes ago) kernel.
>
> it is on a software raid5 root, formatted XFS, and it refuses to boot.  :(
>
> I get:
>
> EXT2-fs: unable to read superblock
> XFS: SB read failed
> Kernel panic: VFS: Unable to mount root fs on 09:01
>
> ...so before I try to go any further, is this even possible?  Or is it not
> supported...
>
>


From owner-linux-xfs@oss.sgi.com Sat May 12 19:50:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D2oOK15359
	for linux-xfs-outgoing; Sat, 12 May 2001 19:50:24 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D2oMF15355
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 19:50:22 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4D2oKv23573
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 10:50:20 +0800
Received: from kalapati ([203.167.9.52]) by sisa.i-manila.com.ph ; Sun, 13 May 2001 10:50:23 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 7FAEB1211
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 10:50:15 +0800 (PHT)
Date: Sun, 13 May 2001 10:50:15 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: biosize=13
Message-ID: <Pine.LNX.4.21.0105131047020.4341-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I remember a message awhile back saying that the benefits of setting the
mount option biosize=13 plus more would be incorporated in development
versions of XFS. So I'm wondering, will it still be benefitial on an ia32
machine to mount an XFS filesystem using the "biosize=13" option if the
system is running on Linux kernel 2.4.4 with the following
linux-2.4.4-xfs-cvs-05022001 patch?

Also, would there be any tips related to performance when creating the XFS
filesystem? For example, should a certain option be used of most of the
files will be small, a certain option for mixed large files and small
files, et al. The same question goes for mount points. Or maybe someone
has a website with XFS performance tips? I remember someone else asking
this question awhile back, too.

I hope you all don't mind the questions. I'm in an asking mood today.
Thanks a lot in advance for the help!

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sat May 12 20:13:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D3Dt215641
	for linux-xfs-outgoing; Sat, 12 May 2001 20:13:55 -0700
Received: from dragon.vcu.edu (dragon.vcu.edu [128.172.65.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D3DsF15638
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 20:13:54 -0700
Received: from [192.168.1.11] (64.83.12.50.dsl50-static-ric.cavtel.net [64.83.12.50] (may be forged))
	by dragon.vcu.edu (8.9.3/8.9.3) with ESMTP id XAA7894089
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 23:14:08 -0400 (EDT)
Date: Sat, 12 May 2001 23:04:01 -0400 (EDT)
From: "K. Mitchell Russell" <krussell@hsc.vcu.edu>
X-X-Sender:  <krussell@loxias.amicable-enterprises.com>
To: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump gui
In-Reply-To: <Pine.LNX.4.33.0105121930240.300-100000@dbear.engr.sgi.com>
Message-ID: <Pine.LNX.4.33.0105122300420.3328-100000@loxias.amicable-enterprises.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, 12 May 2001, Tom Duffy wrote:

> On 12 May 2001, Michael Vanderford wrote:
>
> > Is there a GUI for xfsdump:xfsrestore
>
> no, not on linux AFAIK...wanna write one?
>
> -tduffy
>
> ps, gui's shmui's

a xfsdump gui is kind of wasted resource... but an ncurses menu would be
schweet

-Mitchell


From owner-linux-xfs@oss.sgi.com Sat May 12 20:28:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D3SYP15947
	for linux-xfs-outgoing; Sat, 12 May 2001 20:28:34 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D3SUF15941
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 20:28:30 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4D3SM014473;
	Sat, 12 May 2001 22:28:22 -0500 (CDT)
Message-ID: <3AFDFFDE.55019D91@sgi.com>
Date: Sat, 12 May 2001 22:30:38 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Sevilla III <jijo@i-manila.com.ph>
CC: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: biosize=13
References: <Pine.LNX.4.21.0105131047020.4341-100000@kalapati.jijo.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Federico Sevilla III wrote:

> So I'm wondering, will it still be benefitial on an ia32
> machine to mount an XFS filesystem using the "biosize=13" option if the
> system is running on Linux kernel 2.4.4 with the following
> linux-2.4.4-xfs-cvs-05022001 patch?

That patch should have the relevant change included already, the option
isn't needed in that case.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May 12 20:38:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D3c3r16047
	for linux-xfs-outgoing; Sat, 12 May 2001 20:38:03 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D3c1F16044
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 20:38:01 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4D3bwv27566
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 11:37:58 +0800
Received: from kalapati ([203.167.9.52]) by sisa.i-manila.com.ph ; Sun, 13 May 2001 11:37:55 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 160381B555
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 11:37:09 +0800 (PHT)
Date: Sun, 13 May 2001 11:37:08 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: CVS
Message-ID: <Pine.LNX.4.21.0105131135560.4341-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I'm checking out the linux-2.4-xfs tree in CVS, and noticed I'm
downloading the entire Linux kernel along with it, which is okay since
updates are incremental anyway. I'm wondering, what version of the Linux
kernel is in the linux-2.4-xfs tree in CVS right now?

Thanks!

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sat May 12 20:59:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D3xeP16289
	for linux-xfs-outgoing; Sat, 12 May 2001 20:59:40 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D3xdF16286
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 20:59:39 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4D3xamZ095477;
	Sat, 12 May 2001 22:59:36 -0500 (CDT)
Message-ID: <3AFE06A2.D2AF6F6D@thebarn.com>
Date: Sat, 12 May 2001 22:59:31 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Duffy <tduffy@engr.sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs on small memory
References: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Duffy wrote:

> I was wondering what the smallest memory system somebody has tried XFS
> on.  The webpage says 64MB minimum and I know that I have seen XFS working
> on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?
>
> Ananth told me that the recovery was the most memory intensive part...so,
> I would like to know if anybody has gone through a recovery on a low
> memory system and things have been OK...or not?
>
> thanks,
>

So here is an aging machine for you...
32meg p90... just fast enough to run xmms :-)
Yes hard to believe I'm actually running a linux box at home.

/dev/ide/host0/bus0/target0/lun0/part1 on /music type xfs (rw)
/dev/ide/host0/bus0/target0/lun0/part1
                      80037232  36692548  43344684  46% /music

May 12 22:24:06 funky kernel: Pagebuf cache Copyright (c) 2001 Silicon
Graphics, Inc.
May 12 22:24:06 funky kernel: XFS filesystem Copyright (c) 2001 Silicon
Graphics, Inc.
May 12 22:24:06 funky kernel: Start mounting filesystem: ide0(3,1)
May 12 22:24:06 funky kernel: Starting XFS recovery on filesystem: ide0(3,1)
(dev: 3/1)
May 12 22:24:06 funky kernel: Ending XFS recovery on filesystem: ide0(3,1)
(dev: 3/1)


>

> funky[10:18pm]-=>hinv
> Main memory size: 32 Mbytes
> 1 GenuineIntel Pentium 75 - 200 processor
> 2 16550A serial ports
> 1 post-1991 82077 floppy controller
> 1 1.44M floppy drive
> 1 vga+ graphics device
> 2 IDE devices:
>   /dev/hda: 160086528 sectors (81964 MB) w/2048KiB Cache, CHS=158816/16/63
>   /dev/hdb: ATAPI 4X CD-ROM drive, 128kB Cache
> 1 ethernet interface
>   eth0: 3Com PCI 3c905 Boomerang 100baseTx
> Sound devices:
>   1 Timer
>     system timer
>   1 Mixer
>     CMedia PCI
> PCI bus devices:
>     Class 0406: Silicon Integrated Systems [SiS] 85C501/2 (rev 57).
>     Non-VGA unclassified device: Silicon Integrated Systems [SiS]
> 85C503/5513 (rev 0).
>     IDE interface: OPTi Inc. 82C621 (rev 0).
>     Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 16).
>     Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev
> 0).
>     VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX]
> (rev 0).
>
> -tduffy

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sat May 12 21:09:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D491616475
	for linux-xfs-outgoing; Sat, 12 May 2001 21:09:01 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D490F16472
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 21:09:00 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4D48rf15785;
	Sat, 12 May 2001 23:08:53 -0500 (CDT)
Message-ID: <3AFE095C.CCA3FB69@sgi.com>
Date: Sat, 12 May 2001 23:11:08 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Sevilla III <jijo@i-manila.com.ph>
CC: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: CVS
References: <Pine.LNX.4.21.0105131135560.4341-100000@kalapati.jijo.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Federico Sevilla III wrote:

> I'm wondering, what version of the Linux
> kernel is in the linux-2.4-xfs tree in CVS right now?

in linux-2.4-xfs (devel tree) it's 2.4.4.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May 12 22:20:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D5K1q17283
	for linux-xfs-outgoing; Sat, 12 May 2001 22:20:01 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D5K0F17279
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 22:20:00 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4D5HF715342;
	Sun, 13 May 2001 00:17:15 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sun, 13 May 2001 00:17:14 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: CVS
In-Reply-To: <Pine.LNX.4.21.0105131135560.4341-100000@kalapati.jijo.local>
Message-ID: <Pine.LNX.4.33.0105130016430.15316-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

2.4.4.

I'd like to see a cvs download of just the development patchset as
well..anyone?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Sun, 13 May 2001, Federico Sevilla III wrote:

> Hi everyone,
>
> I'm checking out the linux-2.4-xfs tree in CVS, and noticed I'm
> downloading the entire Linux kernel along with it, which is okay since
> updates are incremental anyway. I'm wondering, what version of the Linux
> kernel is in the linux-2.4-xfs tree in CVS right now?
>
> Thanks!
>
>  --> Jijo
>
> ---
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly
>


From owner-linux-xfs@oss.sgi.com Sat May 12 22:52:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D5qgS17545
	for linux-xfs-outgoing; Sat, 12 May 2001 22:52:42 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D5qfF17542
	for <linux-xfs@oss.sgi.com>; Sat, 12 May 2001 22:52:41 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP
	id 3B5B4CAC507; Sun, 13 May 2001 01:52:24 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 14yomL-0005Sv-00; Sun, 13 May 2001 01:50:53 -0400
Date: Sun, 13 May 2001 01:50:52 -0400
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS + Oracle Install
Message-ID: <20010513015052.A20991@chimesnet.com>
References: <20010511170738.B24494@chimesnet.com> <3AFDD8EE.4D54AFF9@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <3AFDD8EE.4D54AFF9@sgi.com>; from sandeen@sgi.com on Sat, May 12, 2001 at 07:44:30PM -0500
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey Eric,

I can't tell you much more about the problem.  There are no mentions of errors
within the syslog and the only evidence of a problem are the missing files.

Here's a snapshot of the system:

carroll@developer2:/proc > cat meminfo
        total:    used:    free:  shared: buffers:  cached:
		Mem:  1054019584 893939712 160079872        0 73134080 607117312
		Swap: 2147467264        0 2147467264
		MemTotal:      1029316 kB
		MemFree:        156328 kB
		MemShared:           0 kB
		Buffers:         71420 kB
		Cached:         592888 kB
		Active:           7200 kB
		Inact_dirty:    575784 kB
		Inact_clean:     81324 kB
		Inact_target:       12 kB
		HighTotal:      131072 kB
		HighFree:        21560 kB
		LowTotal:       898244 kB
		LowFree:        134768 kB
		SwapTotal:     2097136 kB
		SwapFree:      2097136 kB

carroll@developer2:/proc > cat partitions
major minor  #blocks  name

   3     0   60051600 hda
   3     1      56196 hda1
   3     2    1052257 hda2
   3     3   58942485 hda3
  58     0    2097152 lvma
  58     1    4194304 lvmb
  58     2   12582912 lvmc
  58     3    8388608 lvmd
  58     4    2097152 lvme

tcarroll@developer2:/proc > cat version
Linux version 2.4.4-xfs (root@developer2) (gcc version 2.95.2 19991024 (release)
) #2 SMP Fri May 11 05:48:18 EDT 2001

tcarroll@developer2:/proc > cat cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 747.543
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips        : 1490.94

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 747.543
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 mmx fxsr sse
bogomips        : 1494.22

tcarroll@developer2:/proc > cat mounts
/dev/root / ext2 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/vol0/usr /usr xfs rw 0 0
/dev/vol0/var /var xfs rw 0 0
/dev/hda1 /boot ext2 rw 0 0
/dev/vol0/home /home xfs rw 0 0
tmpfs /dev/shm tmpfs rw 0 0
/dev/vol0/oracle /oracle xfs rw 0 0

On Sat, May 12, 2001 at 07:44:30PM -0500, Eric Sandeen wrote:
> Tom Carroll wrote:
> 
> > When using the oracle(81701) install on a xfs filesystem, the install fails
> > as it attempts to read/write state files. 
> 
> ...
> 
> > info from installActions.log
> > 
> > Unable to read /oracle/oraInventory/Contents/CompsList0.ser. Some inventory information may be lost.
> > Unable to read /oracle/oraInventory/Contents/PatchesList0.ser. Some inventory information may be lost.
> 
> Hi Tom - We'll probably need a little more info on that one... "Unable
> to read" is a little vague!  Are there any other error messages in the
> system logs?
> 
> I can see if anyone in Mtn. View or Eagan has Oracle to test this with -
> I don't have it here.
> 
> -Eric
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.
> 

From owner-linux-xfs@oss.sgi.com Sun May 13 02:49:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4D9nUX20586
	for linux-xfs-outgoing; Sun, 13 May 2001 02:49:30 -0700
Received: from mail.coltex.nl (edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4D9nSF20583
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 02:49:28 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by  mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f4D7nMO01328
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 09:49:22 +0200
Message-Id: <4.3.2.7.2.20010513114003.039e6d50@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sun, 13 May 2001 11:44:23 +0200
To: linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: 
In-Reply-To: <3AFE06A2.D2AF6F6D@thebarn.com>
References: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 22:59 12-5-2001 -0500, you wrote:
>Tom Duffy wrote:
>
> > I was wondering what the smallest memory system somebody has tried XFS
> > on.  The webpage says 64MB minimum and I know that I have seen XFS working
> > on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?
> >
> > Ananth told me that the recovery was the most memory intensive part...so,
> > I would like to know if anybody has gone through a recovery on a low
> > memory system and things have been OK...or not?
> >
> > thanks,
> >
>
>So here is an aging machine for you...
>32meg p90... just fast enough to run xmms :-)
>Yes hard to believe I'm actually running a linux box at home.

I have a Pentium 233 MMX with 32MB ram and a 20GB disk that seems to do 
fine recovering from a reboot.
It isn't really fast but it's a small MySQL database server that needs the 
uptime more then it does speed. It will never be hit very hard.

I have not tried a 486 yet but I will see if it works someday. If I get 
Mips on the Cobalt Qube2 going again I will test that one too :-)

Bye

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Sun May 13 03:37:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DAbsb21200
	for linux-xfs-outgoing; Sun, 13 May 2001 03:37:54 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DAbrF21197
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 03:37:53 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3C58C1E0CA; Sun, 13 May 2001 12:37:52 +0200 (MEST)
Date: Sun, 13 May 2001 12:37:27 +0200
From: Andi Kleen <ak@suse.de>
To: Ivan Rayner <ivanr@melbourne.sgi.com>
Cc: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: xfsdump safe?
Message-ID: <20010513123727.A10204@gruyere.muc.suse.de>
References: <20010511145453.A10184@gruyere.muc.suse.de> <Pine.SGI.4.32.0105121257590.48937-100000@omen.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.SGI.4.32.0105121257590.48937-100000@omen.melbourne.sgi.com>; from ivanr@melbourne.sgi.com on Sat, May 12, 2001 at 01:04:53PM +1000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, May 12, 2001 at 01:04:53PM +1000, Ivan Rayner wrote:
> On Fri, 11 May 2001, Andi Kleen wrote:
> 
> > On Fri, May 11, 2001 at 10:31:46PM +1000, Ivan Rayner wrote:
> > > On Fri, 11 May 2001, Andi Kleen wrote:
> > >
> > > > Regarding xfsdump:
> > > >
> > > > The qlock functions seem to be dummied out (inside #ifdef HIDDEN), but
> > > > it still seems to create threads in some circumstances, which probably need
> > > > locking. Is it really safe to use?
> > >
> > > I think you'll find that the linux version of xfsdump runs in single
> > > threaded mode.  This is controlled by the 'miniroot' flag which is set to
> > > true on Linux - the key bits are around line 604 in cmd/xfsdump/common/main.c.
> >
> > As far as I can see common/drive_{scsitape,minrmt}.c do not check that
> > flag before calling cldmgr_create()
> 
> Looking at drive_scsitape.c (should be the same for minrmt)
> cldmgr_create() is called from ring_thread() which is called by
> ring_create() as a callback. ring_create() should not be called in
> singlethreaded mode - see the lines around 658 in drive_scsitape.c.
> 
> (You'll note that the miniroot flag I mentioned earlier becomes the
> 'singlethreaded' flag in the drive*.c files.)

Thanks for the clarification. What is the main problem with running
it multithreaded on linux -- is it only the missing semaphore implementation
or are there other issues too?


-Andi


From owner-linux-xfs@oss.sgi.com Sun May 13 06:25:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DDPRR23906
	for linux-xfs-outgoing; Sun, 13 May 2001 06:25:27 -0700
Received: from femail4.rdc1.on.home.com (femail4.rdc1.on.home.com [24.2.9.91])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DDPQF23903
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 06:25:26 -0700
Received: from home.com ([24.112.8.12]) by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP
          id <20010513132629.ZGXD718.femail4.rdc1.on.home.com@home.com>
          for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 06:26:29 -0700
Message-ID: <3AFE8A89.1040103@home.com>
Date: Sun, 13 May 2001 09:22:17 -0400
From: Mike Sowka <msowka@home.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: ide-scsi problem...
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

     I have to say... I was very excited about using XFS but for now am 
a little dissapointed. I'll start with saying that my system works 
without a glitch (and without XFS :( ) on my regular RH7.1 installation. 
This means I had ide-scsi emulation working for my IDE CDR, my sound 
card ( SoundBlaster 5.1) and TNT2 Ultra with the latest NVIDIA modules 
and GLX.
   Upon installing XFS (with the RH7.1 installer), where everything 
seemed to have gone find, funny things started to happend. I installed 
XFS file system on all three of my Linux partitions (/boot, /, and 
/home), I have two FAT32 partitions as well. Off the bat I get an error 
during startup which goes something like this:
Updating /etc/fstab cannot stat /dev/scd0 [FAILED]
Then uppon "fully" booting up it seems that I don't have eithor my my 
CDROMs, one of which is a regular cdrom on /dev/hdb and my CDR on 
/dev/hdd (by the way I did the installation with "linear" and 
"hdd=ide-scsi" flags in lilo). Upon running through the /dev/ide and 
/dev/scsi trees it seems that the /dev/ide/cd does not want to mount and 
/dev/scsi/cd does but both links under /dev/cdrom(1) are broken... :(
   Moving on... after recompiling the NVIDIA_kernel like I have done so 
so many times before and changing the /etc/X11/XF86Config-4 X did not 
restart after reboot!!!!
   Sound card does not work either... :(
   Conclusion: PLEASE, PLEASE look into these as I haven't given up on 
XFS just yet and get back to me on any sort of "work-arounds"! I'm back 
to ex2 for now.. but will be waiting patiently for any fixes or 
updates... RSVP
Thanx,
Mike


From owner-linux-xfs@oss.sgi.com Sun May 13 06:47:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DDlKI24108
	for linux-xfs-outgoing; Sun, 13 May 2001 06:47:20 -0700
Received: from gentoo.surrey.redhat.com ([194.201.25.236])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DDlJF24105
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 06:47:19 -0700
Received: (from saint@localhost)
	by gentoo.surrey.redhat.com (8.11.0/8.11.0) id f4DDio114987;
	Sun, 13 May 2001 14:44:50 +0100
Date: Sun, 13 May 2001 14:44:50 +0100
From: David Sainty <dsainty@redhat.com>
To: Mike Sowka <msowka@home.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: ide-scsi problem...
Message-ID: <20010513144450.B14638@redhat.com>
References: <3AFE8A89.1040103@home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AFE8A89.1040103@home.com>; from msowka@home.com on Sun, May 13, 2001 at 09:22:17AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sounds like devfs...  Read the RELEASE-NOTES file, particularly:

"""
devfs
-----

The installed kernels have devfs enabled by default,
any changes made to /dev will not be retained across reboot.

devfs may be disabled by adding:
	append="devfs=nomount" 
to the appropriate lilo.conf entry.

For more information on devfs refer to:
http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html
"""

Try adding the append=... line to your /etc/lilo.conf file, and then 
re-run lilo ("/sbin/lilo -v") as root. (-v means verbose)

Regards,


DS..

On Sun, May 13, 2001 at 09:22:17AM -0400, Mike Sowka wrote:

/*                                                  Facta Non Verba. */

From owner-linux-xfs@oss.sgi.com Sun May 13 07:19:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DEJrd24610
	for linux-xfs-outgoing; Sun, 13 May 2001 07:19:53 -0700
Received: from smtp-server1.tampabay.rr.com (smtp-server1.tampabay.rr.com [65.32.1.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DEJqF24607
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 07:19:52 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server1.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f4DEJo520248
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 10:19:51 -0400 (EDT)
Message-ID: <3AFE993D.5EE483A3@cfl.rr.com>
Date: Sun, 13 May 2001 10:25:01 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: ide-scsi problem...
References: <3AFE8A89.1040103@home.com> <20010513144450.B14638@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

David Sainty wrote:
> 
> Sounds like devfs...  Read the RELEASE-NOTES file, particularly:
> 
> """
> devfs
> -----
> 
> The installed kernels have devfs enabled by default,
> any changes made to /dev will not be retained across reboot.
> 
> devfs may be disabled by adding:
>         append="devfs=nomount"
> to the appropriate lilo.conf entry.
> 
> For more information on devfs refer to:
> http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html
> """
> 
> Try adding the append=... line to your /etc/lilo.conf file, and then
> re-run lilo ("/sbin/lilo -v") as root. (-v means verbose)
> 
> Regards,
> 
> DS..
You might also consider that with the 2.4.x kernels if you have bothe a
scsi cdrw and an
ide cdrw that pre 2.4 kernels ended up with the scsi one being sr0/scd0
and the ide sr1/scd1
and the 2.4.x kernels they come out just the opposite. As for your sound
if your using
alsa you'll probably have to reinstall it because the make
modules_install command removes
any modules that were in /lib/modules/"uname -r"/kernel . The NVidia
thing I'm not sure of
but it's probably just a modules thing also. Did you do the make install
while running the
kernel you want them to run on??

-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Sun May 13 08:04:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DF42q25188
	for linux-xfs-outgoing; Sun, 13 May 2001 08:04:02 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4DF3xF25185
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 08:03:59 -0700
Received: (qmail 14907 invoked from network); 13 May 2001 15:03:48 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 13 May 2001 15:03:47 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@ocs.com.au>
To: dmarkh@cfl.rr.com
cc: linux-xfs@oss.sgi.com
Subject: Re: ide-scsi problem... 
In-reply-to: Your message of "Sun, 13 May 2001 10:25:01 -0400."
             <3AFE993D.5EE483A3@cfl.rr.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 May 2001 01:03:43 +1000
Message-ID: <1631.989766223@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 13 May 2001 10:25:01 -0400, 
Mark Hounschell <dmarkh@cfl.rr.com> wrote:
>As for your sound if your using alsa you'll probably have to reinstall
>it because the make modules_install command removes any modules that
>were in /lib/modules/"uname -r"/kernel.

Nobody except the kernel should put modules in the kernel subdirectory
under /lib/modules/`uname -r`/.  If any third party code is putting
modules in the kernel subdirectory please let me know ASAP so I can
kill them.  ALSA, Nvidia, pcmcia etc. *must* use separate
subdirectories under /lib/modules/`uname -r`/.


From owner-linux-xfs@oss.sgi.com Sun May 13 08:19:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DFJta25376
	for linux-xfs-outgoing; Sun, 13 May 2001 08:19:55 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DFJrF25373
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 08:19:54 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4DFJpmZ099253;
	Sun, 13 May 2001 10:19:51 -0500 (CDT)
Message-ID: <3AFEA60D.6702C482@thebarn.com>
Date: Sun, 13 May 2001 10:19:41 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Mike Sowka <msowka@home.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: ide-scsi problem...
References: <3AFE8A89.1040103@home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mike Sowka wrote:


These are all devfs issues discussed many times on the xfs list.
Please refer to the archives.
http://linux-xfs.sgi.com/projects/xfs/ml.html

devfs may be disabled by adding "devfs=nomount" to your
append line in lilo.conf


>      I have to say... I was very excited about using XFS but for now am
> a little dissapointed. I'll start with saying that my system works
> without a glitch (and without XFS :( ) on my regular RH7.1 installation.
> This means I had ide-scsi emulation working for my IDE CDR, my sound
> card ( SoundBlaster 5.1) and TNT2 Ultra with the latest NVIDIA modules
> and GLX.
>    Upon installing XFS (with the RH7.1 installer), where everything
> seemed to have gone find, funny things started to happend. I installed
> XFS file system on all three of my Linux partitions (/boot, /, and
> /home), I have two FAT32 partitions as well. Off the bat I get an error
> during startup which goes something like this:
> Updating /etc/fstab cannot stat /dev/scd0 [FAILED]
> Then uppon "fully" booting up it seems that I don't have eithor my my
> CDROMs, one of which is a regular cdrom on /dev/hdb and my CDR on
> /dev/hdd (by the way I did the installation with "linear" and
> "hdd=ide-scsi" flags in lilo). Upon running through the /dev/ide and
> /dev/scsi trees it seems that the /dev/ide/cd does not want to mount and
> /dev/scsi/cd does but both links under /dev/cdrom(1) are broken... :(
>    Moving on... after recompiling the NVIDIA_kernel like I have done so
> so many times before and changing the /etc/X11/XF86Config-4 X did not
> restart after reboot!!!!
>    Sound card does not work either... :(
>    Conclusion: PLEASE, PLEASE look into these as I haven't given up on
> XFS just yet and get back to me on any sort of "work-arounds"! I'm back
> to ex2 for now.. but will be waiting patiently for any fixes or
> updates... RSVP
> Thanx,
> Mike

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 13 08:23:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DFNaS25431
	for linux-xfs-outgoing; Sun, 13 May 2001 08:23:36 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DFNZF25428
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 08:23:35 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4DFNVmZ099285;
	Sun, 13 May 2001 10:23:32 -0500 (CDT)
Message-ID: <3AFEA6EE.E9C8DC8B@thebarn.com>
Date: Sun, 13 May 2001 10:23:26 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: 
References: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com> <4.3.2.7.2.20010513114003.039e6d50@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:

> At 22:59 12-5-2001 -0500, you wrote:
> >Tom Duffy wrote:
> >
> > > I was wondering what the smallest memory system somebody has tried XFS
> > > on.  The webpage says 64MB minimum and I know that I have seen XFS working
> > > on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?
> > >
> > > Ananth told me that the recovery was the most memory intensive part...so,
> > > I would like to know if anybody has gone through a recovery on a low
> > > memory system and things have been OK...or not?
> > >
> > > thanks,
> > >
> >
> >So here is an aging machine for you...
> >32meg p90... just fast enough to run xmms :-)
> >Yes hard to believe I'm actually running a linux box at home.
>
> I have a Pentium 233 MMX with 32MB ram and a 20GB disk that seems to do
> fine recovering from a reboot.
> It isn't really fast but it's a small MySQL database server that needs the
> uptime more then it does speed. It will never be hit very hard.
>
> I have not tried a 486 yet but I will see if it works someday. If I get
> Mips on the Cobalt Qube2 going again I will test that one too :-)

Is there a 2.4 version of the kernel for qube?


I have one sitting in my office not doing anything... it would be nice
to toss XFS and a fiber channel card in the the thing and turn it
into something useful.


>
>
> Bye
>
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 13 08:26:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DFQeW25471
	for linux-xfs-outgoing; Sun, 13 May 2001 08:26:40 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DFQdF25466
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 08:26:39 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4DFQamZ099318;
	Sun, 13 May 2001 10:26:36 -0500 (CDT)
Message-ID: <3AFEA7A6.8E69E2EB@thebarn.com>
Date: Sun, 13 May 2001 10:26:31 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: CVS
References: <Pine.LNX.4.33.0105130016430.15316-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:

> 2.4.4.
>
> I'd like to see a cvs download of just the development patchset as
> well..anyone?

I'm not sure what you are aking for here?



>
>
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
>
> On Sun, 13 May 2001, Federico Sevilla III wrote:
>
> > Hi everyone,
> >
> > I'm checking out the linux-2.4-xfs tree in CVS, and noticed I'm
> > downloading the entire Linux kernel along with it, which is okay since
> > updates are incremental anyway. I'm wondering, what version of the Linux
> > kernel is in the linux-2.4-xfs tree in CVS right now?
> >
> > Thanks!
> >
> >  --> Jijo
> >
> > ---
> > Linux, MS-DOS, and Windows NT ...
> > ... also known as the Good, the Bad, and the Ugly
> >

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 13 08:28:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DFSwW25622
	for linux-xfs-outgoing; Sun, 13 May 2001 08:28:58 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DFStF25618
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 08:28:55 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:62765 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S48221AbREMP2g>;
	Sun, 13 May 2001 17:28:36 +0200
Message-Id: <4.3.2.7.2.20010513172736.038cbd58@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Sun, 13 May 2001 17:28:43 +0200
To: Russell Cattelan <cattelan@thebarn.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: 
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3AFEA6EE.E9C8DC8B@thebarn.com>
References: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com>
 <4.3.2.7.2.20010513114003.039e6d50@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 10:23 13-5-2001 -0500, Russell Cattelan wrote:
>Seth Mos wrote:
> > I have not tried a 486 yet but I will see if it works someday. If I get
> > Mips on the Cobalt Qube2 going again I will test that one too :-)
>
>Is there a 2.4 version of the kernel for qube?

The Mips folks are making some progress on the environment in general.

>I have one sitting in my office not doing anything... it would be nice
>to toss XFS and a fiber channel card in the the thing and turn it
>into something useful.

Same thing over here.

Bye
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Sun May 13 09:20:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DGKLr26305
	for linux-xfs-outgoing; Sun, 13 May 2001 09:20:21 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4DGKKF26301
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 09:20:20 -0700
Received: (qmail 22645 invoked by uid 0); 13 May 2001 16:20:14 -0000
Received: from adsl-4-86.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.86)
  by mail.gmx.net (mp030-rz3) with SMTP; 13 May 2001 16:20:14 -0000
Message-ID: <200105131820030355.01053731@mail.gmx.de>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sun, 13 May 2001 18:20:03 +0200
From: "linux" <dahouet@gmx.net>
To: linux-xfs@oss.sgi.com
Subject: Some questions.
Mime-Version: 1.0
Content-Type: text/plain; charset="WINDOWS-1250"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4DGKLF26302
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

i've installed an root xfs partition on a 2.4.4 kernel.
i'm pretty happy except my squid server which has 
often some problems to stop. i'm not sure it's xfs fault, but...

today, my server had a power failure this afternoon...
when it started, it said :
May 13 16:23:37 bretagne kernel: Start mounting filesystem: ide0(3,1)
May 13 16:23:37 bretagne kernel: XFS: WARNING: recovery required on readonly filesystem.
May 13 16:23:37 bretagne kernel: 
May 13 16:23:37 bretagne kernel: XFS: write access will be enabled during mount.
May 13 16:23:37 bretagne kernel: 
May 13 16:23:37 bretagne kernel: Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1)
May 13 16:23:37 bretagne kernel: Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1)
May 13 16:23:37 bretagne kernel: VFS: Mounted root (xfs filesystem) readonly.
May 13 16:23:37 bretagne kernel: Freeing unused kernel memory: 212k freed
May 13 16:23:37 bretagne kernel: Adding Swap: 457844k swap-space (priority -1)
May 13 16:23:37 bretagne kernel: EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
May 13 16:23:37 bretagne kernel: Start mounting filesystem: ide0(3,3)
May 13 16:23:37 bretagne kernel: Starting XFS recovery on filesystem: ide0(3,3) (dev: 3/3)
May 13 16:23:37 bretagne kernel: Ending XFS recovery on filesystem: ide0(3,3) (dev: 3/3)

what exactely does the kernel do when it says the recovery thing ?
why a ext2-fs warning ?


on the future release of xfs, when will we have to do a new mkfs.xfs ?
or only a kernel release ?

thanks for all your work and answers
@++
nico


From owner-linux-xfs@oss.sgi.com Sun May 13 09:43:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DGhep26492
	for linux-xfs-outgoing; Sun, 13 May 2001 09:43:40 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DGhdF26489
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 09:43:39 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4DGhb020046;
	Sun, 13 May 2001 11:43:37 -0500 (CDT)
Message-ID: <3AFEBA45.A9200F54@sgi.com>
Date: Sun, 13 May 2001 11:45:57 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Some questions.
References: <200105131820030355.01053731@mail.gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:
  
> what exactely does the kernel do when it says the recovery thing ?

It re-plays the log to commit transactions which were still in the log
when your power failed.

> why a ext2-fs warning ?

Not sure - do you have ANY ext2 filesystems on this box?
 
> on the future release of xfs, when will we have to do a new mkfs.xfs ?
> or only a kernel release ?

The on-disk format is fixed (it's been around for years on Irix), so you
won't need to re-make any existing XFS filesystems you have, even on new
releases of XFS.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May 13 09:59:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DGxjN26668
	for linux-xfs-outgoing; Sun, 13 May 2001 09:59:45 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4DGxiF26665
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 09:59:44 -0700
Received: (qmail 16596 invoked by uid 0); 13 May 2001 16:59:42 -0000
Received: from adsl-4-86.adsl.easynet.fr (HELO mail.gmx.de) (195.114.94.86)
  by mail.gmx.net (mp001-rz3) with SMTP; 13 May 2001 16:59:42 -0000
Message-ID: <200105131859310891.01295B49@mail.gmx.de>
In-Reply-To: <3AFEBA45.A9200F54@sgi.com>
References: <200105131820030355.01053731@mail.gmx.de>
 <3AFEBA45.A9200F54@sgi.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Sun, 13 May 2001 18:59:31 +0200
From: "linux" <dahouet@gmx.net>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Some questions.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4DGxjF26666
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Le 13/05/2001 à 11:45 Eric Sandeen a écrit :
>> what exactely does the kernel do when it says the recovery thing ?
>It re-plays the log to commit transactions which were still in the log
>when your power failed.
yep
but how can we know what was done good or bad ?

>> why a ext2-fs warning ?
>Not sure - do you have ANY ext2 filesystems on this box?
ok i'm stupid, i have my old linux partition on ext2
i didn't remember that this partition was in the /etc/fstab
 
>> on the future release of xfs, when will we have to do a new mkfs.xfs ?
>> or only a kernel release ?
>The on-disk format is fixed (it's been around for years on Irix), so you
>won't need to re-make any existing XFS filesystems you have, even on new
>releases of XFS.
ok good news.
has it happened once on irix since the beginning ?

now it's time on tuning my system...
any suggestion ?
thanks
@++
nico


From owner-linux-xfs@oss.sgi.com Sun May 13 10:06:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DH6bR26800
	for linux-xfs-outgoing; Sun, 13 May 2001 10:06:37 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DH6bF26796
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 10:06:37 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4DH6Xf04006;
	Sun, 13 May 2001 12:06:33 -0500 (CDT)
Message-ID: <3AFEBFA7.C28F1E50@sgi.com>
Date: Sun, 13 May 2001 12:08:55 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Some questions.
References: <200105131820030355.01053731@mail.gmx.de>
	 <3AFEBA45.A9200F54@sgi.com> <200105131859310891.01295B49@mail.gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:

> but how can we know what was done good or bad ?

Well, it didn't give you any errors, so it was done good.  :)  Note that
this does NOT mean that no data was lost, as some files may have been
delay-allocated, or in the write cache when your power went down.
 
> has it (/* format change */) happened once on irix since the beginning ?

I don't know for sure.
 
> now it's time on tuning my system...

There have been a lot of people asking for information on "tuning" xfs,
and we should probably put together a short document on how the various
options might affect performance.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May 13 10:18:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DHIfK26932
	for linux-xfs-outgoing; Sun, 13 May 2001 10:18:41 -0700
Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DHIeF26929
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 10:18:40 -0700
Received: by chiara.elte.hu (Postfix, from userid 17000)
	id 4495D1FC2; Sun, 13 May 2001 19:18:31 +0200 (CEST)
Date: Sun, 13 May 2001 19:18:30 +0200
From: KELEMEN Peter <fuji@elte.hu>
To: linux-xfs@oss.sgi.com
Subject: XFS on i486 w/36M RAM: OK
Message-ID: <20010513191830.A907@chiara.elte.hu>
Reply-To: KELEMEN Peter <fuji@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary
X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20
X-GPG-Fingerprint: D402 4AF3 7488 165B CC34  4147 7F0C D922 EE4C 26E8
X-PGP-KeyID: 1024/45F83E45 1998/04/04
X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD  6D AA B5 8A D6 03 0F BF
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just wanted to tell people that XFS was successfully built, an
XFS filesystem was created, mounted, lightly oppressed, damaged
and replayed without any problems on an AMD DX4-100 with 36M RAM.
I'm using the filesystem as a temporary partition for the time
being (my $TMPDIR points there).

Peter

PS: Latest CVS devel tree.

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \       /      fuji@elte.hu
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From owner-linux-xfs@oss.sgi.com Sun May 13 16:09:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DN9kw31431
	for linux-xfs-outgoing; Sun, 13 May 2001 16:09:46 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DN9iF31428
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 16:09:44 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA1328352
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 01:09:40 +0200 (CEST)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (localhost [127.0.0.1])
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA36235;
	Mon, 14 May 2001 09:08:19 +1000 (EST)
Message-Id: <200105132308.JAA36235@snort.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Tom Duffy <tduffy@engr.sgi.com>
Subject: Re: xfs on small memory 
In-reply-to: Your message of "Sat, 12 May 2001 18:57:08 MST."
             <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com> 
cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 14 May 2001 09:08:19 +1000
From: Daniel Moore <dxm@snort.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Tom Duffy writes:
 => I was wondering what the smallest memory system somebody has tried XFS
 => on.  The webpage says 64MB minimum and I know that I have seen XFS working
 => on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?
 => 
 => Ananth told me that the recovery was the most memory intensive part...so,
 => I would like to know if anybody has gone through a recovery on a low
 => memory system and things have been OK...or not?
 => 
 => thanks,
 => 
 => -tduffy
 => 

32 Mb was fine when I checked. Lower should be ok too. The original IRIX
code could chew a lot of memory in recovery and would usually fail on small
memory systems. But we've rewritten the code responsible a couple of times
since then so it uses smarter memory allocation.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Sun May 13 16:25:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4DNPOc31552
	for linux-xfs-outgoing; Sun, 13 May 2001 16:25:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4DNPNF31549
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 16:25:23 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id QAA05079
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 16:25:01 -0700 (PDT)
	mail_from (ajag@fudge.melbourne.sgi.com)
Received: from fudge.melbourne.sgi.com (fudge.melbourne.sgi.com [134.14.55.184]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06691; Mon, 14 May 2001 09:23:44 +1000
Received: (from ajag@localhost) by fudge.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id JAA12995; Mon, 14 May 2001 09:23:41 +1000 (EST)
Date: Mon, 14 May 2001 09:23:41 +1000
From: Andrew Gildfind <ajag@fudge.melbourne.sgi.com>
To: =?iso-8859-1?Q?M=E1rio_Gamito?= <mg-listas@netvisao.pt>
Cc: linux-xfs@oss.sgi.com
Subject: Re: ACLs vs. umask question
Message-ID: <20010514092341.A77065@fudge.melbourne.sgi.com>
References: <3AFCA08B.FBD465DA@netvisao.pt>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Mailer: Mutt 1.0us
In-Reply-To: <3AFCA08B.FBD465DA@netvisao.pt>; from mg-listas@netvisao.pt on Sat, May 12, 2001 at 03:31:39AM +0100
X-MIME-Autoconverted: from 8bit to quoted-printable by fudge.melbourne.sgi.com id JAA12995
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4DNPOF31550
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, May 12, 2001 at 03:31:39AM +0100, Mário Gamito wrote:
> Hi!
> 
> I'm considering using XFS mainly because of ACL support.
> But since i read the following quoatation in URL...
> 
> http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00368.html
> 
> "The 1.0 release, however, applies default ACLs which are
> affected by the umask. This has been fixed in the CVS tree
> so that default ACLs are used in preference to the umask.
> (the fix didn't make it in time to 1.0)."
> 
> ...i have a question:
> Does this mean that ACL is *really* not working because is overrided by
> umask, or is it just the default behaviour which in turn can be
> overrided by means of some configuration?
> 

No I'm afraid this was a bug that escaped. In the released code namei.c had not
been patched to ensure that the umask was not applied when a default ACL was
present on the parent directory. As the caveat states this has been fixed in the
CVS tree.


Andrew


-- 
Andrew Gildfind - R&D Software Engineer - SGI Melbourne Australia
email: ajag@sgi.com - work: +61.3.9834.8200 mobile: 0412.834.183

From owner-linux-xfs@oss.sgi.com Sun May 13 17:18:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E0IwF32122
	for linux-xfs-outgoing; Sun, 13 May 2001 17:18:58 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E0IvF32119
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 17:18:57 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA18748
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 17:17:32 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07024; Mon, 14 May 2001 10:17:39 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA65752;
	Mon, 14 May 2001 10:17:38 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Mon, 14 May 2001 10:17:38 +1000
To: Andi Kleen <ak@suse.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump safe?
In-Reply-To: <20010513123727.A10204@gruyere.muc.suse.de>
Message-ID: <Pine.SGI.4.32.0105140954520.65777-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 13 May 2001, Andi Kleen wrote:

> Thanks for the clarification. What is the main problem with running
> it multithreaded on linux -- is it only the missing semaphore implementation
> or are there other issues too?

It's simply a porting excercise.  I have done some of the work using
pthreads, but other higher priority projects came along... The only
feature multithreading will give you is the ability to dump to multiple
tapes simultaneously.

Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com



From owner-linux-xfs@oss.sgi.com Sun May 13 18:10:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E1Aqq32496
	for linux-xfs-outgoing; Sun, 13 May 2001 18:10:52 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E1ApF32493
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 18:10:51 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA02368
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 18:21:45 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id SAA58259;
	Sun, 13 May 2001 18:09:33 -0700 (PDT)
Date: Sun, 13 May 2001 18:08:51 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Keith Owens <kaos@ocs.com.au>
cc: <dmarkh@cfl.rr.com>, <linux-xfs@oss.sgi.com>
Subject: Re: ide-scsi problem... 
In-Reply-To: <1631.989766223@ocs3.ocs-net>
Message-ID: <Pine.LNX.4.33.0105131800230.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Nobody except the kernel should put modules in the kernel subdirectory
> under /lib/modules/`uname -r`/.  If any third party code is putting
> modules in the kernel subdirectory please let me know ASAP so I can
> kill them.  ALSA, Nvidia, pcmcia etc. *must* use separate
> subdirectories under /lib/modules/`uname -r`/.

alsa and vmware sticks their stuff in /lib/modules/`uname -r`/misc which
is the old naming scheme.

nvidia sticks their one module (without the .o I should mention) in
/lib/modules/`uname -r`/video which is also the old naming convention..

not sure dude was insinuating that they were in the kernel subdirectory...

-tduffy



From owner-linux-xfs@oss.sgi.com Sun May 13 21:24:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E4O3C02500
	for linux-xfs-outgoing; Sun, 13 May 2001 21:24:03 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E4O2F02497
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 21:24:03 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4E4Me128016
	for <linux-xfs@oss.sgi.com>; Sun, 13 May 2001 23:22:40 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Sun, 13 May 2001 23:22:39 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS performance issue solved
Message-ID: <Pine.LNX.4.33.0105132315290.27971-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Some of you have been writing about slow access times to stuff like rpm
database, slocate db, etc. I've found one major thing which caused my
system to return to it's normal smoking self. I recently got a new
Athlon-C 1.333Ghz machine. I was very proud, and expected only the best
out of this machine. I use the full 1.0 installer for 7.1. After
installation, I discovered the RPM db was corrupt, and the system
basically thought almost no packages were installed, despite the fact it
booted with no real issues. I immediately got the 2.4.4 XFS devel tree,
and recompiled, cause I've found that the new tree is much better than the
default install version. My preference. Going through the recompile I
chose to use the Generic DMA selection. I even decided to choose my ALI
chipset. After rebooting the system was slightly better, no more devfs or
other non-essential overhead. But there was still some fundamental issue.
Pine, slocate, rpm, all were not NEARLY fast enough. I recompiled again,
this time with no generic DMA support or ALI support. My system now
performs like a 1.333 Ghz should. It smokes! File create/delete, and r/w
times are pretty darn good. In some respects better than they've ever
been. I'm going to hit this same build on my work box, a 433 Celeron, and
see what happens. That is the more problematic box overall, but I know
I've got similar options, regarding DMA, selected as well. I'll post when
I see success/failure on that front in the AM.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Mon May 14 01:46:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E8kcl06573
	for linux-xfs-outgoing; Mon, 14 May 2001 01:46:38 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E8kbF06570
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 01:46:37 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA19528;
	Mon, 14 May 2001 10:46:35 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id KAA16459;
	Mon, 14 May 2001 10:46:30 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id A8F6F57306; Mon, 14 May 2001 10:50:59 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 63ABC25835; Mon, 14 May 2001 10:52:06 +0200 (CEST)
Message-ID: <3AFF9B1A.5EA1524F@ch.sauter-bc.com>
Date: Mon, 14 May 2001 10:45:14 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Benjamin Reed <ranger@befunk.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: masochism (software RAID5 XFS root)
References: <Pine.LNX.4.21.0105112345160.10913-100000@www.scenespot.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Benjamin Reed schrieb:
> 
> I'm attempting to do a software RAID bootstrap with redhat 7.1 and a
> custom-compiled (from CVS, as of about 20 minutes ago) kernel.
Did you use an original kernel source or the one delivered with rh-7.1.
In earlier releases RedHat was using the raid auto run patch to make
raid root possible. I don't know now.
> 
> it is on a software raid5 root, formatted XFS, and it refuses to boot.  :(
Did you try devfs=nomount as kernel boot parameter?
Are you using an initrd to boot. I have sent a patch to this list how
to change mkinitrd so that it will create an initrd that works with
or without devfs.
http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00554.html
> 
> I get:
> 
> EXT2-fs: unable to read superblock
> XFS: SB read failed
> Kernel panic: VFS: Unable to mount root fs on 09:01
> 
> ...so before I try to go any further, is this even possible?  Or is it not
> supported...
> 
> --
> Ben Reed a.k.a. Ranger Rick (ranger@befunk.com)
> http://defiance.dyndns.org/ / http://radio.scenespot.org/
> A preposition is something one should never end a sentence with.
> Now playing on Defiance Radio: Somebody by Depeche Mode

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Mon May 14 02:05:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E95hk07007
	for linux-xfs-outgoing; Mon, 14 May 2001 02:05:43 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E95fF07004
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 02:05:42 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id EDBCCCC43; Mon, 14 May 2001 11:04:00 +0100 (BST)
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Cc: Linux XFS <linux-xfs@oss.sgi.com>
Subject: Re: Mystery Mouse
References: <3AF9ACAC.E621337C@pipcws.ca.boeing.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 14 May 2001 11:04:00 +0100
In-Reply-To: <3AF9ACAC.E621337C@pipcws.ca.boeing.com> (Ric Tibbetts's message of "Wed, 09 May 2001 13:46:36 -0700")
Message-ID: <m366f4gsbz.fsf@giants.mandrakesoft.com>
Lines: 17
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ric Tibbetts <ric@pipcws.ca.boeing.com> writes:

> All
> I have an interesting conflict with my mouse, & kudzu.
> It's a standard Logitech 3 button PS/2 Mouse. Nothing fancy. LM 8.0 & kudzu have
> teamed up to make me miserable. 
> Every time I boot, kudzu changes the state of the mouse. If it's connected &
> happy, kudzu will claim that the mouse has been removed, and pop up the window
> to confirm the removal of the device. On the next re-boot, it will detect the
> mouse, and want to re-install it. This happens EVERY TIME I reboot. 
> For now, I've removed kudzu fro the boot up procedure until I can figure this
> out.
> Does anyone have any suggestions?

this should go on mdk mailing list
(http://www.linux-mandrake.com/en/flists.php3), this should BTW: fixed
in latest cooker kernel.

From owner-linux-xfs@oss.sgi.com Mon May 14 02:06:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E96f407026
	for linux-xfs-outgoing; Mon, 14 May 2001 02:06:41 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E96dF07023
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 02:06:40 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 57D4FCC43; Mon, 14 May 2001 11:05:00 +0100 (BST)
To: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Cc: Eric Sandeen <sandeen@sgi.com>, Johannes Eriksson <joheriks@abo.fi>,
   linux-xfs@oss.sgi.com
Subject: Re: XFS on SuSE7.1
References: <3AF3BF07.5C0E03CB@wipro.co.in> <3AF41C77.D1A23AA9@sgi.com>
	<20010505200401.A16626@infa.abo.fi> <3AF43774.62270B72@sgi.com>
	<3AF45406.BFB1F78C@sgi.com>
	<10105071026.ZM65164@wobbly.melbourne.sgi.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 14 May 2001 11:05:00 +0100
In-Reply-To: <10105071026.ZM65164@wobbly.melbourne.sgi.com> ("Nathan Scott"'s message of "Mon, 7 May 2001 10:26:11 -0500")
Message-ID: <m31ypsgsab.fsf@giants.mandrakesoft.com>
Lines: 29
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Nathan Scott" <nathans@wobbly.melbourne.sgi.com> writes:

> hi,
> 
> On May 5,  2:27pm, Eric Sandeen wrote:
> > Subject: Re: XFS on SuSE7.1
> > Ah, I see now that it's probably a result of building the userspace
> > packages on an older system - the man location is set during "configure"
> > so if it's in /usr/man rather than /usr/share/man, that's probably a
> > result of building on a non-FHS 2.0 compliant system.
> > 
> > Still, next spin, we can clean that up.
> > 
> > Thanks for pointing it out!
> > 
> 
> I'm not sure there's too much we can change in our rpms,
> since we want these to work on "older" systems too (ie.
> systems which use /usr/man and do not have /usr/share/man
> on the default man search path).
> 
> What I might do though is change the default location to
> install to.  Currently, if we cannot make an educated guess
> as to the correct location, we fall back to /usr/doc (this
> is whats biting the Mandrake folk, I'll bet).  Instead, it
> seems like guessing at /usr/share/man is the right thing to
> do, with so many distros starting to follow the fhs now.

why don't you use the %{_mandir} %{_docdir} %{_infodir} macros ?

From owner-linux-xfs@oss.sgi.com Mon May 14 02:07:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E97H107043
	for linux-xfs-outgoing; Mon, 14 May 2001 02:07:17 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E97GF07040
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 02:07:16 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 0716DCC44; Mon, 14 May 2001 11:05:37 +0100 (BST)
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Ric Tibbetts <ric@pipcws.ca.boeing.com>, linux-xfs@oss.sgi.com,
   Mandrake Install <install@linux-mandrake.com>,
   Mandrake Kernel <kernel@linux-mandrake.com>
Subject: Re: Mandrake RPM's
References: <3AF049D9.4090201@runbox.com>
	<m3bspbwotj.fsf@giants.mandrakesoft.com>
	<3AF0A70D.C5CE4733@thebarn.com>
	<m37kzyrhj1.fsf@giants.mandrakesoft.com>
	<3AF1A6DC.67C1CA2F@thebarn.com>
	<m3bsp9xwdi.fsf@giants.mandrakesoft.com>
	<3AF2D62A.775AEFF2@pipcws.ca.boeing.com>
	<3AF732F3.2E0E3B28@thebarn.com>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 14 May 2001 11:05:37 +0100
In-Reply-To: <3AF732F3.2E0E3B28@thebarn.com> (Russell Cattelan's message of "Mon, 07 May 2001 19:42:43 -0400")
Message-ID: <m3wv7kfdou.fsf@giants.mandrakesoft.com>
Lines: 18
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan <cattelan@thebarn.com> writes:

> Ric Tibbetts wrote:
> 
> Ok I build the Mandrake 8.0 kernel rpm with XFS 1.0
> included.
> Everything is in the "testing" directory on oss.sgi.com.
> 
> I've also removed the jumbo patch and replaced with a mandrake "core" patch,
> to use this patch the XFS will also be needed "linux-2.4-xfs-1.0.patch.gz"
> 
> The src rpm has everything tied together so I would recommend that if you really
> want to build the tree.
> 
> I haven't booted the kernels so if anybody is brave enough to try please report
> back.

i'll do thanks for the works..

From owner-linux-xfs@oss.sgi.com Mon May 14 02:16:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4E9GUj07170
	for linux-xfs-outgoing; Mon, 14 May 2001 02:16:30 -0700
Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4E9GTF07167
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 02:16:29 -0700
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO202.gate.nec.co.jp (8.9.3/3.7W01041220) with ESMTP id SAA04121
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:30 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP
	id SAA11418 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:25 +0900 (JST)
Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f4E9GMv16847 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:23 +0900 (JST)
Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4])
          by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J
          release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA252
          for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:17 +0900
Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Mon May 14 18:16:16 2001 +0900
Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142])
	by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id SAA98368
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:19 +0900 (JST)
Received: from bsd.tnes.nec.co.jp (izumi.bsd.tnes.nec.co.jp [10.1.101.168])
	by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f4E9GJc03856
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:16:19 +0900
Message-ID: <3AFFA2F2.7EA64EFA@bsd.tnes.nec.co.jp>
Date: Mon, 14 May 2001 18:18:42 +0900
From: Takayuki Sasaki <sasaki@bsd.tnes.nec.co.jp>
X-Mailer: Mozilla 4.75 [ja] (Win98; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: A typo in cmd/xfstest/015
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, 

First thanks to SGI and all the developers for the Release 1.0.
BTW: I am investigating the xfs test tools, and found a typo in
cmd/xfstests/015.

The line 62 says:
_df_dir $TEST_DIR | $AWK_PROG '{ print $5 }'
        ^^^^^^^^^^
but it should be:
_df_dir $SCRATCH_MNT | $AWK_PROG '{ print $5 }'
        ^^^^^^^^^^^^

Best regards
Takayuki Sasaki

From owner-linux-xfs@oss.sgi.com Mon May 14 03:20:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EAKLP08543
	for linux-xfs-outgoing; Mon, 14 May 2001 03:20:21 -0700
Received: from smtp-server2.tampabay.rr.com (smtp-server2.tampabay.rr.com [65.32.1.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EAKKF08539
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 03:20:20 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f4EAKCv07665;
	Mon, 14 May 2001 06:20:13 -0400 (EDT)
Message-ID: <3AFFB29C.C1D569F4@cfl.rr.com>
Date: Mon, 14 May 2001 06:25:32 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Owens <kaos@ocs.com.au>
CC: linux-xfs@oss.sgi.com
Subject: Re: ide-scsi problem...
References: <1631.989766223@ocs3.ocs-net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Owens wrote:
> 
> On Sun, 13 May 2001 10:25:01 -0400,
> Mark Hounschell <dmarkh@cfl.rr.com> wrote:
> >As for your sound if your using alsa you'll probably have to reinstall
> >it because the make modules_install command removes any modules that
> >were in /lib/modules/"uname -r"/kernel.
> 
> Nobody except the kernel should put modules in the kernel subdirectory
> under /lib/modules/`uname -r`/.  If any third party code is putting
> modules in the kernel subdirectory please let me know ASAP so I can
> kill them.  ALSA, Nvidia, pcmcia etc. *must* use separate
> subdirectories under /lib/modules/`uname -r`/.

NVidia uses kernel/video. I had to modify the make file to change it to
misc/video.
Alsa, I forget where the default was but I always set it to misc/snd. It
seems that
we should probably all use /lib/modules/"uname-r"/local/ according the
LFS and how
it defines "local". Back to NVidia, if kernel/video exists it uses that
first by default.
If not then it uses just video. See exerpt from the makefile below.

ifeq ($(shell if test -d $(KERNDIR)/kernel; then echo yes; fi),yes)
INSTALLDIR=$(KERNDIR)/kernel/video
else
INSTALLDIR=$(KERNDIR)/video
endif


You are right, nobody but the kernel should use kernel but there are
those that do.

-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Mon May 14 03:52:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EAqUh08902
	for linux-xfs-outgoing; Mon, 14 May 2001 03:52:30 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EAqTF08898
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 03:52:29 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4EAqOv17570
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:52:24 +0800
Received: from kalapati ([203.167.26.70]) by sisa.i-manila.com.ph ; Mon, 14 May 2001 18:52:30 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 99C971340
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:52:18 +0800 (PHT)
Date: Mon, 14 May 2001 18:52:18 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: What's wrong with df?
Message-ID: <Pine.LNX.4.21.0105141844370.3448-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

While migrating a ReiserFS partition to XFS, I noticed that df reported a
pretty significant space utilization difference between the two
filesystems. I transferred my files using two methods, and both had
identical results.

First I used tar from /xfs: "tar -cl /reiserfs | tar xv", then I used cp:
"cp -a /reiserfs /xfs". Here is the output when I ran "df -h" after each
file transfer operation:

Filesystem	Size	Used	Avail	Use%	Mounted on
/dev/hda5	2.0G	692M	1.4G	33%	/reiserfs
/dev/hda3	952M	746M	206M	78%	/xfs

If this is accurate (although it doesn't seem accurate as I will later
elaborate), then XFS uses 52MB more than ReiserFS does for a relatively
small partition (this is actually my root partition, and I only exclude a
small boot and the home partition).

I decided to check using du by running "du -csm" and found that ReiserFS
uses 734MB and XFS uses 733MB. This looks more accurate. Would anyone know
what's wrong with df? It's a much handier tool to use than du, but if it's
not accurate then it doesn't look like a good tool to use, handy or not.

Thanks in advance for your comments and suggestions.

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Mon May 14 05:15:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ECFYc11001
	for linux-xfs-outgoing; Mon, 14 May 2001 05:15:34 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ECFJF10995
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 05:15:19 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id OAA1362267
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:15:16 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA1805676; Mon, 14 May 2001 07:13:54 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA90144; Mon, 14 May 2001 07:13:54 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4ECGBQ17507; Mon, 14 May 2001 07:16:11 -0500
Message-Id: <200105141216.f4ECGBQ17507@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: Marc Jauvin <marc@register4less.com>, linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug... 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Sat, 12 May 2001 19:06:10 CDT." <Pine.LNX.4.33.0105121905420.13692-100000@UberGeek.coremetrics.com> 
Date: Mon, 14 May 2001 07:16:11 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I am going to attempt to explain a little of how XFS writes data to disk,
and what this means when the power is turned off.

For most transactions, the modifications to the filesystem are committed
to a group of in memory buffers. These buffers are flushed to disk by:

	o a synchronous transaction
	o being filled
	o background sync activity 

File data is flushed to disk via bdflush unless you use fsync, O_SYNC on
open or fdatasync.

Filesystem design is mostly about compromises between speed of operation
and safety of operation, even in the case of XFS. If you want a filesystem
which is truly safe from power outages then you have to use applications
which do I/O in a manner which indicates they want the data on disk before
the system call returns, and in the case of XFS, mount with the wsync
option which makes all transactions safe on disk before system calls
return. Of course, performance will suffer. There is a range of medical
image scanners which actually have an Irix box embedded in them using XFS.
These boxes regularly just get unplugged or have the power removed for
some reason, and the manufacturer insisted on complete data recovery
after a crash. The above factors were what got them to this state.

So if you write to a file and then immediately drop the power, the chances
are you will not see the data after reboot. If you do a metadata operation
and imediately drop power, there is also a chance it will be not be present
after reboot. The filesystem however, will be in a consistent state.


> Is there anyway to mount with less latency on the writes?

You can control the frequency of data getting flushed to disk (both file
data and metadata in the journal) with the bdflush parameters in

/proc/sys/vm/bdflush

Steve

> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Fri, 11 May 2001, Marc Jauvin wrote:
> 
> > I understand, but the file should have been kept to its original state, no?
>  I
> > had garbage all over the file after the reset...
> >
> >
> > Russell Cattelan wrote:
> >
> > > Marc Jauvin wrote:
> >
> > >> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
> > >>
> > >> ----
> > >>
> > >> I installed XFS 1.0 for RedHat 7.1 and everything is great... until I di
> d the
> > >> following:
> > >>
> > >> make modification to /etc/fstab, and IMMEDIATELY after saving the
> > >> modifications, I hit the reset button; when the system reboots, the
> > >> /etc/fstab is baddly corrupted and XFS does not fix it (end up using the
> > >> linux rescue disk to fix fstab manually\)
> > >>
> > >> I could reproduce the bug 2 times;
> >
> > >> Any idea\?
> >
> > > Yes don't do that.
> > > XFS uses delayed allocation / delayed write by default any data written
> > > immediacy before a crash probably won't be on
> > > disk, this is known behavior and isn't considered a bug, it's a trade off
> .
> > > Full sync mode on file systems is much safer and gives more likely hood o
> f
> > > data integrity. caches gives much better
> > > performance but has the potential of losing cached data in the event of a
> > > crash.
> >
> >
> >
> > --
> > marc.
> >
> > 3 out of 4 Americans make up 75% of the population.
> >



From owner-linux-xfs@oss.sgi.com Mon May 14 07:07:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EE7QD13247
	for linux-xfs-outgoing; Mon, 14 May 2001 07:07:26 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EE7PF13244
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 07:07:25 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA19644
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 07:06:01 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1807706; Mon, 14 May 2001 09:06:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA07232; Mon, 14 May 2001 09:06:07 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EE8OT17877; Mon, 14 May 2001 09:08:24 -0500
Message-Id: <200105141408.f4EE8OT17877@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: What's wrong with df? 
In-Reply-To: Message from Federico Sevilla III <jijo@i-manila.com.ph> 
   of "Mon, 14 May 2001 18:52:18 +0800." <Pine.LNX.4.21.0105141844370.3448-100000@kalapati.jijo.local> 
Date: Mon, 14 May 2001 09:08:24 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I cannot speak for the differences between du and df on reiserfs, but I can
on XFS.

du works by traversing the directory tree doing stat's on all the files
and summing the blocks it finds. df usually works by looking at some
global counters maintained by the filesystem. The difference is that
df is looking at the total space usage in the filesystem including meta
data not directly associated with files. In XFS there are maps of free
space and free inodes which are not accounted for as part of any file.

So typically df will report more space used than du will, in fact I would
be worried if it did not.

Steve 

> Hi everyone,
> 
> While migrating a ReiserFS partition to XFS, I noticed that df reported a
> pretty significant space utilization difference between the two
> filesystems. I transferred my files using two methods, and both had
> identical results.
> 
> First I used tar from /xfs: "tar -cl /reiserfs | tar xv", then I used cp:
> "cp -a /reiserfs /xfs". Here is the output when I ran "df -h" after each
> file transfer operation:
> 
> Filesystem	Size	Used	Avail	Use%	Mounted on
> /dev/hda5	2.0G	692M	1.4G	33%	/reiserfs
> /dev/hda3	952M	746M	206M	78%	/xfs
> 
> If this is accurate (although it doesn't seem accurate as I will later
> elaborate), then XFS uses 52MB more than ReiserFS does for a relatively
> small partition (this is actually my root partition, and I only exclude a
> small boot and the home partition).
> 
> I decided to check using du by running "du -csm" and found that ReiserFS
> uses 734MB and XFS uses 733MB. This looks more accurate. Would anyone know
> what's wrong with df? It's a much handier tool to use than du, but if it's
> not accurate then it doesn't look like a good tool to use, handy or not.
> 
> Thanks in advance for your comments and suggestions.
> 
>  --> Jijo
> 
> ---
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly



From owner-linux-xfs@oss.sgi.com Mon May 14 07:25:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EEPMi13539
	for linux-xfs-outgoing; Mon, 14 May 2001 07:25:22 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EEPLF13536
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 07:25:21 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA09924
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 07:36:15 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1805877; Mon, 14 May 2001 09:24:02 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA70313; Mon, 14 May 2001 09:24:02 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EEQJU17908; Mon, 14 May 2001 09:26:19 -0500
Message-Id: <200105141426.f4EEQJU17908@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: biosize=13 
In-Reply-To: Message from Federico Sevilla III <jijo@i-manila.com.ph> 
   of "Sun, 13 May 2001 10:50:15 +0800." <Pine.LNX.4.21.0105131047020.4341-100000@kalapati.jijo.local> 
Date: Mon, 14 May 2001 09:26:19 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi everyone,
> 
> I remember a message awhile back saying that the benefits of setting the
> mount option biosize=13 plus more would be incorporated in development
> versions of XFS. So I'm wondering, will it still be benefitial on an ia32
> machine to mount an XFS filesystem using the "biosize=13" option if the
> system is running on Linux kernel 2.4.4 with the following
> linux-2.4.4-xfs-cvs-05022001 patch?

This patch will not remove the need for biosize - you will need to apply
this patch to a 2.4.4 tree and then do a cvs update to get the current
code base. I will ask Russell to update the patch with some more recent
ones, there have been sufficient changes since May 2nd I think.

Steve


> 
> Also, would there be any tips related to performance when creating the XFS
> filesystem? For example, should a certain option be used of most of the
> files will be small, a certain option for mixed large files and small
> files, et al. The same question goes for mount points. Or maybe someone
> has a website with XFS performance tips? I remember someone else asking
> this question awhile back, too.

For mkfs options, there is not a lot you can do right now, the most useful
option would be the blocksize, but this is currently fixed at the pagesize.

One option which may make a difference is -i size=xxx the default inode
size is 256 bytes, you can make it bigger (upto 4K) this will mean that
more directories will keep their contents in the inode and need less
disk I/O to read and write (but inodes will conversly need more I/O
to read, since inodes are read and written in clusters this is not a
straightfoward calculation). Since extents are also held in the inode
if there is room, this also reduces the number of files which have out
of inode metadata.

Another option I have found makes a difference in the performance of
the filesystem is the log size: -l size=xxxb A larger log means that 
when there is a lot of metadata activity, there is more time before
modified metadata has to be flushed to disk to make room in the log
for later changes. However, a larger log also slows down recovery.

Finally for really large filesystems, you want to keep the agcount as
low as possible (-d agcount=) An allocation group can be upto 4Gbytes in
size, more allocation groups means more of them to scan in low free
space conditions. The allocation group size also governs the maximum
extent size you can have in a file. There are some changes in the Irix
version which will show up on linux shortly which will make the ag
options in mkfs easier to use - right now they are very non-intuitive.

At mount time, there are really three options which will make a difference

	o biosize (in the released tree the default is 16 or 64K, in the
	  development tree the default is 12 or 4K). Making this larger
	  may help some applications, it will hinder others.

	o osyncisdsync - indicates that O_SYNC is treated as O_DSYNC, which
	  is the behavior ext2 gives you by default. Without this option,
	  O_SYNC file I/O will sync more metadata for the file.

	o logbufs=4 or logbufs=8, this increases (from 2) the number of
	  in memory log buffers. This means you can have more active
	  transactions at once, and can still perform metadata changes
	  while the log is being synced to disk. The flip side of this
	  is that the amount of metadata changes which may be lost on
	  crash is greater.

Steve

p.s. maybe this should go in the FAQ


> 
> I hope you all don't mind the questions. I'm in an asking mood today.
> Thanks a lot in advance for the help!
> 
>  --> Jijo
> 




From owner-linux-xfs@oss.sgi.com Mon May 14 08:27:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFRgL15024
	for linux-xfs-outgoing; Mon, 14 May 2001 08:27:42 -0700
Received: from giants.mandrakesoft.com (office.mandrakesoft.com [195.68.114.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFRfF15021
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:27:41 -0700
Received: by giants.mandrakesoft.com (Postfix, from userid 500)
	id 8A27FCC43; Mon, 14 May 2001 17:26:00 +0100 (BST)
To: "Steve Wray" <steve.wray@the.net.nz>
Cc: "Eric Sandeen" <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: Re: clean install of sgi/xfs/redhat 7.1 and rernel mods won't compile
References: <NBBBKLKHMJHIJLHOGAOJEEJGIOAA.steve.wray@the.net.nz>
From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
Date: 14 May 2001 17:26:00 +0100
In-Reply-To: <NBBBKLKHMJHIJLHOGAOJEEJGIOAA.steve.wray@the.net.nz> ("Steve Wray"'s message of "Fri, 11 May 2001 16:39:07 +1200")
Message-ID: <m31yprx5gn.fsf@giants.mandrakesoft.com>
Lines: 10
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.0.102
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Steve Wray" <steve.wray@the.net.nz> writes:

> Well make mrproper worked!
> I can't imagine why redhat (or anyone else, except maybe microsoft)
> would distribute kernel sourcecode that won't compile out of the box!

this is for dealing with muliple kernel header in the same source,
which make sense a lot when you boot a kernel-smp and want to
recompile a module for your kernel and not for the last
compiled/shipped one.

From owner-linux-xfs@oss.sgi.com Mon May 14 08:29:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFTrh15081
	for linux-xfs-outgoing; Mon, 14 May 2001 08:29:53 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFTpF15077
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:29:52 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id RAA1138594
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 17:29:49 +0200
Message-Id: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 14 May 2001 17:29:46 +0200
To: linux-xfs@oss.sgi.com
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: XFS & Kickstart installation
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


	Hello,

Has anyone tried a kickstart installation when trying to install
an XFS enabled system?

On http://linux-xfs.sgi.com/projects/xfs/1.0_installer.html
you can read:

Kickstart installations have been extended to include file system type. 
Add "--fs xfs" or "--fs ext2" the "part" command to seleect file system type.

So I've tried with my kickstart configuration which works fine with RH 7.1:

"part / --size 800 --fs xfs" 

but this does not work if I start up with SGI installer CD. It also does not
work if I omit --fs xfs.

I get this error:

"No valid devices were found on which to create new filesystems".

Any ideas?

Werner Maes





From owner-linux-xfs@oss.sgi.com Mon May 14 08:35:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFZxh15360
	for linux-xfs-outgoing; Mon, 14 May 2001 08:35:59 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFZwF15357
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:35:58 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EFZvk25862
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:35:57 -0500 (CDT)
Message-ID: <3AFFFBE9.7BB740B9@sgi.com>
Date: Mon, 14 May 2001 10:38:17 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - Add new arg to xfs_ag_best_blocks
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 14 08:27:31 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

This is a merge of irix6.5f:irix:94019a, userspace files also affected
but not in this checkin:

cmd/xfs/mkfs/xfs_mkfs.c

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94783a
linux/fs/xfs/xfs_macros.c - 1.38
        - Change "Best" AG size from 1GB to 4GB when the filesystem
exceeds 64GB          (irix6.5f:irix:94019a PVs 821993 821994)

linux/fs/xfs/xfs_ag.h - 1.38
        - Add new arg to xfs_ag_best_blocks (irix6.5f:irix:94019a PVs
821993 821994)

From owner-linux-xfs@oss.sgi.com Mon May 14 08:44:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFiFj15546
	for linux-xfs-outgoing; Mon, 14 May 2001 08:44:15 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFiEF15543
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:44:14 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EFi6k28430;
	Mon, 14 May 2001 10:44:06 -0500 (CDT)
Message-ID: <3AFFFDD2.3AA29421@sgi.com>
Date: Mon, 14 May 2001 10:46:26 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS & Kickstart installation
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

werner maes wrote:
 
> So I've tried with my kickstart configuration which works fine with RH 7.1:
> 
> "part / --size 800 --fs xfs"
> 
> but this does not work if I start up with SGI installer CD. It also does not
> work if I omit --fs xfs.

Hm, this used to work...

Can you try the "--onpart" directive, to specify a partition?

i.e. 

part / --size 800 --onpart hda1 --fs xfs

In the meantime I'll look and see if I can figure out what's going on.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 08:45:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFjST15567
	for linux-xfs-outgoing; Mon, 14 May 2001 08:45:28 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFjSF15564
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:45:28 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EFjRk28863
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:45:27 -0500 (CDT)
Message-ID: <3AFFFE23.44194F4C@sgi.com>
Date: Mon, 14 May 2001 10:47:47 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - Add instrumentation for error conditions.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 14 08:39:44 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

This is a merge of Irix6.5f:irix:93790c, affecting PV 818277.


The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94785a
linux/fs/xfs/xfs_ialloc.c - 1.145
linux/fs/xfs/xfs_rw.c - 1.339
linux/fs/xfs/xfs_vnodeops.c - 1.501
linux/fs/xfs/xfs_mount.h - 1.127
linux/fs/xfs/xfs_inode.c - 1.319
        - Add instrumentation for error conditions.
          (Irix6.5f:irix:93790c, PV818277)


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 08:50:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFoPI15676
	for linux-xfs-outgoing; Mon, 14 May 2001 08:50:25 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFoNF15673
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:50:23 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EFoMk00719
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:50:22 -0500 (CDT)
Message-ID: <3AFFFF4A.AAA770D0@sgi.com>
Date: Mon, 14 May 2001 10:52:42 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - Move the call to _MAC_XFS_IACCESS() down after the call to 
 xfs_trans_ijoin().
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 14 08:49:02 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

This is a merge of irix6.5f:irix:93795a, affects PV 819774

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94787a
linux/fs/xfs/xfs_vnodeops.c - 1.502
        - Move the call to _MAC_XFS_IACCESS() down after the call to
xfs_trans_ijoin().
          (irix6.5f:irix:93795a PV 819774)

From owner-linux-xfs@oss.sgi.com Mon May 14 08:58:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EFwoa15888
	for linux-xfs-outgoing; Mon, 14 May 2001 08:58:50 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EFwnF15885
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 08:58:50 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4EFuU431746;
	Mon, 14 May 2001 10:56:30 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 14 May 2001 10:56:29 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: What's wrong with df?
In-Reply-To: <Pine.LNX.4.21.0105141844370.3448-100000@kalapati.jijo.local>
Message-ID: <Pine.LNX.4.33.0105141055430.31445-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I usually don't put all my eggs in one basket with DF. I use it as a
generic tool, but for accuracy, I use du. Perhaps you can perform du -sk
and compare that to the DF output. You should see good similarities.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Mon, 14 May 2001, Federico Sevilla III wrote:

> Hi everyone,
>
> While migrating a ReiserFS partition to XFS, I noticed that df reported a
> pretty significant space utilization difference between the two
> filesystems. I transferred my files using two methods, and both had
> identical results.
>
> First I used tar from /xfs: "tar -cl /reiserfs | tar xv", then I used cp:
> "cp -a /reiserfs /xfs". Here is the output when I ran "df -h" after each
> file transfer operation:
>
> Filesystem	Size	Used	Avail	Use%	Mounted on
> /dev/hda5	2.0G	692M	1.4G	33%	/reiserfs
> /dev/hda3	952M	746M	206M	78%	/xfs
>
> If this is accurate (although it doesn't seem accurate as I will later
> elaborate), then XFS uses 52MB more than ReiserFS does for a relatively
> small partition (this is actually my root partition, and I only exclude a
> small boot and the home partition).
>
> I decided to check using du by running "du -csm" and found that ReiserFS
> uses 734MB and XFS uses 733MB. This looks more accurate. Would anyone know
> what's wrong with df? It's a much handier tool to use than du, but if it's
> not accurate then it doesn't look like a good tool to use, handy or not.
>
> Thanks in advance for your comments and suggestions.
>
>  --> Jijo
>
> ---
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly
>


From owner-linux-xfs@oss.sgi.com Mon May 14 09:33:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EGX4Q16644
	for linux-xfs-outgoing; Mon, 14 May 2001 09:33:04 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EGX2F16641
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 09:33:02 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id SAA613208;
	Mon, 14 May 2001 18:32:22 +0200
Message-Id: <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Mon, 14 May 2001 18:32:17 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: XFS & Kickstart installation
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3AFFFDD2.3AA29421@sgi.com>
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 10:46 14/05/2001 -0500, Eric Sandeen wrote:
>werner maes wrote:
> 
>> So I've tried with my kickstart configuration which works fine with RH 7.1:
>> 
>> "part / --size 800 --fs xfs"
>> 
>> but this does not work if I start up with SGI installer CD. It also does
not
>> work if I omit --fs xfs.
>
>Hm, this used to work...
>
>Can you try the "--onpart" directive, to specify a partition?
>
>i.e. 
>
>part / --size 800 --onpart hda1 --fs xfs

In my case, I don't have partitions created on the disks, I wanted to do
this using kickstart.
I've done another test on a machine without hardware RAID (my first tests
were done on a machine 
with a hardware RAID controller). I get a similar error: "Error mounting
device sda1 as /: No such
device. This most likely means that the partition has not been formatted."

>In the meantime I'll look and see if I can figure out what's going on.

ok, thanks

Werner Maes


From owner-linux-xfs@oss.sgi.com Mon May 14 09:49:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EGnIw17083
	for linux-xfs-outgoing; Mon, 14 May 2001 09:49:18 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EGnBF17078
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 09:49:12 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA1396943
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:49:07 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1807193 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 11:47:50 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA53479 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 11:47:50 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EGo6l19097; Mon, 14 May 2001 11:50:06 -0500
Message-Id: <200105141650.f4EGo6l19097@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: [PATCH] [CFT] - LVM snapshotting support for XFS
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="==_Exmh_-2055509860"
Date: Mon, 14 May 2001 11:50:06 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multipart MIME message.

--==_Exmh_-2055509860
Content-Type: text/plain


Here is some experimental code for XFS which should allow use of the LVM
snapshotting capability. There are two attachments to this message, a
kernel patch which will apply to the current development tree (2.4.4 base)
and a tar file which adds a new command to the xfs commands. You will also
need to apply the VFS-lock.patch from the lvm sources to enable snapshotting.

The new command added is xfs_freeze which can be used to stop and flush
an xfs filesystem and then restart it. If you apply the VFS-lock patch
from the lvm sources then you will not need this.

I am looking for people to test this code, previous experience with lvm 
and its snapshotting facility would probably be a pre-requisit.

Steve



--==_Exmh_-2055509860
Content-Type: application/x-patch ; name="snapshot.patch"
Content-Description: snapshot.patch
Content-Disposition: attachment; filename="snapshot.patch"


===========================================================================
Index: linux/fs/xfs/linux/xfs_ioctl.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/linux/xfs_ioctl.c_1.36	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/linux/xfs_ioctl.c	Fri May 11 15:47:37 2001
@@ -1239,6 +1239,47 @@
 		return 0;
 	}
 
+	case XFS_IOC_FREEZE: {
+
+		if (!capable(CAP_SYS_ADMIN))
+			return -EPERM;
+
+		/* Stop new writers */
+		xfs_start_freeze(mp, XFS_FREEZE_WRITE);
+
+		/* Flush delalloc and delwri data */
+		VFS_SYNC(vfsp, SYNC_DELWRI|SYNC_WAIT, sys_cred, error);
+
+		/* Pause transaction subsystem */
+		xfs_start_freeze(mp, XFS_FREEZE_TRANS);
+
+		/* Flush log to disk */
+		xfs_log_force(mp, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC);
+
+		/* Flush any remaining inodes into buffers */
+		VFS_SYNC(vfsp, SYNC_BDFLUSH|SYNC_ATTR, sys_cred, error);
+
+		/* Push all the buffers out to disk */
+		xfs_binval(mp->m_ddev_targ);
+		if (mp->m_rtdev != NODEV) {
+			xfs_binval(mp->m_rtdev_targ);
+		}
+
+		/* Push the superblock and write an unmount record */
+		xfs_log_unmount_write(mp);
+		xfs_unmountfs_writesb(mp);
+		return 0;
+	}
+
+	case XFS_IOC_THAW: {
+
+		if (!capable(CAP_SYS_ADMIN))
+			return -EPERM;
+
+		xfs_finish_freeze(mp);
+		return 0;
+	}
+
 #if (defined(DEBUG) || defined(INDUCE_IO_ERROR))
 	case XFS_IOC_ERROR_INJECTION: {
 		xfs_error_injection_t in;

===========================================================================
Index: linux/fs/xfs/linux/xfs_super.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/linux/xfs_super.c_1.121	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/linux/xfs_super.c	Mon May 14 10:18:41 2001
@@ -725,6 +725,36 @@
 	return 0;
 }
 
+void
+linvfs_freeze_fs(
+	struct super_block *sb)
+{
+	vfs_t *vfsp;
+	vnode_t *vp;
+	int error;
+
+	vfsp = LINVFS_GET_VFS(sb);
+        if (sb->s_flags & MS_RDONLY) {
+                return;
+        }
+
+	VFS_ROOT(vfsp, &vp, error);
+	VOP_IOCTL(vp, LINVFS_GET_IP(vp), NULL, XFS_IOC_FREEZE, 0, error);
+	VN_RELE(vp);
+}
+
+void
+linvfs_unfreeze_fs(
+	struct super_block *sb)
+{
+	vfs_t *vfsp;
+	vnode_t *vp;
+	int error;
+
+	vfsp = LINVFS_GET_VFS(sb);
+	VFS_ROOT(vfsp, &vp, error);
+	VOP_IOCTL(vp, LINVFS_GET_IP(vp), NULL, XFS_IOC_THAW, 0, error);
+}
 
 int
 linvfs_dmapi_mount(
@@ -807,6 +837,8 @@
 	clear_inode:		linvfs_clear_inode,
 	put_super:		linvfs_put_super,
 	write_super:		linvfs_write_super,
+	write_super_lockfs:	linvfs_freeze_fs,
+	unlockfs:		linvfs_unfreeze_fs,
 	statfs:			linvfs_statfs,
 	remount_fs:		linvfs_remount
 };

===========================================================================
Index: linux/fs/xfs/xfs_log.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/xfs_log.c_1.236	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/xfs_log.c	Fri May 11 15:21:49 2001
@@ -802,6 +802,9 @@
 	int 		spl, needed = 0, gen;
 	xlog_t		*log = mp->m_log; 
 
+	if (mp->m_frozen)
+		return 0;
+
 	spl = LOG_LOCK(log);
 	if (((log->l_covered_state == XLOG_STATE_COVER_NEED) ||
 		(log->l_covered_state == XLOG_STATE_COVER_NEED2))

===========================================================================
Index: linux/fs/xfs/xfs_mount.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/xfs_mount.c_1.255	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/xfs_mount.c	Fri May 11 13:41:40 2001
@@ -116,6 +116,11 @@
 	 */
 	xfs_trans_ail_init(mp);
 
+	/* Init freeze sync structures */
+	spinlock_init(&mp->m_freeze_lock, "xfs_freeze");
+	init_sv(&mp->m_wait_unfreeze, SV_DEFAULT, "xfs_freeze", 0);
+	atomic_set(&mp->m_active_trans, 0);
+
 	return mp;
 }	/* xfs_mount_init */
 	
@@ -163,6 +168,8 @@
 	if (remove_bhv) {
 		VFS_REMOVEBHV(XFS_MTOVFS(mp), &mp->m_bhv);
 	}
+	spinlock_destroy(&mp->m_freeze_lock);
+	sv_destroy(&mp->m_wait_unfreeze);
 	kmem_free(mp, sizeof(xfs_mount_t));
 }
 
@@ -1579,3 +1586,64 @@
 	xfs_mod_sb(tp, fields);
 	(void)xfs_trans_commit(tp, 0, NULL);
 }
+
+/* Functions used to lock access out of the filesystem for snapshotting
+ * via special purpose hardware or via a logical volume manager
+ */
+
+void
+xfs_start_freeze(
+	xfs_mount_t	*mp,
+	int		level)
+{
+	int	s = mutex_spinlock(&mp->m_freeze_lock);
+
+	mp->m_frozen = level;
+	mutex_spinunlock(&mp->m_freeze_lock, s);
+
+	if (level == XFS_FREEZE_TRANS) {
+		while (atomic_read(&mp->m_active_trans) > 0)
+			delay(100);
+	}
+}
+
+void
+xfs_finish_freeze(
+	xfs_mount_t *mp)
+{
+	int	s = mutex_spinlock(&mp->m_freeze_lock);
+
+	if (mp->m_frozen) {
+		mp->m_frozen = 0;
+		sv_broadcast(&mp->m_wait_unfreeze);
+	}
+
+	mutex_spinunlock(&mp->m_freeze_lock, s);
+}
+
+void
+xfs_check_frozen(
+	xfs_mount_t *mp,
+	int	level)
+{
+	int	s;
+
+	if (!mp->m_frozen) {
+		if (level == XFS_FREEZE_TRANS)
+			atomic_inc(&mp->m_active_trans);
+		return;
+	}
+
+	s = mutex_spinlock(&mp->m_freeze_lock);
+
+	if (mp->m_frozen < level) {
+		mutex_spinunlock(&mp->m_freeze_lock, s);
+		if (level == XFS_FREEZE_TRANS)
+			atomic_inc(&mp->m_active_trans);
+		return;
+	}
+	sv_wait(&mp->m_wait_unfreeze, PINOD, &mp->m_freeze_lock, s);
+	if (level == XFS_FREEZE_TRANS)
+		atomic_inc(&mp->m_active_trans);
+}
+

===========================================================================
Index: linux/fs/xfs/xfs_mount.h
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/xfs_mount.h_1.126	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/xfs_mount.h	Fri May 11 11:42:06 2001
@@ -308,6 +308,10 @@
 						/* which bits matter in rpc
 						   log item pin masks */
 	uint			m_cxfstype;	/* mounted shared, etc. */
+	lock_t			m_freeze_lock;
+	uint			m_frozen;
+	sv_t			m_wait_unfreeze;
+	atomic_t		m_active_trans;
 } xfs_mount_t;
 
 /*
@@ -481,6 +485,14 @@
 void		xfs_force_shutdown(struct xfs_mount *, int);
 int		xfs_syncsub(xfs_mount_t *, int, int, int *);
 void		xfs_xlatesb(void *, struct xfs_sb *, int, xfs_arch_t, __int64_t);
+
+#define XFS_FREEZE_WRITE	1
+#define XFS_FREEZE_TRANS	2
+
+void		xfs_start_freeze(xfs_mount_t *, int);
+void		xfs_finish_freeze(xfs_mount_t *);
+void		xfs_check_frozen(xfs_mount_t *, int);
+
 extern	struct vfsops xfs_vfsops;
 
 #endif	/* __KERNEL__ */

===========================================================================
Index: linux/fs/xfs/xfs_trans.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/xfs_trans.c_1.119	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/xfs_trans.c	Fri May 11 15:50:11 2001
@@ -105,6 +105,8 @@
 {
 	xfs_trans_t	*tp;
 
+	xfs_check_frozen(mp, XFS_FREEZE_TRANS);
+
 	ASSERT(xfs_trans_zone != NULL);
 	tp = kmem_zone_zalloc(xfs_trans_zone, KM_SLEEP_IO);
 	tp->t_dqinfo = NULL;
@@ -165,6 +167,8 @@
 	 */
 	if (tp->t_dqinfo) 
 		xfs_trans_dup_dqinfo(tp, ntp);
+
+	atomic_inc(&tp->t_mountp->m_active_trans);
 	return ntp;
 }
 
@@ -1052,6 +1056,7 @@
 xfs_trans_free(
 	xfs_trans_t	*tp)
 {
+	atomic_dec(&tp->t_mountp->m_active_trans);
 	if (tp->t_dqinfo)
 		xfs_trans_free_dqinfo(tp);
 	kmem_zone_free(xfs_trans_zone, tp);

===========================================================================
Index: linux/fs/xfs/xfsidbg.c
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/fs/xfs/xfsidbg.c_1.161	Mon May 14 10:25:20 2001
+++ linux/fs/xfs/xfsidbg.c	Fri May 11 12:48:48 2001
@@ -3999,6 +3999,8 @@
 		(xfs_dfiloff_t)mp->m_dirfreeblk);
 	kdb_printf("chsize %d chash 0x%p\n",
 		mp->m_chsize, mp->m_chash);
+	kdb_printf("m_frozen %d m_active_trans %d\n",
+		mp->m_frozen, mp->m_active_trans.counter);
 	if (mp->m_fsname != NULL)
 		kdb_printf("mountpoint \"%s\"\n", mp->m_fsname);
 	else

===========================================================================
Index: linux/include/linux/xfs_fs.h
===========================================================================

--- /usr/tmp/TmpDir.18981-0/linux/include/linux/xfs_fs.h_1.23	Mon May 14 10:25:20 2001
+++ linux/include/linux/xfs_fs.h	Thu May 10 17:00:49 2001
@@ -453,6 +453,8 @@
 #define XFS_IOC_ERROR_CLEARALL       _IOW('X', 117, struct xfs_error_injection)
 #endif /* DEBUG || INDUCE_IO_ERROR */
 #define	XFS_IOC_ATTRCTL_BY_HANDLE    _IOWR('X', 118, struct xfs_fsop_attr_handlereq)
+#define XFS_IOC_FREEZE		     _IOWR('X', 119, int)
+#define XFS_IOC_THAW		     _IOWR('X', 120, int)
 /*
  * ioctl command to export information not in standard interfaces
  * 	140: IRIX statvfs.f_fstr field - UUID from the superblock

--==_Exmh_-2055509860
Content-Type: application/x-gzip ; name="xfsfreeze.tgz"
Content-Description: xfsfreeze.tgz
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xfsfreeze.tgz"

H4sIAKP5/zoAA+xceXcax5bPv82nqNhZQIMkQIvzpDhvkIRkxgg0gBx7Eh9OQxfQT0036UVL
Yn/3+d1b1auQFCc6fsk7IjpWU33r1t23bmWysDavp8HS92bB5ql5Iae2I7943E+tXqvtbm9/
UavV6jtbDf79YvcF/abP9k4Nay8aL3Z36/Wtxhbgt7d2d78QtUemY+UnCkLTF+ILx/Ot++Bc
GV55/sXnIOlzfp6XnotDb3nj27N5KMqTimhAJWJgO/bEc8WJby7n9iSoirY72RCi6TiiT6CB
6MtA+pfS2gAG/AzndiDIjHxzIXA59aUUgTcNr0xf7osbLxIT0xW+tOwg9O1xFEphh8J0rU3P
FwvPsqc3WACmyLWkL8K5FKH0F4HwpuJS+oENchr0he6cdM/FiXSlbzriLBqDWNGxJ9INpDAD
4FjSWjCXlhjf8IZjImegyRHHHg4xQ6C8g/qUSEvYLmOYe0tQNDdDIvvKixzgliIK5DRyqgKg
QPNje/iqdz4Uze478WOz3292h+/2xZUdzr0oFPJSKlT2YunYwAxafNMNb8AVNp+2+oevsKN5
0O60h+8ExHLcHnZbg4E47vVFU5w1+8P24Xmn2Rdn5/2z3qClqT+OfKD1q0AO2mOhF/mIyTDd
m/TkmCGbpMY60xJmgwBrYuKY9oJWaR8O8C2xhDo80uXM9C3bnUFEUx+/5UK6JAZPqc+xLyTZ
DPY5WjkQ8aVtgRiQK223Kq7mkkhPROL5tJ+WruxAVoW5pHUYgevgdK/AIQUrnHBmhjg4PgTG
apM8QW+1eKCwPOF6IaNlfBNvMbZdNoVAsZ4xBJJYTE5yaJXYI1moZcBa0QQWAUEGHlTsa6W8
g8UHc7aTuXkJgcqJtOEvwsShy5vfY8mO586AicjIEbYPBokNiM+3Q3mvgSvPrYqdf5CZS4hZ
ijPHnEixLgYR7d7aqlXFgReEUOlpU9Qa9Xp9vb5Ve1EV54Om5ubQc0MTbELTnr9gzHt3RImq
qO8ihDQXWANlZgh6zi6ubqpk46ArNKGHN7a8qorDphD/2K5tb5FQ99RJ8zBc7m1uXl1dbQQz
ewMKEtrKIfepsvQsGRkzZBlBLpBfVQRS7okcSi8IYpSbkOS/5CQMNiH7NpBtDk7aJ2edLm9u
XS8d090sPS+Vhr2zo3ZfvBQbpVfNN63RwXm7c3TUOh5g6asyIgwCYiiDUKxP8V1BVzZtd+JE
ltwcR7ZjWXIaiG++EXIy98QNbPnDB3XtepVSyZ7KX0T5q3Iee6VKkJWSRnQf6pJ0ETtLpcNe
97h9ct5vgTIoZWrPIooBtyiJV8BiSEIc0erGvNQZ9A+P253WILc/udqA0qg+WF7MCAeypuOs
B3PRbzWPTlviTas/aPe6pQ6IHCYYNtb4ggS0JjpUYqwJoiSMMQAgxmXJS3xb25j9WioNzg+A
hyiJBeDYY5Qp9GuOlAEb/rlkjBfmUlhjDlu/IhgEkwsx870rgvNmS0SkUCwuKEbQrwCGsjRt
X/jhZEnbFyaFg4mw5NjGJUuoVII0zMgJ9yDyRKKVu7VEOjS+Kp82X7cqYv1QbIiv/rsknUDS
qmZjRHf75x3g0br6vUrnW7RzUFFIJ4403T3jOQWAVElzM3C/DYUfuUQQvIB8AbGNgOMjs+zs
5dV6y0ZoMVao4S/ItrU+J+ZkDtbMKPRopWRsbCaowJZS5Z7QQlwtAyy2u4Nhs9OBxBbixc6O
WLfA7Nnrk9FR73BEZl4EQvkYW1oBsJSxnwcOLvnSdFgonBeVLLWUNJtfldmAK3ntGz+JL4lG
smDxnvzXX1iwJPpe+ndXcH/uM8nW/1rnj33GA/V/rb67xfX/i9rWi916g+p/LD7V/5/j8zwu
fjlM4jcKWi6a0+iCSDKTYVKDZ1IvEiT54mnzf3r9l3V13e7iusHX/dabNtnTy13+ysHsZe1v
7jD/YZ+c/6tE+uhjgAf8f6u+tRP3/7XGDuDqO7s7T/7/WT5P/f9T///U/z/1/0/9/0P9/8bv
asZLh6dHw2b/pEVNMBLrSOVUrMe9dbq4MSl1Oked9oEaJuDiLZpAdXV+3j6q0O3jTvOE7q93
0mNVM5zvVeNjuSNa1T+u7M7ubMQO2t2VjRgBZU8rgme7sadK76//WVX/ZS30Mc54oP57Ud/S
z39evNhtbO0Cfndna+up/vscn821kli7XQHWP60CFIzlsUpAoPrzNSCQfEIRuJqBP1QFAs+f
KAOx+w/VgYqBxykEgehxKkEg+nOlICF4hFoQaB6pGIwJ+pRqUKnmscpBoHqsepAs/o8UhELH
jEeoCMnc7y0J1Vm3a8LY4D+9Jsyj/OSaUKxtlkrP4xLre1WKbcx/yKwtXDLB/FpwE2za3iR0
aLmEnAOcYjI3fWNt6poLuW8Ym2uIgZCFWHr05IJW6bAcLHRoorTaJ2C6Ri13CeIS4Bj60rOt
UhSYM1mmy0rpt5Ix5Sci03IQIrb61dKzc7q/J74OxE/eko3+vaKACfjZxX+lnrqxR9dCf9an
IvnEz17gfGAxlAthTiYyCHLwUQofufftMNbDFNR0EPvhjYge3kSpdcp5gmQUmmPYbXlThpPN
Bb5UfnafVUuGQR5Bwqjslwx5bYflBq4+lkosEAkder4c0YYyCVSs0WVV6GvNOUsL4ZIcWenS
oHvASDW8gS/hcr9UMuB05TKuUZ0HMlSQZYXwmf+sUhEvX4ruORXOwFcUv3j2dbBH+ZAjEEtA
s4acFQq6+XWgmUq4qorT3nl32DqCKcOJfN/zy/jX9SrEr2K4Tpfg2Lia00gXFALnSxrhJhQu
QduXWdqIEyCcLJYEvf4D/hlZNohMRFIhMuDZoe1Gcv+OLeHNEiQ+g0M84wNqCvtq1mF2yjMR
PgUan4xFxGxn+E4IobMzjIJTwxj70rxgn7iS3yK2TinaUTKDR7AoiFgWwz0KwUqRrqyRZlyz
SvrydHjxVqopJjdR2Ar9gNypDTopWpMvV+mppSjjHzj1y0qVCiNBj6xCG85d9kNe1h4fMG8c
OqDcrNKAXUeJ7I1pwFEGx0rXyhgCOwcILS0QgssUd0x/Nok9Yg1fLtkdcIcMgIU8iXyfcqwK
GgyKRIAITCQpwOnU2i8GNH7CYMlg4tvL0MtDO+asKiL6tR8vOsieDr5x4GOnM8cZnCoAMM5M
FOAYqPCB+0j/rgEN3calVgcWYmVhcWwGki7LxO5Ptfekodh7Jsp3wGtZSYZgYMLTcC96pvyo
1TtWFhUgM0/mXEPT1wnQim+n3+6VYh6Bq84GrCw2gQkVjKYRZ+GQVXCRgovuw/VPholHAwzO
eSD2lo/KHYgZZHzSIcwMXNTJxVNQDm6K6P9SgqzchqIYmwmpKvaxEBXe9wwDY2CupFueKvfo
jfpHvW7nXXwQQXwfh4ulimvTOIwbvgwj32VuY2eeKoIInO0kFgbd4zRLKKsUVkbt3uHouN9q
/V+rKr5h4Ep61r1R+VamesZB6ZmyQCrdinE6EwE0p6vCdCF8xTxFKU93sDF81fzxL8zExPEC
SRRzVPl3d7ZPn9/zyc1/4nEmD4BQ1D7SGffPf7br+Imf/zV26V0AdAuNp+d/n+Vzx/znE58A
AsXffgC0koO/1QRIPI2A/rIjIPEfNwMSn3MIJFZPgURi9X/k2WAe7R+aBD23pwhUUzHqtLvn
b0dUqOHnVek5Fm1X3lrPTY7c6HqTWubC+MgMFplRUUlFaBDwbVBok7GwMP8FzoMwmqJihMyR
zNww4IoNNhj59DqpmlhpgoiSwflZqz86bZ60D0Xteue77d2dre1GDqTbPG0Z3MjTSIknIWPb
C2xUkqg4R6Noq2EIg5Z+HVHZGuzTaoBVvYiexCqusWGmi9bUGa0CTtf1ho+4BzGwstDgQjGi
vdlD4RrnECwhe6tX19gxjkdH7V67e9zjLaOF7RI+CoLkFvgqrqfkweCnml6KBTomm3yBOm9u
LWEoF3DLaSA5lJmOPXMprm2U1GiOJWPZHtGSSsbAkXKhRno8pRtDPzgEi55/k2IxqAVOtygq
VY+bJdEowJnXKZx5XYCDsGKTiW2Ax2bHMMCT1vBtczjs/9R8zyzS2kCv5TiaBtd5joSBpdG1
UjUdrC4hJIlgdmk6EXpltMmbEFQlQ67aJ69Doo836uvVO4sbXUBDTurI+MutrerAyA0gVlgA
Dwxo99K0fqrvvt/PyORYUa1T0jjQLG2m3CnsqhZAiojjNVK8iawj10NvHb8Qr30419KD97sI
m2NUh1IldURphchUsx1CRS511KZH+aNACVo7m0F33vKNfqvZGbbhdrXr+L3YFVBnBNbpHaZQ
jRVQr5oD0imAvtNQaqRKUvSEokRLwQ6MleTglHQUS6/Ll8VtWj/cJuzDLSpEpXSXScIgD06b
Z5xOevRq6TJCAoPnOVRtjReXI+V7LEv66kh3Bv/WiXJq+0GYxjrCghRuu5Y9MXUKROIzCRz9
MbQZhHEVR95dTdDCrOCXOqcyHjdajOFWVOmgOroR0uF6JhAzJGwXRcbw9vn8+uwSDk+Vi0tY
9OSC3qDFNj44w5BmJrZGsm/Ux46Tc0XYN/+dA7tisLuNYJqIZV/NEJ0EK8gN5IwIZfk53uRC
DQozW3mVd1LnE1Ju5CVR3t1eH6P8s0zL8kdhRRR3Knp5a6oHfV5Vn2aQteh9HPmxb0LJnbc9
px0kbKrhQKGSLWW+DVGHKIs7NejtvWQiqiQvo4yF1ShqE0c37rC0t4nm4ORB1sLCue9Fs7nI
HEt4qHDivCKvUeegRjSD2IRizST617j1+nXOMI05NkKwNpUlqOvoGDuNE4qQNP4EG4wqAxWH
JcPW1S9TFdtOwRJBSTukV7ippgqUX+moRCiCpZyg1SLVp5IR4I+qXs1FkSJhZ6ROSOKWKkWA
ymnBmRNESXMy1+aPHamLmNNQZkheZerXT7b+gK1vFPfaaWLO6rpczxpFZRW9XrpTIY+3KkXl
ERT2Ri7ZYF1pJmL1YsEwVp2jYBt3wirPzTCj8nuAhoSUDWPLGhqCJNoqI1PYGgenb0bt4xEl
HPTIrw3kvjodpkMwlzMwzAvhm9wloNl1VXGWpj+hkXR7oyMc1KY8dwREDUJ0pDrFGTdmyC4M
Qc9nLO7nlUILiJJsDSTbTE3okimGUcAgvRSE2jdf/pIr1jWWN81O+8goFzj8sIrYD4WDK4lU
vYJUE9+c+uijMsJNvNf13HX0aTSHiR2tSFwvzyILPIZ9KSKXCnjUbOhR5Tp0Fj/GJTQgC80j
uuM0xX2//kMaA9bFwrtMAjUTuaxTJl02NrJ0GJrw0WGv+6bVH5aX9eqyURG/GahZAJsJ8S+B
YSMbUVIIFRUSAB030vs6BiQAcXhIIdjxUwAdB9L7sTcnELG/C/GR2sIpt5Gj161+t9UZjVhA
ryU05KhwX/SMjWzZprXeejtsdY9aZLLbuu4jjUCmS5apPWVnYunxnwXS3fRMrZfVvQP6hKPT
jbjXhu+ST47NyUW01A8qg9DzZTyOCEhVKq9yRwkm1i07uEB88iyusLRmLXtkLeTlwsQ9wsPf
yUV0Og2oLUMUGkuFzkszsctlOktHmzXs7NL2ogAr3phyH+z70jb5ndtx5FwQ3i+FKA84AdoU
R27iio9hCGAUJuVBkKeNvyvaKvl2yVrYHEt+S4Ie1pLN6qlp0jGwbLJ867anvqu2LalOcGf7
uUV98J2o+G6+CBLHqoVV/kgmTQmQpMi00uiB1bu7LSgXqpcQWMVNJ/DSAsOkv3GGGvutwZtN
epSmqumpCXiVwAkV2a+WBz8/oPOAWUmEuHD4/YD9zPerOTVP+0nidUacprMLcDTVR+OCHt/X
0ESbKGngXbaDFGlRpuSyAGTE3YpWAdDdBLa1n6wvbWsU0vrSzswbHG4Ut9/vq3TBM23uGzLZ
KcvSKEwE3NMpE0JKHjWiy+6dtob9d3dKJvCWo5lEQEsHBqqgiHvkzGsHZVJVRVct3ORnZgF+
mO2sk1cFVJ98e3RgztQx6oxAl0xUmriieVIATQuZTCuUhvAZquVlEKd53uN4d+Hn8a83y50Q
0HwtJl1zSWtePJYZ34QyyO7gyJFs4W9qbEPlHwPnoBfm9XISJlMSov2Kyyjet4Txlr9ORhVk
bETDHQywvwTR+NJzooXMbvLDO7Yk2lDb8nuyYw0kwHiwcXtbZhcEqLwjV87qI+OOmKR8exgS
RbaahNDWyLV/iSA0K+2iY2vL6QdwoXI9emyAUEEL1YTHHOyVbVE2zADzyi1o9jf9HEfzEecZ
vZrToa5NGTBaSl+xGj8H4rtG3gBzVkWv09xvUn6Y25AK/95dlu3n/VUNJWm0l/ppZt/HvNvr
+FEMHvg5pJdTBveFDfbKQAcOWAU9pCHjVOZH435lqpJ7uXxXFMP74XUKnrG+PBT8JIVSrpeB
4EgQg4ReiI5WB4fYxQKR51xRHvPepi5lsyABVHIoYgcHndcDTrc8q86s3SMXhO0x0nsiGCH0
yn5xYWRemraznyUtvkO0ZQdhx4Pe2Yii+Uj/YbxRuwuA/0pnpGduNa6Dk/E0+zU1O4U5W3F3
t9Puvqbt3G5sNbhBdR3bvdDlzUMI/ve8N2wSAm41fomglgApkl6Ush7a20aPcdKlzd+l0TU3
qL5v91G8u84Fp2P6M22JvxvF4FWzz5Vro6Zd0Vrn0i5ABHuYfpS+x50TLnw5XFCBB6PUqZBC
xYM8tPtvGjwxzbt08tiZ202d+E9t115ECzZTmsfTNXl9IFypqyb6P5GgZZjMJVzw1sz3tN0d
NU9GB+icXg+M3e1bNzu95O5OPT/jPW2+zd4uw7rXRL3W2K6sxvJu2AJUY2d3NViMTYHVG99p
sARa85ypcPq9H48HR81h864aR/1vWEZpTcwpzJVXmWyJb9nEqqNmkkPvyOW0K5PD6fHzBCo2
Z/SEeaHe+fxYpCFTshW5AOsPMEFpJK3UbvPAaeZu2gPb1Xm0zo9o9Q47UFU0DQOLJOP+PRT3
hw8QjJh+n8zTLHcn0dmyMrclU1rmd37ME8DkF3vJoDB04IecGfYOzhHlh82h+GbF4mjQ7p50
Wnexjs6N6APf9Juq/PByhDSoqwc5oWbJyJYhuO8yAMVquLFrul4MlzCk0DI3qw81s7JGf8g5
MY2gqnY2kqqG+h5ALXBPpU7qwTiIYKUIxbG/UILTUr7QBSDKO3UosoyPys4oAsxiAC7bV0H4
yV8VqD8o4Ixj5AQGKEqTsV1kWpIETAsh18hkQbIiJUCTLpUG1Bvw9P0O2EUCq18Uugd2ksAq
NaAKdhEg1A793jE1cpqp1D0SOeuytSClzANQ9gR6kUSVoQVBFZ54pu3Ybbj0+WZyuF69pcW4
F9YzSH75msqqouHQ6wu2egFbv8mQqjzfGRAwPSXV3S+uVVitCjWwLZKQm2gcnbZP9OyT1opU
ZCcWDKpGFPR6RhHUzMohfa5/WyJZxzTDTJCkRxZk/evqdeCDyLkYkHP2JZodfuynJxaZhyT3
Nug0LqJ5bOrda44JE1uq1sJknGRbz9Xr7eTlGd3aun9W4xoaDeafBqg3AnjH/7f3pM1pXNl+
hl/RL6mJwYOQkeQlo0yqQEI2zzJoAMVxJlNUA43UY6CZ7kaykvJ/f2e7Wy+ylOTNvKrHrbJF
d99z7nbuctaLrikAu+VXx3oei9EAniW4JLSdb9qFPI0Mly7S+5kxuJcafc616UGLMwKFPACJ
B+xhchV6sHgA01necVDNq3hjddmncCKcauSyrc7qaLUIAIiPsNUocAxOSGqFkgr8SMRmccYK
SBMmCdWMvEKzJKY7uKZ2R2QI6A1HmfvN5MNR6gwBETsri/CCD4hnp5PxYPKm3T8lpyJDCRtf
MdNEB/iIdtjOXIws3hgt69UyZOMJuRKGooCJZrs6/uDKS/jduiA3C7sd1FEWtUWsgtzCrbKv
c/kt1J8LOk+xizhAXbRAh4H4p/C2aEk6hTWdaRZeBOl1iJjvvNNu5/I1WuXB717/9PKkC4eJ
SXc4HAwR0zRYRrewHqPhRhwsSQ9KrAYgYdBbtEDYrufRdgrUg9J3NP+AXQfqLFaNMyRgHBqm
g/2nSi+SKZCE7WjPz5/nNSqhjkHk1JsMRL0uJJlpcSnBkW3+xPSMEkJb9hsLLe+0XgJcig43
n4uwYNezkgCtRrhboM6Zuloqg5NotSG/q8TRHWz8JMEOBpYw0Up2PvmlERWM6z08TqZ3MvD3
TizM7c6u8qn39Br+P4bqS8zIODubiUgx2aIomUSClsqLNkDDG5lurMjF5UVvVPBNHSvQS06v
/JboNJv3c1mTrE2N5fcsCA7nQHjhAii86Y20TZII82qw0y0D3JM2aGbmz66BsOqFBKOWIzzh
/f0Atv2KOaipkvhYalUS5eZurezq5OuDtbCE2ECTPs63K4zEyZVramtrNMq724guhjS7ZK7t
83FhiadCMcWLb8i6EyY22YZHWheLuL6iTNyLyVeOkZUHLO5Z73T0kyL8oxe54/wCWv2rUbhA
g23Ng+j/iVtV0mYvf5pCMMzzd1XgP4yjbu3Gj0PyWWN8YrCCBZexF06d5EVRteIAnffmeie1
s2/EshLXYfWu6BzpbMW4q6rMmqFhLVGS27o/q7re04wD0w7dhuImWLowVX05mKJKrKF1gb8E
cWRxrLpZRa2yJZuqRRkOzbMbclDWEllGfsVxl4VWuB72VwZSYLYnimeW9AwbeO0j5gpVpWIm
ledN8Esip3WZPovCec/erIhpe1zV45NWGPVxbh4nouTkl71TS5PFDbEFnp5Ug9A3VaVcceeb
Ue+nbo1h65VaTVyo69436mWT69K0qI9sB1GTtufl89dJxSYZ/uyVoQE6qbsmzHxqmpy8u6hd
txre9UG9MkVXZH5oELMFvV6zG1u3cJyNqDGVisrIw2EsFXmHEoumhF0j4mBDNvK9Ye9HbzFb
p8ta/UmiVOJP5tFsi8NNpPfE22zjTYQq1BWqxcncxF/fcXBejOVLdu+of/lqtpp7X38lZlZx
sFiiToI+mZKETps5QSJKScgAY3QBxNgbvPdqT3580vBazxoF6th6Dhb1uVnQ1sNAxcaaYIcC
e2iKFbPogiK1IbIDaUoV8+MiyJEFqep7ePBlSOkimKo24IvH9FEG9uXDYMU8hTt4KLCvNKzY
u5Q09fSdMzCH31oNFZODPCSq6TMjevRAYrjsC7AN+0BqYEi3k44OHlduBvrwUV3ctrv46Ogh
XazosG0T4tHzL5MTjE2nN6AlxK6woSfxliiurIHUZb58GCRaaNnNfP4i38yHrmDM1MsSll9U
jCFDhY0qTG1bzzL0pFSbRX2sBLgai6p761krj0VEFPchEklwDtvBo7D1+pfvOt3hqKBah49A
dNEev0E2HjYU2pLy2I7y2PRZvxyfiAXy6J4/Cp0jY8gje/EoZIOLbn/S+VCO7uWj0KG9Iqo8
DcosvlcPwad1BaP37Yvuj+NKQcW+dRAlt/4m+JQWLghas2WwqE3RpXlLu1SO6HzwOo+nVYRn
GV2VoxmO81gOirDEhY1is4L8LG4VEDqr6QsXPKWHL0BUQOOiVC9cxu7BVEDeBtNjxShZCqH3
k17/v7sn496g7+U61Z0PGYlIGb6T8257aNxlbHwvv4DvQfKV3FEGNqyT8bkzbRxybxXMG1fG
kG8KR8gomDstmDsUEykLgcEoCvIfPJP8BbsQW29uothxGCWz6pDsotdzP55b1oWIodI6evYX
2bHgbH2zSJoLaBOac9OBec/DWKkstMYzs7EUcmQAFvmdjRDC3n5beEByeHk0lzLcQId0Xeh0
uPFjfxVA/cJf2HPc89oYPwbYLPEs6HTqytEQLc4S1vyIZ7cd9Uob07EfEnG2GKCoczE6GQ8B
8Tmzx2h3JX5H2IFwPiDXIpbFJx55d6+9TudJxrWs0xm96Z3Bevit/Yq4nlrru+/kc936+K49
egsfOddey/o0HnQ6NRJ7EONHzHRdXgDjxhAwFK269/33Xh41wo8NAhe+EAJBatMpZcc/3nff
5XJ5g7Oz31kzwfDougGcqp0CyFSSZgabnur6jrrdt+e9d73xIVqavFxwMib1HTuDdJr1qp5H
ZKFR6fy8CKFpqX4lVbRtwV13ZaSm/3SAil36X02l8V8oPNAfEwLmC/Ffjg4OW3L/y/Nnh60j
iv979HwX/+XfkXbxX3bxX3bxX3bxX3bxX35f/Bc6M1FwycmbyUQfFbPvC9VKKUy/ZMKeR0J5
qGJCZTIwbRwExTIkI8bBIyDWQUrGEDCuZ8riSj0UZIwDjjhMZtYUAjOfR5sekv15EQ50zxSl
VUme5G6l0cjvglyzONB+bfSzIM/qIwY2JdMe/FXUeFyuLLUerV4F2dgS0MrIARsKsqJIxbhW
JK5jBX4sarEZrORuPZOpyAXlc/vzuY8uydz2G2VQBquQthaYF4ARUlEYcgFJkG7DOUZQuQrn
2hvOlIPY1jf+UpvXsSe02ODQp3CuXXMdOOV5D3/3ZXj8tWXNkM0fr4SuyHu3NCteuhj7VyE3
HR+AiYZ18CoUcmKbLaji7CN7rDrjEqc0CY7FpNUyUDZcdX404xS1xgVA+BrXiDyApioXgB1k
roxCNT+F2bbMrA/asVccCKIb2YSMuZ1/1bym0UcjKyiM7BywGPHCJuFBTqhx2j49HaKUt/26
P6itNo15ncK11Bgl6w0nab2GmTsdFlYDGwg5Pci678Gv+t73q0kybSbTiXISzIjPrFI6RcUQ
UHkpf7qnFLrYVJZDILH5sXogFsTXjzeLxPzGmaKfqArxVeK8CK/95Np5M8u9CXNo4DSDJlHW
G/KjwT3FhYxmUeyCzkM3y3Q1TSfoRpJ562/odpVjtgsz0stxdzi8vBhPztvjbv/kw2TcHY17
/ddG7jC6OD/tnpzXEo7kYAkWKu3e+QS9QSbjSmUFk+3TJM196/V749qnxl1dcoTrMIXnd5fj
7o+T0+5Z+/J83PDu6nmkp1CT4eBD7ZMCnQfQougOXuQy44hDBSUjDnLtGzX2frikNw3v4qfu
cOACX/YtcIaGpaAQXogG5+V/lfabLQqzeg5ttLyksOOYhO/pt2QTUo1U132hr3T2B3RX8ldu
soIpbPT9vYWgZT0GRx5b3Hx/r5HJ5UUcpRFFp+NoaHCa4FUVjfpQEor0jzzbdukrYSicz4FL
Q7cpOiUvLCh1s6jEZ6Igbmrh2599onup58EGTerXKRlXSjQnPMfqPG6OprLb5TKxDFJvalaN
I4Ube8QkYh7nNkA+FKEx5toKxbMUgElb60mgNlVTbsH6JloKt7tvznFk8ld7KgsAb864DroL
g/e0flwGgq5uD4eAXH5aWAwvSd5TR/gPe3wZJlyJwgwOOW006AIJ+EuWOWyGswyixWKSNsRK
askukyTst7IlshEgDtJ5fEqXwXoiWYpWR8yJc/JpQRZZKu9rwQSqhY2QCnuZylIMfkJfjCLG
c5oNTwD4xWot/bTgtxaCJbQWq8FuigaTlZ1tpiW7bJOquC3faVCadQ6UyCNdAmFXBQHW0a0f
pg8sApYLtzZKBVIOMru+Yj8bp8uszGLc9gu64gjJ0kNBxxRkDVI3d/EA5AHRIQNF9k45KqzK
Sff8fHLSvmh3zrt2x3l2Us0LZh/VIE2vb3DtnjE520cPpFbvC4koSajIpkbrqPMQNMoUZcnd
cRPfcvVUv38tF7wX+WNE0YZ4yczqVMm8wGX62OTiBaniPlt5nCUo98bKKCtMxXrIfOXZW3Gf
rTwyPSvWg/U1O/cKXqqc1GWMJqTgPtZ7NcfMV3llZ1LzysrEryQTT6WK+m2K0BOmYj8eV6Qv
mYjNb7uf1WSoOI92B2iqrzjPx4WUrygqQ+de4XtNWJ8NKQlPY7MFvcHk/bA37vJBP4w2zBU8
VQcQIB8AbObprV6j3Hl0aBbyQGyaMAuRwTmsPbZqF0YNb3oPxiwR12sC4aJFG6weIaTNsgGZ
puuoAbtcY9GgoHYNODg1VsBUN9ZAiI0FXuhTr5QVa+YFVa1SY7RQOOTEfNN/PqiAfC0n3cGZ
bjkMJixCKGINZ9fI/sOraFHeG85slJo5dSrD6NZjOPrQP9GVCCO+6YX8wAhDeQXMbK9nCi7A
4hZ6DudwbD/HFJDSy0tyVwy3tAxmOHYXoG6Q+255AbweZJtBMC76njrUPwBp+Bick/7gfbs3
fgxqWd4eUoJhRv7wzgB+6t3AmsAPqTgv3g8o4eTNa4xiq5GTD105dlm6s4gZKrP2oKX8l+hO
r+b3ktyoO7awNdAfn+xDy9Fa+0S2rgo4M1/aozGGf/jyTJH9JVfhotMHc19w+jDHqEplNYEn
9lW4AYYOmbppcO3fhHIhFDEhHKZrhT/EjwpD47JHspeG7D65YAGfI/nQ/K4S2sJXj7hjjRxz
ULhfLgJjwVQkMwZAvQk4OgNa6NBFbFomqNArNxPBnvXF1gUlUy4hmSovYNbwAJwVzAhzq8MJ
ZTbVT6aMET26dBNc1g6vxUKYKXslW06YmSL0JVrqIjAvE2dMXSBYUU3lfNpVB8rFCGxc/1zm
qfH4T7D/0JvLChBgOl+LI6k3rxYoZIiNR7V/hSrAWMX24HvcyoDDPDDqBlToGig9mDu1DK91
NcUkiwmL7cgyvUviQ+wwliNK2zZxeONrkT5+4YvIssD4mYDJ71giHBB1MaQmLRHWcf300FuZ
zNBrKkSuGfWwybHjXY6+cxQPUD47MHhUgtkKY6Pjy1PoUuoIpHjLpy0DI/ERvByYFTdEw7By
wi1IlBT3lKSgMkVZgFZZzI1i71IhOtKXcnfi2xDsgcfIdNtFNsoC1YVmTJLLnSMUiohqIDId
lWxX5DauI7rBi5Uf33n8Np87h9/ANKwOKiKpeLqSIATi5c9GgSlGUGW6KYWEEvKgqqpfgI2i
NA+Lb61QSRlgLTlHBEaMzuGVko8cocpR1yIC6GC8/o5n+Xwe3EzoNjwqOaVS7YtPcxB8fWIO
BoeuDIRuVsxBwIgUAzy1qsU9kvg3MGCp/5EVzQEG+o7RcdVS1QBQcOM0qQk/rM9ccbcFmSxU
UbfGlAOdG2FMXkmfhfEsij5OAjUHqe17+C4MPA51T56c4hZpIKfLj/BBz12acwj8Z6/f6Xwo
zj/NZ99TNpB5CFjDzdqAeb/2r54U1ARWdyvj11RdCkWK71G8i6Ep8mBrXJx8VJdJHG397Mx0
hmm9YCCi8clsuYWNMObYNbL+8JRAEarexfQsptbqiBO4B6uQgHutgpy3ZsZbWbElt1E8T4og
NHKDIIuadrnJ6lNMntz7HCuKXN04OBgG9xp2T0aFUOtyqF4/D0UM4TxTFrGZDHRaWJZArcuh
isqCjp+m2Xb1+oPO+L52CdS6HKqoLP8Kb1Sxlm/qjddYxHn3h+55rkEmO5bj6TaVQYTrggJ6
/Uz2rA4SlxlWRtKaFMR7cL7xOTCKWFmxA/QqVudHAdCnCDp/0ZXJ/MGrydJd5xKDlS8nD9Ru
azD2JbEOHvpIGH4K5ugoq/oXGAwyp+AD+TJc0FZ2lml/NmYQhwxK9P0jOQATZAnaMoWTJHMS
HPzaHbs0ja3rAeToZ0ItcNxvAPF0I+b+hOa7Djd0Hd16KzTfsqLzzH29GepR5FkDRSSmrMTT
q4Qb3jwLRqEo9Vz+MtgyNDFz5IQg5irkeE63mjjFrCNyN59QR+9LCBxYatSHVYr2YcRAOT34
L9PZvB1LdHrT2WXmDbgfWS+w0A1exLTakN0KRhSSqNxmyeWYWzSDQhPiRwVQlFhdmotyYVRA
TzJuooijEqt5nglzmoeRmJ94CMcfFIWhABjV8TSVe68neNP36MNo3H034i7A/UhtF7C985F+
rq4hkiBNUK6hOZGfWpSnAwRYEXWdYVSBdPfdOLpuHjWkOUx20M61i5jcf1awe84wjiLAHb78
kzI3NLuRDQGnCANQcSGQzXKhnF149VFEaWJsA8fLjxLGE06MGA1ku16pUVbCZ40ho/5Q+/O/
tjA3Z7Q1I6PjyTNi0yEh0QHm8YnZv6voJqBIQtM7T1ixfMug4Xb04hZafh7oWQJfSUguOSlg
DBIr0RuGDwlj0ogn2Y62w+rlYgn/srdnGAIXaJFMk1Ig/GiqBnX4qGvGka6twwWcqaR+dLa+
OSgBXAb+ogQQb4u4Hxg1ucXAbE41h+1GgFUzZ4/h2GeKY5+Vc+y4j8pJjwP/VNAAVLPxOfYH
tR4VJQIjlGJrADVBIwjUr1lEbDv7fdrQFk0JKiXPx/RM+wd8NP5w8IvNh38LBc8C4PybemFX
qx9MuXl0O4FyaVeQBqPVIErsmQcAxivlqDrxZqa6xDMyMACmvSSz8aI1BkXzp/ktN0nzFG94
QTprZgVbfA31RPRiZquPo1+CNbxJbiQjadm2a84PH/w0WoUiOmQRCu9GKmwVFW5HJ9I3vMlB
wnWKM+a471EzUbFuW5PILd56gfej4BqzClKfaBqG2fSNvo7iDo4/cbSOYLsMPs2CTWrykAiO
ZFgZg8SyPSZfPzi4YnA7+5433lBsyS1nHQ4G47+dvOmevDXZj6pyfQESm377qrK35822MUYx
wzuk1upEkEeKouc3l+PTwfu+xsrhnXlIgNijjUTZsySJpg+ijQhGk4YV4Ql6xmQhMQC5xdKR
SPd3YYX6g7ZzPx4Hip5H6yep9h3hHZBiiZpSUGiPLgMkukqKkQ+7aBClcR+ZC/PUBUI6mo/U
N41+y1Sl4HdlzVMhuHmoqHlUNpwp1EZvqmHal7V5zY17S93/9+DBH3Zf94Awh91TBBM0B8/s
XrkKcRVVN26SeRYsFLiw/sYVjAXHZZ0DjNvgh+7wA2RWXXTkXmuIh0/Yne9g8sKekt6JhiCP
jHV3noXplYVJDir6gJKHPz07h+lJMTw0ipZ9xyJdsRIs/O0SDmX7kZYe5FENcBHqjU7xj0J1
YKNK0ebaiyZkTo4uNPB7Tg9P94uWPLUw58yET+ha18E4u+Ih6SyLW3vC6qchdLu9DtEOEjyJ
2WgOM6nYbEXwJ+e9bt8ulYLTvyd4n6FnyzAoKR1GfdLto/XCacVaxIgAZbRDHeOeusRGcTYY
nnRP9TKGCq1KTam1mMP5pnjF01FUTmUYVxLwnaTfaBBpZNMFOwzaMPQGFFb9vD183a20qNe+
9w4P3nWUdWEGhgwVMkCqFnSBCfqIwyIpTBUO92VvIMGjYfT2og2xkWJQTMcTqp7YOQqnMvNx
vZxiGLokkbBU3sa/Qsep8+gWY3JSGHXEf/RWhesjJNDT8GYazHy8/gktKZ8k5Obk3fqAKoDJ
P2/mCA/jy3OzKpXWC44k95aHCuM5TC7ar7ujn9DzvfXi8NURhXSw375qfXvg2qJjYHuNkcip
9eItc1xLQGnBHj379kU5KI3JkYJMAvgfl/bKV5drOJverqlbqA+/0lZWKmyutfcXkoTHroT6
9liOO0pnLezZ/tkIjrq3NJHN3llASXRKseip0npOzNjB2+KcFhW5faPCqPJikeCEk/ibFK0O
DovbFE6L64IB7I7bGBFFB6XAex5c/TGQrPXxID8JJ5c0xfB+BneSD9gKudeHX7i1v2KVVhxv
N8jQ7slcYecbE6tYTlKOeZOjNJd5DD2H5gPw52/6dgrVUrpub+avxAMjJqsB3okM9y7jre4G
hqEj3S6MW7Kd5rrqRxktuQ/vWSu/ROsz6yLvyvHubNSDBfdk0D/VO6O6TqSXoJcg7rIcpB5V
Nrxqw6aefAw3svVLLFNUgfExX0iQL5EL8LwU2Fmj9SxoFlaEV267IgeyKXFdeNVWpS+jlBwm
tfYth68PFKCuOKFhHiGc7e4zJ5dQPLyxhNOuJ3Ikes03e987fxZH3LNXML3oSiQcTe4aoHC0
MqC72/zZx6by2aNKvW/jmn/ZPxnRkqNfjS7aJ13vG9oZRgN24BsPfjgb1S1PFI+sRVdpBL9r
Fh8CrN4GjTLt4zwB0+ZTsYBWG+X7UpYZ7U85r7bnhzf1umYEHt+QzpsfxoN39apTYzImwKJW
jsXrdJ5tCUPX8EPFBpoXNsXOLX5Cusg6fJxc4KpC33WTvOof4h/1W7rG8aPiHjIWB2yVz5fF
RqTFquUsXZ6i9YyVz5ub7iv11FIpj5++S7dWUSoLZ+MQJ0vgZeqWx50hyGy1qr/qM/rc+6tX
6LJlbs2bw4kzvKkBY7/aFHhwmYzCKWUdz7w58OrV30G0ru+ZGhrlaJDpuenvHZpOdmwKCvji
2KjKFeD+Q8fG7XLlhPflITPjocPf42nFvsl8Ya75FB8cvLZkEq7Ry4SMjvx0dl2rf/FWAIRK
psoMHQBJejdJKyv1m6RIZyTTg+nNvDw5aUuodi0SRIh5sBSnXHWrB4D4HwPlLCR2IKiUUlLC
z1Y9crd8ibRFLBjrruOatoEjm8WGd9HrD07rRfDaBjLnvObicIFHnYkGq5R5gIlRWA7ygT5g
At6oobdlla1nTH/UjH6HvBwmE5EgApVYpFp5ah7I+w3xQBYbHX5DuV2exNHXgl2CaQc7rtJo
Wkehmr2zNrwcAjJ3UB4PLjA6fipwfpFxgaLI8+QOogFF/5DduoscNJw2arjJbBklwYOgs34m
Lh7iGWQUzO54LxRwrtvkuqBst2usqZrN685D4yRVikDmegEaNamUo1EOD8ncpnmSoBGtu66x
2wWTGZzk8pVmvLT1Z/oFaa6gC82wuRxOwfaQq7Uc8AsH2HEpM4V8Wvo0kspvyQ44OXU8y/x4
do3dbk81l2WiYHzMy1VaRZ/Gw3Z/VDmwpzNZw4ucvbzvlDffOkyuCzM7+cgbRIT0xTirGJQi
XlfM/EWVCGbln8f3XDVtf3DCZODX/3RgpP8nyYn/tfLX+O/VvppVvwTNV7+/jPvjfz07fHZ4
KPG/Dl8etV5i/K8Xzw528b/+Hak5fuOZ0fZeVZujN16//a5btd7+DDz+NkHXa31PW4SxPVB4
a2l+EHT0oT+4GPVG1eZ6Uf15cWiw/LxoeX/34NXPe4stPvyDH/dSfFil/hTesCSTzJSqzUVI
KE+7o5Nh7wIjtlabPau21ZGqFN8/v10F99XPq8GJEjAMyeug9rxeb1bH1/jGKRaOCxTGXwXx
VNcvWcYPomtnU3X3CuUqQIk+lLDb5SvFodKXot0usbewuprK8ZZUe4XVc5srV0bSrXMMSwoc
0r/wzdRoyORfoZkjdsm1H88p8lPsw5bExqwJS4WqeLkT6p2Ttb9JriOSnDQy5dEtSNf+MiUL
C9OzboupKBUaBs2HUI8erlB0itJo1PBBaSG/Z6aC7gNCGZIqHVp6cVG9TJT9LFMJ0gULtRvZ
MsOErNswRNhWAglAHavEOoQzpXUUgSyDsHk8dgc2Sa6MQmPYhmjeKUOVhWbqisFMSw2wnzKz
gZsuKUHZG9CnYAGNKupEo/UVRZWxPujb0DNI1eXkHIBsswzSgLsEo+2xMovvnkmoTSl6YmxJ
vIX921BXfxPbhodDRkV9D6NDtWEsWsPqYmpSGAXq9a3pdZkBdHnxvAoIlVq+iAKoCZbOl9uC
topbaQsWwYhJeerSGvTCX6rN8UVVD311JIycxK7PlKkl6zKBmgTd7MBitX0wKDaIZh9dAApE
7hBQVYbFQp1aqFFzsqQbXFMVakKIHAMw1bQCMKFpvR+ks31a5WjZCU1IjFvsYtxbkFhoMlsa
Ab1YqIh9OGpEVdSDGmuVCt3D60PINB+qay0l1YUVH20ONBAukyav192u1z4fDarLmxVkbFQJ
Bn41dyewXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdqlXdql
XdqlXdqlXdqlXdql/4vpfwDHfKUwAPAAAA==

--==_Exmh_-2055509860--



From owner-linux-xfs@oss.sgi.com Mon May 14 10:02:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EH25117263
	for linux-xfs-outgoing; Mon, 14 May 2001 10:02:05 -0700
Received: from smtp5.xs4all.nl (smtp5.xs4all.nl [194.109.6.49])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EH23F17260
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:02:03 -0700
Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45])
	by smtp5.xs4all.nl (8.9.3/8.9.3) with ESMTP id TAA07591;
	Mon, 14 May 2001 19:02:01 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id TAA18150;
	Mon, 14 May 2001 19:02:00 +0200 (CEST)
Date: Mon, 14 May 2001 19:02:00 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: What's wrong with df?
In-Reply-To: <Pine.LNX.4.21.0105141844370.3448-100000@kalapati.jijo.local>
Message-ID: <Pine.BSI.4.10.10105141859400.17403-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 14 May 2001, Federico Sevilla III wrote:

> Hi everyone,
> 
> While migrating a ReiserFS partition to XFS, I noticed that df reported a
> pretty significant space utilization difference between the two
> filesystems. I transferred my files using two methods, and both had
> identical results.
> 
> First I used tar from /xfs: "tar -cl /reiserfs | tar xv", then I used cp:
> "cp -a /reiserfs /xfs". Here is the output when I ran "df -h" after each
> file transfer operation:
> 
> Filesystem	Size	Used	Avail	Use%	Mounted on
> /dev/hda5	2.0G	692M	1.4G	33%	/reiserfs
> /dev/hda3	952M	746M	206M	78%	/xfs
> 
> If this is accurate (although it doesn't seem accurate as I will later
> elaborate), then XFS uses 52MB more than ReiserFS does for a relatively
> small partition (this is actually my root partition, and I only exclude a
> small boot and the home partition).

Do you have tail packing enabled (it is by default).
If you have numerous files smaller then say 4k it will pack more of them
to fill up the spaces.

This results in exactly as much data in a smaller on disk format.

> I decided to check using du by running "du -csm" and found that ReiserFS
> uses 734MB and XFS uses 733MB. This looks more accurate. Would anyone know
> what's wrong with df? It's a much handier tool to use than du, but if it's
> not accurate then it doesn't look like a good tool to use, handy or not.

See above. The actual size of the files stay the same.

Cheers Seth


From owner-linux-xfs@oss.sgi.com Mon May 14 10:38:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EHciY17952
	for linux-xfs-outgoing; Mon, 14 May 2001 10:38:44 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EHcgF17949
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:38:42 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4EHcZv20988
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 01:38:35 +0800
Received: from kalapati ([203.167.26.210]) by sisa.i-manila.com.ph ; Tue, 15 May 2001 01:38:45 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 2CF4246A1A6
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 01:38:30 +0800 (PHT)
Date: Tue, 15 May 2001 01:38:30 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: CVS updates (was: biosize=13)
In-Reply-To: <200105141426.f4EEQJU17908@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105150134450.3831-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 14 May 2001 at 09:26, Steve Lord wrote:
> you will need to apply this patch to a 2.4.4 tree and then do a cvs
> update to get the current code base.

A little clarification on CVS updates:

So, I patch my Linux 2.4.4 tree with the 05022001 CVS patch, rename
linux-2.4.4 to linux-2.4-xfs, cd linux-2.4-xfs, then 'cvs -z3 update -d'.

How does CVS update know if a local file is in sync with the repository or
not? I noticed that a lot of upstream transfers are made. Making cvs show
me a trace using 'cvs -z3 update -d -t', I notice it's "sending" a lot of
files to the server. Does the CVS client send the entire file to the
server to be compared line by line?

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Mon May 14 10:44:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EHiXN18020
	for linux-xfs-outgoing; Mon, 14 May 2001 10:44:33 -0700
Received: from cairn-gorm.cragtech.com (mail.connex.com [216.100.236.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EHiRF18017
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:44:28 -0700
Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21)
	id <KG97PM64>; Mon, 14 May 2001 10:43:22 -0700
Message-ID: <B14BF8753E65D211ABCA00104B301EF501C02B76@cairn-gorm.cragtech.com>
From: Dale Stephenson <Steph@Connex.com>
To: "'Steve Lord'" <lord@sgi.com>, linux-xfs@oss.sgi.com
Cc: "'linux-lvm@sistina.com'" <linux-lvm@sistina.com>
Subject: RE: [PATCH] [CFT] - LVM snapshotting support for XFS
Date: Mon, 14 May 2001 10:43:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0DC9D.5B6166A0"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0DC9D.5B6166A0
Content-Type: text/plain;
	charset="iso-8859-1"

I'll be glad to give this a try.  I've been using the attached patches (in a
tgz) to use snapshots with xfs in the past.  Basically they are some short
LVM patches to allow writable snapshots.  Using this I was able to take a
snapshot and mount the snapshot read-write, allowing XFS to straighten
things out (without the benefit of an xfs_freeze-like command, it was like
turning the power off on the original of the system).  Then I would unmount
the snapshot, change it back to read-only, and remount it for normal
snapshot use.

I did have one other problem using XFS snapshots.  As long as the original
was mounted, I couldn't mount the snapshot as well because it had the same
uuid.  So before I could mount the snapshot read-write I had to change the
UUID using xfs_db (which also required writeable snapshots).  Actually, I
had to change it twice.  My usual sequence would be something like this:

# sync
# lvcreate --size 100 --chunksize 64  --snapshot --name snap0
/dev/volgr1/lvol0
# lvchange -p rw /dev/volgr1/snap0
# xfs_db -x -p xfs_admin -c 'uuid generate'
# xfs_db -x -p xfs_admin -c 'uuid generate'
# mount /dev/volgr1/snap0 /hd/vol_mnt1
# umount /dev/volgr1/snap0
# lvchange -p r /dev/volgr1/snap0
# mount /dev/volgr1/snap0 /hd/vol_mnt1

With a way to freeze the filesystem, I should be safer than just calling
sync and I don't think I'll need to do the read-write mount to replay.  Is
there a way around changing the UUID?

CCed to linux-lvm, since somebody over there may be interested in testing
XFS snapshots.

Dale Stephenson
steph@connex.com

> -----Original Message-----
> From: Steve Lord [mailto:lord@sgi.com]
> Sent: Monday, May 14, 2001 9:50 AM
> To: linux-xfs@oss.sgi.com
> Subject: [PATCH] [CFT] - LVM snapshotting support for XFS
> 
> 
> 
> Here is some experimental code for XFS which should allow use 
> of the LVM
> snapshotting capability. There are two attachments to this message, a
> kernel patch which will apply to the current development tree 
> (2.4.4 base)
> and a tar file which adds a new command to the xfs commands. 
> You will also
> need to apply the VFS-lock.patch from the lvm sources to 
> enable snapshotting.
> 
> The new command added is xfs_freeze which can be used to stop 
> and flush
> an xfs filesystem and then restart it. If you apply the VFS-lock patch
> from the lvm sources then you will not need this.
> 
> I am looking for people to test this code, previous 
> experience with lvm 
> and its snapshotting facility would probably be a pre-requisit.
> 
> Steve
> 
> 
> 


------_=_NextPart_000_01C0DC9D.5B6166A0
Content-Type: application/octet-stream;
	name="writesnap.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="writesnap.tgz"

H4sIAAEsADsAA+1YbU/bSBDmK/yKKdLlkjpObCexSXIgUMvpqqNwAtp+KMgy9iZx8ZtsxyAd+e+3
L363EziOUl3lR2qzLzOzM7PjfXaxIpu/880QaTcW4gNH83qeFuqLrReEIAqCLA+3BAxFHhV+MSSJ
tJUBaY4UScDyQ3k02gLhJZ1Yh2UQaj7AVhAib1PUj83/T8HzPFims7zvG74ZIT/o20bfiuye3nN9
c759uVjCe6SDOARBmQz3JoMRSHindjiOW6OY1xHFyWg8GQ6YzuEh8KI8HnZFETjaGChweLgD2xgr
+kP/XwGyAgR/73Db2wCGe+dAu2VF/IEVqaREg4UbqgGyO1MmYc6g7d/B/j58Of9weQwPD5DrHnUS
SwD9t0CrHUIXEkuAUxAPLnx3OV8Qez6yNc9DBrztJ7pkldiJG8vVb1V0ryMvNF2HLHX66eQktxCA
55tOeNv+8/j8VH2H/SAzbGr3lwBw1iNbxWtM4ORz5gqemS0t68rZ7WbyRNLRbNSFeHnSSWInWHqb
80Pgo3DpOzj/6dgqafgGwnpaBPusGdpeKuQHSA9dP5mOe3kJkpY3xMV0ZZo7lqN2K7HI4qEhtXJm
csMeUsm3GOaGrKhTyCnePt1HGt4qDRx0B2SPTGee26TYnzYOF/tbcOvd2Zd2jTdQ702dO/ls5IeJ
mx3az5alFUXWVENytMbpiOZquDCDLtYo70P8E1c++RZwtDSVWXlY7tzUNQsi11raiITNYznygazb
f2JnQ+G+iQuXfYJP2MXi5mVJAhoR8WbpbazFOMwNJQvsFCD/bhb8wY1KFi/U5o8+NH8ikC0XeuOe
8S3oWZG+0Jw5eukbAOF/RRmt5X9hqGT8L4iU/5WG/18FhP9PPn9UBXXcD13XCvppFVRvAJjNpfFk
IGQ3gHWqJa2BPBHl7A4wkMZdBbjBQOjuUf5PobtOiC8VaJqMrWhjh8/O9oQENV1HQQAt7IN6cXr0
18UfZ5eULHKijwi3Wok0BZZ3PcwTHXKBoE0ta/odSkWZ9IwSPFklCA3k+13G6zywHAA+XSvn9m5O
v4rd+Fi/woaudsHBippluXfIIPcB0G2DHLMJ+9cljSZXEWhyFakrSkl2c9I0MYZrhnAAQjEkADqh
Bkub46ZJ0hmKiSQcF7enhRwSijZc59cQdAvhDyuWn1naPADGOzBzfbIP7K6mOQbpnB8fvac0nreV
I678BlLFTlG04iG/n4pOn2SVePA0o0SyZLMo9lBIT8EezT6pp4ilPy2ifPGQK01sykO+bQYB5urg
kerJsOvOyjcFVlL0Wvk0G6Vi+9HHVIPvhDz/R/NA1xx87r8u/2PiF8v8P1KUhv9fA1X+T6uAsv+F
FlIehzGI0mQoTYS9deyfKBZ0hpPBeCLt5d7/0qgr49e/JHeVhJ3wEQg65hRhmnbNYtdiXS7pWsVp
G+8ifoi4PsLjvx+dXBxnc+ywLYizV5rA+FKSh/gWwkmy3JXk4m0E48a6VdnzQyid5ITF2rFj+Oc3
iOaUA2ztHvc5rkKtyenP5L5a1+nrC0vyZdGyMLVNPMFKsVPqzEfoa9y5rnLXM2zU+MxQyPDl+acy
qZbTkuSlkpg4M/XKZY+LOVqrU1VLI93fEOkmexh11orG2kl1cCB2rtdlhGG1cZa++utiSN/Gtung
zOJw2N8dqNbHD6dn51inPsJ/H2J5sWSt2nWKwXf+S/TPDrxS2d876DS5zw533VTt+Krua6x+zvU1
znHX04p+yeKqudk1aNCgQYMGDRo0aNCgQYMGPz/+AWeG5d0AKAAA

------_=_NextPart_000_01C0DC9D.5B6166A0--

From owner-linux-xfs@oss.sgi.com Mon May 14 10:51:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EHpdO18231
	for linux-xfs-outgoing; Mon, 14 May 2001 10:51:39 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EHpbF18228
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 10:51:37 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1389170
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:51:34 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1809795; Mon, 14 May 2001 12:50:17 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA47926; Mon, 14 May 2001 12:50:17 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EHqWH19225; Mon, 14 May 2001 12:52:32 -0500
Message-Id: <200105141752.f4EHqWH19225@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dale Stephenson <Steph@connex.com>
cc: "'Steve Lord'" <lord@sgi.com>, linux-xfs@oss.sgi.com,
   "'linux-lvm@sistina.com'" <linux-lvm@sistina.com>
Subject: Re: [PATCH] [CFT] - LVM snapshotting support for XFS 
In-Reply-To: Message from Dale Stephenson <Steph@connex.com> 
   of "Mon, 14 May 2001 10:43:16 PDT." <B14BF8753E65D211ABCA00104B301EF501C02B76@cairn-gorm.cragtech.com> 
Date: Mon, 14 May 2001 12:52:32 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_000_01C0DC9D.5B6166A0
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> I'll be glad to give this a try.  I've been using the attached patches (in a
> tgz) to use snapshots with xfs in the past.  Basically they are some short
> LVM patches to allow writable snapshots.  Using this I was able to take a
> snapshot and mount the snapshot read-write, allowing XFS to straighten
> things out (without the benefit of an xfs_freeze-like command, it was like
> turning the power off on the original of the system).  Then I would unmount
> the snapshot, change it back to read-only, and remount it for normal
> snapshot use.
> 
> I did have one other problem using XFS snapshots.  As long as the original
> was mounted, I couldn't mount the snapshot as well because it had the same
> uuid.  So before I could mount the snapshot read-write I had to change the
> UUID using xfs_db (which also required writeable snapshots).  Actually, I
> had to change it twice.  My usual sequence would be something like this:

I forgot about the uuid change step in there, yes this will need changing
to make the filesystem mountable - I will think about this. The reason for
the uuid code in XFS is to deal with hardware which has alternate paths to
disks - it prevents you from mounting the same filesystem from what appear
to be two devices, but are actually alternate routes to the same disks. It
may be reasonable to override it for readonly mounts - although that too
is really dangerous in the alternate path case.


> 
> # sync
> # lvcreate --size 100 --chunksize 64  --snapshot --name snap0
> /dev/volgr1/lvol0
> # lvchange -p rw /dev/volgr1/snap0
> # xfs_db -x -p xfs_admin -c 'uuid generate'
> # xfs_db -x -p xfs_admin -c 'uuid generate'
> # mount /dev/volgr1/snap0 /hd/vol_mnt1
> # umount /dev/volgr1/snap0
> # lvchange -p r /dev/volgr1/snap0
> # mount /dev/volgr1/snap0 /hd/vol_mnt1
> 
> With a way to freeze the filesystem, I should be safer than just calling
> sync and I don't think I'll need to do the read-write mount to replay.  Is
> there a way around changing the UUID?

Using this could you should be able to do a readonly mount of the xfs
snapshotted filesystem, modulo the uuid issue.

Steve

> 
> CCed to linux-lvm, since somebody over there may be interested in testing
> XFS snapshots.
> 
> Dale Stephenson
> steph@connex.com
> 
> > -----Original Message-----
> > From: Steve Lord [mailto:lord@sgi.com]
> > Sent: Monday, May 14, 2001 9:50 AM
> > To: linux-xfs@oss.sgi.com
> > Subject: [PATCH] [CFT] - LVM snapshotting support for XFS
> > 
> > 
> > 
> > Here is some experimental code for XFS which should allow use 
> > of the LVM
> > snapshotting capability. There are two attachments to this message, a
> > kernel patch which will apply to the current development tree 
> > (2.4.4 base)
> > and a tar file which adds a new command to the xfs commands. 
> > You will also
> > need to apply the VFS-lock.patch from the lvm sources to 
> > enable snapshotting.
> > 
> > The new command added is xfs_freeze which can be used to stop 
> > and flush
> > an xfs filesystem and then restart it. If you apply the VFS-lock patch
> > from the lvm sources then you will not need this.
> > 
> > I am looking for people to test this code, previous 
> > experience with lvm 
> > and its snapshotting facility would probably be a pre-requisit.
> > 
> > Steve
> > 
> > 
> > 
> 
> 
> ------_=_NextPart_000_01C0DC9D.5B6166A0
> Content-Type: application/octet-stream;
> 	name="writesnap.tgz"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment;
> 	filename="writesnap.tgz"
> 
> H4sIAAEsADsAA+1YbU/bSBDmK/yKKdLlkjpObCexSXIgUMvpqqNwAtp+KMgy9iZx8ZtsxyAd+e+3
> L363EziOUl3lR2qzLzOzM7PjfXaxIpu/880QaTcW4gNH83qeFuqLrReEIAqCLA+3BAxFHhV+MSSJ
> tJUBaY4UScDyQ3k02gLhJZ1Yh2UQaj7AVhAib1PUj83/T8HzPFims7zvG74ZIT/o20bfiuye3nN9
> c759uVjCe6SDOARBmQz3JoMRSHindjiOW6OY1xHFyWg8GQ6YzuEh8KI8HnZFETjaGChweLgD2xgr
> +kP/XwGyAgR/73Db2wCGe+dAu2VF/IEVqaREg4UbqgGyO1MmYc6g7d/B/j58Of9weQwPD5DrHnUS
> SwD9t0CrHUIXEkuAUxAPLnx3OV8Qez6yNc9DBrztJ7pkldiJG8vVb1V0ryMvNF2HLHX66eQktxCA
> 55tOeNv+8/j8VH2H/SAzbGr3lwBw1iNbxWtM4ORz5gqemS0t68rZ7WbyRNLRbNSFeHnSSWInWHqb
> 80Pgo3DpOzj/6dgqafgGwnpaBPusGdpeKuQHSA9dP5mOe3kJkpY3xMV0ZZo7lqN2K7HI4qEhtXJm
> csMeUsm3GOaGrKhTyCnePt1HGt4qDRx0B2SPTGee26TYnzYOF/tbcOvd2Zd2jTdQ702dO/ls5IeJ
> mx3az5alFUXWVENytMbpiOZquDCDLtYo70P8E1c++RZwtDSVWXlY7tzUNQsi11raiITNYznygazb
> f2JnQ+G+iQuXfYJP2MXi5mVJAhoR8WbpbazFOMwNJQvsFCD/bhb8wY1KFi/U5o8+NH8ikC0XeuOe
> 8S3oWZG+0Jw5eukbAOF/RRmt5X9hqGT8L4iU/5WG/18FhP9PPn9UBXXcD13XCvppFVRvAJjNpfFk
> IGQ3gHWqJa2BPBHl7A4wkMZdBbjBQOjuUf5PobtOiC8VaJqMrWhjh8/O9oQENV1HQQAt7IN6cXr0
> 18UfZ5eULHKijwi3Wok0BZZ3PcwTHXKBoE0ta/odSkWZ9IwSPFklCA3k+13G6zywHAA+XSvn9m5O
> v4rd+Fi/woaudsHBippluXfIIPcB0G2DHLMJ+9cljSZXEWhyFakrSkl2c9I0MYZrhnAAQjEkADqh
> Bkub46ZJ0hmKiSQcF7enhRwSijZc59cQdAvhDyuWn1naPADGOzBzfbIP7K6mOQbpnB8fvac0nreV
> I678BlLFTlG04iG/n4pOn2SVePA0o0SyZLMo9lBIT8EezT6pp4ilPy2ifPGQK01sykO+bQYB5urg
> kerJsOvOyjcFVlL0Wvk0G6Vi+9HHVIPvhDz/R/NA1xx87r8u/2PiF8v8P1KUhv9fA1X+T6uAsv+F
> FlIehzGI0mQoTYS9deyfKBZ0hpPBeCLt5d7/0qgr49e/JHeVhJ3wEQg65hRhmnbNYtdiXS7pWsVp
> G+8ifoi4PsLjvx+dXBxnc+ywLYizV5rA+FKSh/gWwkmy3JXk4m0E48a6VdnzQyid5ITF2rFj+Oc3
> iOaUA2ztHvc5rkKtyenP5L5a1+nrC0vyZdGyMLVNPMFKsVPqzEfoa9y5rnLXM2zU+MxQyPDl+acy
> qZbTkuSlkpg4M/XKZY+LOVqrU1VLI93fEOkmexh11orG2kl1cCB2rtdlhGG1cZa++utiSN/Gtung
> zOJw2N8dqNbHD6dn51inPsJ/H2J5sWSt2nWKwXf+S/TPDrxS2d876DS5zw533VTt+Krua6x+zvU1
> znHX04p+yeKqudk1aNCgQYMGDRo0aNCgQYMGPz/+AWeG5d0AKAAA
> 
> ------_=_NextPart_000_01C0DC9D.5B6166A0--



From owner-linux-xfs@oss.sgi.com Mon May 14 11:33:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EIX2k19059
	for linux-xfs-outgoing; Mon, 14 May 2001 11:33:02 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EIX1F19056
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 11:33:01 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4EIUdj01131;
	Mon, 14 May 2001 13:30:39 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 14 May 2001 13:30:39 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
cc: "DeLuca, Bryan" <bdeluca@coremetrics.com>
Subject: using LVM to create RAID5 volumes?
Message-ID: <Pine.LNX.4.33.0105141329400.1069-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is this possible? It's not as far as I can tell, but I thought I'd ask
here for a second opinion

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Mon May 14 11:45:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EIjWj19338
	for linux-xfs-outgoing; Mon, 14 May 2001 11:45:32 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EIjVF19335
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 11:45:31 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4EIhPt01341
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:43:25 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 14 May 2001 13:43:25 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved
In-Reply-To: <Pine.LNX.4.33.0105132315290.27971-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.33.0105141336350.1069-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

As promised I got my kernel recompiled on my "work" machine. One thing
which seemed to impact performance were the Kernel Debug Symbols. Ok,
stupid mistake, big booboo. Next I went ahead and enabled the DMA support
on this kernel. It was in fact NOT turned on. I also enabled PIIXn support
and tuning. After doing that specific change, my system improved
performance immediately. Good news there. After that, I continued further,
using HDPARM and got a full 65-80% increase in throughput. I used the
following options:

hdparm -X66 -d1 -u1 -c3 -m16 /dev/hdx

All parameters work like a champ, and I can even use them on my cdrom as
well. Now, not only does the system work it's butt off, but I can finally
make ISO's from cd to the hdd with no real slowdown, not like it was
before, nearly unuseable.

The conclusion:
  The problem here is chipset dependant. The DMA settings seem to affect
the system either way depending on what chipset you use. At this point,
true INTEL chipsets seem to need it turned on to get really good
performance, while AMD chipsets could probably have it turned on, but seem
to perform better without it. I will recompile once again, at home, and
pass the hdparm params to my devices there and report back with specific
findings. Thanks for those of you whom offered information and got me
started in these directions.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Sun, 13 May 2001, Austin Gonyou wrote:

> Some of you have been writing about slow access times to stuff like rpm
> database, slocate db, etc. I've found one major thing which caused my
> system to return to it's normal smoking self. I recently got a new
> Athlon-C 1.333Ghz machine. I was very proud, and expected only the best
> out of this machine. I use the full 1.0 installer for 7.1. After
> installation, I discovered the RPM db was corrupt, and the system
> basically thought almost no packages were installed, despite the fact it
> booted with no real issues. I immediately got the 2.4.4 XFS devel tree,
> and recompiled, cause I've found that the new tree is much better than the
> default install version. My preference. Going through the recompile I
> chose to use the Generic DMA selection. I even decided to choose my ALI
> chipset. After rebooting the system was slightly better, no more devfs or
> other non-essential overhead. But there was still some fundamental issue.
> Pine, slocate, rpm, all were not NEARLY fast enough. I recompiled again,
> this time with no generic DMA support or ALI support. My system now
> performs like a 1.333 Ghz should. It smokes! File create/delete, and r/w
> times are pretty darn good. In some respects better than they've ever
> been. I'm going to hit this same build on my work box, a 433 Celeron, and
> see what happens. That is the more problematic box overall, but I know
> I've got similar options, regarding DMA, selected as well. I'll post when
> I see success/failure on that front in the AM.
>
>


From owner-linux-xfs@oss.sgi.com Mon May 14 11:54:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EIsVu19506
	for linux-xfs-outgoing; Mon, 14 May 2001 11:54:31 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EIsTF19502
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 11:54:30 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1376754
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 20:54:26 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA65091; Mon, 14 May 2001 13:53:09 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4EIq9e13867;
	Mon, 14 May 2001 14:52:09 -0400
Message-ID: <3B002959.77FA36F2@thebarn.com>
Date: Mon, 14 May 2001 14:52:09 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Federico Sevilla III <jijo@i-manila.com.ph>
CC: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: CVS updates (was: biosize=13)
References: <Pine.LNX.4.21.0105150134450.3831-100000@kalapati.jijo.local>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Federico Sevilla III wrote:

> On Mon, 14 May 2001 at 09:26, Steve Lord wrote:
> > you will need to apply this patch to a 2.4.4 tree and then do a cvs
> > update to get the current code base.
>
> A little clarification on CVS updates:
>
> So, I patch my Linux 2.4.4 tree with the 05022001 CVS patch, rename
> linux-2.4.4 to linux-2.4-xfs, cd linux-2.4-xfs, then 'cvs -z3 update -d'.
>
> How does CVS update know if a local file is in sync with the repository or
> not? I noticed that a lot of upstream transfers are made. Making cvs show
> me a trace using 'cvs -z3 update -d -t', I notice it's "sending" a lot of
> files to the server. Does the CVS client send the entire file to the
> server to be compared line by line?

All the revisions of each file is documented in CVS/Entries in each dir of
the
source tree.
It can then to version comparison and time stamp comparisons to find out if
file compares are needed. It's and ugly process and you can read more about
it
in the cvs documentation.

The fastest and least network intensive way to keep up to date it to use
CVSup.



>

>
>
>  --> Jijo
>
> ---
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May 14 12:10:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EJAEv20025
	for linux-xfs-outgoing; Mon, 14 May 2001 12:10:14 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EJADF20022
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 12:10:13 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id AB2A11E143; Mon, 14 May 2001 21:10:08 +0200 (MEST)
Date: Mon, 14 May 2001 21:09:39 +0200
From: Andi Kleen <ak@suse.de>
To: Austin Gonyou <austin@coremetrics.com>
Cc: linux-xfs@oss.sgi.com, "DeLuca, Bryan" <bdeluca@coremetrics.com>
Subject: Re: using LVM to create RAID5 volumes?
Message-ID: <20010514210939.A2583@gruyere.muc.suse.de>
References: <Pine.LNX.4.33.0105141329400.1069-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0105141329400.1069-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Mon, May 14, 2001 at 01:30:39PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 14, 2001 at 01:30:39PM -0500, Austin Gonyou wrote:
> Is this possible? It's not as far as I can tell, but I thought I'd ask
> here for a second opinion

LVM and MD RAID should be arbitarily stackable in 2.4, means you can put
LVM on top of MD or the other way round.


-Andi

From owner-linux-xfs@oss.sgi.com Mon May 14 12:29:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EJTUm20659
	for linux-xfs-outgoing; Mon, 14 May 2001 12:29:30 -0700
Received: from kernelpanix.aura.of.mankind (pD9574FDD.dip.t-dialin.net [217.87.79.221])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EJTSF20656
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 12:29:28 -0700
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4EIRkn05800;
	Mon, 14 May 2001 20:27:46 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Mon, 14 May 2001 20:27:46 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Austin Gonyou <austin@coremetrics.com>
Cc: linux-xfs@oss.sgi.com, "DeLuca, Bryan" <bdeluca@coremetrics.com>
Subject: Re: using LVM to create RAID5 volumes?
Message-ID: <20010514202746.A5779@s2y4n2c.de>
References: <Pine.LNX.4.33.0105141329400.1069-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0105141329400.1069-100000@UberGeek.coremetrics.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

You can't create software RAID 5 with LVM directly. But using LVM on top a
RAID 5 md device should work. I never tried this with RAID 5, but with RAID 1.


utz

Austin Gonyou [austin@coremetrics.com] wrote:
> Is this possible? It's not as far as I can tell, but I thought I'd ask
> here for a second opinion
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com

From owner-linux-xfs@oss.sgi.com Mon May 14 13:00:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EK09721512
	for linux-xfs-outgoing; Mon, 14 May 2001 13:00:09 -0700
Received: from glacier.evanston.fluent.com (glacier.evanston.fluent.com [192.104.61.185])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EK07F21509
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:00:07 -0700
Received: from evanston.fluent.com (taxi [192.104.61.40])
	by glacier.evanston.fluent.com (8.11.3/8.11.3/) with ESMTP id f4EIxok05566
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:59:50 -0500
X-Spam-Filter: check_local@glacier.evanston.fluent.com by digitalanswers.org
Message-ID: <3B0038A6.4DBEB316@evanston.fluent.com>
Date: Mon, 14 May 2001 14:57:26 -0500
From: Paul Rossman <pdr@evanston.fluent.com>
Organization: Fluent, Inc.
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: DAC960 and XFS blocksize error
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi all,

I was wondering if there was anything to worry about in regards to the
following error during the formatting of an XFS disk. I get the error
even when specifying the block size. I'm able to mount the disk and
write to it, etc. Oh - I've disabled devfs and built all of xfs into the
kernel. I guessing this isn't anything I need to work about ... ?

Thanks in advance!
-paul

[root@x /proc]# cat /proc/version
Linux version 2.4.2-SGI_XFS_1.0-fluent (root@x.evanston.fluent.com) (gcc
version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 Sat May 12
15:04:46 CDT 2001


[root@x /]# mkfs.xfs -f /dev/rd/c0d0p1
mkfs.xfs: warning - cannot set blocksize on block device /dev/rd/c0d0p1:
Invalid argument
meta-data=/dev/rd/c0d0p1         isize=256    agcount=103, agsize=260959
blks
data     =                       bsize=4096   blocks=26878745,
imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=3281
realtime =none                   extsz=65536  blocks=0, rtextents=0

[root@x /]# mkfs.xfs -f -b size=4096  /dev/rd/c0d0p1
mkfs.xfs: warning - cannot set blocksize on block device /dev/rd/c0d0p1:
Invalid argument
meta-data=/dev/rd/c0d0p1         isize=256    agcount=103, agsize=260959
blks
data     =                       bsize=4096   blocks=26878745,
imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=3281
realtime =none                   extsz=65536  blocks=0, rtextents=0




[root@x c0]# cat /proc/rd/c0/current_status
***** DAC960 RAID Driver Version 2.4.10 of 1 February 2001 *****
Copyright 1998-2001 by Leonard N. Zubkoff <lnz@dandelion.com>
Configuring Mylex AcceleRAID 170 PCI RAID Controller
  Firmware Version: 6.00-07, Channels: 1, Memory Size: 32MB
  PCI Bus: 0, Device: 4, Function: 1, I/O Address: Unassigned
  PCI Address: 0xFA000000 mapped at 0xE0837000, IRQ Channel: 11
  Controller Queue Depth: 512, Maximum Blocks per Command: 2048
  Driver Queue Depth: 511, Scatter/Gather Limit: 128 of 257 Segments
  Physical Devices:
    0:0  Vendor: QUANTUM   Model: ATLAS10K2-TY367J  Revision: DA40
         Wide Synchronous at 40 MB/sec
         Serial Number: 163022041133
         Disk Status: Online, 71688192 blocks
    0:1  Vendor: QUANTUM   Model: ATLAS10K2-TY367J  Revision: DA40
         Wide Synchronous at 40 MB/sec
         Serial Number: 163020741403
         Disk Status: Online, 71688192 blocks
    0:2  Vendor: QUANTUM   Model: ATLAS10K2-TY367J  Revision: DA40
         Wide Synchronous at 40 MB/sec
         Serial Number: 163020644862
         Disk Status: Online, 71688192 blocks
    0:3  Vendor: QUANTUM   Model: ATLAS10K2-TY367J  Revision: DA40
         Wide Synchronous at 40 MB/sec
         Serial Number: 163021541256
         Disk Status: Online, 71688192 blocks
    0:7  Vendor: MYLEX     Model: AcceleRAID 170    Revision: 0600
         Wide Synchronous at 160 MB/sec
         Serial Number:
  Logical Drives:
    /dev/rd/c0d0: RAID-5, Online, 215040000 blocks
                  Logical Device Initialized, BIOS Geometry: 255/63
                  Stripe Size: 64KB, Segment Size: 8KB
                  Read Cache Disabled, Write Cache Disabled
  No Rebuild or Consistency Check in Progress




[root@x c0]# cat /etc/fstab
/dev/md0       /                       ext2    defaults        1 1
/dev/sda1      /boot                   ext2    defaults        1 2
#/dev/sdb1     /boot2                  ext2    defaults        1 2
/dev/rd/c0d0p1 /home                   xfs     defaults        1 2
/dev/fd0       /mnt/floppy             auto    noauto,owner    0 0
none           /proc                   proc    defaults        0 0
none           /dev/pts                devpts  gid=5,mode=620  0 0
/dev/sda2      swap                    swap    defaults        0 0
/dev/sdb2      swap                    swap    defaults        0 0
/dev/cdrom     /mnt/cdrom              iso9660 noauto,owner,kudzu,ro 0 0

From owner-linux-xfs@oss.sgi.com Mon May 14 13:19:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKJKN21784
	for linux-xfs-outgoing; Mon, 14 May 2001 13:19:20 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKJHF21781
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:19:17 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EKJ9b27276;
	Mon, 14 May 2001 15:19:09 -0500 (CDT)
Message-ID: <3B003E4A.FA627E01@sgi.com>
Date: Mon, 14 May 2001 15:21:30 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS & Kickstart installation
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be> <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

werner maes wrote:

> I've done another test on a machine without hardware RAID (my first tests
> were done on a machine
> with a hardware RAID controller). I get a similar error: "Error mounting
> device sda1 as /: No such
> device. This most likely means that the partition has not been formatted."

Not sure what's going on here, I tried a kickstart install on scsi
drives (disabled the IDE controller for the HD, the CDROM was still
enabled) and it worked just fine.  I tried a combination of ext2 and xfs
filesystems, that worked too.  I don't have any RAID device to test it
on.

Below is the ks.cfg file I used (stripped of comments...)

-Eric


keyboard us
lang en_US
install
mouse  none
timezone --utc US/Central
auth --enablemd5 --useshadow
rootpw kickmeRH
lilo --append "mem=128M" --location partition
zerombr no
part / --size 250 --fs ext2
part swap --size 32 --fs xfs
part /usr --size 500 --grow --maxsize 800
part /home --size 100
%packages
@ Networked Workstation



-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 13:30:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKUld22065
	for linux-xfs-outgoing; Mon, 14 May 2001 13:30:47 -0700
Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKUkF22061
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:30:46 -0700
Received: from gateway (dhcp181-19-151-24.nm01-c3.cpe.charter-ne.com [24.151.19.181])
	by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id NAA03398
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:30:38 -0700 (PDT)
Message-ID: <002c01c0dcb4$600c0b80$0600a8c0@gateway>
Reply-To: "Sean P. Elble" <S_Elble@yahoo.com>
From: "Sean P. Elble" <S_Elble@yahoo.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS/Linux/Samba Problems
Date: Mon, 14 May 2001 16:28:01 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0029_01C0DC92.D80F6F40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01C0DC92.D80F6F40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

I am using XFS 1.0, for Linux, and couldn't be happier, except for one =
thing; Samba won't work with the ACLs, provided with XFS, and, yes, I am =
using the included source ACL from the XFS site! Any ideas why? Any =
response would be greatly appreciated; TIA.

Sean Elble




------=_NextPart_000_0029_01C0DC92.D80F6F40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I am using XFS 1.0, for Linux, and =
couldn't be=20
happier, except for&nbsp;one thing;&nbsp;Samba won't work with the ACLs, =

provided with XFS, and, yes, I am using&nbsp;the included source ACL =
from the=20
XFS site! Any ideas why? Any response would be greatly appreciated;=20
TIA.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sean Elble</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><BR></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0029_01C0DC92.D80F6F40--


From owner-linux-xfs@oss.sgi.com Mon May 14 13:33:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKXvO22151
	for linux-xfs-outgoing; Mon, 14 May 2001 13:33:57 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKXsF22148
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:33:54 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zP2O-0006Gx-00; Mon, 14 May 2001 22:33:52 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4EKWiA29059;
	Mon, 14 May 2001 16:32:44 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Paul Rossman <pdr@evanston.fluent.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: DAC960 and XFS blocksize error
References: <3B0038A6.4DBEB316@evanston.fluent.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 14 May 2001 16:32:44 -0400
In-Reply-To: <3B0038A6.4DBEB316@evanston.fluent.com>
Message-ID: <yq1lmnzy8lv.fsf@jcb.mkp.net>
Lines: 14
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Paul" == Paul Rossman <pdr@evanston.fluent.com> writes:

Paul> [root@x /]# mkfs.xfs -f /dev/rd/c0d0p1 mkfs.xfs: warning -
Paul> cannot set blocksize on block device /dev/rd/c0d0p1

This has been fixed in the current CVS tree.

Eric Sandeen has an updated driver disk containing a workaround for
the 1.0 release.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Mon May 14 13:41:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKf7m22263
	for linux-xfs-outgoing; Mon, 14 May 2001 13:41:07 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKf5F22260
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:41:05 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 14zOzT-0004ou-00; Tue, 15 May 2001 08:30:51 +1200
Date: Tue, 15 May 2001 08:30:51 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Austin Gonyou <austin@coremetrics.com>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved
In-Reply-To: <Pine.LNX.4.33.0105141336350.1069-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.33.0105150820450.16452-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 14 May 2001, Austin Gonyou wrote:

> stupid mistake, big booboo. Next I went ahead and enabled the DMA support
> on this kernel. It was in fact NOT turned on. I also enabled PIIXn support
> and tuning.

This intrigues me -- you have an Athlon box with a VIA or ALi chip set
right? PIIX is Intel only.


> After doing that specific change, my system improved
> performance immediately. Good news there. After that, I continued further,
> using HDPARM and got a full 65-80% increase in throughput. I used the
> following options:
>
> hdparm -X66 -d1 -u1 -c3 -m16 /dev/hdx

You might want to experiment with the -a(n), -A1, -W1 flags
too. Just plain -c1 is probably a tiny bit quicker than -c3 (but it might
not work with your chip set).

If you have a newer drive, check with -i to see which UDMA mode it
supports. -X66 is UDMA 2; -X67, 68 and 69 could work on newer drives.




-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Mon May 14 13:48:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKmrA22533
	for linux-xfs-outgoing; Mon, 14 May 2001 13:48:53 -0700
Received: from wescoserver.gtri.gatech.edu (IDENT:root@wescoserver.gtri.gatech.edu [130.207.208.35])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKmlF22528
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:48:52 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
	by wescoserver.gtri.gatech.edu (8.9.3/8.9.3) with ESMTP id QAA22741;
	Mon, 14 May 2001 16:19:40 -0400
Message-ID: <XFMail.20010514164758.jtrostel@connex.com>
X-Mailer: XFMail 1.4.8 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <002c01c0dcb4$600c0b80$0600a8c0@gateway>
Date: Mon, 14 May 2001 16:47:58 -0400 (EDT)
Reply-To: jtrostel@connex.com
Organization: Connex
From: John Trostel <jtrostel@connex.com>
To: "Sean P. Elble" <S_Elble@yahoo.com>
Subject: RE: XFS/Linux/Samba Problems
Cc: linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Several problems concerning the interaction of XFS and Samba (2.2.0) have been
fixed recently in both the Samba and XFS CVS trees.  It is possible to patch
both to surmount these problems but it is probably easier to get the latest CVS
trees from SGI and Samba, recompile and reinstall.

What specific problems are you seeing? (I can probably tell you if the problems
have been addressed.... and approxiamtely when).

P.S.  You are using the latest Samba aren't you?

On 14-May-2001 Sean P. Elble wrote:
> Hello,
>  
> I am using XFS 1.0, for Linux, and couldn't be happier, except for one
> thing; Samba won't work with the ACLs, provided with XFS, and, yes, I am
> using the included source ACL from the XFS site! Any ideas why? Any
> response would be greatly appreciated; TIA.
>  
> Sean Elble
>  
> 
>  

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Mon May 14 13:49:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKn2c22543
	for linux-xfs-outgoing; Mon, 14 May 2001 13:49:02 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKn1F22540
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:49:01 -0700
Received: from qn-212-58-166-201.quicknet.nl ([212.58.166.201]:64966 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S19529AbRENUsm>;
	Mon, 14 May 2001 22:48:42 +0200
Message-Id: <4.3.2.7.2.20010514224643.03167cc8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Mon, 14 May 2001 22:48:48 +0200
To: linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Compiling CVS tree as of 14 may.
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just checked the tree out about an hour ago and it doesn't compile

make -C xfs
make[2]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs'
make -C linux
make[3]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
make all_targets
make[4]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_griostubs.o 
xfs_griostubs.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_dmistubs.o 
xfs_dmistubs.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_behavior.o 
xfs_behavior.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_cred.o xfs_cred.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_file.o xfs_file.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -DEXPORT_SYMTAB -c xfs_fs_subr.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_globals.o 
xfs_globals.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_ioctl.o xfs_ioctl.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_iops.o xfs_iops.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
-mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
/usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_lrw.o xfs_lrw.c
xfs_lrw.c: In function `xfs_write':
xfs_lrw.c:619: warning: implicit declaration of function `xfs_check_frozen'
xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this function)
xfs_lrw.c:619: (Each undeclared identifier is reported only once
xfs_lrw.c:619: for each function it appears in.)
make[4]: *** [xfs_lrw.o] Error 1
make[4]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
make[3]: *** [first_rule] Error 2
make[3]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
make[2]: *** [_subdir_linux] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs'
make[1]: *** [_subdir_xfs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs'
make: *** [_dir_fs] Error 2
[root@stimpy linux]#

Something I am missing?

Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Mon May 14 13:50:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EKo8I22618
	for linux-xfs-outgoing; Mon, 14 May 2001 13:50:08 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EKo7F22615
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 13:50:07 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4EKo5b06875;
	Mon, 14 May 2001 15:50:05 -0500 (CDT)
Message-ID: <3B00458A.D65EC50F@sgi.com>
Date: Mon, 14 May 2001 15:52:26 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Rossman <pdr@evanston.fluent.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: DAC960 and XFS blocksize error
References: <3B0038A6.4DBEB316@evanston.fluent.com> <yq1lmnzy8lv.fsf@jcb.mkp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Martin K. Petersen" wrote:
> 
> >>>>> "Paul" == Paul Rossman <pdr@evanston.fluent.com> writes:
> 
> Paul> [root@x /]# mkfs.xfs -f /dev/rd/c0d0p1 mkfs.xfs: warning -
> Paul> cannot set blocksize on block device /dev/rd/c0d0p1
> 
> This has been fixed in the current CVS tree.
> 
> Eric Sandeen has an updated driver disk containing a workaround for
> the 1.0 release.

Hi Paul -

Looks like you're already up and running, so not sure if the driver disk
will do you much good...  If you don't mind recompiling, the patch you
need is this:


--- linux-2.4-xfs/linux/drivers/block/DAC960.c  2001/02/22 21:09:04    
1.24
+++ linux-2.4-xfs/linux/drivers/block/DAC960.c  2001/05/03 01:10:53    
1.25
@@ -5104,6 +5104,9 @@ static int DAC960_IOCTL(Inode_T *Inode, 
       return
put_user(Controller->GenericDiskInfo.part[MINOR(Inode->i_rdev)]
                                                 .nr_sects,
                      (long *) Argument);
+    case BLKBSZSET:
+      /* Set block size. */
+      return blk_ioctl (Inode->i_rdev, Request, Argument);
     case BLKRAGET:
       /* Get Read-Ahead. */
       if ((long *) Argument == NULL) return -EINVAL;


HTH,

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 14:05:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EL5pH23213
	for linux-xfs-outgoing; Mon, 14 May 2001 14:05:51 -0700
Received: from kernelpanix.aura.of.mankind (pD901EDB7.dip.t-dialin.net [217.1.237.183])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EL5lF23205
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:05:49 -0700
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4EKPDI07555;
	Mon, 14 May 2001 22:25:13 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Mon, 14 May 2001 22:25:13 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Seth Mos <knuffie@xs4all.nl>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Compiling CVS tree as of 14 may.
Message-ID: <20010514222513.A7540@s2y4n2c.de>
References: <4.3.2.7.2.20010514224643.03167cc8@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4.3.2.7.2.20010514224643.03167cc8@pop.xs4all.nl>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi

i got the same error.


utz

Seth Mos [knuffie@xs4all.nl] wrote:
> I just checked the tree out about an hour ago and it doesn't compile
> 
> make -C xfs
> make[2]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs'
> make -C linux
> make[3]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
> make all_targets
> make[4]: Entering directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_griostubs.o 
> xfs_griostubs.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_dmistubs.o 
> xfs_dmistubs.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_behavior.o 
> xfs_behavior.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_cred.o xfs_cred.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_file.o xfs_file.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -DEXPORT_SYMTAB -c xfs_fs_subr.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_globals.o 
> xfs_globals.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_ioctl.o xfs_ioctl.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_iops.o xfs_iops.c
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.4-xfs/include  -Wall 
> -Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe 
> -mpreferred-stack-boundary=2 -march=athlon   -I .. -I 
> /usr/src/linux-2.4.4-xfs/fs  -funsigned-char   -c -o xfs_lrw.o xfs_lrw.c
> xfs_lrw.c: In function `xfs_write':
> xfs_lrw.c:619: warning: implicit declaration of function `xfs_check_frozen'
> xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this function)
> xfs_lrw.c:619: (Each undeclared identifier is reported only once
> xfs_lrw.c:619: for each function it appears in.)
> make[4]: *** [xfs_lrw.o] Error 1
> make[4]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
> make[3]: *** [first_rule] Error 2
> make[3]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs/linux'
> make[2]: *** [_subdir_linux] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs/xfs'
> make[1]: *** [_subdir_xfs] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.4.4-xfs/fs'
> make: *** [_dir_fs] Error 2
> [root@stimpy linux]#
> 
> Something I am missing?
> 
> Cheers
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.

From owner-linux-xfs@oss.sgi.com Mon May 14 14:09:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EL94l23765
	for linux-xfs-outgoing; Mon, 14 May 2001 14:09:04 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EL93F23762
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:09:03 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4EL90815149;
	Mon, 14 May 2001 16:09:00 -0500 (CDT)
Message-ID: <3B0049FA.14118E6B@sgi.com>
Date: Mon, 14 May 2001 16:11:22 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Compiling CVS tree as of 14 may.
References: <4.3.2.7.2.20010514224643.03167cc8@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:
> 
> xfs_lrw.c:619: warning: implicit declaration of function `xfs_check_frozen'
> xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this function)
> xfs_lrw.c:619: (Each undeclared identifier is reported only once
> xfs_lrw.c:619: for each function it appears in.)

> Something I am missing?

Hm, Steve checked in a change for this file today, but it looks like he
got part of his snapshot patch in there - that missing function is
defined in the patch he posted earlier.

Steve?  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 14:17:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ELHeu23935
	for linux-xfs-outgoing; Mon, 14 May 2001 14:17:40 -0700
Received: from glacier.evanston.fluent.com (glacier.evanston.fluent.com [192.104.61.185])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ELHZF23925
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:17:39 -0700
Received: from evanston.fluent.com (taxi [192.104.61.40])
	by glacier.evanston.fluent.com (8.11.3/8.11.3/) with ESMTP id f4EKH9k22660;
	Mon, 14 May 2001 15:17:14 -0500
X-Spam-Filter: check_local@glacier.evanston.fluent.com by digitalanswers.org
Message-ID: <3B004AC6.1F3DA0EE@evanston.fluent.com>
Date: Mon, 14 May 2001 16:14:46 -0500
From: Paul Rossman <paulr@evanston.fluent.com>
Organization: Fluent, Inc.
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: DAC960 and XFS blocksize error
References: <3B0038A6.4DBEB316@evanston.fluent.com> <yq1lmnzy8lv.fsf@jcb.mkp.net> <3B00458A.D65EC50F@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Eric and Martin,

Thanks for the patch. I saw the boot stuff from a few days ago... and I
also had those problems, but I didn't need to boot with an xfs disk so
just used the rh71 disks to install... I didn't get the connection :)

Should I go ahead and patch the kernel, reboot, then reformat the disk?
Could there be a side effect from having the disk formatted from the old
kernel and using the patched one?

Thanks again, paul

Eric Sandeen wrote:
> 
> "Martin K. Petersen" wrote:
> >
> > >>>>> "Paul" == Paul Rossman <pdr@evanston.fluent.com> writes:
> >
> > Paul> [root@x /]# mkfs.xfs -f /dev/rd/c0d0p1 mkfs.xfs: warning -
> > Paul> cannot set blocksize on block device /dev/rd/c0d0p1
> >
> > This has been fixed in the current CVS tree.
> >
> > Eric Sandeen has an updated driver disk containing a workaround for
> > the 1.0 release.
> 
> Hi Paul -
> 
> Looks like you're already up and running, so not sure if the driver disk
> will do you much good...  If you don't mind recompiling, the patch you
> need is this:
> 
> --- linux-2.4-xfs/linux/drivers/block/DAC960.c  2001/02/22 21:09:04
> 1.24
> +++ linux-2.4-xfs/linux/drivers/block/DAC960.c  2001/05/03 01:10:53
> 1.25
> @@ -5104,6 +5104,9 @@ static int DAC960_IOCTL(Inode_T *Inode,
>        return
> put_user(Controller->GenericDiskInfo.part[MINOR(Inode->i_rdev)]
>                                                  .nr_sects,
>                       (long *) Argument);
> +    case BLKBSZSET:
> +      /* Set block size. */
> +      return blk_ioctl (Inode->i_rdev, Request, Argument);
>      case BLKRAGET:
>        /* Get Read-Ahead. */
>        if ((long *) Argument == NULL) return -EINVAL;
> 
> HTH,
> 
> -Eric
> 
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 14:36:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ELam824146
	for linux-xfs-outgoing; Mon, 14 May 2001 14:36:48 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ELakF24143
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:36:47 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA19029
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:35:22 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1773309; Mon, 14 May 2001 16:35:28 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA04059; Mon, 14 May 2001 16:35:28 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4ELbg819623; Mon, 14 May 2001 16:37:42 -0500
Message-Id: <200105142137.f4ELbg819623@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Eric Sandeen <sandeen@sgi.com>
cc: Seth Mos <knuffie@xs4all.nl>, linux-xfs@oss.sgi.com
Subject: Re: Compiling CVS tree as of 14 may. 
In-Reply-To: Message from Eric Sandeen <sandeen@sgi.com> 
   of "Mon, 14 May 2001 16:11:22 CDT." <3B0049FA.14118E6B@sgi.com> 
Date: Mon, 14 May 2001 16:37:42 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Seth Mos wrote:
> > 
> > xfs_lrw.c:619: warning: implicit declaration of function `xfs_check_frozen'
> > xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this function)
> > xfs_lrw.c:619: (Each undeclared identifier is reported only once
> > xfs_lrw.c:619: for each function it appears in.)
> 
> > Something I am missing?
> 
> Hm, Steve checked in a change for this file today, but it looks like he
> got part of his snapshot patch in there - that missing function is
> defined in the patch he posted earlier.
> 
> Steve?  :)
> 
> -Eric
> 

Eric is correct, I used the wrong tree for a checkin, sorry about that,
fix is on its way. For now just delete the reference to xfs_check_frozen
from the file.

Steve



From owner-linux-xfs@oss.sgi.com Mon May 14 14:43:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ELhRa24367
	for linux-xfs-outgoing; Mon, 14 May 2001 14:43:27 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ELhRF24362
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:43:27 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03305
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 14:54:22 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1812003 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:42:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA91738 for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:42:06 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4ELiK420341; Mon, 14 May 2001 16:44:20 -0500
Message-Id: <200105142144.f4ELiK420341@jen.americas.sgi.com>
Date: Mon, 14 May 2001 16:44:20 -0500
Subject: TAKE - fix build error
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I checked in too much code, back out part of the snapshotting code
which snuck in by mistake.

Date:  Mon May 14 14:41:20 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94833a
linux/fs/xfs/linux/xfs_lrw.c - 1.98
	- Fix build error - wrong code checked in.



From owner-linux-xfs@oss.sgi.com Mon May 14 15:06:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EM6vo24987
	for linux-xfs-outgoing; Mon, 14 May 2001 15:06:57 -0700
Received: from mail.disney.com (mail.disney.com [204.128.192.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EM6uF24984
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:06:56 -0700
Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100])
	by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f4EM6FA12664
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:06:15 -0700 (PDT)
Received: from ds-naso-mc02.studio.disney.com by pain.corp.disney.com with ESMTP for linux-xfs@oss.sgi.com; Mon, 14 May 2001 15:07:36 -0700
Received: by DS-NASO-MC02.wds.disney.com with Internet Mail Service (5.5.2653.19)
	id <KRZ2ZFK7>; Mon, 14 May 2001 15:08:39 -0700
Message-Id: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com>
From: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Direct I/O question: How to get dioinfo using ioctl?
Date: Mon, 14 May 2001 15:04:22 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


A couple of earlier threads mentioned this but didn't explain how to do it. 
Direct I/O appears to work with the following code, but the ioctl command
returns an error.  I'm looking for a command that does the same thing as
fcntl(fileDescriptor, F_DIOINFO, &dioinfo) does on IRIX.  But I don't know
if the 
ioctl command is running xfs_ioctl like it should.

Also direct I/O is running slower than unbuffered I/O on our machine for
some reason,
maybe because of how the disk array is striped, I'm not sure.

Thanks,

Eric Rosenthal
Software Engineer

Disney TV animation


#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/timeb.h>
#include <errno.h>
#include <assert.h>
#include <errno.h>

#include <xfs/xfs_fs.h>

#include <fcntl.h>
#define O_DIRECT 040000
#define O_RDONLY        0

extern int errno;

main()
{ int fd;
  struct dioattr dioinfo; 
  int fcntlRetval, ioctlRetval;
  struct dioattr  da;

  fd = open("/home/origin/erosenth/test/linux/testFile", O_RDONLY |
O_DIRECT);
  fprintf(stderr, "File Descriptor = <%d>   XFS_IOC_DIOINFO = <%d>\n", 
	  fd, XFS_IOC_DIOINFO);
  ioctlRetval = ioctl(fd, XFS_IOC_DIOINFO, &da);

  fprintf(stderr, "ioctlRetval = %d\n", ioctlRetval);
  fprintf(stderr, "errno = <%d>\n", errno);

  perror("");
}


From owner-linux-xfs@oss.sgi.com Mon May 14 15:15:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMFYI25243
	for linux-xfs-outgoing; Mon, 14 May 2001 15:15:34 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMFXF25240
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:15:33 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA04975
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:15:27 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA25298; Mon, 14 May 2001 17:14:11 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4EMDAe21851;
	Mon, 14 May 2001 18:13:10 -0400
Message-ID: <3B005875.90D15118@thebarn.com>
Date: Mon, 14 May 2001 18:13:09 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Martin K. Petersen" <mkp@linuxcare.com>
CC: Paul Rossman <pdr@evanston.fluent.com>, linux-xfs@oss.sgi.com
Subject: Re: DAC960 and XFS blocksize error
References: <3B0038A6.4DBEB316@evanston.fluent.com> <yq1lmnzy8lv.fsf@jcb.mkp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Martin K. Petersen" wrote:

> >>>>> "Paul" == Paul Rossman <pdr@evanston.fluent.com> writes:
>
> Paul> [root@x /]# mkfs.xfs -f /dev/rd/c0d0p1 mkfs.xfs: warning -
> Paul> cannot set blocksize on block device /dev/rd/c0d0p1
>
> This has been fixed in the current CVS tree.

It has also been merged over to the 1.0 tree.


>
>
> Eric Sandeen has an updated driver disk containing a workaround for
> the 1.0 release.
>
> --
> Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
> mkp@linuxcare.com, http://www.linuxcare.com/
> SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May 14 15:15:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMFdQ25257
	for linux-xfs-outgoing; Mon, 14 May 2001 15:15:39 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMFcF25254
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:15:38 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 2EF4C1E265; Tue, 15 May 2001 00:15:37 +0200 (MEST)
Date: Tue, 15 May 2001 00:15:14 +0200
From: Andi Kleen <ak@suse.de>
To: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
Cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Direct I/O question: How to get dioinfo using ioctl?
Message-ID: <20010515001514.A7552@gruyere.muc.suse.de>
References: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com>; from Eric.S.Rosenthal@disney.com on Mon, May 14, 2001 at 03:04:22PM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 14, 2001 at 03:04:22PM -0700, Rosenthal, Eric S. wrote:
> 
> A couple of earlier threads mentioned this but didn't explain how to do it. 
> Direct I/O appears to work with the following code, but the ioctl command
> returns an error.  I'm looking for a command that does the same thing as
> fcntl(fileDescriptor, F_DIOINFO, &dioinfo) does on IRIX.  But I don't know
> if the 
> ioctl command is running xfs_ioctl like it should.

xfs_ioctl only runs when you use ioctl(2), not fcntl(2). Linux doesn't 
hand fcntl through the normal VFS, so XFS never sees it and has to use ioctl.


-Andi

From owner-linux-xfs@oss.sgi.com Mon May 14 15:18:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMIxq25434
	for linux-xfs-outgoing; Mon, 14 May 2001 15:18:59 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMIwF25429
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:18:58 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4EMGkk05505;
	Mon, 14 May 2001 17:16:46 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 14 May 2001 17:16:45 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Juha Saarinen <juha@saarinen.org>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved
In-Reply-To: <Pine.LNX.4.33.0105150820450.16452-100000@vimfuego.saarinen.org>
Message-ID: <Pine.LNX.4.33.0105141713340.4503-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


On Tue, 15 May 2001, Juha Saarinen wrote:

> On Mon, 14 May 2001, Austin Gonyou wrote:
>
> > stupid mistake, big booboo. Next I went ahead and enabled the DMA support
> > on this kernel. It was in fact NOT turned on. I also enabled PIIXn support
> > and tuning.
>
> This intrigues me -- you have an Athlon box with a VIA or ALi chip set
> right? PIIX is Intel only.

The PIIX addition was on an intel system. A dell GX100 with a 433 celeron.
Dood..it's so damn fast now!!!



>
>
> > After doing that specific change, my system improved
> > performance immediately. Good news there. After that, I continued further,
> > using HDPARM and got a full 65-80% increase in throughput. I used the
> > following options:
> >
> > hdparm -X66 -d1 -u1 -c3 -m16 /dev/hdx
>
> You might want to experiment with the -a(n), -A1, -W1 flags
> too. Just plain -c1 is probably a tiny bit quicker than -c3 (but it might
> not work with your chip set).
>

Good call indeed!

> If you have a newer drive, check with -i to see which UDMA mode it
> supports. -X66 is UDMA 2; -X67, 68 and 69 could work on newer drives.

You are correct indeed. One of the drives I have at work support UDMA5.
And so it goes. Also I added -W1 -A1 -a16 -c1 to my parameter list, I
added 9MB/s. WHOOOOLLLY CRAP! Anyway, it kicks ass, and now this system is
cooking.


As promised, when I get home, I'm going to recompile my kernel again, and
tweak these options to see what I can get out of it!


-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Mon May 14 15:37:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMbsJ26046
	for linux-xfs-outgoing; Mon, 14 May 2001 15:37:54 -0700
Received: from dandelion.darkorb.net (cc53440-a.catv1.md.home.com [24.18.90.197])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMbjF26043
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:37:45 -0700
Received: from icognito by dandelion.darkorb.net with local (Exim 3.22 #1 (Debian))
	id 14zQyG-0005om-00
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:37:44 -0400
Date: Mon, 14 May 2001 18:37:44 -0400
From: Gabriel Rocha <grocha@geeksimplex.org>
To: linux-xfs@oss.sgi.com
Subject: compile question
Message-ID: <20010514183744.A22174@dandelion.darkorb.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,
	I have been trying to compile xfs into the kernel for a little
	while now and its getting frustrating...I am using 2.4.4 (on a
	side note, I also tried 2.4.4-ac8, which I noticed fails
	miserably...any plans to integrate the two trees?) I am using
	patch version:
		linux-2.4.4-xfs-cvs-05142001.patch
	and this is the error I get when I try to compile it into the
	kernel:
	
	<snipped>
	gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include  -Wall
	-Wstrict-prototypes -O2 -fno-strict-aliasing
	-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
	-march=i686 -DMODULE -DMODVERSIONS -include
	/usr/src/linux-2.4.4/include/linux/modversions.h -I .. -I
	/usr/src/linux-2.4.4/fs  -funsigned-char   -c -o xfs_lrw.o
	xfs_lrw.c
	xfs_lrw.c: In function `xfs_write':
	xfs_lrw.c:619: warning: implicit declaration of function
	`xfs_check_frozen'
	xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this
	function)
	xfs_lrw.c:619: (Each undeclared identifier is reported only once
	xfs_lrw.c:619: for each function it appears in.)
	xfs_lrw.c: At top level:
	../xfs_log.h:60: warning: `_lsn_cmp' defined but not used
	make[3]: *** [xfs_lrw.o] Error 1
	make[3]: Leaving directory `/usr/src/linux-2.4.4/fs/xfs/linux'
	make[2]: *** [_modsubdir_linux] Error 2
	make[2]: Leaving directory `/usr/src/linux-2.4.4/fs/xfs'
	make[1]: *** [_modsubdir_xfs] Error 2
	make[1]: Leaving directory `/usr/src/linux-2.4.4/fs'
	make: *** [_mod_fs] Error 2

	did I screw something up? here is a copy of my .config:
	please let me know if I did something wrong, I am very eager to
	try out the FS. Thanks. --gabe


#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
CONFIG_MPENTIUMIII=y
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
# CONFIG_X86_UP_IOAPIC is not set

#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y

#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=y
CONFIG_CARDBUS=y
CONFIG_I82365=y
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
# CONFIG_APM_CPU_IDLE is not set
CONFIG_APM_DISPLAY_BLANK=y
CONFIG_APM_RTC_IS_GMT=y
# CONFIG_APM_ALLOW_INTS is not set
CONFIG_APM_REAL_MODE_POWER_OFF=y

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play configuration
#
# CONFIG_PNP is not set
# CONFIG_ISAPNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=m
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
CONFIG_ARPD=y
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set

#
# ATA/IDE/MFM/RLL support
#
CONFIG_IDE=y

#
# IDE, ATA and ATAPI Block devices
#
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
# CONFIG_BLK_DEV_HD is not set
CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
CONFIG_BLK_DEV_IDECS=m
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD7409 is not set
# CONFIG_AMD7409_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_PIIX_TUNING is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_OSB4 is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDEDMA_IVB is not set
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y

#
# SCSI support
#
# CONFIG_SCSI is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
# CONFIG_PPP_FILTER is not set
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_SLIP=m
# CONFIG_SLIP_COMPRESSED is not set
# CONFIG_SLIP_SMART is not set
# CONFIG_SLIP_MODE_SLIP6 is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# PCMCIA network device support
#
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_3C589=m
CONFIG_PCMCIA_3C574=m
CONFIG_PCMCIA_FMVJ18X=m
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_NMCLAN=m
CONFIG_PCMCIA_SMC91C92=m
CONFIG_PCMCIA_XIRC2PS=m
# CONFIG_ARCNET_COM20020_CS is not set
# CONFIG_PCMCIA_IBMTR is not set
CONFIG_PCMCIA_XIRTULIP=m
CONFIG_NET_PCMCIA_RADIO=y
CONFIG_PCMCIA_RAYCS=m
CONFIG_PCMCIA_HERMES=m
CONFIG_PCMCIA_NETWAVE=m
CONFIG_PCMCIA_WAVELAN=m
CONFIG_AIRONET4500_CS=m

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Input core support
#
# CONFIG_INPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set

#
# Joysticks
#
# CONFIG_JOYSTICK is not set
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=m
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
CONFIG_AGP=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_I810 is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_ALI is not set
# CONFIG_DRM is not set

#
# PCMCIA character devices
#
CONFIG_PCMCIA_SERIAL_CS=m

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_REISERFS_FS=m
# CONFIG_REISERFS_CHECK is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
# CONFIG_RAMFS is not set
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_SYSV_FS_WRITE is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
CONFIG_PAGE_BUF=y
CONFIG_XFS_FS=m
CONFIG_XFS_DMAPI=y
# CONFIG_XFS_QUOTA is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_XFS_VNODE_TRACING is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
CONFIG_NFS_FS=m
# CONFIG_NFS_V3 is not set
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
# CONFIG_NFSD_V3 is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Sound
#
CONFIG_SOUND=y
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
CONFIG_SOUND_FUSION=m
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_TVMIXER is not set

#
# USB support
#
# CONFIG_USB is not set

#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_KDB is not set
# CONFIG_KALLSYMS is not set
# CONFIG_FRAME_POINTER is not set
-- 

"It's not brave if you're not scared."

From owner-linux-xfs@oss.sgi.com Mon May 14 15:38:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMcog26096
	for linux-xfs-outgoing; Mon, 14 May 2001 15:38:50 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMcnF26092
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:38:49 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA06590
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:38:00 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1789870; Mon, 14 May 2001 17:36:30 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA61495; Mon, 14 May 2001 17:36:30 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EMchR20416; Mon, 14 May 2001 17:38:43 -0500
Message-Id: <200105142238.f4EMchR20416@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Direct I/O question: How to get dioinfo using ioctl? 
In-Reply-To: Message from "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com> 
   of "Mon, 14 May 2001 15:04:22 PDT." <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com> 
Date: Mon, 14 May 2001 17:38:43 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> A couple of earlier threads mentioned this but didn't explain how to do it. 
> Direct I/O appears to work with the following code, but the ioctl command
> returns an error.  I'm looking for a command that does the same thing as
> fcntl(fileDescriptor, F_DIOINFO, &dioinfo) does on IRIX.  But I don't know
> if the 
> ioctl command is running xfs_ioctl like it should.

The one missing link here is what error do you get back from the ioctl?
And I presume that file is on XFS.

> 
> Also direct I/O is running slower than unbuffered I/O on our machine for
> some reason,
> maybe because of how the disk array is striped, I'm not sure.

That's so you still keep your SGI hardware ;-)  No seriously, I have
found I need to crank the I/O size on direct I/O up fairly high to
get reasonable performance out of it. What sort of speed can you get
from buffered I/O vs direct I/O for what block sizes, and what sort
of raw device speed can you obtain.

One more question - which  kernel are you using, things in the CVS development
tree have changed in this area due to other kernel changes.

Steve

> 
> Thanks,
> 
> Eric Rosenthal
> Software Engineer
> 
> Disney TV animation
> 
> 
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/timeb.h>
> #include <errno.h>
> #include <assert.h>
> #include <errno.h>
> 
> #include <xfs/xfs_fs.h>
> 
> #include <fcntl.h>
> #define O_DIRECT 040000
> #define O_RDONLY        0
> 
> extern int errno;
> 
> main()
> { int fd;
>   struct dioattr dioinfo; 
>   int fcntlRetval, ioctlRetval;
>   struct dioattr  da;
> 
>   fd = open("/home/origin/erosenth/test/linux/testFile", O_RDONLY |
> O_DIRECT);
>   fprintf(stderr, "File Descriptor = <%d>   XFS_IOC_DIOINFO = <%d>\n", 
> 	  fd, XFS_IOC_DIOINFO);
>   ioctlRetval = ioctl(fd, XFS_IOC_DIOINFO, &da);
> 
>   fprintf(stderr, "ioctlRetval = %d\n", ioctlRetval);
>   fprintf(stderr, "errno = <%d>\n", errno);
> 
>   perror("");
> }



From owner-linux-xfs@oss.sgi.com Mon May 14 15:42:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMgoN26173
	for linux-xfs-outgoing; Mon, 14 May 2001 15:42:50 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMgnF26170
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:42:49 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA04764
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:41:25 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1812403; Mon, 14 May 2001 17:41:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA34701; Mon, 14 May 2001 17:41:31 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4EMhiN20431; Mon, 14 May 2001 17:43:44 -0500
Message-Id: <200105142243.f4EMhiN20431@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Gabriel Rocha <grocha@geeksimplex.org>
cc: linux-xfs@oss.sgi.com
Subject: Re: compile question 
In-Reply-To: Message from Gabriel Rocha <grocha@geeksimplex.org> 
   of "Mon, 14 May 2001 18:37:44 EDT." <20010514183744.A22174@dandelion.darkorb.net> 
Date: Mon, 14 May 2001 17:43:44 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Looks like the patch was generated at a bad time - delete line 619 in
fs/xfs/linux/xfs_lrw.c and try again. This line snuck out there by mistake.

Steve


> Hi,
> 	I have been trying to compile xfs into the kernel for a little
> 	while now and its getting frustrating...I am using 2.4.4 (on a
> 	side note, I also tried 2.4.4-ac8, which I noticed fails
> 	miserably...any plans to integrate the two trees?) I am using
> 	patch version:
> 		linux-2.4.4-xfs-cvs-05142001.patch
> 	and this is the error I get when I try to compile it into the
> 	kernel:
> 	
> 	<snipped>
> 	gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include  -Wall
> 	-Wstrict-prototypes -O2 -fno-strict-aliasing
> 	-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
> 	-march=i686 -DMODULE -DMODVERSIONS -include
> 	/usr/src/linux-2.4.4/include/linux/modversions.h -I .. -I
> 	/usr/src/linux-2.4.4/fs  -funsigned-char   -c -o xfs_lrw.o
> 	xfs_lrw.c
> 	xfs_lrw.c: In function `xfs_write':
> 	xfs_lrw.c:619: warning: implicit declaration of function
> 	`xfs_check_frozen'
> 	xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this
> 	function)
> 	xfs_lrw.c:619: (Each undeclared identifier is reported only once
> 	xfs_lrw.c:619: for each function it appears in.)
> 	xfs_lrw.c: At top level:
> 	../xfs_log.h:60: warning: `_lsn_cmp' defined but not used
> 	make[3]: *** [xfs_lrw.o] Error 1
> 	make[3]: Leaving directory `/usr/src/linux-2.4.4/fs/xfs/linux'
> 	make[2]: *** [_modsubdir_linux] Error 2
> 	make[2]: Leaving directory `/usr/src/linux-2.4.4/fs/xfs'
> 	make[1]: *** [_modsubdir_xfs] Error 2
> 	make[1]: Leaving directory `/usr/src/linux-2.4.4/fs'
> 	make: *** [_mod_fs] Error 2


From owner-linux-xfs@oss.sgi.com Mon May 14 15:46:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4EMkl726282
	for linux-xfs-outgoing; Mon, 14 May 2001 15:46:47 -0700
Received: from wescoserver.gtri.gatech.edu (IDENT:root@wescoserver.gtri.gatech.edu [130.207.208.35])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4EMkgF26279
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 15:46:45 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
	by wescoserver.gtri.gatech.edu (8.9.3/8.9.3) with ESMTP id SAA24368;
	Mon, 14 May 2001 18:17:38 -0400
Message-ID: <XFMail.20010514184557.jtrostel@connex.com>
X-Mailer: XFMail 1.4.8 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20010514183744.A22174@dandelion.darkorb.net>
Date: Mon, 14 May 2001 18:45:57 -0400 (EDT)
Reply-To: jtrostel@connex.com
Organization: Connex
From: John Trostel <jtrostel@connex.com>
To: Gabriel Rocha <grocha@geeksimplex.org>
Subject: RE: compile question
Cc: linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


On 14-May-2001 Gabriel Rocha wrote:
> Hi,
>       I have been trying to compile xfs into the kernel for a little
>       while now and its getting frustrating...I am using 2.4.4 (on a
>       side note, I also tried 2.4.4-ac8, which I noticed fails
>       miserably...any plans to integrate the two trees?) I am using
>       patch version:
>               linux-2.4.4-xfs-cvs-05142001.patch
>       and this is the error I get when I try to compile it into the
>       kernel:
>       
>       <snipped>
>       gcc -D__KERNEL__ -I/usr/src/linux-2.4.4/include  -Wall
>       -Wstrict-prototypes -O2 -fno-strict-aliasing
>       -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2
>       -march=i686 -DMODULE -DMODVERSIONS -include
>       /usr/src/linux-2.4.4/include/linux/modversions.h -I .. -I
>       /usr/src/linux-2.4.4/fs  -funsigned-char   -c -o xfs_lrw.o
>       xfs_lrw.c
>       xfs_lrw.c: In function `xfs_write':
>       xfs_lrw.c:619: warning: implicit declaration of function
>       `xfs_check_frozen'
>       xfs_lrw.c:619: `XFS_FREEZE_WRITE' undeclared (first use in this


Without looking at all the rest of the output... Look at the last few emails in
the archive.  Steve Lord checked in a some code from the wrong tree and this
must have propogated into your patch.  Either wait and pick up the next patch,
or delete the reference to xfs_freeze_write in the file and recompile.
 
-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Mon May 14 16:27:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ENRnk26958
	for linux-xfs-outgoing; Mon, 14 May 2001 16:27:49 -0700
Received: from mail.disney.com (mail.disney.com [204.128.192.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ENRlF26955
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:27:47 -0700
Received: from pain10.corp.disney.com (root@pain10.corp.disney.com [153.7.110.100])
	by mail.disney.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f4ENR9A11875
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:27:09 -0700 (PDT)
Received: from ds-naso-mc02.studio.disney.com by pain.corp.disney.com with ESMTP for linux-xfs@oss.sgi.com; Mon, 14 May 2001 16:28:20 -0700
Received: by DS-NASO-MC02.wds.disney.com with Internet Mail Service (5.5.2653.19)
	id <KRZ2Z2VL>; Mon, 14 May 2001 16:29:23 -0700
Message-Id: <99A560B38BC6D21180020004ACA6B36A031FAF65@ds-naso-msa2.wds.disney.com>
From: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: RE: Direct I/O question: How to get dioinfo using ioctl? 
Date: Mon, 14 May 2001 16:25:08 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Thanks for the reply - 

My mistake - I was trying to run 
"ioctl(fileDescriptor, XFS_IOC_DIOINFO, &dioinfo)" on a 
file that wasn't on the xfs volume.  It worked with the right file.  Got to 
lay off that weekend binge drinking!  

As for the fact that direct I/O is slower than buffered I/O - we're
running version 2.4.2 of the Kernel on a PC, and have 2 striped hard drives
connected with a Scsi controller (we plan to add more drives).  The disks
are striped at 4K and the file system block size is 4K.  I'll have to do
some tests to see which sizes are optimal.

The disk rate I got for direct I/O (25 MB/sec) is about what was expected
but the rate with buffered I/O (27 MB/sec with the cache cleared) is higher 
than I would've throught.  Could Linux just handle buffered I/O better than
Irix/NT?

Eric

-----Original Message-----
From: Steve Lord [mailto:lord@sgi.com]
Sent: Monday, May 14, 2001 3:39 PM
To: Rosenthal, Eric S.
Cc: 'linux-xfs@oss.sgi.com'
Subject: Re: Direct I/O question: How to get dioinfo using ioctl? 


> 
> A couple of earlier threads mentioned this but didn't explain how to do
it. 
> Direct I/O appears to work with the following code, but the ioctl command
> returns an error.  I'm looking for a command that does the same thing as
> fcntl(fileDescriptor, F_DIOINFO, &dioinfo) does on IRIX.  But I don't know
> if the 
> ioctl command is running xfs_ioctl like it should.

The one missing link here is what error do you get back from the ioctl?
And I presume that file is on XFS.

> 
> Also direct I/O is running slower than unbuffered I/O on our machine for
> some reason,
> maybe because of how the disk array is striped, I'm not sure.

That's so you still keep your SGI hardware ;-)  No seriously, I have
found I need to crank the I/O size on direct I/O up fairly high to
get reasonable performance out of it. What sort of speed can you get
from buffered I/O vs direct I/O for what block sizes, and what sort
of raw device speed can you obtain.

One more question - which  kernel are you using, things in the CVS
development
tree have changed in this area due to other kernel changes.

Steve

> 
> Thanks,
> 
> Eric Rosenthal
> Software Engineer
> 
> Disney TV animation
> 
> 
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/timeb.h>
> #include <errno.h>
> #include <assert.h>
> #include <errno.h>
> 
> #include <xfs/xfs_fs.h>
> 
> #include <fcntl.h>
> #define O_DIRECT 040000
> #define O_RDONLY        0
> 
> extern int errno;
> 
> main()
> { int fd;
>   struct dioattr dioinfo; 
>   int fcntlRetval, ioctlRetval;
>   struct dioattr  da;
> 
>   fd = open("/home/origin/erosenth/test/linux/testFile", O_RDONLY |
> O_DIRECT);
>   fprintf(stderr, "File Descriptor = <%d>   XFS_IOC_DIOINFO = <%d>\n", 
> 	  fd, XFS_IOC_DIOINFO);
>   ioctlRetval = ioctl(fd, XFS_IOC_DIOINFO, &da);
> 
>   fprintf(stderr, "ioctlRetval = %d\n", ioctlRetval);
>   fprintf(stderr, "errno = <%d>\n", errno);
> 
>   perror("");
> }


From owner-linux-xfs@oss.sgi.com Mon May 14 16:31:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ENVnK27018
	for linux-xfs-outgoing; Mon, 14 May 2001 16:31:49 -0700
Received: from myrealbox.com (mail.myrealbox.com [192.108.102.201])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ENVnF27015
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:31:49 -0700
Received: from myrealbox.com [207.253.156.160] by myrealbox.com
	with Novonyx SMTP Server $Revision:   2.75.1.6  $; Mon, 14 May 2001 17:28:43 -0600 (MDT)
Message-ID: <359C17F9.443B638@myrealbox.com>
Date: Thu, 02 Jul 1998 19:30:01 -0400
From: root <ssfb@myrealbox.com>
X-Mailer: Mozilla 4.75 [fr] (X11; U; Linux 2.4.2 i686)
X-Accept-Language: en,x-ns1nGxWo3EbNh5,x-ns2U0e0btwUq5f
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: patch
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've downloaded the patch for the 2.4.2 kernel, after doing the patch
ant trying to compile the kernel, the XFS support did not show. So, what
can I do?

Thank you

Sylvain

From owner-linux-xfs@oss.sgi.com Mon May 14 16:32:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ENWbS27031
	for linux-xfs-outgoing; Mon, 14 May 2001 16:32:37 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ENWbF27028
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:32:37 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA18731
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:31:00 -0700 (PDT)
	mail_from (dxm@snort.melbourne.sgi.com)
Received: from snort.melbourne.sgi.com (localhost [127.0.0.1])
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA40951;
	Tue, 15 May 2001 09:28:59 +1000 (EST)
Message-Id: <200105142328.JAA40951@snort.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Takayuki Sasaki <sasaki@bsd.tnes.nec.co.jp>
Subject: Re: A typo in cmd/xfstest/015 
In-reply-to: Your message of "Mon, 14 May 2001 18:18:42 +0900."
             <3AFFA2F2.7EA64EFA@bsd.tnes.nec.co.jp> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
cc: linux-xfs@oss.sgi.com
Date: Tue, 15 May 2001 09:28:59 +1000
From: Daniel Moore <dxm@snort.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Takayuki Sasaki writes:
 => Hi, 
 => 
 => First thanks to SGI and all the developers for the Release 1.0.
 => BTW: I am investigating the xfs test tools, and found a typo in
 => cmd/xfstests/015.
 => 
 => The line 62 says:
 => _df_dir $TEST_DIR | $AWK_PROG '{ print $5 }'
 =>         ^^^^^^^^^^
 => but it should be:
 => _df_dir $SCRATCH_MNT | $AWK_PROG '{ print $5 }'
 =>         ^^^^^^^^^^^^

Thanks - well spotted.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Mon May 14 16:43:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ENh6M27459
	for linux-xfs-outgoing; Mon, 14 May 2001 16:43:06 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ENh6F27456
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:43:06 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA21570
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 16:41:32 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA79257; Mon, 14 May 2001 16:36:20 -0700 (PDT)
Message-ID: <3B006C70.BC3CA77A@sgi.com>
Date: Mon, 14 May 2001 16:38:24 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
CC: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Direct I/O question: How to get dioinfo using ioctl?
References: <99A560B38BC6D21180020004ACA6B36A031FAF65@ds-naso-msa2.wds.disney.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Rosenthal, Eric S." wrote:
> 
	[ ... ]
> 
> As for the fact that direct I/O is slower than buffered I/O - we're
> running version 2.4.2 of the Kernel on a PC, and have 2 striped hard drives
> connected with a Scsi controller (we plan to add more drives).  The disks
> are striped at 4K and the file system block size is 4K.  I'll have to do
> some tests to see which sizes are optimal.
> 
> The disk rate I got for direct I/O (25 MB/sec) is about what was expected
> but the rate with buffered I/O (27 MB/sec with the cache cleared) is higher
> than I would've throught.  Could Linux just handle buffered I/O better than
> Irix/NT?


By I/O do you mean read, write or both? For streaming buffered
writes XFS will do nearly as good as raw I/O on the machines I've
tested (scsi disk) ... I can't readily account for better
buffered read performance.

ananth.

--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Mon May 14 17:58:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F0wkp28527
	for linux-xfs-outgoing; Mon, 14 May 2001 17:58:46 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F0wjF28524
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 17:58:45 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA15299
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 17:57:20 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15194; Tue, 15 May 2001 10:57:27 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA64166;
	Tue, 15 May 2001 10:57:25 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105151057.ZM90057@wobbly.melbourne.sgi.com>
Date: Tue, 15 May 2001 10:57:24 -0500
In-Reply-To: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>
        "Direct I/O question: How to get dioinfo using ioctl?" (May 14,  3:04pm)
References: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Rosenthal, Eric S." <Eric.S.Rosenthal@disney.com>,
   "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Direct I/O question: How to get dioinfo using ioctl?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 14,  3:04pm, Rosenthal, Eric S. wrote:
> Subject: Direct I/O question: How to get dioinfo using ioctl?
> 
> returns an error.  I'm looking for a command that does the same thing as
> fcntl(fileDescriptor, F_DIOINFO, &dioinfo) does on IRIX.

FWIW (now that the problem is resolved), the xfs_mkfile.c
code below xfsprogs was just what you were after here.

> 
> #include <stdio.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <sys/timeb.h>
> #include <errno.h>
> #include <assert.h>
> #include <errno.h>
> 

I'd also suggest replacing the next 4/5 lines with <xfs/libxfs.h>

> #include <xfs/xfs_fs.h>
> 
> #include <fcntl.h>
> #define O_DIRECT 040000

  ^... cos this line in particular is evil.  ;-)

> #define O_RDONLY        0
> 
> extern int errno;
> ...


cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Mon May 14 18:52:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F1qSc29725
	for linux-xfs-outgoing; Mon, 14 May 2001 18:52:28 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F1qQF29722
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 18:52:26 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4F1qMv27464
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:52:23 +0800
Received: from kalapati ([203.167.26.156]) by sisa.i-manila.com.ph ; Tue, 15 May 2001 09:52:24 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 7710446A1A6
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:52:15 +0800 (PHT)
Date: Tue, 15 May 2001 09:52:15 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved
In-Reply-To: <Pine.LNX.4.33.0105150820450.16452-100000@vimfuego.saarinen.org>
Message-ID: <Pine.LNX.4.21.0105150948440.434-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 15 May 2001 at 08:30, Juha Saarinen wrote:
> You might want to experiment with the -a(n), -A1, -W1 flags too. Just
> plain -c1 is probably a tiny bit quicker than -c3 (but it might not
> work with your chip set).

hdparm's -W1 flag turns on the hard drive's write-cacheing, which speeds
things up, but makes unclean power downs more dangerous. Does anyone know
how XFS will handle such an event? While on the ReiserFS mailing list
awhile back, I was under the impression that this could do wonderful
damage to the filesystem, although I don't know how things are now. But
then XFS seems to be infinitely more stable than ReiserFS, and the on-disk
format is much more mature, so maybe (I hope) it handles things
differently.

Also, would anyone know how to force the drive to flush its write-cache
onto disk, like sync makes linux flush its buffers?

 --> Jijo

---
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Mon May 14 19:09:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F291p30072
	for linux-xfs-outgoing; Mon, 14 May 2001 19:09:01 -0700
Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F28xF30069
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:08:59 -0700
Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com
          (InterMail vM.4.01.02.00 201-229-116) with SMTP
          id <20010515020858.HFZS4073.mail.rdc1.tn.home.com@CX376762B>
          for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:08:58 -0700
Message-ID: <001901c0dce3$bc8f03b0$98520c18@CX376762B>
Reply-To: "Tom Browder" <TBrowder@home.com>
From: "Tom Browder" <tbrowder@home.com>
To: <linux-xfs@oss.sgi.com>
References: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com> <10105151057.ZM90057@wobbly.melbourne.sgi.com>
Subject: Tar
Date: Mon, 14 May 2001 21:07:04 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I read the FAQ about dump, etc., but how about tar (GNU)?
Can I count on
a successful transfer of a tarball (*.tgz, with subdirs) on
an xfs partition to a non-xfs
partition on another architecture (or the same
architecture)?

Thanks.

Tom Browder


From owner-linux-xfs@oss.sgi.com Mon May 14 19:12:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F2CK430126
	for linux-xfs-outgoing; Mon, 14 May 2001 19:12:20 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F2CIF30122
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:12:19 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 14zUJi-0005tk-00; Tue, 15 May 2001 14:12:06 +1200
Date: Tue, 15 May 2001 14:12:06 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved
In-Reply-To: <Pine.LNX.4.21.0105150948440.434-100000@kalapati.jijo.local>
Message-ID: <Pine.LNX.4.33.0105151407370.18579-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 15 May 2001, Federico Sevilla III wrote:

> hdparm's -W1 flag turns on the hard drive's write-cacheing, which speeds
> things up, but makes unclean power downs more dangerous. Does anyone know
> how XFS will handle such an event? While on the ReiserFS mailing list
> awhile back, I was under the impression that this could do wonderful
> damage to the filesystem, although I don't know how things are now. But
> then XFS seems to be infinitely more stable than ReiserFS, and the on-disk
> format is much more mature, so maybe (I hope) it handles things
> differently.

Write-caching for drives is inherently dangerous, but how dangerous
depends on how the drive itself is designed. This issue was recently
discussed at huge length on the FreeBSD-stable list, with some people
advocating that your data would never be safe with write-caching, whilst
others said it would, depending on the drive, and what precautions you
take.

Some hard drives have large power capacitors which should have enough
juice in them to write out the cache contents to disk when the power goes
out. Doesn't apply to caching SCSI controllers of course.

> Also, would anyone know how to force the drive to flush its write-cache
> onto disk, like sync makes linux flush its buffers?

You can try the hdparm -f paramater, but whether or not it actually forces
the drive to write out the cache is anyone's guess.

-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Mon May 14 19:43:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F2hMD30610
	for linux-xfs-outgoing; Mon, 14 May 2001 19:43:22 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F2hKF30607
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:43:20 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4F2hII15985;
	Mon, 14 May 2001 21:43:18 -0500 (CDT)
Message-ID: <3B009856.6CDCE46@sgi.com>
Date: Mon, 14 May 2001 21:45:42 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: root <ssfb@myrealbox.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: patch
References: <359C17F9.443B638@myrealbox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

root wrote:
> 
> I've downloaded the patch for the 2.4.2 kernel, after doing the patch
> ant trying to compile the kernel, the XFS support did not show. So, what
> can I do?

You need both the linux-2.4-xfs patch and the linux-2.4.2-core patch.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 14 19:55:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F2tpP31186
	for linux-xfs-outgoing; Mon, 14 May 2001 19:55:51 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F2toF31183
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:55:50 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA07398
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 20:06:46 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA1817024; Mon, 14 May 2001 21:54:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA55434; Mon, 14 May 2001 21:54:32 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4F2ufd20620; Mon, 14 May 2001 21:56:41 -0500
Message-Id: <200105150256.f4F2ufd20620@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved 
In-Reply-To: Message from Federico Sevilla III <jijo@i-manila.com.ph> 
   of "Tue, 15 May 2001 09:52:15 +0800." <Pine.LNX.4.21.0105150948440.434-100000@kalapati.jijo.local> 
Date: Mon, 14 May 2001 21:56:41 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tue, 15 May 2001 at 08:30, Juha Saarinen wrote:
> > You might want to experiment with the -a(n), -A1, -W1 flags too. Just
> > plain -c1 is probably a tiny bit quicker than -c3 (but it might not
> > work with your chip set).
> 
> hdparm's -W1 flag turns on the hard drive's write-cacheing, which speeds
> things up, but makes unclean power downs more dangerous. Does anyone know
> how XFS will handle such an event? While on the ReiserFS mailing list
> awhile back, I was under the impression that this could do wonderful
> damage to the filesystem, although I don't know how things are now. But
> then XFS seems to be infinitely more stable than ReiserFS, and the on-disk
> format is much more mature, so maybe (I hope) it handles things
> differently.

If write caching is enabled on drives under XFS then this could
definitely cause problems should the cache not make it out to disk.

XFS and other journalling filesystems tend to rely on write ordering
constraints to maintain consistancy. So we write metadata into the
journal and only once we know the data is on disk in the journal
do we allow the actual metadata out to disk, we do not impose any
constraints on the ordering of writes of the actual metadata.

So say we allocate a new file and place it in a directory. This
involves modifying the data structures which contain free inodes,
the directory blocks, and the inode itself. Plus possibly other
data structures if we need to allocate space for any of this.

If we write all this to the log and the disk system reports it is
on disk, we allow the metadata to go out to disk. Say the directory
blocks make it out to disk, then we crash. If the drive had write
caching on, and had decided in its infinite wisdom to keep the log
in cache, but to flush through the directory write because that is
where the disk head happened to be, we have a corrupt filesystem.

Now if you are happy that you have a disk system which can get all
the data out to disk on power failure then use write caching. But
remember that most modern drives were designed for an operating
system which when coming up from a crash or power problem gives
you the message 'Your filesystems did not appear to have been
cleanly shutdown, next time please shutdown your computer before
turning it off'.


Steve



From owner-linux-xfs@oss.sgi.com Mon May 14 19:58:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F2w2L31341
	for linux-xfs-outgoing; Mon, 14 May 2001 19:58:02 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F2w1F31338
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 19:58:01 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA02139
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 20:08:57 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id TAA09860;
	Mon, 14 May 2001 19:56:44 -0700 (PDT)
Date: Mon, 14 May 2001 19:55:59 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Tom Browder <tbrowder@home.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Tar
In-Reply-To: <001901c0dce3$bc8f03b0$98520c18@CX376762B>
Message-ID: <Pine.LNX.4.33.0105141955460.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I read the FAQ about dump, etc., but how about tar (GNU)?
> Can I count on
> a successful transfer of a tarball (*.tgz, with subdirs) on
> an xfs partition to a non-xfs
> partition on another architecture (or the same
> architecture)?

tar works fine...no caveats.

-tduffy


From owner-linux-xfs@oss.sgi.com Mon May 14 20:47:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F3l4v31981
	for linux-xfs-outgoing; Mon, 14 May 2001 20:47:04 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F3l3F31978
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 20:47:03 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id UAA08252
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 20:57:54 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA87611
	for linux-xfs@oss.sgi.com; Tue, 15 May 2001 13:45:41 +1000 (EST)
Date: Tue, 15 May 2001 13:45:41 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105150345.NAA87611@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - mkfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Date:  Mon May 14 20:43:23 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94884a
cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.12
	- merge Glen's IRIX change - -d agsize=/su=/sw= (AG, stripe
	  unit/width size) and dynamic configuration of default log
	  size.

cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.5
	- updates for changes to mkfs:
	  - merge support for -d agsize=/su=/sw= (AG, stripe unit/width
	  size)
	  - merge support for dynamic configuration of default log size
	  - fix coupla typos.

cmd/xfsprogs/include/xfs_mount.h - 1.3
	- noop for userspace, sync with kernel.

cmd/xfsprogs/include/xfs_ag.h - 1.2
	- sync with kernel, required for current mkfs change -
	  XFS_AG_BEST_BLOCKS macro changed slightly.

cmd/xfsprogs/VERSION - 1.17
cmd/xfsprogs/doc/CHANGES - 1.19
cmd/xfsprogs/debian/changelog - 1.14
	- bump revision number, document updates for 1.2.6.


From owner-linux-xfs@oss.sgi.com Mon May 14 21:14:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F4Ess32403
	for linux-xfs-outgoing; Mon, 14 May 2001 21:14:54 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F4ErF32399
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 21:14:53 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA04619
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 21:13:28 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA17238
	for linux-xfs@oss.sgi.com; Tue, 15 May 2001 14:13:34 +1000 (EST)
Date: Tue, 15 May 2001 14:13:34 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105150413.OAA17238@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - xfsrestore and suid files
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This fixes the problem with xfsrestore not restoring the suid or guid
modes on a file.
It occurred because a chown was done after the chmod when restoring
the files and the chown was clearing these mode bits even running as root.
On IRIX, as root, this is not the case.
The Linux man page indicates that this behavior for root is dependent
on the kernel version. 
Anyway, I have changed the ordering so that the chown is done before
the chmod and test 056 now passes.

--Tim

Date:  Mon May 14 21:05:35 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94886a
cmd/xfstests/056 - 1.1
	- Test out that the modes of suid,guid,sticky are restored as well on
	  files and directories.

cmd/xfstests/056.out - 1.1
	- output for 056 - does an ls -l comparison of permissions.

cmd/xfsdump/restore/tree.c - 1.4
	- Make chown come before chmod so that suid and guid bits are not cleared
	  when restoring directories.

cmd/xfsdump/common/arch_xlate.c - 1.4
	- Add some diags for ino and mode on bstat translation.

cmd/xfsdump/restore/content.c - 1.7
	- Make chown come before chmod so that suid and guid bits are not cleared
	  when restoring regular files.

cmd/xfstests/group - 1.9
	- Add 056.

cmd/xfstests/common.dump - 1.7
	- Add code to create directories and files with given permissions.



From owner-linux-xfs@oss.sgi.com Mon May 14 21:50:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F4o0500410
	for linux-xfs-outgoing; Mon, 14 May 2001 21:50:00 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F4nxF00406
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 21:49:59 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4F4kgw07653;
	Mon, 14 May 2001 23:46:42 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Mon, 14 May 2001 23:46:42 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance issue solved 
In-Reply-To: <200105150256.f4F2ufd20620@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105142345310.7573-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is agreed, about the -W1 flag. Wouldn't asynchronous IO solve this
though?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com




From owner-linux-xfs@oss.sgi.com Mon May 14 22:01:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F51g600563
	for linux-xfs-outgoing; Mon, 14 May 2001 22:01:42 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F51gF00560
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 22:01:42 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA08381
	for <linux-xfs@oss.sgi.com>; Mon, 14 May 2001 22:12:36 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA65144
	for linux-xfs@oss.sgi.com; Tue, 15 May 2001 15:00:09 +1000 (EST)
Date: Tue, 15 May 2001 15:00:09 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105150500.PAA65144@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - xfsdump
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 14 21:59:22 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:94893a
cmd/xfsdump/VERSION - 1.9
cmd/xfsdump/doc/CHANGES - 1.10
cmd/xfsdump/debian/changelog - 1.6
	- bump version number, document restore mode bits fix,
	  debian build depends fix.

cmd/xfsdump/debian/control - 1.5
	- add build dependency on a more recent xfslibs-dev version.       



From owner-linux-xfs@oss.sgi.com Tue May 15 00:34:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F7YhM03618
	for linux-xfs-outgoing; Tue, 15 May 2001 00:34:43 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F7YMF03613
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 00:34:26 -0700
Received: [from blizbor.ima.pl (jurek.primark.gdansk.tpnet.pl [195.117.150.37])
                               by ima.pl with ESMTP id f4F6nwZ26310
                               for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 08:49:59 +0200]
Message-Id: <5.0.0.25.0.20010515093330.023bbeb0@olo.ima.pl>
X-Sender: blizbor@olo.ima.pl
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 15 May 2001 09:38:21 +0200
To: <linux-xfs@oss.sgi.com>
From: Blizbor <tb670725@ima.pl>
Subject: Re: Tar
In-Reply-To: <001901c0dce3$bc8f03b0$98520c18@CX376762B>
References: <99A560B38BC6D21180020004ACA6B36A031FAF64@ds-naso-msa2.wds.disney.com>
 <10105151057.ZM90057@wobbly.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 5/15/01 04:07 AM, you wrote:
>I read the FAQ about dump, etc., but how about tar (GNU)?
>Can I count on
>a successful transfer of a tarball (*.tgz, with subdirs) on
>an xfs partition to a non-xfs
>partition on another architecture (or the same
>architecture)?

Tar works between almost everything. You can create *.tar on SCO UNIX,
and then untar this file on HP-UX, AIX, Digital UNIX or whatever you want
(and have at least posix compliant implementation of tar). Regardless of
processor type used (ia32, Risc, PowerPC), regardless of filesystem type.
Years ago I was working in sux heavy mixed environment. No problems at all
(with tar of course :)) ). There are implementations of the tar for MS Windows
and MS DOS.

Regards,
Blizbor


From owner-linux-xfs@oss.sgi.com Tue May 15 01:39:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F8dL204657
	for linux-xfs-outgoing; Tue, 15 May 2001 01:39:21 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F8dJF04654
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 01:39:19 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA03926
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:39:14 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id KAA20610
	for linux-xfs@oss.sgi.com; Tue, 15 May 2001 10:39:14 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP id CEE5E57306
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:48:22 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP id E902625837
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:49:28 +0200 (CEST)
Message-ID: <3B00EC32.7A1BA16A@ch.sauter-bc.com>
Date: Tue, 15 May 2001 10:43:30 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: xfs on small memory
References: <Pine.LNX.4.33.0105121852211.300-100000@dbear.engr.sgi.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I made the lowmem test with my test machine. It is a pentium 200 and
I used 12MB of ram. The disks are two Quantum Fireballs 15GB with DMA
enabled. The disks have 3 partitions each configured as RAID 1.
/dev/md0 /boot  (50M)
/dev/md2 /      (14G)
/dev/md1 swap   (500M)

The RAID /dev/md2 was syncing while I ran hevy NFS and disk to disk
copy traffic and I updated some RPMS. Everything worked very fine!!!
No crash, no endless swapping.
The same test with only 8MB ram was a pain because lack of ressources.

Tom Duffy schrieb:
> 
> I was wondering what the smallest memory system somebody has tried XFS
> on.  The webpage says 64MB minimum and I know that I have seen XFS working
> on 64MB, but I was wondering, will 32MB be ok?  How about 16MB w/ swap?
> 
> Ananth told me that the recovery was the most memory intensive part...so,
> I would like to know if anybody has gone through a recovery on a low
> memory system and things have been OK...or not?
> 
> thanks,
> 
> -tduffy

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Tue May 15 02:47:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4F9l7a05925
	for linux-xfs-outgoing; Tue, 15 May 2001 02:47:07 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4F9l4F05922
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 02:47:04 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id LAA1156434;
	Tue, 15 May 2001 11:47:01 +0200
Message-Id: <3.0.6.32.20010515114656.007b0e60@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 15 May 2001 11:46:56 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: XFS & Kickstart installation
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B003E4A.FA627E01@sgi.com>
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
 <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 15:21 14/05/2001 -0500, Eric Sandeen wrote:
>werner maes wrote:
>
>> I've done another test on a machine without hardware RAID (my first tests
>> were done on a machine
>> with a hardware RAID controller). I get a similar error: "Error mounting
>> device sda1 as /: No such
>> device. This most likely means that the partition has not been formatted."
>
>Not sure what's going on here, I tried a kickstart install on scsi
>drives (disabled the IDE controller for the HD, the CDROM was still
>enabled) and it worked just fine.  I tried a combination of ext2 and xfs
>filesystems, that worked too.  I don't have any RAID device to test it
>on.

Did you have your partitions already created with XFS? Or did you use a
"clean" disk?
Could you try to add "clearpart --all" to your configuration?
I've tried your ks.cfg but I still get the same error. I get the messages:
"Formatting
/, formatting /usr, formatting /home, ... but these commands don't take
much time. Therefore
I presume that the formatting has not been done correctly.

Below is my ks.cfg file which works fine with RH 7.1 but not with SGI
installer.
I did not add '--fs xfs' because XFS is the default.

auth --useshadow --enablemd5
clearpart --all
install
cdrom
keyboard us
lang en_US
lilo --location mbr
mouse genericps/2
network --bootproto dhcp 
part /tmp --size 500 
part /var --size 500 
part / --size 800 
part swap --size 128 
part /usr --size 1000 
part /home --size 500 --grow 
reboot
rootpw testtest 
timezone Europe/Brussels
%packages
@ Server



From owner-linux-xfs@oss.sgi.com Tue May 15 05:03:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FC3J809792
	for linux-xfs-outgoing; Tue, 15 May 2001 05:03:19 -0700
Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FC3CF09785
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 05:03:18 -0700
Received: from ua.pt (mail.ua.pt [193.136.80.80])
	by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 699CF97C35
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:02:54 +0100 (WEST)
Received: from [193.137.83.80] (HELO netvisao.pt)
  by ua.pt (CommuniGate Pro SMTP 3.4.4)
  with ESMTP id 8503431 for linux-xfs@oss.sgi.com; Tue, 15 May 2001 13:02:55 +0100
Message-ID: <3B011CD1.E45AD4B4@netvisao.pt>
Date: Tue, 15 May 2001 13:10:57 +0100
From: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ML do XFS <linux-xfs@oss.sgi.com>
Subject: For when a new stable release?
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

First of all, my congratulations to the people who worked for bringing
XFS to Linux.
You've done a man's job.

I'm using it now in my /home in an intensive use Samba server and i'm
quite happy with it.

Yet, i'm sad because of the bug(?) which makes ACLs support unuseful.
Am i right?

When there will be a new stable release that fixes it?
I presume the fix is on CVS, but i'd rather wait for the next stable
release in which, i presume, that problem will disappear.

BTW, when that day comes, i suppose i won't have to re-format the
partition, right?
Just compile the kernel with that new release and things will work well,
right?

Thank you.

Mário Gamito
pt is for Portugal

From owner-linux-xfs@oss.sgi.com Tue May 15 05:36:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FCar310602
	for linux-xfs-outgoing; Tue, 15 May 2001 05:36:53 -0700
Received: from smtprelay.ua.pt (smtprelay.ua.pt [193.136.80.103])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FCapF10599
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 05:36:51 -0700
Received: from ua.pt (mail.ua.pt [193.136.80.80])
	by smtprelay.ua.pt (Sendmail-smtprelay) with ESMTP id 31D6B97DF8
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:36:48 +0100 (WEST)
Received: from [193.137.83.80] (HELO netvisao.pt)
  by ua.pt (CommuniGate Pro SMTP 3.4.4)
  with ESMTP id 8503886 for linux-xfs@oss.sgi.com; Tue, 15 May 2001 13:36:49 +0100
Message-ID: <3B0124C3.7E791032@netvisao.pt>
Date: Tue, 15 May 2001 13:44:51 +0100
From: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ML do XFS <linux-xfs@oss.sgi.com>
Subject: gcc / kgcc / egcs
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I' using XFS on SuSE 7.0

I've compiled XFS on kernel 2.4.2 with egcs' rpm that came with SuSE 6.3
(it seems that from that point on they've abandoned it).

Now that i've tried the same for kernel 2.4.3, it seems to expect kgcc
instead.
I'm kinda lost here to tell the truth.

Tips?

Mário Gamito
pt is for Portugal

From owner-linux-xfs@oss.sgi.com Tue May 15 06:26:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FDQ5911643
	for linux-xfs-outgoing; Tue, 15 May 2001 06:26:05 -0700
Received: from walt400.holman.net ([63.228.97.139])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FDQ4F11640
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 06:26:04 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP
	id B4AD340A352; Tue, 15 May 2001 06:35:19 -0700 (PDT)
Message-ID: <3B013096.9050908@uswest.net>
Date: Tue, 15 May 2001 06:35:18 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9+) Gecko/20010513
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS performance issue solved
References: <Pine.LNX.4.33.0105142345310.7573-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That's the way I've always looked at it. I've always thought the -W1 
flag was redudant, as well as a bit dangerous. If you've already enabled 
asynchrounous access, you have "lazy" writes from the kernel. The only 
other thing I've got to add, is that the only time I've had FS 
corruption problems using XFS is when I experimented with -W1 and had an 
unclean shutdown. Not worth it in my opinion.

-Walt


Austin Gonyou wrote:

>This is agreed, about the -W1 flag. Wouldn't asynchronous IO solve this
>though?
>



From owner-linux-xfs@oss.sgi.com Tue May 15 06:29:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FDTPv11711
	for linux-xfs-outgoing; Tue, 15 May 2001 06:29:25 -0700
Received: from arago5.tn.utwente.nl (root@arago5.tn.utwente.nl [130.89.70.125])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FDTOF11708
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 06:29:24 -0700
Received: (from marten@localhost)
	by arago5.tn.utwente.nl (8.9.3/8.9.3/Debian 8.9.3-21) id PAA27086
	for linux-xfs@oss.sgi.com; Tue, 15 May 2001 15:29:20 +0200
Date: Tue, 15 May 2001 15:29:20 +0200
From: Marten van Wezel <marten@arago.utwente.nl>
To: linux-xfs@oss.sgi.com
Subject: Bad blocks handling?
Message-ID: <20010515152920.B26867@arago5.tn.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sir,

Does XFS support Bad blocks handling? I am browsing the web for quite a while
now but I can't find any reference to how XFS behaves under less then optimal
hardware conditions?

What happens when a block on a drive is physically bad, what happens when
a scsicable is badly connected, etc etc?

Are there provisions in XFS for this type of problems (mapping out bad blocks
or perhaps even on-the-fly adjustments) or do we simply have to hope that
the hardware itself is flawless?

-Marten van Wezel

From owner-linux-xfs@oss.sgi.com Tue May 15 06:37:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FDbKh11850
	for linux-xfs-outgoing; Tue, 15 May 2001 06:37:20 -0700
Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FDbGF11843
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 06:37:17 -0700
Received: (from kszysiu@localhost)
	by main.braxis.co.uk (8.9.3/8.9.3) id PAA12019;
	Tue, 15 May 2001 15:36:24 +0200
Date: Tue, 15 May 2001 15:36:23 +0200
From: Krzysztof Rusocki <kszysiu@braxis.co.uk>
To: =?iso-8859-1?Q?M=E1rio_Gamito?= <mg-listas@netvisao.pt>
Cc: linux-xfs@oss.sgi.com
Subject: Re: gcc / kgcc / egcs
Message-ID: <20010515153623.A11399@main.braxis.co.uk>
References: <3B0124C3.7E791032@netvisao.pt>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B0124C3.7E791032@netvisao.pt>; from mg-listas@netvisao.pt on Tue, May 15, 2001 at 01:44:51PM +0100
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi Mario,

Just comment out line in linux/Makefile that mentions
about kgcc  and uncomment line  with egcs.

#CC             = $(CROSS_COMPILE)gcc -V egcs-2.91.66

this should be uncommented ^^^^

that should make it work... i think..

Cheers,
Krzysztof

On Tue, May 15, 2001 at 01:44:51PM +0100, Mário Gamito wrote:
> Hi!
> 
> I' using XFS on SuSE 7.0
> 
> I've compiled XFS on kernel 2.4.2 with egcs' rpm that came with SuSE 6.3
> (it seems that from that point on they've abandoned it).
> 
> Now that i've tried the same for kernel 2.4.3, it seems to expect kgcc
> instead.
> I'm kinda lost here to tell the truth.
> 
> Tips?
> 
> Mário Gamito
> pt is for Portugal

From owner-linux-xfs@oss.sgi.com Tue May 15 07:15:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FEFZ612811
	for linux-xfs-outgoing; Tue, 15 May 2001 07:15:35 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FEFYF12808
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 07:15:34 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDD00BFSRKWOC@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue,
 15 May 2001 09:15:09 -0500 (CDT)
Date: Tue, 15 May 2001 10:14:15 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: For when a new stable release?
In-reply-to: <3B011CD1.E45AD4B4@netvisao.pt>
To: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Cc: ML do XFS <linux-xfs@oss.sgi.com>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010515101415.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 8BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


On 15-May-2001 Mário Gamito wrote:
> Hi!
> 
> First of all, my congratulations to the people who worked for bringing
> XFS to Linux.
> You've done a man's job.
> 
> I'm using it now in my /home in an intensive use Samba server and i'm
> quite happy with it.
> 
> Yet, i'm sad because of the bug(?) which makes ACLs support unuseful.
> Am i right?

Which bug is this?

1. The inode eating bug

This is caused by a (fixed) bug in the .../linux/fs/posix_acl.c file. I could
send you a patch for just this bug if you are interested. (You would need to
recompile the kernel afterwards of course).

2. The umask/default acl bug

This bug involves several files (5 I think).  Again, I have cut out just this
change as a patch and could send it to you.  You can get around this bug on
your Samba server, I think, by setting your umask to 777, the default ACL to 
rwxrwxrwx and then letting Samba control the permissions with 'create mask' and
'create mode'. 

> 
> When there will be a new stable release that fixes it?
> I presume the fix is on CVS, but i'd rather wait for the next stable
> release in which, i presume, that problem will disappear.


The fixes are in the CVS tree.  It's up to the SGI folks to determine when the
next release will be.

There are also some fixes in the Samba CVS tree that should make XFS ACL
support more useful. 
 
> BTW, when that day comes, i suppose i won't have to re-format the
> partition, right?

Did you reformat the partition to support XFS this time?  If you have already
formatted the partition to be XFS, I think it would be pretty unlikely you will
need to reformat later.  From what I can gather, the IRIX XFS format has been
around long enough that they (SGI) want to maintain the format.

> Just compile the kernel with that new release and things will work well,
> right?

Well.... XFS will work well.  As for the rest of the kernel..... YMMV ;->

> Thank you.
> 
> Mário Gamito
> pt is for Portugal

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Tue May 15 07:20:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FEKLZ12875
	for linux-xfs-outgoing; Tue, 15 May 2001 07:20:21 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FEKLF12872
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 07:20:21 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4FEKCr13652;
	Tue, 15 May 2001 09:20:12 -0500 (CDT)
Message-ID: <3B013BB2.8282698A@sgi.com>
Date: Tue, 15 May 2001 09:22:42 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS & Kickstart installation
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
	 <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be> <3.0.6.32.20010515114656.007b0e60@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

werner maes wrote:

> Did you have your partitions already created with XFS? Or did you use a
> "clean" disk?

I tried it both ways.  I also tried it with and without "--fs xfs"

> Could you try to add "clearpart --all" to your configuration?

Sure thing, I'll let you know.

> I've tried your ks.cfg but I still get the same error. I get the messages:
> "Formatting
> /, formatting /usr, formatting /home, ... but these commands don't take
> much time. Therefore
> I presume that the formatting has not been done correctly.

Formatting an XFS partition is MUCH quicker than formatting an ext2
partition.

-Eric
 

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 07:30:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FEU0713093
	for linux-xfs-outgoing; Tue, 15 May 2001 07:30:00 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FETxF13090
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 07:29:59 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4FETub27165;
	Tue, 15 May 2001 09:29:56 -0500 (CDT)
Message-ID: <3B013DF9.59C1E8DA@sgi.com>
Date: Tue, 15 May 2001 09:32:25 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Marten van Wezel <marten@arago.utwente.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Bad blocks handling?
References: <20010515152920.B26867@arago5.tn.utwente.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Marten van Wezel wrote:

> Does XFS support Bad blocks handling? I am browsing the web for quite a while
> now but I can't find any reference to how XFS behaves under less then optimal
> hardware conditions?
> 
> What happens when a block on a drive is physically bad, what happens when
> a scsicable is badly connected, etc etc?
> 
> Are there provisions in XFS for this type of problems (mapping out bad blocks
> or perhaps even on-the-fly adjustments) or do we simply have to hope that
> the hardware itself is flawless?

>From the archives:

> > Does anybody know how xfs handles "just appeared" badblocks? If even...
> > How to inform xfs about badblocks (if that's possible) to let xfs avoid them
> > or just kiss hdd goodbye

> A feature just went into XFS which is shutdown on error, which basically
> means that if we get a metadata I/O error the filesystem gets shutdown,
> all processes in the filesystem get errored out of their system calls,
> and you get to type unmount somewhere.

> Steve


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 07:33:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FEXdP13194
	for linux-xfs-outgoing; Tue, 15 May 2001 07:33:39 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FEXcF13188
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 07:33:38 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zftD-000743-00; Tue, 15 May 2001 16:33:31 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FEWLn30495;
	Tue, 15 May 2001 10:32:21 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Paul Rossman <paulr@evanston.fluent.com>
Cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: DAC960 and XFS blocksize error
References: <3B0038A6.4DBEB316@evanston.fluent.com>
	<yq1lmnzy8lv.fsf@jcb.mkp.net> <3B00458A.D65EC50F@sgi.com>
	<3B004AC6.1F3DA0EE@evanston.fluent.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 10:32:21 -0400
In-Reply-To: <3B004AC6.1F3DA0EE@evanston.fluent.com>
Message-ID: <yq1k83id6oa.fsf@jcb.mkp.net>
Lines: 23
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Paul" == Paul Rossman <paulr@evanston.fluent.com> writes:

Paul> Thanks for the patch. I saw the boot stuff from a few days
Paul> ago... and I also had those problems, but I didn't need to boot
Paul> with an xfs disk so just used the rh71 disks to install... I
Paul> didn't get the connection :)

Ah, ok.


Paul> Should I go ahead and patch the kernel, reboot, then reformat
Paul> the disk?  Could there be a side effect from having the disk
Paul> formatted from the old kernel and using the patched one?

Well.  If you can mount the filesystem after a reboot, you've been
lucky and the superblock ended up in the right spot.

Otherwise you'll have to resort to mkfs.xfs.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 07:45:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FEjbc13459
	for linux-xfs-outgoing; Tue, 15 May 2001 07:45:37 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FEjaF13456
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 07:45:36 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4FEjWr26245;
	Tue, 15 May 2001 09:45:32 -0500 (CDT)
Message-ID: <3B0141A2.856A2D30@sgi.com>
Date: Tue, 15 May 2001 09:48:02 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Marten van Wezel <marten@arago.utwente.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Bad blocks handling?
References: <20010515152920.B26867@arago5.tn.utwente.nl> <3B013DF9.59C1E8DA@sgi.com> <20010515163445.D26867@arago5.tn.utwente.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Marten van Wezel wrote:
> 
> Thank you for your speedy reply, I just have one more question which is
> 'what's next?' when that shutdown would happen? Can XFS map out or
> otherwise work around the hard disk error, or is the only way to
> proceed to use the system replacing drives and recreating?

We don't have a method for actually mapping & tracking bad blocks.

Most new drives have something called S.M.A.R.T. which is supposed to
keep track of bad blocks internally to the drive, and move things around
as necessary.

(see http://csl.cse.ucsc.edu/smart.shtml)

This tool should help you know when your drive is going bad, so you can
replace it before errors happen.  By the time the filesystem actually
starts seeing bad blocks, (i.e. the drive can no longer cope) I think
it's time to replace the drive, regardless of the filesystem you're
using.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 08:19:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FFJG113945
	for linux-xfs-outgoing; Tue, 15 May 2001 08:19:16 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FFJEF13942
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 08:19:15 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FFH5l11169;
	Tue, 15 May 2001 10:17:05 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 10:17:04 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: John Trostel <jtrostel@connex.com>
cc: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>,
   ML do XFS <linux-xfs@oss.sgi.com>
Subject: RE: For when a new stable release?
In-Reply-To: <XFMail.20010515101415.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.33.0105151011410.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

One thing I think he's thinking about, when it comes to acl setting is
something like this:

server[/home/userx]#>chacl u:5:,g:4:,o:0: somefile
server[/home/userx]#>exit
server[/home/userx]$>chmod 777 somefile
server[/home/userx]$>ls -l somefile
-rwxrwxrwx    1 userx   userx     72178 May  15 10:25 somefile

server[/home/userx]$>


I don't quite understand here. What good is setting ACLs on files if they
don't stick? Aside from that, that's my only gripe. I need to go do some
testing with directories next. :)

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 15 May 2001, John Trostel wrote:

>
> On 15-May-2001 Mário Gamito wrote:
> > Hi!
> >
> > First of all, my congratulations to the people who worked for bringing
> > XFS to Linux.
> > You've done a man's job.
> >
> > I'm using it now in my /home in an intensive use Samba server and i'm
> > quite happy with it.
> >
> > Yet, i'm sad because of the bug(?) which makes ACLs support unuseful.
> > Am i right?
>
> Which bug is this?
>
> 1. The inode eating bug
>
> This is caused by a (fixed) bug in the .../linux/fs/posix_acl.c file. I could
> send you a patch for just this bug if you are interested. (You would need to
> recompile the kernel afterwards of course).
>
> 2. The umask/default acl bug
>
> This bug involves several files (5 I think).  Again, I have cut out just this
> change as a patch and could send it to you.  You can get around this bug on
> your Samba server, I think, by setting your umask to 777, the default ACL to
> rwxrwxrwx and then letting Samba control the permissions with 'create mask' and
> 'create mode'.
>
> >
> > When there will be a new stable release that fixes it?
> > I presume the fix is on CVS, but i'd rather wait for the next stable
> > release in which, i presume, that problem will disappear.
>
>
> The fixes are in the CVS tree.  It's up to the SGI folks to determine when the
> next release will be.
>
> There are also some fixes in the Samba CVS tree that should make XFS ACL
> support more useful.
>
> > BTW, when that day comes, i suppose i won't have to re-format the
> > partition, right?
>
> Did you reformat the partition to support XFS this time?  If you have already
> formatted the partition to be XFS, I think it would be pretty unlikely you will
> need to reformat later.  From what I can gather, the IRIX XFS format has been
> around long enough that they (SGI) want to maintain the format.
>
> > Just compile the kernel with that new release and things will work well,
> > right?
>
> Well.... XFS will work well.  As for the rest of the kernel..... YMMV ;->
>
> > Thank you.
> >
> > Mário Gamito
> > pt is for Portugal
>
>


From owner-linux-xfs@oss.sgi.com Tue May 15 09:09:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FG9mx14993
	for linux-xfs-outgoing; Tue, 15 May 2001 09:09:48 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FG9kF14990
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:09:46 -0700
Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA01017
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:20:40 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234])
	by nodin.corp.sgi.com (8.11.2/8.11.2/nodin-1.0) with ESMTP id f4FG8h115305459
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:08:43 -0700 (PDT)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id JAA66462;
	Tue, 15 May 2001 09:07:18 -0700 (PDT)
Date: Tue, 15 May 2001 09:06:32 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: John Trostel <jtrostel@connex.com>
cc: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>,
   ML do XFS <linux-xfs@oss.sgi.com>
Subject: RE: For when a new stable release?
In-Reply-To: <XFMail.20010515101415.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.33.0105150859260.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> > BTW, when that day comes, i suppose i won't have to re-format the
> > partition, right?
>
> Did you reformat the partition to support XFS this time?  If you have already
> formatted the partition to be XFS, I think it would be pretty unlikely you will
> need to reformat later.  From what I can gather, the IRIX XFS format has been
> around long enough that they (SGI) want to maintain the format.

the XFS format will stay the same forever (at least the foreseeable
future)...there are certain portions which could change version, but the
old versions would still be supported.  like the directory format on linux
defaults to version 2 where on irix, it uses v1.  but, you should be able
to use both in linux and irix.

-tduffy


From owner-linux-xfs@oss.sgi.com Tue May 15 09:35:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FGZig15586
	for linux-xfs-outgoing; Tue, 15 May 2001 09:35:44 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FGZhF15583
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:35:43 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FGX0H11608
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 11:33:01 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 11:33:00 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Stopping/deactivating volume groups
Message-ID: <Pine.LNX.4.33.0105151132110.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

How do I do this? I wanna blow away all my volgroups and start over...I
can' find it. Aaah..:)

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Tue May 15 09:42:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FGgMH15757
	for linux-xfs-outgoing; Tue, 15 May 2001 09:42:22 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FGgLF15754
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:42:22 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDD00KLAYDYJM@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue,
 15 May 2001 11:41:59 -0500 (CDT)
Date: Tue, 15 May 2001 12:41:19 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: For when a new stable release?
In-reply-to: <Pine.LNX.4.33.0105151011410.11093-100000@UberGeek.coremetrics.com>
To: Austin Gonyou <austin@coremetrics.com>
Cc: ML do XFS <linux-xfs@oss.sgi.com>
Cc: ML do XFS <linux-xfs@oss.sgi.com>,
   =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010515124119.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

But you just changed the acl!

1. setup the acl on file 'jt_junk'

[jt@jtsdell xfs_part]$ chacl u::rwx,g::rwx,o::r-x,u:user1:r--,m::rwx jt_junk 

2. look at the 'normal' part of the acl with just 'ls -l'

[jt@jtsdell xfs_part]$ ls -l jt_junk 
-rwxrwxr-x    1 jt       jt              0 May 11 13:36 jt_junk


3. change the 'normal' part of the acl with 'chmod'

[jt@jtsdell xfs_part]$ chmod 777 jt_junk 

4. look at the 'normal' part of the acl with just 'ls -l'

[jt@jtsdell xfs_part]$ ls -l jt_junk 
-rwxrwxrwx    1 jt       jt              0 May 11 13:36 jt_junk

5. look at the entire acl with 'chacl -l'

[jt@jtsdell xfs_part]$ chacl -l jt_junk 
jt_junk [u::rwx,g::rwx,o::rwx,u:user1:r--,m::rwx]

The part of the acl not affected by the 'normal' command 'chmod' is still
there! Just because I have acls enabled on a file system should not mean that I
should be precluded from using the 'normal' tools to work on the files.  That
would break many things!

On 15-May-2001 Austin Gonyou wrote:
> One thing I think he's thinking about, when it comes to acl setting is
> something like this:
> 
> server[/home/userx]#>chacl u:5:,g:4:,o:0: somefile

You should have done an 'ls -l' to see what the permissions were here! I
suspect they would have been 540.

> server[/home/userx]#>exit
> server[/home/userx]$>chmod 777 somefile

Now you've changed the permissions back to 777.

> server[/home/userx]$>ls -l somefile
> -rwxrwxrwx    1 userx   userx     72178 May  15 10:25 somefile


And you see these 777 permissions with ls -l

> I don't quite understand here. What good is setting ACLs on files if they
> don't stick? Aside from that, that's my only gripe. I need to go do some
> testing with directories next. :)

Why should they stick if you have appropriate permission to change them?

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Tue May 15 09:55:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FGt9R16098
	for linux-xfs-outgoing; Tue, 15 May 2001 09:55:09 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FGt8F16095
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 09:55:09 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zi67-0007Bm-00; Tue, 15 May 2001 18:54:59 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FGrnO30663;
	Tue, 15 May 2001 12:53:49 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: Stopping/deactivating volume groups
References: <Pine.LNX.4.33.0105151132110.11093-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 12:53:49 -0400
In-Reply-To: <Pine.LNX.4.33.0105151132110.11093-100000@UberGeek.coremetrics.com>
Message-ID: <yq1itj2blk2.fsf@jcb.mkp.net>
Lines: 11
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> How do I do this? I wanna blow away all my volgroups and start
Austin> over...I can' find it. Aaah..:)

lvremove and vgremove

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 10:10:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHAle16487
	for linux-xfs-outgoing; Tue, 15 May 2001 10:10:47 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHAkF16484
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:10:46 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FH6ou11866;
	Tue, 15 May 2001 12:06:50 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 12:06:50 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Stopping/deactivating volume groups
In-Reply-To: <yq1itj2blk2.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105151206220.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've already removed my volumes..now I try to use vgremove, and it says it
can't stop an active volume group.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 15 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> How do I do this? I wanna blow away all my volgroups and start
> Austin> over...I can' find it. Aaah..:)
>
> lvremove and vgremove
>
>


From owner-linux-xfs@oss.sgi.com Tue May 15 10:11:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHBd916508
	for linux-xfs-outgoing; Tue, 15 May 2001 10:11:39 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHBcF16504
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:11:39 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FH8is11882;
	Tue, 15 May 2001 12:08:44 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 12:08:43 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: John Trostel <jtrostel@connex.com>
cc: ML do XFS <linux-xfs@oss.sgi.com>, ML do XFS <linux-xfs@oss.sgi.com>,
   =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Subject: RE: For when a new stable release?
In-Reply-To: <XFMail.20010515124119.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.33.0105151207340.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I agree with this. but my problem is ACLs should protect. At this point
the file can still be modified/deleted by ANYONE if I chmod 777 that file.
What's the point of ACLs if they don't stop malicios behaviour?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 15 May 2001, John Trostel wrote:

> But you just changed the acl!
>
> 1. setup the acl on file 'jt_junk'
>
> [jt@jtsdell xfs_part]$ chacl u::rwx,g::rwx,o::r-x,u:user1:r--,m::rwx jt_junk
>
> 2. look at the 'normal' part of the acl with just 'ls -l'
>
> [jt@jtsdell xfs_part]$ ls -l jt_junk
> -rwxrwxr-x    1 jt       jt              0 May 11 13:36 jt_junk
>
>
> 3. change the 'normal' part of the acl with 'chmod'
>
> [jt@jtsdell xfs_part]$ chmod 777 jt_junk
>
> 4. look at the 'normal' part of the acl with just 'ls -l'
>
> [jt@jtsdell xfs_part]$ ls -l jt_junk
> -rwxrwxrwx    1 jt       jt              0 May 11 13:36 jt_junk
>
> 5. look at the entire acl with 'chacl -l'
>
> [jt@jtsdell xfs_part]$ chacl -l jt_junk
> jt_junk [u::rwx,g::rwx,o::rwx,u:user1:r--,m::rwx]
>
> The part of the acl not affected by the 'normal' command 'chmod' is still
> there! Just because I have acls enabled on a file system should not mean that I
> should be precluded from using the 'normal' tools to work on the files.  That
> would break many things!
>
> On 15-May-2001 Austin Gonyou wrote:
> > One thing I think he's thinking about, when it comes to acl setting is
> > something like this:
> >
> > server[/home/userx]#>chacl u:5:,g:4:,o:0: somefile
>
> You should have done an 'ls -l' to see what the permissions were here! I
> suspect they would have been 540.
>
> > server[/home/userx]#>exit
> > server[/home/userx]$>chmod 777 somefile
>
> Now you've changed the permissions back to 777.
>
> > server[/home/userx]$>ls -l somefile
> > -rwxrwxrwx    1 userx   userx     72178 May  15 10:25 somefile
>
>
> And you see these 777 permissions with ls -l
>
> > I don't quite understand here. What good is setting ACLs on files if they
> > don't stick? Aside from that, that's my only gripe. I need to go do some
> > testing with directories next. :)
>
> Why should they stick if you have appropriate permission to change them?
>
>


From owner-linux-xfs@oss.sgi.com Tue May 15 10:14:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHEPu16583
	for linux-xfs-outgoing; Tue, 15 May 2001 10:14:25 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHEOF16580
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:14:24 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14ziOt-0007Cw-00; Tue, 15 May 2001 19:14:23 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FHDFe30673;
	Tue, 15 May 2001 13:13:15 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: Stopping/deactivating volume groups
References: <Pine.LNX.4.33.0105151206220.11093-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 13:13:15 -0400
In-Reply-To: <Pine.LNX.4.33.0105151206220.11093-100000@UberGeek.coremetrics.com>
Message-ID: <yq1eltqbkno.fsf@jcb.mkp.net>
Lines: 11
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> I've already removed my volumes..now I try to use vgremove,
Austin> and it says it can't stop an active volume group.

vgchange -a n

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 10:19:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHJCl16734
	for linux-xfs-outgoing; Tue, 15 May 2001 10:19:12 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHJAF16731
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:19:10 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FHGiY12027;
	Tue, 15 May 2001 12:16:44 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 12:16:44 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: John Trostel <jtrostel@connex.com>
cc: ML do XFS <linux-xfs@oss.sgi.com>, ML do XFS <linux-xfs@oss.sgi.com>,
   =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Subject: RE: For when a new stable release?
In-Reply-To: <XFMail.20010515124119.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.33.0105151212390.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Here's another example.

-----begin user test-----
[austin@UberGeek test]$ chacl u::rwx,g::rwx,o::r-x,u:root:r--,m::rwx
somefile
[austin@UberGeek test]$ ls -l
total 4
-rwxrwxr-x    1 austin   austin          0 May 15 12:09 somefile
[austin@UberGeek test]$ chmod 777 somefile
[austin@UberGeek test]$ ls -l
total 4
-rwxrwxrwx    1 austin   austin          0 May 15 12:09 somefile
[austin@UberGeek test]$ chacl -l somefile
somefile [u::rwx,g::rwx,o::rwx,u:root:r--,m::rwx]
[austin@UberGeek test]$ rm somefile
[austin@UberGeek test]$ ls
[austin@UberGeek test]$
-----end user test-----

What good did that do?

So let's do that as root...

-----begin root test-----
[austin@UberGeek test]$ su
Password:
[root@UberGeek test]# chacl u::rwx,g::rwx,o::r-x,u:root:r--,m::rwx
somefile
chacl: error setting access acl on "somefile": No such file or directory
[root@UberGeek test]# touch somefile
[root@UberGeek test]# chacl u::rwx,g::rwx,o::r-x,u:root:r--,m::rwx
somefile
[root@UberGeek test]# ls -l
total 4
-rwxrwxr-x    1 root     root            0 May 15 12:13 somefile
[root@UberGeek test]# chown austin:austin somefile
[root@UberGeek test]# ls -l
total 4
-rwxrwxr-x    1 austin   austin          0 May 15 12:13 somefile
[root@UberGeek test]# exit
[austin@UberGeek test]$ chacl -l somefile
somefile [u::rwx,g::rwx,o::r-x,u:root:r--,m::rwx]
[austin@UberGeek test]$ rm somefile
[austin@UberGeek test]$ ls
-----end root test-----


So what's the point. I still don't see it. I see no strict enforcement of
the ACL. I'm not in the root group, no super powers..just rm. :)


-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Tue May 15 10:35:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHZMp17159
	for linux-xfs-outgoing; Tue, 15 May 2001 10:35:22 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHZLF17156
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:35:21 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDE00BNG0UN1A@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue,
 15 May 2001 12:35:11 -0500 (CDT)
Date: Tue, 15 May 2001 13:34:31 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: For when a new stable release?
In-reply-to: <Pine.LNX.4.33.0105151207340.11093-100000@UberGeek.coremetrics.com>
To: Austin Gonyou <austin@coremetrics.com>
Cc: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Cc: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>,
   ML do XFS <linux-xfs@oss.sgi.com>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010515133431.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Then don't chmod 777 the file.  If the file has been given the ACL
u::rwx,g::rwx,o::rwx,u:user1:r-x,m::rwx then everyone _except_ 'user1' can
delete the file.  If the file had been given
u::rwx,g::rwx,o::r-x,u:user1:rwx,m::rwx, then _only_ the true owner and user1
would be able to delete the file.

Start as root (or someother user who owns a file)
[root@jtsdell xfs_part]# chgrp root jt_junk 
[root@jtsdell xfs_part]# ls -l jt_junk 
-rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk
[root@jtsdell xfs_part]# chacl -l jt_junk
jt_junk []

(There's no ACL defined on this file yet.... lets define one that doesn't allow
'jt' to delete the file... but looks 'normal' to 'ls -l')

[root@jtsdell xfs_part]# chacl u::rwx,g::rwx,o::rwx,u:jt:r-x,m::rwx jt_junk 
[root@jtsdell xfs_part]# chacl -l jt_junk
jt_junk [u::rwx,g::rwx,o::rwx,u:jt:r-x,m::rwx]

See... 'chacl -l' sees the extended permission structure.

[root@jtsdell xfs_part]# ls -l jt_junk 
-rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk

But 'ls -l' does not see it.

[root@jtsdell xfs_part]# exit
exit

Go back to being 'jt'

[jt@jtsdell xfs_part]$ ls -l jt_junk
-rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk

File looks like I (as 'jt') can delete it.  Let's try.

[jt@jtsdell xfs_part]$ rm jt_junk 
rm: remove write-protected file `jt_junk'? y
rm: cannot unlink `jt_junk': Permission denied

Gee Whiz!?! What happened? I've been acl-ized!

On 15-May-2001 Austin Gonyou wrote:
> I agree with this. but my problem is ACLs should protect. At this point
> the file can still be modified/deleted by ANYONE if I chmod 777 that file.
> What's the point of ACLs if they don't stop malicios behaviour?

ACLs are designed to allow you to specify permissions on a finer scale than the
traditional ugo scheme.  You can tailor protection for just  a few users or
groups.
-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Tue May 15 10:36:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHa8M17185
	for linux-xfs-outgoing; Tue, 15 May 2001 10:36:08 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHa7F17182
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:36:07 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA25291
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:34:44 -0700 (PDT)
	mail_from (tduffy@engr.sgi.com)
Received: from dbear.engr.sgi.com (dbear.engr.sgi.com [163.154.18.85])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id KAA07461;
	Tue, 15 May 2001 10:34:47 -0700 (PDT)
Date: Tue, 15 May 2001 10:34:01 -0700 (PDT)
From: Tom Duffy <tduffy@engr.sgi.com>
To: Simon Matter <simon.matter@ch.sauter-bc.com>
cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: xfs on small memory
In-Reply-To: <3B00EC32.7A1BA16A@ch.sauter-bc.com>
Message-ID: <Pine.LNX.4.33.0105150911000.300-100000@dbear.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I made the lowmem test with my test machine. It is a pentium 200 and
> I used 12MB of ram. The disks are two Quantum Fireballs 15GB with DMA
> enabled. The disks have 3 partitions each configured as RAID 1.
> /dev/md0 /boot  (50M)
> /dev/md2 /      (14G)
> /dev/md1 swap   (500M)
>
> The RAID /dev/md2 was syncing while I ran hevy NFS and disk to disk
> copy traffic and I updated some RPMS. Everything worked very fine!!!
> No crash, no endless swapping.
> The same test with only 8MB ram was a pain because lack of ressources.

did you kill power to the machine and try a reboot w/ 12MB RAM?  did the
XFS recovery go OK.  I guess this might be explicit from your email when
you said that you were doing a raid resync, but I just want to be clear.

thanks,

-tduffy


From owner-linux-xfs@oss.sgi.com Tue May 15 10:42:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHgmp17353
	for linux-xfs-outgoing; Tue, 15 May 2001 10:42:48 -0700
Received: from novalfsmtp2.novsvcs.net (ns5.novsvcs.net [192.208.44.111])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHglF17350
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:42:47 -0700
Received: from pp-rafiki-chbs.cp.chbs ([168.246.161.139])
	by novalfsmtp2.novsvcs.net (8.10.2/8.9.3) with ESMTP id f4FHiis03028
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:44:45 -0400
X-Authentication-Warning: novalfsmtp2.novsvcs.net: Host [168.246.161.139] claimed to be pp-rafiki-chbs.cp.chbs
Received: from pp-banzai-chbs.cp.chbs (pp-banzai-chbs.cp.chbs [168.246.161.82])
	by pp-rafiki-chbs.cp.chbs (Build 101 8.9.3/NT-8.9.3) with ESMTP id TAA08833
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 19:42:25 +0200
From: kenneth.leung@syngenta.com
Received: by pp-banzai-chbs with Internet Mail Service (5.5.2653.19)
	id <KW4140DK>; Tue, 15 May 2001 19:42:22 +0200
Message-ID: <AF84AD19B4A8D411B18500508BAF0E0E658F76@SE-EXCUR01-USLJ>
To: linux-xfs@oss.sgi.com
Subject: Question re: installation over network
Date: Tue, 15 May 2001 19:42:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All,

I am attempting to install SGI's Linux + XFS version 1.0 over our network. I
have created a boot floppy from the bootnet.img, and booted the new system
with this floppy. On another RedHat 7.1 system, I have the following ISO
images mounted and NFS exported.

/mnt/sgi-disk		(SGI XFS Installation CD)
/mnt/seawolf-disk1	(RedHat 7.1 CD #1)
/mnt/seawolf-disk2	(RedHat 7.1 CD #2)

I provide the name of the NFS server, and the /mnt/sgi-disk mount point so
that I can install Linux + XFS. The SGI installation begins, and seems to go
along smoothly. I set up networking, choose a time zone, choose my packages,
etc. However, when the package installation begins, it automatically fails,
complaining that it can't find an RPM in the /mnt/CDROM... directory.

I think the problem has to do with the fact that the installation never even
asks me where the RedHat 7.1 NFS mount points are! If the installation
doesn't know where all the mount points are, how can it possibly find the
files it needs? So, is my inherent setup flawed here?

Looking forward to your suggestions!
Ken

*******************************************
Kenneth Leung
IT Administrator
Torrey Mesa Research Institute
kenneth.leung@syngenta.com
(858) 812-1223
*******************************************


From owner-linux-xfs@oss.sgi.com Tue May 15 10:45:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHjqI17417
	for linux-xfs-outgoing; Tue, 15 May 2001 10:45:52 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHjpF17414
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:45:51 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4FHjTI10181;
	Tue, 15 May 2001 12:45:29 -0500 (CDT)
Message-ID: <3B016BD0.BFB31CCF@sgi.com>
Date: Tue, 15 May 2001 12:48:00 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS & Kickstart installation
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
	 <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be> <3.0.6.32.20010515114656.007b0e60@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

werner maes wrote:

> Below is my ks.cfg file which works fine with RH 7.1 but not with SGI
> installer.
> I did not add '--fs xfs' because XFS is the default.

Hi again Werner - 

I'm at a loss here - your ks.cfg works just fine for me, I did an
install on scsi, and the system installed and came up with no problems.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 10:49:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FHnWt17509
	for linux-xfs-outgoing; Tue, 15 May 2001 10:49:32 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FHnVF17506
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 10:49:31 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4FHnTI11536;
	Tue, 15 May 2001 12:49:29 -0500 (CDT)
Message-ID: <3B016CC0.EC3F3D13@sgi.com>
Date: Tue, 15 May 2001 12:52:00 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: kenneth.leung@syngenta.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Question re: installation over network
References: <AF84AD19B4A8D411B18500508BAF0E0E658F76@SE-EXCUR01-USLJ>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kenneth.leung@syngenta.com wrote:
> 
> All,
> 
> I am attempting to install SGI's Linux + XFS version 1.0 over our network. I
> have created a boot floppy from the bootnet.img, and booted the new system
> with this floppy. On another RedHat 7.1 system, I have the following ISO
> images mounted and NFS exported.
> 
> /mnt/sgi-disk           (SGI XFS Installation CD)
> /mnt/seawolf-disk1      (RedHat 7.1 CD #1)
> /mnt/seawolf-disk2      (RedHat 7.1 CD #2)
> 
> I provide the name of the NFS server, and the /mnt/sgi-disk mount point so
> that I can install Linux + XFS. The SGI installation begins, and seems to go
> along smoothly. I set up networking, choose a time zone, choose my packages,
> etc. However, when the package installation begins, it automatically fails,
> complaining that it can't find an RPM in the /mnt/CDROM... directory.

The problem is that the installer expects to find everything it needs
under /mnt/sgi-disk (this is standard Red Hat installer behavior).

Pretending for a moment that you don't have the install images mounted
on loopback, what you would need to do is copy all of the RPMS from
seawolf-diskX/RedHat/RPMS into sgi-disk/RedHat/RPMS. 

Since you have everything loopback mounted, you could probably get
creative with symlinks...

What you need to end up with is a top-level dir that contains all of the
sgi disk, plus all of the RPMs from RH disks 1 and 2 under RedHat/RPMS

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 11:54:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FIsa718746
	for linux-xfs-outgoing; Tue, 15 May 2001 11:54:36 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FIsUF18743
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 11:54:30 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FIl4x12562;
	Tue, 15 May 2001 13:47:05 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 13:47:04 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: John Trostel <jtrostel@connex.com>
cc: =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>,
   =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>,
   ML do XFS <linux-xfs@oss.sgi.com>
Subject: RE: For when a new stable release?
In-Reply-To: <XFMail.20010515133431.jtrostel@connex.com>
Message-ID: <Pine.LNX.4.33.0105151346340.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Umm..the owner is still root. But I see what you mean. So you can prevent
say a common user from deleting things, but the perms are enforced across
users?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 15 May 2001, John Trostel wrote:

> Then don't chmod 777 the file.  If the file has been given the ACL
> u::rwx,g::rwx,o::rwx,u:user1:r-x,m::rwx then everyone _except_ 'user1' can
> delete the file.  If the file had been given
> u::rwx,g::rwx,o::r-x,u:user1:rwx,m::rwx, then _only_ the true owner and user1
> would be able to delete the file.
>
> Start as root (or someother user who owns a file)
> [root@jtsdell xfs_part]# chgrp root jt_junk
> [root@jtsdell xfs_part]# ls -l jt_junk
> -rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk
> [root@jtsdell xfs_part]# chacl -l jt_junk
> jt_junk []
>
> (There's no ACL defined on this file yet.... lets define one that doesn't allow
> 'jt' to delete the file... but looks 'normal' to 'ls -l')
>
> [root@jtsdell xfs_part]# chacl u::rwx,g::rwx,o::rwx,u:jt:r-x,m::rwx jt_junk
> [root@jtsdell xfs_part]# chacl -l jt_junk
> jt_junk [u::rwx,g::rwx,o::rwx,u:jt:r-x,m::rwx]
>
> See... 'chacl -l' sees the extended permission structure.
>
> [root@jtsdell xfs_part]# ls -l jt_junk
> -rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk
>
> But 'ls -l' does not see it.
>
> [root@jtsdell xfs_part]# exit
> exit
>
> Go back to being 'jt'
>
> [jt@jtsdell xfs_part]$ ls -l jt_junk
> -rwxrwxrwx    1 root     root            0 May 11 13:36 jt_junk
>
> File looks like I (as 'jt') can delete it.  Let's try.
>
> [jt@jtsdell xfs_part]$ rm jt_junk
> rm: remove write-protected file `jt_junk'? y
> rm: cannot unlink `jt_junk': Permission denied
>
> Gee Whiz!?! What happened? I've been acl-ized!
>
> On 15-May-2001 Austin Gonyou wrote:
> > I agree with this. but my problem is ACLs should protect. At this point
> > the file can still be modified/deleted by ANYONE if I chmod 777 that file.
> > What's the point of ACLs if they don't stop malicios behaviour?
>
> ACLs are designed to allow you to specify permissions on a finer scale than the
> traditional ugo scheme.  You can tailor protection for just  a few users or
> groups.
>


From owner-linux-xfs@oss.sgi.com Tue May 15 12:05:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJ5bJ18931
	for linux-xfs-outgoing; Tue, 15 May 2001 12:05:37 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJ5aF18928
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:05:36 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDE00E7N518VJ@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue,
 15 May 2001 14:05:33 -0500 (CDT)
Date: Tue, 15 May 2001 15:04:53 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: For when a new stable release?
In-reply-to: <Pine.LNX.4.33.0105151346340.11093-100000@UberGeek.coremetrics.com>
To: Austin Gonyou <austin@coremetrics.com>
Cc: ML do XFS <linux-xfs@oss.sgi.com>
Cc: ML do XFS <linux-xfs@oss.sgi.com>,
   =?iso-8859-1?Q?M=E1rio?= Gamito <mg-listas@netvisao.pt>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010515150453.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The perms are first applied as normal, i.e., ugo/rwx, then the extended acls
are added on as an additional qualifying condition.

u::rwx,g::rwx,o::r-x,u:user1:r--,u:user2:---,u:user3:rw-,m::rwx
\__________________/ \_________________________________/
  'normal' perms              'extended perms'

so... 'normal' perms would apply to everyone except user1, user2, and user3. 
These users would get the perms shown in the 'extended perms'

On 15-May-2001 Austin Gonyou wrote:
> Umm..the owner is still root. But I see what you mean. So you can prevent
> say a common user from deleting things, but the perms are enforced across
> users?
> 

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Tue May 15 12:14:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJEfV19133
	for linux-xfs-outgoing; Tue, 15 May 2001 12:14:41 -0700
Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJEFF19126
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:14:16 -0700
Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1])
	by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id OAA05677;
	Tue, 15 May 2001 14:35:42 -0400
Message-ID: <3B0176FE.E58EF6B9@mindspring.com>
Date: Tue, 15 May 2001 14:35:42 -0400
From: Danny Cox <danscox@mindspring.com>
Reply-To: dcox@Connex.com
Organization: Connex Inc
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Austin Gonyou <austin@coremetrics.com>
CC: John Trostel <jtrostel@Connex.com>, ML do XFS <linux-xfs@oss.sgi.com>,
   "=?iso-8859-1?Q?M=E1rio?= Gamito" <mg-listas@netvisao.pt>
Subject: Re: For when a new stable release?
References: <Pine.LNX.4.33.0105151212390.11093-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin,

Austin Gonyou wrote:
> 
> Here's another example.
> 
> -----begin user test-----
> [austin@UberGeek test]$ chacl u::rwx,g::rwx,o::r-x,u:root:r--,m::rwx
> somefile
> [austin@UberGeek test]$ ls -l
> total 4
> -rwxrwxr-x    1 austin   austin          0 May 15 12:09 somefile
> [austin@UberGeek test]$ chmod 777 somefile
> [austin@UberGeek test]$ ls -l
> total 4
> -rwxrwxrwx    1 austin   austin          0 May 15 12:09 somefile
> [austin@UberGeek test]$ chacl -l somefile
> somefile [u::rwx,g::rwx,o::rwx,u:root:r--,m::rwx]
> [austin@UberGeek test]$ rm somefile
> [austin@UberGeek test]$ ls
> [austin@UberGeek test]$
> -----end user test-----
> 
> What good did that do?

	It did just as you instructed it.

	Under Linux and UNIX, creating/deleting a file is governed by the
permissions on the directory, not the file itself.  This is with or
without ACLs.

-- 
"Men occasionally stumble over the truth, but most of them pick 
themselves up and hurry off as if nothing had happened." 
   -- Winston Churchill 

Danny

From owner-linux-xfs@oss.sgi.com Tue May 15 12:20:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJK6319202
	for linux-xfs-outgoing; Tue, 15 May 2001 12:20:06 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJK5F19199
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:20:06 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FJISc12766
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:18:28 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 14:18:28 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: adding a new stripe to a stripeset
Message-ID: <Pine.LNX.4.33.0105151411230.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Can this be done? Say I create a new volume like this:

vgcreate testvg1 /dev/sda[1-2] /dev/sdb1

then

lvcreate -i3 -L 10240M (a 3 "disk" stripeset)

In this instance each partition is about 4gb. So, now I want to add a new
disk to the vg.

vgextend testvg1 /dev/sdb2

next I want to have more than 12gb in my current volume

lvextend -L +4096 /dev/testvg1/lvol1

This fails because my current stripelimit is 3 and that equates to about
12.5gb. Although vgdisplay shows 16gb in the vol group. So, I'm asking is
there a way to add another stripe to a stripeset, so I can not have an
unused pv in my volume group? Thanks for the info.


 --
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Tue May 15 12:29:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJTmb19344
	for linux-xfs-outgoing; Tue, 15 May 2001 12:29:48 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJThF19341
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:29:43 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zkVn-0007Ko-00; Tue, 15 May 2001 21:29:41 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FJSU730742;
	Tue, 15 May 2001 15:28:30 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: adding a new stripe to a stripeset
References: <Pine.LNX.4.33.0105151411230.11093-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 15:28:30 -0400
In-Reply-To: <Pine.LNX.4.33.0105151411230.11093-100000@UberGeek.coremetrics.com>
Message-ID: <yq1g0e69ztt.fsf@jcb.mkp.net>
Lines: 21
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> Can this be done? Say I create a new volume like this:
Austin> vgcreate testvg1 /dev/sda[1-2] /dev/sdb1

Ugh.  Striping on the same disk isn't going to buy you much.


Austin> So, I'm asking is there a way to add another stripe to a
Austin> stripeset, so I can not have an unused pv in my volume group?

Nope.  You can use the extra space in another striped LV, though,
assuming you have enough space available on the other PVs.

But there's no way to magically change stripe width of an existing
volume.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 12:48:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJmWr19705
	for linux-xfs-outgoing; Tue, 15 May 2001 12:48:32 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJmVF19701
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:48:32 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id B2C7ACAC518
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:48:11 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 14zkm7-0001sp-00
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:46:31 -0400
Date: Tue, 15 May 2001 15:46:31 -0400
To: linux-xfs@oss.sgi.com
Subject: Mount options
Message-ID: <20010515154631.B23813@chimesnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey everyone,

I have a small problem:
When I mount xfs filesystems, I cannot specify any xfs specific options (kio,biosize)

I must issue a remount to modify xfs specific options.  Is there a way around this?

Most grateful,

-Tom Carroll

From owner-linux-xfs@oss.sgi.com Tue May 15 12:57:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJvEw19884
	for linux-xfs-outgoing; Tue, 15 May 2001 12:57:14 -0700
Received: from novalfsmtp2.novsvcs.net (ns5.novsvcs.net [192.208.44.111])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJvEF19881
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:57:14 -0700
Received: from pp-rafiki-chbs.cp.chbs ([168.246.161.139])
	by novalfsmtp2.novsvcs.net (8.10.2/8.9.3) with ESMTP id f4FJxRs13027;
	Tue, 15 May 2001 15:59:28 -0400
X-Authentication-Warning: novalfsmtp2.novsvcs.net: Host [168.246.161.139] claimed to be pp-rafiki-chbs.cp.chbs
Received: from pp-banzai-chbs.cp.chbs (pp-banzai-chbs.cp.chbs [168.246.161.82])
	by pp-rafiki-chbs.cp.chbs (Build 101 8.9.3/NT-8.9.3) with ESMTP id VAA14734;
	Tue, 15 May 2001 21:57:05 +0200
From: kenneth.leung@syngenta.com
Received: by pp-banzai-chbs with Internet Mail Service (5.5.2653.19)
	id <KW41V1XH>; Tue, 15 May 2001 21:57:04 +0200
Message-ID: <AF84AD19B4A8D411B18500508BAF0E0E658F7C@SE-EXCUR01-USLJ>
To: linux-xfs@oss.sgi.com
Cc: sandeen@sgi.com
Subject: Re: installation over network
Date: Tue, 15 May 2001 21:56:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks for your response Eric.

So it seems that mounting loopback images are not the way to go for network
installs. Would I be better off copying the entire contents of the SGI
Installation CD to an NFS mounted directory, followed by copying the RedHat
RPMs to the RPMS directory?

Thank you,
Ken

*******************************************
Kenneth Leung
IT Administrator
Torrey Mesa Research Institute
kenneth.leung@syngenta.com
(858) 812-1223
*******************************************


From owner-linux-xfs@oss.sgi.com Tue May 15 12:58:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FJwjG19909
	for linux-xfs-outgoing; Tue, 15 May 2001 12:58:45 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FJwiF19906
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 12:58:44 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4FJweq09522;
	Tue, 15 May 2001 14:58:40 -0500 (CDT)
Message-ID: <3B018B0A.B36DAC74@sgi.com>
Date: Tue, 15 May 2001 15:01:14 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: kenneth.leung@syngenta.com
CC: linux-xfs@oss.sgi.com
Subject: Re: installation over network
References: <AF84AD19B4A8D411B18500508BAF0E0E658F7C@SE-EXCUR01-USLJ>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kenneth.leung@syngenta.com wrote:
> 
> Thanks for your response Eric.
> 
> So it seems that mounting loopback images are not the way to go for network
> installs. Would I be better off copying the entire contents of the SGI
> Installation CD to an NFS mounted directory, followed by copying the RedHat
> RPMs to the RPMS directory?

If you have the disk space, that would be the most straightforward
method.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 15 13:01:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FK1Le19969
	for linux-xfs-outgoing; Tue, 15 May 2001 13:01:21 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FK1JF19965
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:01:19 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zl0Q-0007NA-00; Tue, 15 May 2001 22:01:18 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FK09G30824;
	Tue, 15 May 2001 16:00:09 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Tom Carroll <tcarroll@chimesnet.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Mount options
References: <20010515154631.B23813@chimesnet.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 16:00:09 -0400
In-Reply-To: <20010515154631.B23813@chimesnet.com>
Message-ID: <yq1bsou9yd2.fsf@jcb.mkp.net>
Lines: 21
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Tom" == Tom Carroll <tcarroll@chimesnet.com> writes:

Tom> I have a small problem: When I mount xfs filesystems, I cannot
Tom> specify any xfs specific options (kio,biosize)

FWIW, kio is deprecated.


Tom> I must issue a remount to modify xfs specific options.  Is there
Tom> a way around this?

(root@hammond) /# mount -t xfs -o biosize=13 /dev/sda8 /mnt
(root@hammond) /# mount | grep mnt
/dev/sda8 on /mnt type xfs (rw,biosize=13)

Works for me.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 13:15:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKFPe20445
	for linux-xfs-outgoing; Tue, 15 May 2001 13:15:25 -0700
Received: from hotmail.com (f197.law11.hotmail.com [64.4.17.197])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKFOF20441
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:15:24 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 15 May 2001 13:15:14 -0700
Received: from 194.6.81.219 by lw11fd.law11.hotmail.msn.com with HTTP;	Tue, 15 May 2001 20:15:14 GMT
X-Originating-IP: [194.6.81.219]
From: "Tim Clymo" <tim_clymo@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
Date: Tue, 15 May 2001 20:15:14 -0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F197fyQgeDKvPEkGhAj00008076@hotmail.com>
X-OriginalArrivalTime: 15 May 2001 20:15:14.0857 (UTC) FILETIME=[C09C7990:01C0DD7B]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At the risk of pushing the point here...

I understand all that has been said about delayed writes, caches etc.
However, with regard to the original question in this thread, is it
still "expected behaviour" for the original source file to be full of
garbage if the system is powered off shortly after a non-synced write?

Editing a plain text file for example with vi, saving the file and
doing an immediate reset - I could understand if the file was back to
its original state before the edit was "written", but my experience is
that instead it is useless junk.

Thanks

Tim

>I am going to attempt to explain a little of how XFS writes data to disk,
>and what this means when the power is turned off.
>
>For most transactions, the modifications to the filesystem are committed
>to a group of in memory buffers. These buffers are flushed to disk by:
>
>        o a synchronous transaction
>        o being filled
>        o background sync activity
>
>File data is flushed to disk via bdflush unless you use fsync, O_SYNC on
>open or fdatasync.
>
>Filesystem design is mostly about compromises between speed of operation
>and safety of operation, even in the case of XFS. If you want a filesystem
>which is truly safe from power outages then you have to use applications
>which do I/O in a manner which indicates they want the data on disk before
>the system call returns, and in the case of XFS, mount with the wsync
>option which makes all transactions safe on disk before system calls
>return. Of course, performance will suffer. There is a range of medical
>image scanners which actually have an Irix box embedded in them using XFS.
>These boxes regularly just get unplugged or have the power removed for
>some reason, and the manufacturer insisted on complete data recovery
>after a crash. The above factors were what got them to this state.
>
>So if you write to a file and then immediately drop the power, the chances
>are you will not see the data after reboot. If you do a metadata operation
>and imediately drop power, there is also a chance it will be not be present
>after reboot. The filesystem however, will be in a consistent state.
>
>
>>Is there anyway to mount with less latency on the writes?
>
>You can control the frequency of data getting flushed to disk (both file
>data and metadata in the journal) with the bdflush parameters in
>
>/proc/sys/vm/bdflush
>
>Steve
>
>>
>>--
>>Austin Gonyou
>>Systems Architect, CCNA
>>Coremetrics, Inc.
>>Phone: 512-796-9023

>>email: austin@coremetrics.com
>>
>>On Fri, 11 May 2001, Marc Jauvin wrote:
>>
>> > I understand, but the file should have been kept to its original state, 
>>no?>>  I
>> > had garbage all over the file after the reset...
>> >
>> >
>> > Russell Cattelan wrote:
>> >
>> > > Marc Jauvin wrote:
>> >
>> > >> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
>> > >>
>> > >> ----
>> > >>
>> > >> I installed XFS 1.0 for RedHat 7.1 and everything is great... until 
>>I di>> d the
>> > >> following:
>> > >>
>> > >> make modification to /etc/fstab, and IMMEDIATELY after saving the
>> > >> modifications, I hit the reset button; when the system reboots, the
>> > >> /etc/fstab is baddly corrupted and XFS does not fix it (end up using 
>>the>> > >> linux rescue disk to fix fstab manually\)
>> > >>
>> > >> I could reproduce the bug 2 times;
>> >
>> > >> Any idea\?
>> >
>> > > Yes don't do that.
>> > > XFS uses delayed allocation / delayed write by default any data 
>>written
>> > > immediacy before a crash probably won't be on
>> > > disk, this is known behavior and isn't considered a bug, it's a trade 
>>off>> .
>> > > Full sync mode on file systems is much safer and gives more likely 
>>hood o>> f
>> > > data integrity. caches gives much better
>> > > performance but has the potential of losing cached data in the event 
>>of a>> > > crash.
>> >
>> >
>> >
>> > --
>> > marc.
>> >
>> > 3 out of 4 Americans make up 75% of the population.
>> >

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


From owner-linux-xfs@oss.sgi.com Tue May 15 13:19:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKJ6P20530
	for linux-xfs-outgoing; Tue, 15 May 2001 13:19:06 -0700
Received: from picard.skynet.be (picard.skynet.be [195.238.3.131])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKJ5F20527
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:19:05 -0700
Received: from skynet.be (adsl-46527.turboline.skynet.be [217.136.53.191])
	by picard.skynet.be (8.11.2/8.11.2/Skynet-OUT-2.11) with ESMTP id f4FKIsO22859
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 22:18:54 +0200 (MET DST)
	(envelope-from <kris.buggenhout@skynet.be>)
Message-ID: <3B018E0A.A9D6680@skynet.be>
Date: Tue, 15 May 2001 22:14:02 +0200
From: kris buggenhout <kris.buggenhout@skynet.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: weird problems
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I started doing benchmarks with Iozone , which inmho gives a reasonable
comparison between filesystems.
I did some testing on a plain ext2, a plain xfs ( one disk / one
partition - same disk / same machine for both tests)
And am trying the same tests with lvm mounted disks or md subdisks

I have come across some weird errors when using lvm

when the test file gets to 512 Meg i get hardware scsi errors ... the
disks are fine ... but the lvm in combo with xfs screws up


config : Athlon 500 2 adaptec 2940 cards ( identical) 256 M ram 4
identical 9Gig disks (seagate .. formerly from big unix server) a 18G
disk and
an 8G ide disk... RedHat 7.1 with the cvs kernel ( from last week) xfs
..

thnx in advance


From owner-linux-xfs@oss.sgi.com Tue May 15 13:24:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKOLU20639
	for linux-xfs-outgoing; Tue, 15 May 2001 13:24:21 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKOKF20636
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:24:20 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 578721E25F; Tue, 15 May 2001 22:24:19 +0200 (MEST)
Date: Tue, 15 May 2001 22:23:41 +0200
From: Andi Kleen <ak@suse.de>
To: Tim Clymo <tim_clymo@hotmail.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
Message-ID: <20010515222341.A30527@gruyere.muc.suse.de>
References: <F197fyQgeDKvPEkGhAj00008076@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F197fyQgeDKvPEkGhAj00008076@hotmail.com>; from tim_clymo@hotmail.com on Tue, May 15, 2001 at 08:15:14PM -0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 15, 2001 at 08:15:14PM -0000, Tim Clymo wrote:
> Editing a plain text file for example with vi, saving the file and
> doing an immediate reset - I could understand if the file was back to
> its original state before the edit was "written", but my experience is
> that instead it is useless junk.

As I understand it the problem is that XFS/Linux doesn't support 
unwritten extents yet (unlike Irix XFS). An unwritten extent would tell
XFS to zero the data on crash recovery, if it wasn't turned into an 
written extent by a finished flush. Without them recovery has no way to know 
if there is old data or new data in the extent and has to leave it alone, so 
you likely see old data if you hit reset fast. See the old XFS design 
documentation somewhere on their website for more details.

-Andi

From owner-linux-xfs@oss.sgi.com Tue May 15 13:29:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKT4020754
	for linux-xfs-outgoing; Tue, 15 May 2001 13:29:04 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKT3F20750
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:29:03 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA03481
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:39:59 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1825168; Tue, 15 May 2001 15:27:46 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA00712; Tue, 15 May 2001 15:27:45 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FKTbp07543; Tue, 15 May 2001 15:29:37 -0500
Message-Id: <200105152029.f4FKTbp07543@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Andi Kleen <ak@suse.de>
cc: Tim Clymo <tim_clymo@hotmail.com>, linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug... 
In-Reply-To: Message from Andi Kleen <ak@suse.de> 
   of "Tue, 15 May 2001 22:23:41 +0200." <20010515222341.A30527@gruyere.muc.suse.de> 
Date: Tue, 15 May 2001 15:29:37 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tue, May 15, 2001 at 08:15:14PM -0000, Tim Clymo wrote:
> > Editing a plain text file for example with vi, saving the file and
> > doing an immediate reset - I could understand if the file was back to
> > its original state before the edit was "written", but my experience is
> > that instead it is useless junk.
> 
> As I understand it the problem is that XFS/Linux doesn't support 
> unwritten extents yet (unlike Irix XFS). An unwritten extent would tell
> XFS to zero the data on crash recovery, if it wasn't turned into an 
> written extent by a finished flush. Without them recovery has no way to know 
> if there is old data or new data in the extent and has to leave it alone, so 
> you likely see old data if you hit reset fast. See the old XFS design 
> documentation somewhere on their website for more details.
> 
> -Andi

Sounds like a reasonable explaination to me - running xfs_bmap on the file
with crud in it will tell you if it has extents or not - and if you are
seeing anything but zeros this has to be the case.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 15 13:47:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKlQF20996
	for linux-xfs-outgoing; Tue, 15 May 2001 13:47:26 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKlMF20992
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:47:26 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4FKlHP18733
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:47:17 -0700
Date: Tue, 15 May 2001 13:47:17 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: linux-xfs@oss.sgi.com
Subject: Memory and quota issues.
In-Reply-To: <200105152029.f4FKTbp07543@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is anyone else having memory problems  with the CVS kernel?  Ive got a
server here with 384MB, and its using 325 of it right now.  It should be
using about 30, tops.  It *might* be something to do with debian woody,
but i wanna make sure no one else is having XFS issues.  Also, i cant seem
to get quota working.  I'm using devfs, but i dont think thats the issue,
when i switched to XFS kernels i started getting this error from quota:

fudd:/home# /etc/init.d/quota start
Checking quotas...done.
Turning on quotas.
quotaon: using /home/quota.group on
/dev/ide/host2/bus0/target0/lun0/part9: Invalid argument
quotaon: using /home/quota.user on
/dev/ide/host2/bus0/target0/lun0/part9: Invalid argument

Any ideas? I dont know if its XFS, but id like to atleast rule it out.

Thanks.

Dana


From owner-linux-xfs@oss.sgi.com Tue May 15 13:50:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKoip21096
	for linux-xfs-outgoing; Tue, 15 May 2001 13:50:44 -0700
Received: from picard.skynet.be (picard.skynet.be [195.238.3.131])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKogF21091
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:50:43 -0700
Received: from skynet.be (adsl-46527.turboline.skynet.be [217.136.53.191])
	by picard.skynet.be (8.11.2/8.11.2/Skynet-OUT-2.11) with ESMTP id f4FKoaO28299
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 22:50:36 +0200 (MET DST)
	(envelope-from <kris.buggenhout@skynet.be>)
Message-ID: <3B019573.BA31A06F@skynet.be>
Date: Tue, 15 May 2001 22:45:39 +0200
From: kris buggenhout <kris.buggenhout@skynet.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: performance woe's
Content-Type: multipart/alternative;
 boundary="------------44B7BD601B1461A3524761AF"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--------------44B7BD601B1461A3524761AF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

still doing iozone testing

I found that when U go out of the buffer cache ( in my case 128Meg) the
performance drops ( as one would expect)
But surprinsingly writes are still a lot faster than reads when using
XFS, this is kinda paradox ...
As the slowest operation for a disk is actually the write operation...


any idea's ?


snippet of the (preliminiary) results:

                                                            random
random    bkwd  record  stride
              KB  reclen   write rewrite    read    reread    read
write    read rewrite    read   fwrite frewrite   fread  freread

           65536      64  129422  160472   205958   207538  189159
92569  200343  300786  190322   116578   119016  197913   200438
           65536     128  137591  149548   189628   177738  186519
97034  188552  238659  188278    99012   108400  185875   180353

          131072      64   21390   14634     7161     7002    7663
26880    4544  317377    7253    14230    20834    7092     7156
          131072     128   21451   21038     6975     6984    8780
27774    4883  207294    6671    21400    17567    7240     7122


--------------44B7BD601B1461A3524761AF
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>still doing iozone testing
<p>I found that when U go out of the buffer cache ( in my case 128Meg)
the performance drops ( as one would expect)
<br>But surprinsingly writes are still a lot faster than reads when using
XFS, this is kinda paradox ...
<br>As the slowest operation for a disk is actually the write operation...
<br>&nbsp;
<p>any idea's ?
<br>&nbsp;
<p>snippet of the (preliminiary) results:
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
random&nbsp; random&nbsp;&nbsp;&nbsp; bkwd&nbsp; record&nbsp; stride</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
KB&nbsp; reclen&nbsp;&nbsp; write rewrite&nbsp;&nbsp;&nbsp; read&nbsp;&nbsp;&nbsp;
reread&nbsp;&nbsp;&nbsp; read&nbsp;&nbsp; write&nbsp;&nbsp;&nbsp; read
rewrite&nbsp;&nbsp;&nbsp; read&nbsp;&nbsp; fwrite frewrite&nbsp;&nbsp;
fread&nbsp; freread</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 65536&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
64&nbsp; 129422&nbsp; 160472&nbsp;&nbsp; 205958&nbsp;&nbsp; 207538&nbsp;
189159&nbsp;&nbsp; 92569&nbsp; 200343&nbsp; 300786&nbsp; 190322&nbsp;&nbsp;
116578&nbsp;&nbsp; 119016&nbsp; 197913&nbsp;&nbsp; 200438</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 65536&nbsp;&nbsp;&nbsp;&nbsp;
128&nbsp; 137591&nbsp; 149548&nbsp;&nbsp; 189628&nbsp;&nbsp; 177738&nbsp;
186519&nbsp;&nbsp; 97034&nbsp; 188552&nbsp; 238659&nbsp; 188278&nbsp;&nbsp;&nbsp;
99012&nbsp;&nbsp; 108400&nbsp; 185875&nbsp;&nbsp; 180353</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 131072&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
64&nbsp;&nbsp; 21390&nbsp;&nbsp; 14634&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">7161&nbsp;&nbsp;&nbsp;&nbsp;
7002&nbsp;&nbsp;&nbsp; 7663</font>&nbsp;&nbsp; 26880&nbsp;&nbsp;&nbsp;
<font color="#FF0000">4544</font>&nbsp; 317377&nbsp;&nbsp;&nbsp; <font color="#FF0000">7253</font>&nbsp;&nbsp;&nbsp;
14230&nbsp;&nbsp;&nbsp; 20834&nbsp;&nbsp;&nbsp; <font color="#FF0000">7092&nbsp;&nbsp;&nbsp;&nbsp;
7156</font></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 131072&nbsp;&nbsp;&nbsp;&nbsp;
128&nbsp;&nbsp; 21451&nbsp;&nbsp; 21038&nbsp;&nbsp;&nbsp;&nbsp; <font color="#FF0000">6975&nbsp;&nbsp;&nbsp;&nbsp;
6984&nbsp;&nbsp;&nbsp; 8780</font>&nbsp;&nbsp; 27774&nbsp;&nbsp;&nbsp;
<font color="#FF0000">4883</font>&nbsp; 207294&nbsp;&nbsp;&nbsp; <font color="#FF0000">6671</font>&nbsp;&nbsp;&nbsp;
21400&nbsp;&nbsp;&nbsp; 17567&nbsp;&nbsp;&nbsp; <font color="#FF0000">7240&nbsp;&nbsp;&nbsp;&nbsp;
7122</font></tt>
<br><tt></tt>&nbsp;</html>

--------------44B7BD601B1461A3524761AF--


From owner-linux-xfs@oss.sgi.com Tue May 15 13:51:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FKpV821112
	for linux-xfs-outgoing; Tue, 15 May 2001 13:51:31 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FKpTF21107
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 13:51:30 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zlmy-0007QX-00; Tue, 15 May 2001 22:51:28 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FKoJR04894;
	Tue, 15 May 2001 16:50:19 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: kris buggenhout <kris.buggenhout@skynet.be>
Cc: linux-xfs@oss.sgi.com
Subject: Re: weird problems
References: <3B018E0A.A9D6680@skynet.be>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 16:50:19 -0400
In-Reply-To: <3B018E0A.A9D6680@skynet.be>
Message-ID: <yq1u22m8hh0.fsf@jcb.mkp.net>
Lines: 17
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "kris" == kris buggenhout <kris.buggenhout@skynet.be> writes:

kris> I have come across some weird errors when using lvm

kris> when the test file gets to 512 Meg i get hardware scsi errors
kris> ... the disks are fine ... but the lvm in combo with xfs screws
kris> up

Hmmm. Works fine for me here.

Could you please post the output of vgdisplay -v and SCSI errors you
get?

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 14:01:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FL1gm21316
	for linux-xfs-outgoing; Tue, 15 May 2001 14:01:42 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FL1fF21313
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:01:41 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id RAA31180;
	Tue, 15 May 2001 17:01:19 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Tue, 15 May 2001 17:01:19 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: Dana Soward <dragon@thegoop.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Memory and quota issues.
In-Reply-To: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
Message-ID: <Pine.LNX.4.30.0105151659190.926-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote

> Is anyone else having memory problems  with the CVS kernel?  Ive got a
> server here with 384MB, and its using 325 of it right now.  It should be
> using about 30, tops.  It *might* be something to do with debian woody,
> but i wanna make sure no one else is having XFS issues.  Also, i cant seem

Are you sure that all that memory is being used?  The 2.4 kernel is very
aggressive when it comes to cacheing (which is a good thing).  What does
the output of 'free' say?

In general, you *want* all your memory used up.  You just don't want
running processes to be the ones using it all.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


From owner-linux-xfs@oss.sgi.com Tue May 15 14:08:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FL87921427
	for linux-xfs-outgoing; Tue, 15 May 2001 14:08:07 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FL86F21424
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:08:06 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA03987
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:19:02 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA01741; Tue, 15 May 2001 16:06:49 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4FL5me18803;
	Tue, 15 May 2001 17:05:48 -0400
Message-ID: <3B019A2A.7480C35@thebarn.com>
Date: Tue, 15 May 2001 17:05:47 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Clymo <tim_clymo@hotmail.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
References: <F197fyQgeDKvPEkGhAj00008076@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tim Clymo wrote:

> At the risk of pushing the point here...
>
> I understand all that has been said about delayed writes, caches etc.
> However, with regard to the original question in this thread, is it
> still "expected behaviour" for the original source file to be full of
> garbage if the system is powered off shortly after a non-synced write?
>
> Editing a plain text file for example with vi, saving the file and
> doing an immediate reset - I could understand if the file was back to
> its original state before the edit was "written", but my experience is
> that instead it is useless junk.

If you followed the thread and my last explanation you will note that the file
was not full of garbage but NULL's. the file had no extents  which means it
consisted
entirely of a whole aka NULL's
As to why the contents of the file where not the 'old' data, most editors
either
mv the old copy to a backup name or truncate the file before writing to it.
Effectively we are dealing with a "new" file and not one that is being
"updated" or
written over.


>
>
> Thanks
>
> Tim
>
> >I am going to attempt to explain a little of how XFS writes data to disk,
> >and what this means when the power is turned off.
> >
> >For most transactions, the modifications to the filesystem are committed
> >to a group of in memory buffers. These buffers are flushed to disk by:
> >
> >        o a synchronous transaction
> >        o being filled
> >        o background sync activity
> >
> >File data is flushed to disk via bdflush unless you use fsync, O_SYNC on
> >open or fdatasync.
> >
> >Filesystem design is mostly about compromises between speed of operation
> >and safety of operation, even in the case of XFS. If you want a filesystem
> >which is truly safe from power outages then you have to use applications
> >which do I/O in a manner which indicates they want the data on disk before
> >the system call returns, and in the case of XFS, mount with the wsync
> >option which makes all transactions safe on disk before system calls
> >return. Of course, performance will suffer. There is a range of medical
> >image scanners which actually have an Irix box embedded in them using XFS.
> >These boxes regularly just get unplugged or have the power removed for
> >some reason, and the manufacturer insisted on complete data recovery
> >after a crash. The above factors were what got them to this state.
> >
> >So if you write to a file and then immediately drop the power, the chances
> >are you will not see the data after reboot. If you do a metadata operation
> >and imediately drop power, there is also a chance it will be not be present
> >after reboot. The filesystem however, will be in a consistent state.
> >
> >
> >>Is there anyway to mount with less latency on the writes?
> >
> >You can control the frequency of data getting flushed to disk (both file
> >data and metadata in the journal) with the bdflush parameters in
> >
> >/proc/sys/vm/bdflush
> >
> >Steve
> >
> >>
> >>--
> >>Austin Gonyou
> >>Systems Architect, CCNA
> >>Coremetrics, Inc.
> >>Phone: 512-796-9023
>
> >>email: austin@coremetrics.com
> >>
> >>On Fri, 11 May 2001, Marc Jauvin wrote:
> >>
> >> > I understand, but the file should have been kept to its original state,
> >>no?>>  I
> >> > had garbage all over the file after the reset...
> >> >
> >> >
> >> > Russell Cattelan wrote:
> >> >
> >> > > Marc Jauvin wrote:
> >> >
> >> > >> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
> >> > >>
> >> > >> ----
> >> > >>
> >> > >> I installed XFS 1.0 for RedHat 7.1 and everything is great... until
> >>I di>> d the
> >> > >> following:
> >> > >>
> >> > >> make modification to /etc/fstab, and IMMEDIATELY after saving the
> >> > >> modifications, I hit the reset button; when the system reboots, the
> >> > >> /etc/fstab is baddly corrupted and XFS does not fix it (end up using
> >>the>> > >> linux rescue disk to fix fstab manually\)
> >> > >>
> >> > >> I could reproduce the bug 2 times;
> >> >
> >> > >> Any idea\?
> >> >
> >> > > Yes don't do that.
> >> > > XFS uses delayed allocation / delayed write by default any data
> >>written
> >> > > immediacy before a crash probably won't be on
> >> > > disk, this is known behavior and isn't considered a bug, it's a trade
> >>off>> .
> >> > > Full sync mode on file systems is much safer and gives more likely
> >>hood o>> f
> >> > > data integrity. caches gives much better
> >> > > performance but has the potential of losing cached data in the event
> >>of a>> > > crash.
> >> >
> >> >
> >> >
> >> > --
> >> > marc.
> >> >
> >> > 3 out of 4 Americans make up 75% of the population.
> >> >
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May 15 14:08:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FL8tb21454
	for linux-xfs-outgoing; Tue, 15 May 2001 14:08:55 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FL8pF21451
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:08:55 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4FL8i2k025682;
	Tue, 15 May 2001 14:08:44 -0700
Date: Tue, 15 May 2001 14:08:44 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Dana Soward <dragon@thegoop.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues.
In-Reply-To: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
Message-ID: <Pine.LNX.4.21.0105151406040.31449-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I too have a problem with using quota in xfs, when I mount -a in a single
user I get this error:
Out of Memory. Killed process 1 (sh).

My machine has 256MB, the xfs partition size is 350GB.
free output:
[root@gauss xfs]# free
             total       used       free     shared    buffers     cached
Mem:        255056     252676       2380          0        884      60308
-/+ buffers/cache:     191484      63572
Swap:       658656       3760     654896

I'm going to double the RAM to 512MB to see if that fixes the quota
problem.


*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Tue, 15 May 2001, Dana Soward wrote:

> Is anyone else having memory problems  with the CVS kernel?  Ive got a
> server here with 384MB, and its using 325 of it right now.  It should be
> using about 30, tops.  It *might* be something to do with debian woody,
> but i wanna make sure no one else is having XFS issues.  Also, i cant seem
> to get quota working.  I'm using devfs, but i dont think thats the issue,
> when i switched to XFS kernels i started getting this error from quota:
> 
> fudd:/home# /etc/init.d/quota start
> Checking quotas...done.
> Turning on quotas.
> quotaon: using /home/quota.group on
> /dev/ide/host2/bus0/target0/lun0/part9: Invalid argument
> quotaon: using /home/quota.user on
> /dev/ide/host2/bus0/target0/lun0/part9: Invalid argument
> 
> Any ideas? I dont know if its XFS, but id like to atleast rule it out.
> 
> Thanks.
> 
> Dana
> 


From owner-linux-xfs@oss.sgi.com Tue May 15 14:15:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLFnr21578
	for linux-xfs-outgoing; Tue, 15 May 2001 14:15:49 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLFmF21575
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:15:48 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1538980
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 23:15:40 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1823631; Tue, 15 May 2001 16:14:21 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA12673; Tue, 15 May 2001 16:14:21 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FLGCV08057; Tue, 15 May 2001 16:16:12 -0500
Message-Id: <200105152116.f4FLGCV08057@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: marchuk@ee.washington.edu
cc: Dana Soward <dragon@thegoop.com>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: Message from <marchuk@ee.washington.edu> 
   of "Tue, 15 May 2001 14:08:44 PDT." <Pine.LNX.4.21.0105151406040.31449-100000@darkstar.ee.washington.edu> 
Date: Tue, 15 May 2001 16:16:12 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I too have a problem with using quota in xfs, when I mount -a in a single
> user I get this error:
> Out of Memory. Killed process 1 (sh).
> 
> My machine has 256MB, the xfs partition size is 350GB.
> free output:
> [root@gauss xfs]# free
>              total       used       free     shared    buffers     cached
> Mem:        255056     252676       2380          0        884      60308
> -/+ buffers/cache:     191484      63572
> Swap:       658656       3760     654896
> 
> I'm going to double the RAM to 512MB to see if that fixes the quota
> problem.
> 
> 


We are working the quota memory usage issue internally, a memory reclaim
function which is called to prune the quota cache in Irix is not being
called in the linux version right now, so quota memory usage is not being
controlled.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 15 14:23:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLNni21739
	for linux-xfs-outgoing; Tue, 15 May 2001 14:23:49 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLNnF21736
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:23:49 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4FLNcU18869;
	Tue, 15 May 2001 14:23:38 -0700
Date: Tue, 15 May 2001 14:23:38 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: Joshua Baker-LePain <jlb17@duke.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues.
In-Reply-To: <Pine.LNX.4.30.0105151659190.926-100000@chaos.egr.duke.edu>
Message-ID: <Pine.LNX.4.21.0105151421150.15848-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is the output of free.  It IS using it, its not cached.

fudd:/home# free -m
             total       used       free     shared    buffers     cached
Mem:           374        371          3          0          0         28
-/+ buffers/cache:        342         32
Swap:          384          4        380

This is my partition layout aswell:

fudd:/home# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/ide/host2/bus0/target0/lun0/part5
                      1.4G  157M  1.2G  12% /
/dev/ide/host2/bus0/target0/lun0/part1
                       15M  7.7M  7.7M  50% /boot
/dev/ide/host2/bus0/target0/lun0/part6
                      2.4G  1.3G  1.1G  52% /usr
/dev/ide/host2/bus0/target0/lun0/part7
                      1.9G   98M  1.8G   6% /var
/dev/ide/host2/bus0/target0/lun0/part9
                       27G   21G  6.2G  78% /home

All but / are xfs partitions.

Dana

On Tue, 15 May 2001, Joshua Baker-LePain wrote:

> On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote
> 
> > Is anyone else having memory problems  with the CVS kernel?  Ive got a
> > server here with 384MB, and its using 325 of it right now.  It should be
> > using about 30, tops.  It *might* be something to do with debian woody,
> > but i wanna make sure no one else is having XFS issues.  Also, i cant seem
> 
> Are you sure that all that memory is being used?  The 2.4 kernel is very
> aggressive when it comes to cacheing (which is a good thing).  What does
> the output of 'free' say?
> 
> In general, you *want* all your memory used up.  You just don't want
> running processes to be the ones using it all.
> 
> -- 
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University
> 


From owner-linux-xfs@oss.sgi.com Tue May 15 14:27:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLReq21797
	for linux-xfs-outgoing; Tue, 15 May 2001 14:27:40 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLRcF21794
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:27:38 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id OAA04283
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:27:32 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1798544; Tue, 15 May 2001 16:26:09 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA76994; Tue, 15 May 2001 16:26:09 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FLS0n08135; Tue, 15 May 2001 16:28:00 -0500
Message-Id: <200105152128.f4FLS0n08135@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dana Soward <dragon@thegoop.com>
cc: Joshua Baker-LePain <jlb17@duke.edu>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: Message from Dana Soward <dragon@thegoop.com> 
   of "Tue, 15 May 2001 14:23:38 PDT." <Pine.LNX.4.21.0105151421150.15848-100000@daffy.thegoop.com> 
Date: Tue, 15 May 2001 16:28:00 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Could you send the output of 

	cat /proc/slabinfo

This will tell us where the memory might be if it is in the kernel.

Steve


> This is the output of free.  It IS using it, its not cached.
> 
> fudd:/home# free -m
>              total       used       free     shared    buffers     cached
> Mem:           374        371          3          0          0         28
> -/+ buffers/cache:        342         32
> Swap:          384          4        380
> 
> This is my partition layout aswell:
> 
> fudd:/home# df -h
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/ide/host2/bus0/target0/lun0/part5
>                       1.4G  157M  1.2G  12% /
> /dev/ide/host2/bus0/target0/lun0/part1
>                        15M  7.7M  7.7M  50% /boot
> /dev/ide/host2/bus0/target0/lun0/part6
>                       2.4G  1.3G  1.1G  52% /usr
> /dev/ide/host2/bus0/target0/lun0/part7
>                       1.9G   98M  1.8G   6% /var
> /dev/ide/host2/bus0/target0/lun0/part9
>                        27G   21G  6.2G  78% /home
> 
> All but / are xfs partitions.
> 
> Dana
> 
> On Tue, 15 May 2001, Joshua Baker-LePain wrote:
> 
> > On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote
> > 
> > > Is anyone else having memory problems  with the CVS kernel?  Ive got a
> > > server here with 384MB, and its using 325 of it right now.  It should be
> > > using about 30, tops.  It *might* be something to do with debian woody,
> > > but i wanna make sure no one else is having XFS issues.  Also, i cant see
> m
> > 
> > Are you sure that all that memory is being used?  The 2.4 kernel is very
> > aggressive when it comes to cacheing (which is a good thing).  What does
> > the output of 'free' say?
> > 
> > In general, you *want* all your memory used up.  You just don't want
> > running processes to be the ones using it all.
> > 
> > -- 
> > Joshua Baker-LePain
> > Department of Biomedical Engineering
> > Duke University
> > 



From owner-linux-xfs@oss.sgi.com Tue May 15 14:30:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLUEe21874
	for linux-xfs-outgoing; Tue, 15 May 2001 14:30:14 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLUCF21871
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:30:12 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4FLTu018902;
	Tue, 15 May 2001 14:29:56 -0700
Date: Tue, 15 May 2001 14:29:56 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: Steve Lord <lord@sgi.com>
cc: Joshua Baker-LePain <jlb17@duke.edu>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: <200105152128.f4FLS0n08135@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105151428220.15848-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Here you go. FYI, it has only taken about 3.5 days to get to this
level of memory loss.  Thanks for the help.

slabinfo - version: 1.1
kmem_cache            80    117    100    3    3    1
ip_fib_hash           10    113     32    1    1    1
dqtrx                  1     20    192    1    1    1
dquots                39     44    356    4    4    1
ktrace_ent        126277 126280   1024 31570 31570    1
ktrace_hdr        126277 126412     20  748  748    1
xfs_chashlist       4538   6084     20   36   36    1
xfs_ili              700   5778    144  213  214    1
xfs_ifork              0      0     56    0    0    1
xfs_efi_item           0     15    260    0    1    1
xfs_efd_item           0     15    260    0    1    1
xfs_buf_item           4     26    152    1    1    1
xfs_dabuf              0    202     16    0    1    1
xfs_da_state           0     11    340    0    1    1
xfs_trans              1    156    320    1   13    1
xfs_inode         126273 126280    492 15785 15785    1
xfs_btree_cur          0     28    140    0    1    1
xfs_bmap_free_item      0      0     16    0    0    1
page_buf_t            19    360    160    1   15    1
page_buf_reg_t         4    113     32    1    1    1
avl_object_t           5    113     32    1    1    1
avl_entry_t            7    339     32    1    3    1
urb_priv               0      0     32    0    0    1
uhci_desc           1038   1062     64   18   18    1
ip_mrt_cache           0      0     96    0    0    1
tcp_tw_bucket          0     30    128    0    1    1
tcp_bind_bucket       13    113     32    1    1    1
tcp_open_request       0     40     96    0    1    1
inet_peer_cache        0      0     64    0    0    1
ip_dst_cache           5     20    192    1    1    1
arp_cache              2     30    128    1    1    1
nfs_read_data          0      0    384    0    0    1
nfs_write_data         0      0    384    0    0    1
nfs_page               0      0     96    0    0    1
blkdev_requests     2304   2320     96   58   58    1
dnotify cache          0      0     20    0    0    1
file lock cache        1     42     92    1    1    1
fasync cache           0      0     16    0    0    1
uid_cache              7    113     32    1    1    1
skbuff_head_cache    160    360    192   18   18    1
sock                  39     48    928   11   12    1
inode_cache       171286 209160    480 26144 26145    1
bdev_cache          3290   3304     64   56   56    1
sigqueue               0     29    132    0    1    1
kiobuf                19    343   1152    9   49    2
dentry_cache       89099 160770    128 5359 5359    1
dquot                  0      0     96    0    0    1
filp                 551    560     96   14   14    1
names_cache            0      2   4096    0    2    1
buffer_head         5252  45040     96  380 1126    1
mm_struct             45     60    128    2    2    1
vm_area_struct      1778   2006     64   33   34    1
fs_cache              44     59     64    1    1    1
files_cache           44     54    416    6    6    1
signal_act            48     54   1312   18   18    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072            0      0 131072    0    0   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536             9      9  65536    9    9   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             0      0  32768    0    0    8
size-16384(DMA)        0      0  16384    0    0    4
size-16384             3      4  16384    3    4    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192              1      1   8192    1    1    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096             47     47   4096   47   47    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048             42     70   2048   23   35    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             44     48   1024   12   12    1
size-512(DMA)          0      0    512    0    0    1
size-512             314    320    512   40   40    1
size-256(DMA)          0      0    256    0    0    1
size-256            1020   1230    256   75   82    1
size-128(DMA)          0      0    128    0    0    1
size-128            4021   4800    128  159  160    1
size-64(DMA)           0      0     64    0    0    1
size-64            41097  45548     64  772  772    1
size-32(DMA)           0      0     32    0    0    1
size-32            26240  45313     32  356  401    1

On Tue, 15 May 2001, Steve Lord wrote:

> 
> Could you send the output of 
> 
> 	cat /proc/slabinfo
> 
> This will tell us where the memory might be if it is in the kernel.
> 
> Steve
> 
> 
> > This is the output of free.  It IS using it, its not cached.
> > 
> > fudd:/home# free -m
> >              total       used       free     shared    buffers     cached
> > Mem:           374        371          3          0          0         28
> > -/+ buffers/cache:        342         32
> > Swap:          384          4        380
> > 
> > This is my partition layout aswell:
> > 
> > fudd:/home# df -h
> > Filesystem            Size  Used Avail Use% Mounted on
> > /dev/ide/host2/bus0/target0/lun0/part5
> >                       1.4G  157M  1.2G  12% /
> > /dev/ide/host2/bus0/target0/lun0/part1
> >                        15M  7.7M  7.7M  50% /boot
> > /dev/ide/host2/bus0/target0/lun0/part6
> >                       2.4G  1.3G  1.1G  52% /usr
> > /dev/ide/host2/bus0/target0/lun0/part7
> >                       1.9G   98M  1.8G   6% /var
> > /dev/ide/host2/bus0/target0/lun0/part9
> >                        27G   21G  6.2G  78% /home
> > 
> > All but / are xfs partitions.
> > 
> > Dana
> > 
> > On Tue, 15 May 2001, Joshua Baker-LePain wrote:
> > 
> > > On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote
> > > 
> > > > Is anyone else having memory problems  with the CVS kernel?  Ive got a
> > > > server here with 384MB, and its using 325 of it right now.  It should be
> > > > using about 30, tops.  It *might* be something to do with debian woody,
> > > > but i wanna make sure no one else is having XFS issues.  Also, i cant see
> > m
> > > 
> > > Are you sure that all that memory is being used?  The 2.4 kernel is very
> > > aggressive when it comes to cacheing (which is a good thing).  What does
> > > the output of 'free' say?
> > > 
> > > In general, you *want* all your memory used up.  You just don't want
> > > running processes to be the ones using it all.
> > > 
> > > -- 
> > > Joshua Baker-LePain
> > > Department of Biomedical Engineering
> > > Duke University
> > > 
> 
> 


From owner-linux-xfs@oss.sgi.com Tue May 15 14:34:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLY5i21965
	for linux-xfs-outgoing; Tue, 15 May 2001 14:34:05 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLY3F21961
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:34:03 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA1507545
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 23:33:57 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1796201; Tue, 15 May 2001 16:31:26 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA06225; Tue, 15 May 2001 16:31:25 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FLXGD08163; Tue, 15 May 2001 16:33:16 -0500
Message-Id: <200105152133.f4FLXGD08163@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dana Soward <dragon@thegoop.com>
cc: Steve Lord <lord@sgi.com>, Joshua Baker-LePain <jlb17@duke.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: Message from Dana Soward <dragon@thegoop.com> 
   of "Tue, 15 May 2001 14:29:56 PDT." <Pine.LNX.4.21.0105151428220.15848-100000@daffy.thegoop.com> 
Date: Tue, 15 May 2001 16:33:16 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Here you go. FYI, it has only taken about 3.5 days to get to this
> level of memory loss.  Thanks for the help.

Ah ha!

The quick fix it to rebuild your kernel with the xfsdebug and vnode tracing
options turned off. These are development options, I do not thing we should
have made these available externally.

Steve

> 
> slabinfo - version: 1.1
> kmem_cache            80    117    100    3    3    1
> ip_fib_hash           10    113     32    1    1    1
> dqtrx                  1     20    192    1    1    1
> dquots                39     44    356    4    4    1
> ktrace_ent        126277 126280   1024 31570 31570    1
> ktrace_hdr        126277 126412     20  748  748    1
> xfs_chashlist       4538   6084     20   36   36    1
> xfs_ili              700   5778    144  213  214    1
> xfs_ifork              0      0     56    0    0    1
> xfs_efi_item           0     15    260    0    1    1
> xfs_efd_item           0     15    260    0    1    1
> xfs_buf_item           4     26    152    1    1    1
> xfs_dabuf              0    202     16    0    1    1
> xfs_da_state           0     11    340    0    1    1
> xfs_trans              1    156    320    1   13    1
> xfs_inode         126273 126280    492 15785 15785    1
> xfs_btree_cur          0     28    140    0    1    1
> xfs_bmap_free_item      0      0     16    0    0    1
> page_buf_t            19    360    160    1   15    1
> page_buf_reg_t         4    113     32    1    1    1
> avl_object_t           5    113     32    1    1    1
> avl_entry_t            7    339     32    1    3    1
> urb_priv               0      0     32    0    0    1
> uhci_desc           1038   1062     64   18   18    1
> ip_mrt_cache           0      0     96    0    0    1
> tcp_tw_bucket          0     30    128    0    1    1
> tcp_bind_bucket       13    113     32    1    1    1
> tcp_open_request       0     40     96    0    1    1
> inet_peer_cache        0      0     64    0    0    1
> ip_dst_cache           5     20    192    1    1    1
> arp_cache              2     30    128    1    1    1
> nfs_read_data          0      0    384    0    0    1
> nfs_write_data         0      0    384    0    0    1
> nfs_page               0      0     96    0    0    1
> blkdev_requests     2304   2320     96   58   58    1
> dnotify cache          0      0     20    0    0    1
> file lock cache        1     42     92    1    1    1
> fasync cache           0      0     16    0    0    1
> uid_cache              7    113     32    1    1    1
> skbuff_head_cache    160    360    192   18   18    1
> sock                  39     48    928   11   12    1
> inode_cache       171286 209160    480 26144 26145    1
> bdev_cache          3290   3304     64   56   56    1
> sigqueue               0     29    132    0    1    1
> kiobuf                19    343   1152    9   49    2
> dentry_cache       89099 160770    128 5359 5359    1
> dquot                  0      0     96    0    0    1
> filp                 551    560     96   14   14    1
> names_cache            0      2   4096    0    2    1
> buffer_head         5252  45040     96  380 1126    1
> mm_struct             45     60    128    2    2    1
> vm_area_struct      1778   2006     64   33   34    1
> fs_cache              44     59     64    1    1    1
> files_cache           44     54    416    6    6    1
> signal_act            48     54   1312   18   18    1
> size-131072(DMA)       0      0 131072    0    0   32
> size-131072            0      0 131072    0    0   32
> size-65536(DMA)        0      0  65536    0    0   16
> size-65536             9      9  65536    9    9   16
> size-32768(DMA)        0      0  32768    0    0    8
> size-32768             0      0  32768    0    0    8
> size-16384(DMA)        0      0  16384    0    0    4
> size-16384             3      4  16384    3    4    4
> size-8192(DMA)         0      0   8192    0    0    2
> size-8192              1      1   8192    1    1    2
> size-4096(DMA)         0      0   4096    0    0    1
> size-4096             47     47   4096   47   47    1
> size-2048(DMA)         0      0   2048    0    0    1
> size-2048             42     70   2048   23   35    1
> size-1024(DMA)         0      0   1024    0    0    1
> size-1024             44     48   1024   12   12    1
> size-512(DMA)          0      0    512    0    0    1
> size-512             314    320    512   40   40    1
> size-256(DMA)          0      0    256    0    0    1
> size-256            1020   1230    256   75   82    1
> size-128(DMA)          0      0    128    0    0    1
> size-128            4021   4800    128  159  160    1
> size-64(DMA)           0      0     64    0    0    1
> size-64            41097  45548     64  772  772    1
> size-32(DMA)           0      0     32    0    0    1
> size-32            26240  45313     32  356  401    1
> 
> On Tue, 15 May 2001, Steve Lord wrote:
> 
> > 
> > Could you send the output of 
> > 
> > 	cat /proc/slabinfo
> > 
> > This will tell us where the memory might be if it is in the kernel.
> > 
> > Steve
> > 
> > 
> > > This is the output of free.  It IS using it, its not cached.
> > > 
> > > fudd:/home# free -m
> > >              total       used       free     shared    buffers     cached
> > > Mem:           374        371          3          0          0         28
> > > -/+ buffers/cache:        342         32
> > > Swap:          384          4        380
> > > 
> > > This is my partition layout aswell:
> > > 
> > > fudd:/home# df -h
> > > Filesystem            Size  Used Avail Use% Mounted on
> > > /dev/ide/host2/bus0/target0/lun0/part5
> > >                       1.4G  157M  1.2G  12% /
> > > /dev/ide/host2/bus0/target0/lun0/part1
> > >                        15M  7.7M  7.7M  50% /boot
> > > /dev/ide/host2/bus0/target0/lun0/part6
> > >                       2.4G  1.3G  1.1G  52% /usr
> > > /dev/ide/host2/bus0/target0/lun0/part7
> > >                       1.9G   98M  1.8G   6% /var
> > > /dev/ide/host2/bus0/target0/lun0/part9
> > >                        27G   21G  6.2G  78% /home
> > > 
> > > All but / are xfs partitions.
> > > 
> > > Dana
> > > 
> > > On Tue, 15 May 2001, Joshua Baker-LePain wrote:
> > > 
> > > > On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote
> > > > 
> > > > > Is anyone else having memory problems  with the CVS kernel?  Ive got 
> a
> > > > > server here with 384MB, and its using 325 of it right now.  It should
>  be
> > > > > using about 30, tops.  It *might* be something to do with debian wood
> y,
> > > > > but i wanna make sure no one else is having XFS issues.  Also, i cant
>  see
> > > m
> > > > 
> > > > Are you sure that all that memory is being used?  The 2.4 kernel is ver
> y
> > > > aggressive when it comes to cacheing (which is a good thing).  What doe
> s
> > > > the output of 'free' say?
> > > > 
> > > > In general, you *want* all your memory used up.  You just don't want
> > > > running processes to be the ones using it all.
> > > > 
> > > > -- 
> > > > Joshua Baker-LePain
> > > > Department of Biomedical Engineering
> > > > Duke University
> > > > 
> > 
> > 



From owner-linux-xfs@oss.sgi.com Tue May 15 14:37:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLbG422041
	for linux-xfs-outgoing; Tue, 15 May 2001 14:37:16 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLbFF22038
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:37:15 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4FLbA2k031873;
	Tue, 15 May 2001 14:37:10 -0700
Date: Tue, 15 May 2001 14:37:10 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Steve Lord <lord@sgi.com>
cc: Dana Soward <dragon@thegoop.com>, Joshua Baker-LePain <jlb17@duke.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: <200105152133.f4FLXGD08163@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105151436450.31449-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

But my kernel config does not have debug options turned on.  I never turn
on debug options.

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Tue, 15 May 2001, Steve Lord wrote:

> > Here you go. FYI, it has only taken about 3.5 days to get to this
> > level of memory loss.  Thanks for the help.
> 
> Ah ha!
> 
> The quick fix it to rebuild your kernel with the xfsdebug and vnode tracing
> options turned off. These are development options, I do not thing we should
> have made these available externally.
> 
> Steve
> 
> > 
> > slabinfo - version: 1.1
> > kmem_cache            80    117    100    3    3    1
> > ip_fib_hash           10    113     32    1    1    1
> > dqtrx                  1     20    192    1    1    1
> > dquots                39     44    356    4    4    1
> > ktrace_ent        126277 126280   1024 31570 31570    1
> > ktrace_hdr        126277 126412     20  748  748    1
> > xfs_chashlist       4538   6084     20   36   36    1
> > xfs_ili              700   5778    144  213  214    1
> > xfs_ifork              0      0     56    0    0    1
> > xfs_efi_item           0     15    260    0    1    1
> > xfs_efd_item           0     15    260    0    1    1
> > xfs_buf_item           4     26    152    1    1    1
> > xfs_dabuf              0    202     16    0    1    1
> > xfs_da_state           0     11    340    0    1    1
> > xfs_trans              1    156    320    1   13    1
> > xfs_inode         126273 126280    492 15785 15785    1
> > xfs_btree_cur          0     28    140    0    1    1
> > xfs_bmap_free_item      0      0     16    0    0    1
> > page_buf_t            19    360    160    1   15    1
> > page_buf_reg_t         4    113     32    1    1    1
> > avl_object_t           5    113     32    1    1    1
> > avl_entry_t            7    339     32    1    3    1
> > urb_priv               0      0     32    0    0    1
> > uhci_desc           1038   1062     64   18   18    1
> > ip_mrt_cache           0      0     96    0    0    1
> > tcp_tw_bucket          0     30    128    0    1    1
> > tcp_bind_bucket       13    113     32    1    1    1
> > tcp_open_request       0     40     96    0    1    1
> > inet_peer_cache        0      0     64    0    0    1
> > ip_dst_cache           5     20    192    1    1    1
> > arp_cache              2     30    128    1    1    1
> > nfs_read_data          0      0    384    0    0    1
> > nfs_write_data         0      0    384    0    0    1
> > nfs_page               0      0     96    0    0    1
> > blkdev_requests     2304   2320     96   58   58    1
> > dnotify cache          0      0     20    0    0    1
> > file lock cache        1     42     92    1    1    1
> > fasync cache           0      0     16    0    0    1
> > uid_cache              7    113     32    1    1    1
> > skbuff_head_cache    160    360    192   18   18    1
> > sock                  39     48    928   11   12    1
> > inode_cache       171286 209160    480 26144 26145    1
> > bdev_cache          3290   3304     64   56   56    1
> > sigqueue               0     29    132    0    1    1
> > kiobuf                19    343   1152    9   49    2
> > dentry_cache       89099 160770    128 5359 5359    1
> > dquot                  0      0     96    0    0    1
> > filp                 551    560     96   14   14    1
> > names_cache            0      2   4096    0    2    1
> > buffer_head         5252  45040     96  380 1126    1
> > mm_struct             45     60    128    2    2    1
> > vm_area_struct      1778   2006     64   33   34    1
> > fs_cache              44     59     64    1    1    1
> > files_cache           44     54    416    6    6    1
> > signal_act            48     54   1312   18   18    1
> > size-131072(DMA)       0      0 131072    0    0   32
> > size-131072            0      0 131072    0    0   32
> > size-65536(DMA)        0      0  65536    0    0   16
> > size-65536             9      9  65536    9    9   16
> > size-32768(DMA)        0      0  32768    0    0    8
> > size-32768             0      0  32768    0    0    8
> > size-16384(DMA)        0      0  16384    0    0    4
> > size-16384             3      4  16384    3    4    4
> > size-8192(DMA)         0      0   8192    0    0    2
> > size-8192              1      1   8192    1    1    2
> > size-4096(DMA)         0      0   4096    0    0    1
> > size-4096             47     47   4096   47   47    1
> > size-2048(DMA)         0      0   2048    0    0    1
> > size-2048             42     70   2048   23   35    1
> > size-1024(DMA)         0      0   1024    0    0    1
> > size-1024             44     48   1024   12   12    1
> > size-512(DMA)          0      0    512    0    0    1
> > size-512             314    320    512   40   40    1
> > size-256(DMA)          0      0    256    0    0    1
> > size-256            1020   1230    256   75   82    1
> > size-128(DMA)          0      0    128    0    0    1
> > size-128            4021   4800    128  159  160    1
> > size-64(DMA)           0      0     64    0    0    1
> > size-64            41097  45548     64  772  772    1
> > size-32(DMA)           0      0     32    0    0    1
> > size-32            26240  45313     32  356  401    1
> > 
> > On Tue, 15 May 2001, Steve Lord wrote:
> > 
> > > 
> > > Could you send the output of 
> > > 
> > > 	cat /proc/slabinfo
> > > 
> > > This will tell us where the memory might be if it is in the kernel.
> > > 
> > > Steve
> > > 
> > > 
> > > > This is the output of free.  It IS using it, its not cached.
> > > > 
> > > > fudd:/home# free -m
> > > >              total       used       free     shared    buffers     cached
> > > > Mem:           374        371          3          0          0         28
> > > > -/+ buffers/cache:        342         32
> > > > Swap:          384          4        380
> > > > 
> > > > This is my partition layout aswell:
> > > > 
> > > > fudd:/home# df -h
> > > > Filesystem            Size  Used Avail Use% Mounted on
> > > > /dev/ide/host2/bus0/target0/lun0/part5
> > > >                       1.4G  157M  1.2G  12% /
> > > > /dev/ide/host2/bus0/target0/lun0/part1
> > > >                        15M  7.7M  7.7M  50% /boot
> > > > /dev/ide/host2/bus0/target0/lun0/part6
> > > >                       2.4G  1.3G  1.1G  52% /usr
> > > > /dev/ide/host2/bus0/target0/lun0/part7
> > > >                       1.9G   98M  1.8G   6% /var
> > > > /dev/ide/host2/bus0/target0/lun0/part9
> > > >                        27G   21G  6.2G  78% /home
> > > > 
> > > > All but / are xfs partitions.
> > > > 
> > > > Dana
> > > > 
> > > > On Tue, 15 May 2001, Joshua Baker-LePain wrote:
> > > > 
> > > > > On Tue, 15 May 2001 at 1:47pm, Dana Soward wrote
> > > > > 
> > > > > > Is anyone else having memory problems  with the CVS kernel?  Ive got 
> > a
> > > > > > server here with 384MB, and its using 325 of it right now.  It should
> >  be
> > > > > > using about 30, tops.  It *might* be something to do with debian wood
> > y,
> > > > > > but i wanna make sure no one else is having XFS issues.  Also, i cant
> >  see
> > > > m
> > > > > 
> > > > > Are you sure that all that memory is being used?  The 2.4 kernel is ver
> > y
> > > > > aggressive when it comes to cacheing (which is a good thing).  What doe
> > s
> > > > > the output of 'free' say?
> > > > > 
> > > > > In general, you *want* all your memory used up.  You just don't want
> > > > > running processes to be the ones using it all.
> > > > > 
> > > > > -- 
> > > > > Joshua Baker-LePain
> > > > > Department of Biomedical Engineering
> > > > > Duke University
> > > > > 
> > > 
> > > 
> 
> 


From owner-linux-xfs@oss.sgi.com Tue May 15 14:40:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLeLs22146
	for linux-xfs-outgoing; Tue, 15 May 2001 14:40:21 -0700
Received: from marvin.linux-dude.com (c-d68a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.214])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLeJF22143
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:40:20 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f4FLe3k31157;
	Tue, 15 May 2001 23:40:03 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Dana Soward <dragon@thegoop.com>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues.
Date: Tue, 15 May 2001 23:40:02 +0200
X-Mailer: KMail [version 1.2]
References: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
In-Reply-To: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
MIME-Version: 1.0
Message-Id: <01051523400200.19349@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tuesday 15 May 2001 22:47, Dana Soward wrote:
> Is anyone else having memory problems  with the CVS kernel?  Ive got a
> server here with 384MB, and its using 325 of it right now.  It should be
> using about 30, tops.  It *might* be something to do with debian woody,
I believe I've seen that for a while. And all that after only 15 minutes of
doing practically nothing. I haven't tried the kernel from cvs for a couple
of days though.

Greetings,
/jarek

From owner-linux-xfs@oss.sgi.com Tue May 15 14:40:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLepl22164
	for linux-xfs-outgoing; Tue, 15 May 2001 14:40:51 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLepF22161
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:40:51 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id OAA09613
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:40:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1829689; Tue, 15 May 2001 16:39:33 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA93759; Tue, 15 May 2001 16:39:33 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FLfOF08493; Tue, 15 May 2001 16:41:24 -0500
Message-Id: <200105152141.f4FLfOF08493@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: marchuk@ee.washington.edu
cc: Steve Lord <lord@sgi.com>, Dana Soward <dragon@thegoop.com>,
   Joshua Baker-LePain <jlb17@duke.edu>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: Message from marchuk@ee.washington.edu 
   of "Tue, 15 May 2001 14:37:10 PDT." <Pine.LNX.4.21.0105151436450.31449-100000@darkstar.ee.washington.edu> 
Date: Tue, 15 May 2001 16:41:24 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> But my kernel config does not have debug options turned on.  I never turn
> on debug options.
> 

Right, you are seeing a problem with quota memory use and Dana is seeing
debug memory usage. My previous message about quota memory usage is probably
at the back of your issue, a fix is in the works.

Steve





From owner-linux-xfs@oss.sgi.com Tue May 15 14:46:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLkIg22261
	for linux-xfs-outgoing; Tue, 15 May 2001 14:46:18 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLkHF22258
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:46:17 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4FLhwT13750;
	Tue, 15 May 2001 16:43:58 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 15 May 2001 16:43:58 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: adding a new stripe to a stripeset
In-Reply-To: <yq1g0e69ztt.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105151642490.11093-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've done this with veritas, and that's why I'm asking. I'm just trying to
see the limitations. I agree, striping on the same disk won't do anything,
but It's all I've got to test with. I don't care about performance, just
capabilities. Thanks for the feedback.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 15 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> Can this be done? Say I create a new volume like this:
> Austin> vgcreate testvg1 /dev/sda[1-2] /dev/sdb1
>
> Ugh.  Striping on the same disk isn't going to buy you much.
>
>
> Austin> So, I'm asking is there a way to add another stripe to a
> Austin> stripeset, so I can not have an unused pv in my volume group?
>
> Nope.  You can use the extra space in another striped LV, though,
> assuming you have enough space available on the other PVs.
>
> But there's no way to magically change stripe width of an existing
> volume.
>
>


From owner-linux-xfs@oss.sgi.com Tue May 15 14:49:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLnOm22319
	for linux-xfs-outgoing; Tue, 15 May 2001 14:49:24 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLnOF22316
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:49:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA24075
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:48:00 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1715870; Tue, 15 May 2001 16:48:05 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA66387; Tue, 15 May 2001 16:48:05 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4FLnuv09024; Tue, 15 May 2001 16:49:56 -0500
Message-Id: <200105152149.f4FLnuv09024@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Jarek Luberek <jarek@swipnet.se>
cc: Dana Soward <dragon@thegoop.com>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues. 
In-Reply-To: Message from Jarek Luberek <jarek@swipnet.se> 
   of "Tue, 15 May 2001 23:40:02 +0200." <01051523400200.19349@marvin> 
Date: Tue, 15 May 2001 16:49:56 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tuesday 15 May 2001 22:47, Dana Soward wrote:
> > Is anyone else having memory problems  with the CVS kernel?  Ive got a
> > server here with 384MB, and its using 325 of it right now.  It should be
> > using about 30, tops.  It *might* be something to do with debian woody,
> I believe I've seen that for a while. And all that after only 15 minutes of
> doing practically nothing. I haven't tried the kernel from cvs for a couple
> of days though.
> 
> Greetings,
> /jarek

There was another issue with the cvs tree up until late last week in the
2.4.4 version, xfs memory usage would have been very high. This is fixed
now.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 15 14:54:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLseW22439
	for linux-xfs-outgoing; Tue, 15 May 2001 14:54:40 -0700
Received: from tux.mkp.net (tux.mkp.net [130.225.60.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLscF22433
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:54:38 -0700
Received: from tux.mkp.net ([130.225.60.11] helo=jcb.mkp.net)
	by tux.mkp.net with esmtp (Exim 3.16 #1)
	id 14zmlz-0007Uj-00; Tue, 15 May 2001 23:54:32 +0200
Received: (from mkp@localhost)
	by jcb.mkp.net (8.11.0/8.9.3) id f4FLrLS05008;
	Tue, 15 May 2001 17:53:21 -0400
X-Authentication-Warning: jcb.mkp.net: mkp set sender to mkp@mkp.net using -f
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: adding a new stripe to a stripeset
References: <Pine.LNX.4.33.0105151642490.11093-100000@UberGeek.coremetrics.com>
From: "Martin K. Petersen" <mkp@linuxcare.com>
Organization: Linuxcare, Inc.
Date: 15 May 2001 17:53:21 -0400
In-Reply-To: <Pine.LNX.4.33.0105151642490.11093-100000@UberGeek.coremetrics.com>
Message-ID: <yq1puda8ejy.fsf@jcb.mkp.net>
Lines: 14
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:

Austin> I've done this with veritas, and that's why I'm asking. 

Well.  Veritas VM does this by effectively concatenating two stripe
sets.

If you just add a single disk (and the rest in your volume group are
full), the added space won't be striped.

-- 
Martin K. Petersen, Principal Linux Consultant, Linuxcare, Inc.
mkp@linuxcare.com, http://www.linuxcare.com/
SGI XFS for Linux Developer, http://oss.sgi.com/projects/xfs/

From owner-linux-xfs@oss.sgi.com Tue May 15 14:57:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FLvQv22530
	for linux-xfs-outgoing; Tue, 15 May 2001 14:57:26 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FLvPF22527
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 14:57:25 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4FLvNk18621
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 16:57:23 -0500 (CDT)
Message-ID: <3B01A6DC.1624B698@sgi.com>
Date: Tue, 15 May 2001 16:59:56 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - fix pagebuf module use count screwiness
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Tue May 15 14:54:22 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

last mod to this file lost a MOD_INC_USE_COUNT that caused pagebuf
module usage count to go negative.

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95001a
linux/fs/pagebuf/page_buf_locking.c - 1.11
	- Add a MOD_INC_USE_COUNT that got lost in the pagebuf shuffle...

From owner-linux-xfs@oss.sgi.com Tue May 15 15:14:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FMEVm22842
	for linux-xfs-outgoing; Tue, 15 May 2001 15:14:31 -0700
Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FMEUF22839
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:14:30 -0700
Received: from gateway (dhcp181-19-151-24.nm01-c3.cpe.charter-ne.com [24.151.19.181])
	by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id PAA18433
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:14:21 -0700 (PDT)
Message-ID: <000f01c0dd8c$0922a800$0600a8c0@gateway>
Reply-To: "Sean P. Elble" <S_Elble@yahoo.com>
From: "Sean P. Elble" <S_Elble@yahoo.com>
To: <linux-xfs@oss.sgi.com>
Subject: Samba ACLs: /usr/include/linux/acl.h
Date: Tue, 15 May 2001 18:11:47 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000C_01C0DD6A.81692F40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C0DD6A.81692F40
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

One more question . . . where should this acl.h file come from? I did a =
search on my system (find / -name acl.h), and about three different =
versions of this file came up, two being in the Linux source code, with =
one of those under a POSIX directory, and the third was in the XFS ACL =
software directory. I used the one from the XFS ACL directory, and Samba =
_still_ doesn't state that XFS ACL support is there (all it displays is =
Checking for XFS ACL support . . . , with no yes or no answer being =
provided). Any help in this matter would be greatly appreciated. Thanks =
again!

Sean P. Elble

------=_NextPart_000_000C_01C0DD6A.81692F40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One more question . . . =
where&nbsp;should this=20
acl.h file come from? I did a search on my system (find / -name acl.h), =
and=20
about three different versions of this file came up, two being in the =
Linux=20
source code, with one of those under a POSIX directory, and the third =
was in the=20
XFS ACL&nbsp;software directory. I used the one from the XFS ACL =
directory, and=20
Samba _still_ doesn't state that XFS ACL support is there (all it =
displays is=20
Checking for XFS ACL support . . . , with no yes or no answer being =
provided).=20
Any help in this matter would be greatly appreciated. Thanks =
again!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Sean P. =
Elble</FONT></DIV></BODY></HTML>

------=_NextPart_000_000C_01C0DD6A.81692F40--


From owner-linux-xfs@oss.sgi.com Tue May 15 15:24:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FMOC623079
	for linux-xfs-outgoing; Tue, 15 May 2001 15:24:12 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FMOCF23076
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:24:12 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 1B5D61E3D1; Wed, 16 May 2001 00:24:11 +0200 (MEST)
Date: Wed, 16 May 2001 00:23:39 +0200
From: Andi Kleen <ak@suse.de>
To: Dana Soward <dragon@thegoop.com>
Cc: Joshua Baker-LePain <jlb17@duke.edu>, linux-xfs@oss.sgi.com
Subject: Re: Memory and quota issues.
Message-ID: <20010516002338.A2238@gruyere.muc.suse.de>
References: <Pine.LNX.4.30.0105151659190.926-100000@chaos.egr.duke.edu> <Pine.LNX.4.21.0105151421150.15848-100000@daffy.thegoop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0105151421150.15848-100000@daffy.thegoop.com>; from dragon@thegoop.com on Tue, May 15, 2001 at 02:23:38PM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 15, 2001 at 02:23:38PM -0700, Dana Soward wrote:
> This is the output of free.  It IS using it, its not cached.

You cannot distingush between used and cached in Linux, it's all the same
programs and program data and cached file data are all in the same page cache,
and free shows it as mem used.
The buffers column shown in free is only the data used for metadata buffers,
like directories on disk, which is only a small fraction of the cached data.
XFS in fact can put them also into the page cache, so the metadata buffers
are even less important.

-Andi

From owner-linux-xfs@oss.sgi.com Tue May 15 15:25:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FMPvD23117
	for linux-xfs-outgoing; Tue, 15 May 2001 15:25:57 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FMPqF23114
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:25:57 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDE00I74EB2AV@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue,
 15 May 2001 17:25:51 -0500 (CDT)
Date: Tue, 15 May 2001 18:25:11 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: RE: Samba ACLs: /usr/include/linux/acl.h
In-reply-to: <000f01c0dd8c$0922a800$0600a8c0@gateway>
To: "Sean P. Elble" <S_Elble@yahoo.com>
Cc: linux-xfs@oss.sgi.com
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010515182511.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

There _should_ be an acl.h in /usr/include/linux/acl.h

Is it there?

There _needs_ to be /usr/lib/libacl.a.

Is it there?

Is it the same size as the libacl.a in .../cmd/acl/libacl/libacl.a?

On 15-May-2001 Sean P. Elble wrote:
> Hello,
>  
> One more question . . . where should this acl.h file come from? I did a
> search on my system (find / -name acl.h), and about three different
> versions of this file came up, two being in the Linux source code, with
> one of those under a POSIX directory, and the third was in the XFS ACL
> software directory. I used the one from the XFS ACL directory, and Samba
> _still_ doesn't state that XFS ACL support is there (all it displays is
> Checking for XFS ACL support . . . , with no yes or no answer being
> provided). Any help in this matter would be greatly appreciated. Thanks
> again!
>  
> Sean P. Elble

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Tue May 15 15:32:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4FMWXC23224
	for linux-xfs-outgoing; Tue, 15 May 2001 15:32:33 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4FMWVF23221
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:32:32 -0700
Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA02478
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 15:30:47 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA79370; Tue, 15 May 2001 15:24:59 -0700 (PDT)
Message-ID: <3B01AD37.BD977793@sgi.com>
Date: Tue, 15 May 2001 15:27:03 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: Tim Clymo <tim_clymo@hotmail.com>, linux-xfs@oss.sgi.com
Subject: Re: Might have found a bug...
References: <F197fyQgeDKvPEkGhAj00008076@hotmail.com> <3B019A2A.7480C35@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:
> 
> Tim Clymo wrote:
> 
> > At the risk of pushing the point here...
> >
> > I understand all that has been said about delayed writes, caches etc.
> > However, with regard to the original question in this thread, is it
> > still "expected behaviour" for the original source file to be full of
> > garbage if the system is powered off shortly after a non-synced write?
> >
> > Editing a plain text file for example with vi, saving the file and
> > doing an immediate reset - I could understand if the file was back to
> > its original state before the edit was "written", but my experience is
> > that instead it is useless junk.
> 
> If you followed the thread and my last explanation you will note that the file
> was not full of garbage but NULL's. the file had no extents  which means it
> consisted
> entirely of a whole aka NULL's
> As to why the contents of the file where not the 'old' data, most editors
> either
> mv the old copy to a backup name or truncate the file before writing to it.
> Effectively we are dealing with a "new" file and not one that is being
> "updated" or
> written over.
> 


Indeed, this is the case: the original file contains NULL's
but the .swp file contains the correct contents, and in my case,
it included the modifications done < 1 sec before hitting the
power off button. So the solution is:

	vi -r <file-name>

Does that work for you?

ananth.

--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May 15 19:12:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G2Ck126997
	for linux-xfs-outgoing; Tue, 15 May 2001 19:12:46 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G2CjF26994
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 19:12:45 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id EAA1542233
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 04:12:42 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA1830731 for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:11:25 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA39887 for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:11:24 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4G2DDk12584; Tue, 15 May 2001 21:13:13 -0500
Message-Id: <200105160213.f4G2DDk12584@jen.americas.sgi.com>
Date: Tue, 15 May 2001 21:13:13 -0500
Subject: TAKE - clean up uuid support code
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Change the uuid init code, and use a straight semaphore, no effect on
xfs itself.

Date:  Tue May 15 19:10:14 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-base

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95036a
linux/fs/xfs_support/uuid.c - 1.3
	- Make uiud_create usable - it was using an uninitialized lock somehow.

linux/fs/xfs_support/uuid.h - 1.3
	- remove unused prototype

linux/fs/xfs_support/support.c - 1.3
	- remove uneeded initialization call



From owner-linux-xfs@oss.sgi.com Tue May 15 19:50:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G2oPO27670
	for linux-xfs-outgoing; Tue, 15 May 2001 19:50:25 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G2oPF27667
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 19:50:25 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA06074
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 19:50:06 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA1820957 for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:48:50 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA77278 for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:48:50 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4G2ocm16254; Tue, 15 May 2001 21:50:38 -0500
Message-Id: <200105160250.f4G2ocm16254@jen.americas.sgi.com>
Date: Tue, 15 May 2001 21:50:38 -0500
Subject: TAKE - fix mount noatime
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

There was no way to get noatime into xfs prior to this, there were
some readonly combinations which got rejected by the parser too.

Date:  Tue May 15 19:47:50 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95038a
linux/fs/xfs/linux/xfs_super.c - 1.122
	- Pay attention to mount options already parsed by the vfs layer, noatime
	  and readonly are the ones affected here.



From owner-linux-xfs@oss.sgi.com Tue May 15 21:04:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G444Q28598
	for linux-xfs-outgoing; Tue, 15 May 2001 21:04:04 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G443F28595
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:04:03 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA26944
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 21:02:38 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA05694;
	Wed, 16 May 2001 14:03:56 +1000
Date: Wed, 16 May 2001 14:03:56 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105160403.OAA05694@sherman.melbourne.sgi.com>
Subject: TAKE - Make serial console sequence to invoke kdb user defined
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

You can edit drivers/char/serial.c to define kdb_serial_str to any
sequence you like.  This allows users who dislike control-A to define
their own sequence to enter kdb over a serial line.

Date:  Tue May 15 21:01:18 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95042a
linux/drivers/char/serial.c - 1.39


From owner-linux-xfs@oss.sgi.com Tue May 15 23:10:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G6Afr30459
	for linux-xfs-outgoing; Tue, 15 May 2001 23:10:41 -0700
Received: from rmx441-mta.mail.com (rmx441-mta.mail.com [165.251.48.44])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G6AeF30455
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 23:10:40 -0700
Received: from weba7.iname.net (weba07.mail.com [165.251.4.17])
	by rmx441-mta.mail.com (8.9.3/8.9.3) with ESMTP id CAA04163;
	Wed, 16 May 2001 02:10:27 -0400 (EDT)
From: lmj@homemail.com
Received: (from root@localhost)
	by weba7.iname.net (8.9.1a/8.9.2.Alpha2) id CAA20934;
	Wed, 16 May 2001 02:10:26 -0400 (EDT)
MIME-Version: 1.0
Message-Id: <0105160210265M.00126@weba7.iname.net>
Date: Wed, 16 May 2001 02:10:26 -0400 (EDT)
Content-Type: Text/Plain
Content-Transfer-Encoding: 7bit
To: linux-xfs@oss.sgi.com
Subject: Patch problem
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello


This is practically identical to a question posted by
Jan Jonasson on 2 May. Using the answers posted in that
mail thread I still have a problem with this new patch
for 2.4.4.

I'm trying to apply the
linux-2.4.4-xfs-cvs-05152001.patch.gz on a 2.4.4 kernel
according to the instructions at
http://linux-xfs.sgi.com/projects/xfs/1.0_source.html .

I apply the patch in the /usr/src/linux directory, using
the -p1 flag.

I get the following messages:

patching file linux/Documentation/CVS/Entries
patching file linux/Documentation/CVS/Repository
patching file linux/Documentation/CVS/Root
can't find file to patch at input line 326553
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -rNu linux-2.4.4/linux/Documentation/Changes
linux-2.4-xfs/linux/Documentation/Changes
|--- linux-2.4.4/linux/Documentation/Changes Wed Apr 11 21:02:27 2001
|+++ linux-2.4-xfs/linux/Documentation/Changes Wed May 2 01:22:13 2001
--------------------------
File to patch:



Similar errors are reported from other subdirectories,
not just Documentation. All of them seem to have one
thing in common and that is that they want to patch a
file in a CVS subdirectory.

What am I doing wrong?

Another question. How stable is this patch compared to
patches for 2.4.2 and 2.4.3?

Thanks
Magnus Johansson
(I am not on the mailing list.)

------------------------------------------------------
Get the Latest News at CNN Interactive: http://CNN.com

From owner-linux-xfs@oss.sgi.com Tue May 15 23:14:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G6Evu30510
	for linux-xfs-outgoing; Tue, 15 May 2001 23:14:57 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G6EtF30507
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 23:14:55 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA18352;
	Wed, 16 May 2001 08:14:53 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id IAA16959;
	Wed, 16 May 2001 08:14:51 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 2A60557306; Wed, 16 May 2001 08:23:52 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 1BCE125835; Wed, 16 May 2001 08:24:57 +0200 (CEST)
Message-ID: <3B021BD1.17AA61BE@ch.sauter-bc.com>
Date: Wed, 16 May 2001 08:18:57 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Tom Duffy <tduffy@engr.sgi.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: xfs on small memory
References: <Pine.LNX.4.33.0105150911000.300-100000@dbear.engr.sgi.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The disk was not in sync because I never gave a chance to finish
syncing after install. I did not kill power!
I will crash this machine tonight :-)

Simon

Tom Duffy schrieb:
> 
> > I made the lowmem test with my test machine. It is a pentium 200 and
> > I used 12MB of ram. The disks are two Quantum Fireballs 15GB with DMA
> > enabled. The disks have 3 partitions each configured as RAID 1.
> > /dev/md0 /boot  (50M)
> > /dev/md2 /      (14G)
> > /dev/md1 swap   (500M)
> >
> > The RAID /dev/md2 was syncing while I ran hevy NFS and disk to disk
> > copy traffic and I updated some RPMS. Everything worked very fine!!!
> > No crash, no endless swapping.
> > The same test with only 8MB ram was a pain because lack of ressources.
> 
> did you kill power to the machine and try a reboot w/ 12MB RAM?  did the
> XFS recovery go OK.  I guess this might be explicit from your email when
> you said that you were doing a raid resync, but I just want to be clear.
> 
> thanks,
> 
> -tduffy

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Tue May 15 23:31:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G6VIS30790
	for linux-xfs-outgoing; Tue, 15 May 2001 23:31:18 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G6VHF30787
	for <linux-xfs@oss.sgi.com>; Tue, 15 May 2001 23:31:18 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4G6UxaJ008501;
	Wed, 16 May 2001 01:31:08 -0500 (CDT)
Message-ID: <3B022C0E.6A419019@thebarn.com>
Date: Wed, 16 May 2001 02:28:14 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: lmj@homemail.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Patch problem
References: <0105160210265M.00126@weba7.iname.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

lmj@homemail.com wrote:

> Hello
>
> This is practically identical to a question posted by
> Jan Jonasson on 2 May. Using the answers posted in that
> mail thread I still have a problem with this new patch
> for 2.4.4.
>
> I'm trying to apply the
> linux-2.4.4-xfs-cvs-05152001.patch.gz on a 2.4.4 kernel
> according to the instructions at
> http://linux-xfs.sgi.com/projects/xfs/1.0_source.html .

Those instructions do not apply to this patch

were where you when applied the patch?
you should be one level up from the linux base.
Look at the path names in the patch should make more
sense after that.

>
>
> I apply the patch in the /usr/src/linux directory, using
> the -p1 flag.
>
> I get the following messages:
>
> patching file linux/Documentation/CVS/Entries
> patching file linux/Documentation/CVS/Repository
> patching file linux/Documentation/CVS/Root
> can't find file to patch at input line 326553
> Perhaps you used the wrong -p or --strip option?
> The text leading up to this was:
> --------------------------
> |diff -rNu linux-2.4.4/linux/Documentation/Changes
> linux-2.4-xfs/linux/Documentation/Changes
> |--- linux-2.4.4/linux/Documentation/Changes Wed Apr 11 21:02:27 2001
> |+++ linux-2.4-xfs/linux/Documentation/Changes Wed May 2 01:22:13 2001
> --------------------------
> File to patch:
>
> Similar errors are reported from other subdirectories,
> not just Documentation. All of them seem to have one
> thing in common and that is that they want to patch a
> file in a CVS subdirectory.
>
> What am I doing wrong?
>
> Another question. How stable is this patch compared to
> patches for 2.4.2 and 2.4.3?
>
> Thanks
> Magnus Johansson
> (I am not on the mailing list.)
>
> ------------------------------------------------------
> Get the Latest News at CNN Interactive: http://CNN.com


From owner-linux-xfs@oss.sgi.com Wed May 16 00:32:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G7WxV32168
	for linux-xfs-outgoing; Wed, 16 May 2001 00:32:59 -0700
Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G7WuF32165
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 00:32:57 -0700
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO202.gate.nec.co.jp (8.9.3/3.7W01041220) with ESMTP id QAA20124
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:33:00 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.9.3/3.7W-MAILGATE-NEC) with ESMTP
	id QAA14710 for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:32:53 +0900 (JST)
Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f4G7WnB23959 for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:32:50 +0900 (JST)
Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4])
          by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J
          release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA166
          for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:32:39 +0900
Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed May 16 16:32:38 2001 +0900
Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.101.142])
	by mailsv.tnes.nec.co.jp (8.9.3/3.7W01031510) with ESMTP id QAA35699
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:32:47 +0900 (JST)
Received: from bsd.tnes.nec.co.jp (izumi.bsd.tnes.nec.co.jp [10.1.101.168])
	by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id f4G7Wlc08295
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:32:47 +0900
Message-ID: <3B022DAF.C679F51@bsd.tnes.nec.co.jp>
Date: Wed, 16 May 2001 16:35:11 +0900
From: Takayuki Sasaki <sasaki@bsd.tnes.nec.co.jp>
X-Mailer: Mozilla 4.75 [ja] (Win98; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: cmd/xfstests/032 failed
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

One of the XFS QA SUITE, cmd/xfstests/032 reports an error on my machine 
as follows:

# ./check 032
make: Nothing to be done for `default'.
032 - output mismatch (see 032.out.bad)
2a3,13
> mkfs.xfs: /dev/sda13 appears to contain an existing filesystem (bfs).
> mkfs.xfs: Use the -f option to force overwrite
> mkfs.xfs: /dev/sda13 appears to contain an existing filesystem (ext2).
> mkfs.xfs: Use the -f option to force overwrite
> Failed - overwrote fs type jfs!
> mkfs.xfs: /dev/sda13 appears to contain an existing filesystem (minix).
> mkfs.xfs: Use the -f option to force overwrite
> mkfs.xfs: /dev/sda13 appears to contain an existing filesystem (vfat).
> mkfs.xfs: Use the -f option to force overwrite
> mkfs.xfs: /dev/sda13 appears to contain an existing filesystem (xfs).
> mkfs.xfs: Use the -f option to force overwrite
Failures: 032
Failed 1 of 1 tests

I checked cmd/xfsprogs/mkfs/mountinfo.c, and I guess this may be caused
by
fstype() which does not check whether the file system is jfs or not.

Any sugestions?

Thanks in advance,
Takayuki Sasaki

From owner-linux-xfs@oss.sgi.com Wed May 16 00:43:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G7hQE32352
	for linux-xfs-outgoing; Wed, 16 May 2001 00:43:26 -0700
Received: from nebulascape.dyndns.org (eem12.resnet.cornell.edu [128.253.247.185])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G7hKF32344
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 00:43:25 -0700
Received: (from eem12@localhost)
	by nebulascape.dyndns.org (8.11.2/8.11.2) id f4G7f1n31269
	for linux-xfs@oss.sgi.com; Wed, 16 May 2001 03:41:01 -0400
Date: Wed, 16 May 2001 03:41:01 -0400
From: Ed McKenzie <eem12@cornell.edu>
To: linux-xfs@oss.sgi.com
Subject: XFS hangs running benchmark?
Message-ID: <20010516034101.A31153@cornell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi all,

	Just a heads-up to a possible bug ...

	On the reiserfs mailing list there was some discussion of
benchmark results (reiserfs, xfs, ext2, ext3), but it seems XFS hung
on one of the benchmarks. See

   http://marc.theaimsgroup.com/?l=reiserfs&m=98995044704142&w=2

-- 
Ed McKenzie
<eem12@cornell.edu>

From owner-linux-xfs@oss.sgi.com Wed May 16 02:54:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4G9s8j02538
	for linux-xfs-outgoing; Wed, 16 May 2001 02:54:08 -0700
Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4G9s5F02535
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 02:54:06 -0700
Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4])
	by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f4G9rjZ29914;
	Wed, 16 May 2001 19:53:46 +1000 (EST)
Date: Wed, 16 May 2001 19:53:46 +1000 (EST)
From: Chris Pascoe <c.pascoe@csee.uq.edu.au>
To: Tom Duffy <tduffy@engr.sgi.com>
cc: ML do XFS <linux-xfs@oss.sgi.com>
Subject: minor mkfs.xfs.8 page bug
In-Reply-To: <Pine.LNX.4.33.0105150859260.300-100000@dbear.engr.sgi.com>
Message-ID: <Pine.GSO.4.33.0105161945130.475-200000@mango.csee.uq.edu.au>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-990006826=:475"
X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-758783491-990006826=:475
Content-Type: TEXT/PLAIN; charset=US-ASCII


> ... like the directory format on linux
> defaults to version 2 where on irix, it uses v1.  but, you should be able
> to use both in linux and irix.

Little note, the manual page for mkfs.xfs from the current CVS tree says
that it defaults to version 1.  diff against /xfsprogs/man/man8/mkfs.xfs.8
attached.

Chris

---559023410-758783491-990006826=:475
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mkfs.xfs.8.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.33.0105161953460.475@mango.csee.uq.edu.au>
Content-Description: 
Content-Disposition: attachment; filename="mkfs.xfs.8.diff"

SW5kZXg6IG1rZnMueGZzLjgNCj09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NClJD
UyBmaWxlOiAvY3ZzL2xpbnV4LTIuNC14ZnMvY21kL3hmc3Byb2dzL21hbi9t
YW44L21rZnMueGZzLjgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjUNCmRp
ZmYgLXUgLXIxLjUgbWtmcy54ZnMuOA0KLS0tIG1rZnMueGZzLjggIDIwMDEv
MDUvMTUgMDM6NDM6MjMgICAgIDEuNQ0KKysrIG1rZnMueGZzLjggIDIwMDEv
MDUvMTYgMDk6NDk6MTANCkBAIC0zMzYsNyArMzM2LDcgQEANCiBhbmQNCiBc
ZjN2ZXJzaW9uPVxmMVxmMnZhbHVlXGYxLg0KIFRoZSBuYW1pbmcgKGRpcmVj
dG9yeSkgdmVyc2lvbiBpcyAxIG9yIDIsDQotZGVmYXVsdGluZyB0byAxIGlm
IHVuc3BlY2lmaWVkLg0KK2RlZmF1bHRpbmcgdG8gMiBpZiB1bnNwZWNpZmll
ZC4NCiBXaXRoIHZlcnNpb24gMiBkaXJlY3RvcmllcywNCiB0aGUgZGlyZWN0
b3J5IGJsb2NrIHNpemUgY2FuIGJlIGFueSBwb3dlciBvZiAyIHNpemUNCiBm
cm9tIHRoZSBmaWxlc3lzdGVtIGJsb2NrIHNpemUgdXAgdG8gNjU1MzYuDQo=
---559023410-758783491-990006826=:475--

From owner-linux-xfs@oss.sgi.com Wed May 16 03:45:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GAjim03588
	for linux-xfs-outgoing; Wed, 16 May 2001 03:45:44 -0700
Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GAjgF03585
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 03:45:42 -0700
Received: from pclab (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229])
	by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with SMTP id MAA719822;
	Wed, 16 May 2001 12:45:31 +0200
Message-Id: <3.0.6.32.20010516124515.007e84b0@mail.cc.kuleuven.ac.be>
X-Sender: pb429905@mail.cc.kuleuven.ac.be
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Wed, 16 May 2001 12:45:15 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: werner maes <werner.maes@cc.kuleuven.ac.be>
Subject: Re: XFS & Kickstart installation
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B016BD0.BFB31CCF@sgi.com>
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
 <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be>
 <3.0.6.32.20010515114656.007b0e60@mail.cc.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>Hi again Werner - 
>
>I'm at a loss here - your ks.cfg works just fine for me, I did an
>install on scsi, and the system installed and came up with no problems.

Hello Eric,

I've now found out why it did not work here. EUREKA!

During install I went to another shell using ALT-F5 and I what did I see
there:

insmod of tlan.o
insmdod of ext3.o
...

During CD-install I also got:

insmod of xfs_support.o
insmod of xfs.o

THESE modules were not loaded when I started from floppy. WHY?
Because I used RedHat's boot disk instead of the boot image provided by SGI.

It now seems to work fine,

Thanks a lot for your support,

Werner 


From owner-linux-xfs@oss.sgi.com Wed May 16 04:01:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GB1UM03811
	for linux-xfs-outgoing; Wed, 16 May 2001 04:01:30 -0700
Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GB1TF03808
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 04:01:29 -0700
Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com
          (InterMail vM.4.01.02.00 201-229-116) with SMTP
          id <20010516110125.HYSX4073.mail.rdc1.tn.home.com@CX376762B>
          for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 04:01:25 -0700
Message-ID: <002001c0ddf7$489a0d50$98520c18@CX376762B>
Reply-To: "Tom Browder" <TBrowder@home.com>
From: "Tom Browder" <tbrowder@home.com>
To: <linux-xfs@oss.sgi.com>
References: <0105160210265M.00126@weba7.iname.net> <3B022C0E.6A419019@thebarn.com>
Subject: How to Use Red Hat Install CD Without a Bootable CD Capability?
Date: Wed, 16 May 2001 05:59:30 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Does anyone know how I might use the XFS Red Hat
installation CD without
bootable CD capability?  The boot.img file is too large to
fit on a floppy, and my
CD won't boot (it should but just won't see bootable CDs for
some reason).

Thanks.

Tom Browder



From owner-linux-xfs@oss.sgi.com Wed May 16 04:08:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GB8uk04066
	for linux-xfs-outgoing; Wed, 16 May 2001 04:08:56 -0700
Received: from dcs.qmw.ac.uk (nick.dcs.qmw.ac.uk [138.37.88.61])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GB8rF04061
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 04:08:54 -0700
Received: from mb (helo=localhost)
	by dcs.qmw.ac.uk with local-esmtp (Exim 3.22 #6)
	id 14zzAi-0000vt-00; Wed, 16 May 2001 12:08:52 +0100
Date: Wed, 16 May 2001 12:08:46 +0100 (BST)
From: Matt Bernstein <mb@dcs.qmw.ac.uk>
To: <linux-xfs@oss.sgi.com>
cc: <linux-kernel@vger.kernel.org>
Subject: Oops with 2.4.3-XFS
Message-ID: <Pine.LNX.4.33.0105161159400.2837-100000@nick.dcs.qmw.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

[ I'm not subscribed to linux-xfs, please cc me ]

We have managed to get a Debian potato system (with the 2.4 updates from
http://people.debian.org/~bunk/debian plus xfs-tools which we imported
from woody) to run 2.4.3-XFS.

However, in testing a directory with lots (~177000) of files, we get the
following oops (copied by hand, and run through ksymoops on a Red Hat box
since the Debian one segfaulted :( )

HTH,

Matt

r2-pc:~/oopsie$ ksymoops -m System.map -v vmlinux -K -L -O -S <oops
ksymoops 2.4.0 on i686 2.4.2-2.  Options used
     -v vmlinux (specified)
     -K (specified)
     -L (specified)
     -O (specified)
     -m System.map (specified)
     -S

Unable to handle kernel NULL pointer dereference at virtual address 00000008 printing eip:
c01950e9
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c01950e9>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010256
eax: 00000000   ebx: cff25c00   ecx: 00000008   edx: 00000008
esi: 00000000   edi: 00000005   ebp: 00000000   esp: cee59b94
ds: 0018   es: 0018   ss: 0018
Process xntpd (pid: 364, stackpage=cee59000)
Stack: c0411e90 00000fe6 00000005 c0411e90 c0198682 cd2b06c8 c01986e6 00000000
       02683f18 00000000 00000010 c0411e08 0000e016 c01980d7 cff25c00 00000000
       cbf894b0 cee59c04 cee59c08 00000000 00000000 cbf894b0 00000fe6 00000bb0
Call Trace: [<c0198682>] [<c01986e6>] [<c01980d7>] [<c0199074>] [<c01992e0>] [<c01a95b2>] [<c019c33e>]
       [<c019b7a1>] [<c01a85d4>] [<c0196c24>] [<c01aed54>] [<c01af5af>] [<c0106fe0>] [<c01bf124>] [<c01be417>]
       [<c014182b>] [<c013fb4e>] [<c013fe31>] [<c0127fef>] [<c0128162>] [<c0128e3e>] [<c0128ef4>] [<c013c183>]
       [<c01f3c67>] [<c01f0773>] [<c013c3cf>] [<c013c91d>] [<c0106f37>]
Code: f6 45 08 04 74 09 8b 55 30 01 c2 eb 12 89 f6 50 55 e8 51 9f

>>EIP; c01950e9 <xfs_itobp+139/1e0>   <=====
Trace; c0198682 <xfs_iflush_int+272/300>
Trace; c01986e6 <xfs_iflush_int+2d6/300>
Trace; c01980d7 <xfs_iflush+b7/3f0>
Trace; c0199074 <xfs_inode_item_trylock+24/80>
Trace; c01992e0 <xfs_inode_item_push+10/20>
Trace; c01a95b2 <xfs_trans_push_ail+122/200>
Trace; c019c33e <xlog_grant_push_ail+15e/170>
Trace; c019b7a1 <xfs_log_reserve+41/90>
Trace; c01a85d4 <xfs_trans_reserve+84/140>
Trace; c0196c24 <xfs_itruncate_finish+354/3f0>
Trace; c01aed54 <xfs_inactive_free_eofblocks+284/2d0>
Trace; c01af5af <xfs_inactive+10f/480>
Trace; c0106fe0 <ret_from_intr+0/20>
Trace; c01bf124 <vn_put+34/50>
Trace; c01be417 <linvfs_put_inode+17/20>
Trace; c014182b <iput+2b/150>
Trace; c013fb4e <prune_dcache+de/150>
Trace; c013fe31 <shrink_dcache_memory+21/30>
Trace; c0127fef <do_try_to_free_pages+5f/80>
Trace; c0128162 <try_to_free_pages+22/30>
Trace; c0128e3e <__alloc_pages+24e/2f0>
Trace; c0128ef4 <__get_free_pages+14/20>
Trace; c013c183 <__pollwait+33/a0>
Trace; c01f3c67 <datagram_poll+27/f0>
Trace; c01f0773 <sock_poll+23/30>
Trace; c013c3cf <do_select+11f/210>
Trace; c013c91d <sys_select+42d/5a0>
Trace; c0106f37 <system_call+33/38>
Code;  c01950e9 <xfs_itobp+139/1e0>            00000000 <_EIP>:
Code;  c01950e9 <xfs_itobp+139/1e0>               0:   f6 45 08 04               testb  $0x4,0x8(%ebp)   <=====
Code;  c01950ed <xfs_itobp+13d/1e0>               4:   74 09                     je     f <_EIP+0xf> c01950f8 <xfs_itobp+148/1e0>
Code;  c01950ef <xfs_itobp+13f/1e0>               6:   8b 55 30                  mov    0x30(%ebp),%edx
Code;  c01950f2 <xfs_itobp+142/1e0>               9:   01 c2                     add    %eax,%edx
Code;  c01950f4 <xfs_itobp+144/1e0>               b:   eb 12                     jmp    1f <_EIP+0x1f> c0195108 <xfs_itobp+158/1e0>
Code;  c01950f6 <xfs_itobp+146/1e0>               d:   89 f6                     mov    %esi,%esi
Code;  c01950f8 <xfs_itobp+148/1e0>               f:   50                        push   %eax
Code;  c01950f9 <xfs_itobp+149/1e0>              10:   55                        push   %ebp
Code;  c01950fa <xfs_itobp+14a/1e0>              11:   e8 51 9f 00 00            call   9f67 <_EIP+0x9f67> c019f050 <xlog_find_zeroed+150/200>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Al/D1vU/2MhEp5cRApvnAKCWumj3KYcd1ucNLVrPwZOWzVxwWQCfaqVg
6L3NvlsLoQgvkPbru2dPYJs=
=z9ET
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Wed May 16 05:25:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GCP3T05823
	for linux-xfs-outgoing; Wed, 16 May 2001 05:25:03 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GCP1F05819
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 05:25:02 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4GCOuv07546
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:24:56 +0800
Received: from kalapati ([203.167.26.55]) by sisa.i-manila.com.ph ; Wed, 16 May 2001 20:25:03 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id F1E244660E6
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:24:52 +0800 (PHT)
Date: Wed, 16 May 2001 20:24:52 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Benchmarking ReiserFS, ext2, XFS
Message-ID: <Pine.LNX.4.21.0105161929390.1579-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

Following the link that Ed McKenzie <eem12@cornell.edu> sent, I read the
ReiserFS list archives searching for benchmarks comparing the performance
of ReiserFS, ext2, and XFS.

Here are results of benchmarks comparing the three using mongo.pl (what
seems to be a pretty extensive benchmark test suite that is has been used
by the ReiserFS development team to measure the performance of their
filesystem since they started, it seems).

<http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ext2-reiserfs-xfs.html>

These test were done on a machine running RedHat 7.1 with the Linux kernel
2.4.3, with a Duron 700MHz CPU, 128MB RAM, and a 9GB SCSI HDD. Filesystem
versions compared are: Ext2 version 0.5b, ReiserFS version 3.6.25, and XFS
version 1.0.

Perhaps the XFS developers would have something to say about the test
results? Speculations on how much better the latest CVS copy of XFS will
perform on Linux 2.4.4?

I do not have a machine to do benchmarks, but if someone out there has, it
would be great to see an updated comparison.

Also I'd like to relay the comments of someone on IRC that I got to chat
with when trying to find someone to talk to about these benchmarks. He/she
said that his/her only real irk with XFS is that the developers aren't
able to keep track of the -ac patches. As a consequence, he is in constant
need of fixing patch rej's. ReiserFS is at an advantage here, because it
has been incorporated into the Linux 2.4 kernel tree.

Comments?

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Wed May 16 07:47:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GElKA08652
	for linux-xfs-outgoing; Wed, 16 May 2001 07:47:20 -0700
Received: from web11706.mail.yahoo.com (web11706.mail.yahoo.com [216.136.172.72])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4GElKF08649
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 07:47:20 -0700
Message-ID: <20010516144716.92978.qmail@web11706.mail.yahoo.com>
Received: from [209.150.5.114] by web11706.mail.yahoo.com; Wed, 16 May 2001 07:47:16 PDT
Date: Wed, 16 May 2001 07:47:16 -0700 (PDT)
From: Sean Elble <s_elble@yahoo.com>
Subject: Samba ACLs - Latest Samba & XFS CVS
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello (again!),

I downloaded the latest Samba and XFS CVS versions
yesterday, and tried to compile ACL support, yet
again. I'm still getting the same message, that
doesn't specify if XFS ACL suppor is being enabled! I
really need some help . . . I've put the acl.h file in
/usr/include/linux/acl.h, and I have
/usr/lib/libacl.a, but it _still_ isn't working. John,
I thank you for all of your help, but, I really don't
know why this isn't working. Is there any way I can
force Samba to put XFS ACL support in? I'm desperate
at this point. One more thing; I'm using Windows 2000
RC2 (Beta); now, I doubt this means anything, since it
isn't explicitly stating the support was enabled, but,
just letting you know . . . Thanks again for all of
your valuable help.

Sean

=====
------------------------------
Sean Elble
MaximumLinux.org
Voice Mail: 1-800-699-2466; Voice Mail Box 8603550213
E-Mail: S_Elble@yahoo.com
------------------------------

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Wed May 16 07:58:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GEw1708858
	for linux-xfs-outgoing; Wed, 16 May 2001 07:58:01 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GEw0F08855
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 07:58:01 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4GEvb519239;
	Wed, 16 May 2001 09:57:37 -0500 (CDT)
Message-ID: <3B029601.E082FD0B@sgi.com>
Date: Wed, 16 May 2001 10:00:17 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: lmj@homemail.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Patch problem
References: <0105160210265M.00126@weba7.iname.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

lmj@homemail.com wrote:

 
> Another question. How stable is this patch compared to
> patches for 2.4.2 and 2.4.3?

And the answer to this is, it's NOT stable compared to 2.4.2 and 2.4.3.

It's a snapshot of a point in time when the patch was made.

In fact, it's possible (although unlikely) that it won't even compile.

Unless you're planning on tracking CVS and the mailing list to stay up
to date, you should use either the 2.4.2 or 2.4.3 patch for now.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 07:59:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GExXV08906
	for linux-xfs-outgoing; Wed, 16 May 2001 07:59:33 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GExXF08903
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 07:59:33 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4GExV519640;
	Wed, 16 May 2001 09:59:31 -0500 (CDT)
Message-ID: <3B029673.F51DC230@sgi.com>
Date: Wed, 16 May 2001 10:02:11 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Browder <TBrowder@home.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: How to Use Red Hat Install CD Without a Bootable CD Capability?
References: <0105160210265M.00126@weba7.iname.net> <3B022C0E.6A419019@thebarn.com> <002001c0ddf7$489a0d50$98520c18@CX376762B>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Browder wrote:
> 
> Does anyone know how I might use the XFS Red Hat
> installation CD without
> bootable CD capability?  The boot.img file is too large to
> fit on a floppy,

The boot.img file should be _exactly_ the same size as your floppy.

Don't try to copy it to the floppy, use:

$ dd if=boot.img of=/dev/fd0 bs=1440k

to make the boot floppy.

It's an image of a floppy disk, not a file that should be copied to a
floppy disk.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 08:05:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GF55o09291
	for linux-xfs-outgoing; Wed, 16 May 2001 08:05:05 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GF54F09288
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:05:04 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA27853
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:03:41 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1833992; Wed, 16 May 2001 10:03:47 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA75915; Wed, 16 May 2001 10:03:46 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GF5So17570; Wed, 16 May 2001 10:05:28 -0500
Message-Id: <200105161505.f4GF5So17570@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Matt Bernstein <mb@dcs.qmw.ac.uk>
cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Oops with 2.4.3-XFS 
In-Reply-To: Message from Matt Bernstein <mb@dcs.qmw.ac.uk> 
   of "Wed, 16 May 2001 12:08:46 BST." <Pine.LNX.4.33.0105161159400.2837-100000@nick.dcs.qmw.ac.uk> 
Date: Wed, 16 May 2001 10:05:28 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> [ I'm not subscribed to linux-xfs, please cc me ]
> 
> We have managed to get a Debian potato system (with the 2.4 updates from
> http://people.debian.org/~bunk/debian plus xfs-tools which we imported
> from woody) to run 2.4.3-XFS.
> 
> However, in testing a directory with lots (~177000) of files, we get the
> following oops (copied by hand, and run through ksymoops on a Red Hat box
> since the Debian one segfaulted :( )
> 
> HTH,
> 
> Matt
> 

Can you describe your testing beyond using a directory with 177000 files
in it?

Also, can you explain how you obtained the xfs code, from a patch, from
the cvs development tree, or from somewhere else?

Thanks

   Steve



From owner-linux-xfs@oss.sgi.com Wed May 16 08:11:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFBuu09411
	for linux-xfs-outgoing; Wed, 16 May 2001 08:11:56 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFBtF09408
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:11:55 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03500
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:22:52 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1834118; Wed, 16 May 2001 09:49:57 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA94822; Wed, 16 May 2001 09:49:57 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GEpcj17003; Wed, 16 May 2001 09:51:38 -0500
Message-Id: <200105161451.f4GEpcj17003@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
cc: reiserfs-list@namesys.com
Subject: Re: Benchmarking ReiserFS, ext2, XFS 
References: <Pine.LNX.4.21.0105161929390.1579-100000@kalapati.jijo.local>
Comments: In-reply-to Federico Sevilla III <jijo@i-manila.com.ph>
   message dated "Wed, 16 May 2001 20:24:52 +0800."
Date: Wed, 16 May 2001 09:51:38 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Thanks for the info, I just took a look at the reiserfs archive,
and subscribed to the list. Interesting that no one on the xfs
list was contacted about this with questions such as how to configure
xfs etc (I could say mindcraft here but that might be inflamatory ;-).
It would certainly be interesting to see which config options were
used in the filesystem part of the kernel compile. The RPMs were
shipped with all features turned on which will impact performance,
turning off quotas and acls would be a good thing.

Anyway, I am not surprised reiserfs wins on small file
tests, someone independent might want to ask what happens if you
pull the power in the middle of the test. I suspect the answer on
reiserfs is that almost nothing is on the disk after reboot, the file
creation/removal part of bonnie++ (30000 files created and removed
twice) can complete without disk I/O on reiserfs.

I will download the mongo tests and try them out myself.

As for the ac kernels - I challenge anyone who is working for a living
and has other things to do to keep something the size of XFS upto date
with Alan's kernels - I have seen 3 of those in one day. Plus changes
tend to come and go, and XFS does have its fingers in the VM system,
getting those in sync is not always straight forward, so it is not a
matter of apply a patch and go.

Steve

p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend
this:

    if ( $FILESYSTEM eq "xfs" ) {
        system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
        system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;
    }

This increases the journal size from the default, mounts with 4 in core log
buffers instead of 2 and makes sure that O_SYNC has the same behavior as
it does on ext2. For the release kernel I would also add biosize=13 to
the mount options, this no longer makes a difference in the cvs kernels.


> Hi everyone,
> 
> Following the link that Ed McKenzie <eem12@cornell.edu> sent, I read the
> ReiserFS list archives searching for benchmarks comparing the performance
> of ReiserFS, ext2, and XFS.
> 
> Here are results of benchmarks comparing the three using mongo.pl (what
> seems to be a pretty extensive benchmark test suite that is has been used
> by the ReiserFS development team to measure the performance of their
> filesystem since they started, it seems).
> 
> <http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ext2-reiserfs-xfs.
> html>
> 
> These test were done on a machine running RedHat 7.1 with the Linux kernel
> 2.4.3, with a Duron 700MHz CPU, 128MB RAM, and a 9GB SCSI HDD. Filesystem
> versions compared are: Ext2 version 0.5b, ReiserFS version 3.6.25, and XFS
> version 1.0.

I would ask exactly what was done to apply the 1.0 patches to 2.4.3, this
is not what we released, was this actually the rpm, or was it downloaded
from the cvs tree?

> 
> Perhaps the XFS developers would have something to say about the test
> results? Speculations on how much better the latest CVS copy of XFS will
> perform on Linux 2.4.4?
> 
> I do not have a machine to do benchmarks, but if someone out there has, it
> would be great to see an updated comparison.
> 
> Also I'd like to relay the comments of someone on IRC that I got to chat
> with when trying to find someone to talk to about these benchmarks. He/she
> said that his/her only real irk with XFS is that the developers aren't
> able to keep track of the -ac patches. As a consequence, he is in constant
> need of fixing patch rej's. ReiserFS is at an advantage here, because it
> has been incorporated into the Linux 2.4 kernel tree.
> 
> Comments?
> 
>  --> Jijo
> 
> --
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly



From owner-linux-xfs@oss.sgi.com Wed May 16 08:15:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFFi009562
	for linux-xfs-outgoing; Wed, 16 May 2001 08:15:44 -0700
Received: from dermis.amis.com (dermis.amis.com [207.141.5.253])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4GFFdF09559
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:15:43 -0700
Received: from [172.16.89.23] by dermis.amis.com
          via smtpd (for oss.sgi.com [216.32.174.190]) with SMTP; 16 May 2001 15:15:39 UT
Received: from pop1.amis.com ([172.16.89.10])
          by mx1.pc.amis.com (Lotus Domino Release 5.0.7)
          with ESMTP id 2001051609114329:65467 ;
          Wed, 16 May 2001 09:11:43 -0600 
Received: from amis.com ([172.16.17.176])
          by pop1.amis.com (Lotus Domino Release 5.0.6a)
          with ESMTP id 2001051609152283:1177 ;
          Wed, 16 May 2001 09:15:22 -0600 
Message-ID: <3B029987.4DBE7E7B@amis.com>
Date: Wed, 16 May 2001 09:15:19 -0600
From: Eric Whiting <ewhiting@amis.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.5-pre1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
CC: Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS
References: <Pine.LNX.4.21.0105161929390.1579-100000@kalapati.jijo.local> <200105161451.f4GEpcj17003@jen.americas.sgi.com>
X-MIMETrack: Itemize by SMTP Server on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/16/2001
 09:15:22 AM,
	Serialize by Router on pop1/AMI(Release 5.0.6a |January 17, 2001) at 05/16/2001
 09:15:23 AM,
	Serialize complete at 05/16/2001 09:15:23 AM,
	Itemize by SMTP Server on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/16/2001
 09:11:43 AM,
	Serialize by Router on mx1/amis(Release 5.0.7 |March 21, 2001) at 05/16/2001
 09:12:00 AM,
	Serialize complete at 05/16/2001 09:12:00 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'd like to see IBM's JFS included in the testing. I'm sure others
might like ext3 results.  If I could only get a 2.4.4 kernel to patch
with both xfs and jfs and ext3 and resierfs-knfsd. 

This is not a fs war -- we all love linux and people are trying to
make it better right? reiserfs/xfs/jfs/ext3 are all big improvments
and very much needed. I'm sure there is room for them all and
applications for all of them. I've been watching the reiserfs and xfs
lists. I've been impressed at how competent/helpful/respectful you all
are. 

Also -- I looked at some of those 'published' bonnie numbers on one of
the reiserfs/xfs/ext2 comparisons and it looked like an IDE disk with
DMA turned off. Pretty slow results compared to what I'd expect for
any hard disk less than 2 years old.

eric


Steve Lord wrote:
> 
> Thanks for the info, I just took a look at the reiserfs archive,
> and subscribed to the list. Interesting that no one on the xfs
> list was contacted about this with questions such as how to configure
> xfs etc (I could say mindcraft here but that might be inflamatory ;-).
> It would certainly be interesting to see which config options were
> used in the filesystem part of the kernel compile. The RPMs were
> shipped with all features turned on which will impact performance,
> turning off quotas and acls would be a good thing.
> 
> Anyway, I am not surprised reiserfs wins on small file
> tests, someone independent might want to ask what happens if you
> pull the power in the middle of the test. I suspect the answer on
> reiserfs is that almost nothing is on the disk after reboot, the file
> creation/removal part of bonnie++ (30000 files created and removed
> twice) can complete without disk I/O on reiserfs.
> 
> I will download the mongo tests and try them out myself.
> 
> As for the ac kernels - I challenge anyone who is working for a living
> and has other things to do to keep something the size of XFS upto date
> with Alan's kernels - I have seen 3 of those in one day. Plus changes
> tend to come and go, and XFS does have its fingers in the VM system,
> getting those in sync is not always straight forward, so it is not a
> matter of apply a patch and go.
> 
> Steve
> 
> p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend
> this:
> 
>     if ( $FILESYSTEM eq "xfs" ) {
>         system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
>         system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;
>     }
> 
> This increases the journal size from the default, mounts with 4 in core log
> buffers instead of 2 and makes sure that O_SYNC has the same behavior as
> it does on ext2. For the release kernel I would also add biosize=13 to
> the mount options, this no longer makes a difference in the cvs kernels.
> 
> > Hi everyone,
> >
> > Following the link that Ed McKenzie <eem12@cornell.edu> sent, I read the
> > ReiserFS list archives searching for benchmarks comparing the performance
> > of ReiserFS, ext2, and XFS.
> >
> > Here are results of benchmarks comparing the three using mongo.pl (what
> > seems to be a pretty extensive benchmark test suite that is has been used
> > by the ReiserFS development team to measure the performance of their
> > filesystem since they started, it seems).
> >
> > <http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ext2-reiserfs-xfs.
> > html>
> >
> > These test were done on a machine running RedHat 7.1 with the Linux kernel
> > 2.4.3, with a Duron 700MHz CPU, 128MB RAM, and a 9GB SCSI HDD. Filesystem
> > versions compared are: Ext2 version 0.5b, ReiserFS version 3.6.25, and XFS
> > version 1.0.
> 
> I would ask exactly what was done to apply the 1.0 patches to 2.4.3, this
> is not what we released, was this actually the rpm, or was it downloaded
> from the cvs tree?
> 
> >
> > Perhaps the XFS developers would have something to say about the test
> > results? Speculations on how much better the latest CVS copy of XFS will
> > perform on Linux 2.4.4?
> >
> > I do not have a machine to do benchmarks, but if someone out there has, it
> > would be great to see an updated comparison.
> >
> > Also I'd like to relay the comments of someone on IRC that I got to chat
> > with when trying to find someone to talk to about these benchmarks. He/she
> > said that his/her only real irk with XFS is that the developers aren't
> > able to keep track of the -ac patches. As a consequence, he is in constant
> > need of fixing patch rej's. ReiserFS is at an advantage here, because it
> > has been incorporated into the Linux 2.4 kernel tree.
> >
> > Comments?
> >
> >  --> Jijo
> >
> > --
> > Linux, MS-DOS, and Windows NT ...
> > ... also known as the Good, the Bad, and the Ugly

-- 
__________________________________________________________________
Eric T. Whiting					AMI Semiconductors

From owner-linux-xfs@oss.sgi.com Wed May 16 08:20:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFKG909652
	for linux-xfs-outgoing; Wed, 16 May 2001 08:20:16 -0700
Received: from www.quasihorse.com (cs666825-126.austin.rr.com [66.68.25.126])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFKGF09648
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:20:16 -0700
Received: by www.quasihorse.com (Postfix, from userid 500)
	id D3BE541F; Wed, 16 May 2001 10:18:03 -0500 (CDT)
Date: Wed, 16 May 2001 10:18:03 -0500
From: pac@fortuitous.com
To: linux-xfs@oss.sgi.com
Subject: vmware file locking problem:
Message-ID: <20010516101803.A32539@bistro.marx>
Reply-To: pac@fortuitous.com
References: <yq1g0e69ztt.fsf@jcb.mkp.net> <Pine.LNX.4.33.0105151642490.11093-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <Pine.LNX.4.33.0105151642490.11093-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Tue, May 15, 2001 at 04:43:58PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

 Quoting from Zao Yang (zyang@ubicom.com):
---------------------------------------------------

my home directory and the .vmware directory are on a XFS
filesystem. when I start vmware 2.0.3, it complains about not being able
to detect if file locking is supported on the filesystem. it wants me to
put the following line in the configuration file:

host.FSSupportLocking1 = 0x58465342

I tried that. but vmware still complains with same message. 

vmware used to work when my home directory is on ext2 filesystem. 

I also tried vmware 2.0.4 and had same problem. does anyone know where
the problems might be, and if vmware supports XFS?

--------------------------------------------------------------

 I run vmware 2.0.4 and have the same trouble. Any ideas?
 I had my vmware on Reiser before XFS and it worked ok.
  Thanks,

  -Phil C.
.---------------------------------------------------------
| P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
| Fortuitous Technologies Inc. |  http://fortuitous.com   |
| Linux Training Services      |  Tel : 1-512 467-2154    |
| Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
 ---------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed May 16 08:20:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFKHD09660
	for linux-xfs-outgoing; Wed, 16 May 2001 08:20:17 -0700
Received: from roc-24-169-102-121.rochester.rr.com (roc-24-169-102-121.rochester.rr.com [24.169.102.121])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFKGF09651
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:20:16 -0700
Received: from localhost ([127.0.0.1] helo=tiny)
	by roc-24-169-102-121.rochester.rr.com with esmtp (Exim 3.16 #4)
	id 15033t-0001Hc-00; Wed, 16 May 2001 10:18:05 -0500
Date: Wed, 16 May 2001 11:18:04 -0400
From: Chris Mason <mason@suse.com>
To: Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS 
Message-ID: <114230000.990026284@tiny>
In-Reply-To: <200105161451.f4GEpcj17003@jen.americas.sgi.com>
X-Mailer: Mulberry/2.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


On Wednesday, May 16, 2001 09:51:38 AM -0500 Steve Lord <lord@sgi.com>
wrote:

> 
> Thanks for the info, I just took a look at the reiserfs archive,
> and subscribed to the list. Interesting that no one on the xfs
> list was contacted about this with questions such as how to configure
> xfs etc (I could say mindcraft here but that might be inflamatory ;-).

I hope everyone on the reiserfs lists realizes how informal these
benchmarks are.  If you want a real idea of how <foofs> performs, you've
got to talk with someone who knows a lot about foofs to make sure things
are fair.

> It would certainly be interesting to see which config options were
> used in the filesystem part of the kernel compile. The RPMs were
> shipped with all features turned on which will impact performance,
> turning off quotas and acls would be a good thing.

reiserfs acls are so fast, its like they aren't even there ;-)

> 
> Anyway, I am not surprised reiserfs wins on small file
> tests, someone independent might want to ask what happens if you
> pull the power in the middle of the test. I suspect the answer on
> reiserfs is that almost nothing is on the disk after reboot, the file
> creation/removal part of bonnie++ (30000 files created and removed
> twice) can complete without disk I/O on reiserfs.
> 

In 2.4.4, the metadata flush time is the same as the bdflush metadata
interval (5 secs by default).  Our bonnie++ numbers should be a little
worse  for the file creation tests now.

-chris


From owner-linux-xfs@oss.sgi.com Wed May 16 08:20:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFKM309670
	for linux-xfs-outgoing; Wed, 16 May 2001 08:20:22 -0700
Received: from dcs.qmw.ac.uk (nick.dcs.qmw.ac.uk [138.37.88.61])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFKLF09667
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:20:21 -0700
Received: from mb (helo=localhost)
	by dcs.qmw.ac.uk with local-esmtp (Exim 3.22 #6)
	id 150363-0004oH-00; Wed, 16 May 2001 16:20:19 +0100
Date: Wed, 16 May 2001 16:20:14 +0100 (BST)
From: Matt Bernstein <mb@dcs.qmw.ac.uk>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>, <linux-kernel@vger.kernel.org>
Subject: Re: Oops with 2.4.3-XFS 
In-Reply-To: <200105161505.f4GF5So17570@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105161606240.2837-100000@nick.dcs.qmw.ac.uk>
X-URL: http://www.theBachChoir.org.uk/
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>> However, in testing a directory with lots (~177000) of files, we get the
>> following oops (copied by hand, and run through ksymoops on a Red Hat box
>> since the Debian one segfaulted :( )

>Can you describe your testing beyond using a directory with 177000 files
>in it?
>Also, can you explain how you obtained the xfs code, from a patch, from
>the cvs development tree, or from somewhere else?

Certainly :) (have been investigating further through the day)

The code was obtained as the patches for 2.4.3, (it was also patched for a
scsi changer, but all the scsi stuff is modules that weren't loaded), and
we used your Red Hat ISO in rescue mode to convert our root partition to
XFS.

I'd been trying to hammer a partition remotely. I'd exported it with
knfsd, but the oops I posted was caused by trying to tar said directory
(locally--no NFS involvement) to a file in its parent (which does contain
some large (~4GB) files.

kernel built with egcs-1.1.2, not very much in it, modules loaded at the
time were nfs, sunrpc, lockd, autofs (but I will test again without any of
those loaded when the box is less busy)--I had removed nfsd and friends.

We tried to recreate this on a second box a couple of hours ago and
failed, so we can't rule out a hardware/other non-XFS problem. Two
immediate potential culprits are the VIA KT133 UDMA and the drive itself
(NB the second box has the same motherboard, but not a WDC drive):

# hdparm -i /dev/hda

/dev/hda:

 Model=WDC WD400BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6R1239029
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=0
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=78165360
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4
 UDMA modes: mode0 mode1 mode2 mode3 *mode4 mode5

Thanks for the reply. Any more information on request :)

Matt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Apqx1vU/2MhEp5cRAgecAJ0bAm1Jlay2AjHjGaQ1Zck7/1vOewCgujgD
mAnEXzuyabuUwcPy22e1avM=
=41+h
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Wed May 16 08:21:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFLTP09714
	for linux-xfs-outgoing; Wed, 16 May 2001 08:21:29 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFLTF09711
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:21:29 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 0ECAACAC50A
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 11:20:59 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 150351-0002LA-00
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 11:19:15 -0400
Date: Wed, 16 May 2001 11:19:15 -0400
To: linux-xfs@oss.sgi.com
Subject: Mount options uid,gid
Message-ID: <20010516111915.C23813@chimesnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey people,

Got a quick question,

Will mount options uid= and gid= be supported in the future?

Thanks.

-Tom Carroll

From owner-linux-xfs@oss.sgi.com Wed May 16 08:26:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFQAR09808
	for linux-xfs-outgoing; Wed, 16 May 2001 08:26:10 -0700
Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFQ8F09805
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:26:09 -0700
Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.147] (may be forged))
	by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id RAA32095;
	Wed, 16 May 2001 17:25:46 +0200
Received: from localhost (localhost [127.0.0.1])
	by vie-ac.office.ecetra.com (8.11.3/8.11.3) with ESMTP id f4GFPkK12996;
	Wed, 16 May 2001 17:25:46 +0200
Date: Wed, 16 May 2001 17:25:46 +0200 (CEST)
From: Adam Cioccarelli <alciocca@ecetra.com>
To: <pac@fortuitous.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: vmware file locking problem:
In-Reply-To: <20010516101803.A32539@bistro.marx>
Message-ID: <Pine.LNX.4.33.0105161724240.12813-100000@vie-ac.office.ecetra.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I had the same message, but it's just a message, vmware still works...

Regards,
Adam


On Wed, 16 May 2001 pac@fortuitous.com wrote:

>  Quoting from Zao Yang (zyang@ubicom.com):
> ---------------------------------------------------
>
> my home directory and the .vmware directory are on a XFS
> filesystem. when I start vmware 2.0.3, it complains about not being able
> to detect if file locking is supported on the filesystem. it wants me to
> put the following line in the configuration file:
>
> host.FSSupportLocking1 = 0x58465342
>
> I tried that. but vmware still complains with same message.
>
> vmware used to work when my home directory is on ext2 filesystem.
>
> I also tried vmware 2.0.4 and had same problem. does anyone know where
> the problems might be, and if vmware supports XFS?
>
> --------------------------------------------------------------
>
>  I run vmware 2.0.4 and have the same trouble. Any ideas?
>  I had my vmware on Reiser before XFS and it worked ok.
>   Thanks,
>
>   -Phil C.
> .---------------------------------------------------------
> | P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
> | Fortuitous Technologies Inc. |  http://fortuitous.com   |
> | Linux Training Services      |  Tel : 1-512 467-2154    |
> | Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
>  ---------------------------------------------------------
>


From owner-linux-xfs@oss.sgi.com Wed May 16 08:26:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFQQT09818
	for linux-xfs-outgoing; Wed, 16 May 2001 08:26:26 -0700
Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFQOF09815
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:26:25 -0700
Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11])
	by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id RAA12073;
	Wed, 16 May 2001 17:26:19 +0200
Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18])
	by ep-ag.com (8.9.3/8.9.3) with ESMTP id RAA15613;
	Wed, 16 May 2001 17:26:17 +0200 (MET DST)
Message-ID: <3B029C19.80803@ep-ag.com>
Date: Wed, 16 May 2001 17:26:17 +0200
From: "Klaus Strebel,ITS,204" <stb@ep-ag.com>
Organization: EIGNER+PARTNER AG
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: de, en
MIME-Version: 1.0
To: Sean Elble <s_elble@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Samba ACLs - Latest Samba & XFS CVS
References: <20010516144716.92978.qmail@web11706.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Sean Elble wrote:

> Hello (again!),
> 
> I downloaded the latest Samba and XFS CVS versions
> yesterday, and tried to compile ACL support, yet
> again. I'm still getting the same message, that
> doesn't specify if XFS ACL suppor is being enabled! I
> really need some help . . . I've put the acl.h file in
> /usr/include/linux/acl.h, and I have
> /usr/lib/libacl.a, but it _still_ isn't working. John,
> I thank you for all of your help, but, I really don't
> know why this isn't working. Is there any way I can
> force Samba to put XFS ACL support in? I'm desperate
> at this point. One more thing; I'm using Windows 2000
> RC2 (Beta); now, I doubt this means anything, since it
> isn't explicitly stating the support was enabled, but,
> just letting you know . . . Thanks again for all of
> your valuable help.

Hi Sean,

just can't get the box i first tried it (some weeks ago, samba-2.2.0 was 
not released then ;-) ). Have a look to the configure script of samba. 
They are checking for IRIX platform ACLs only if on irix, because 
xfs-acls are irix acls, you have to convince configure for this test, 
that it is on irix platform. This should bild samba with xfs-acl 
support, but i couldn't test it by now, no spare time (sigh).

If you don't find how to cheat it, let me know, i'll try to find it 
tomorrow.

Bye
Klaus


From owner-linux-xfs@oss.sgi.com Wed May 16 08:27:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFRKT09840
	for linux-xfs-outgoing; Wed, 16 May 2001 08:27:20 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFRJF09836
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:27:19 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA02718
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:27:15 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1832617; Wed, 16 May 2001 10:25:58 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA23340; Wed, 16 May 2001 10:25:58 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GFRdW17637; Wed, 16 May 2001 10:27:39 -0500
Message-Id: <200105161527.f4GFRdW17637@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Tom Carroll <tcarroll@chimesnet.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Mount options uid,gid 
In-Reply-To: Message from Tom Carroll <tcarroll@chimesnet.com> 
   of "Wed, 16 May 2001 11:19:15 EDT." <20010516111915.C23813@chimesnet.com> 
Date: Wed, 16 May 2001 10:27:38 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hey people,
> 
> Got a quick question,
> 
> Will mount options uid= and gid= be supported in the future?
> 
> Thanks.
> 
> -Tom Carroll

Those options appear to be to support filesystems which do not themselves
store uid and gid information internally. So no I do not think we will
support these.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 16 08:31:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFV6g09930
	for linux-xfs-outgoing; Wed, 16 May 2001 08:31:06 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFV5F09927
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:31:05 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4GFSp619519;
	Wed, 16 May 2001 10:28:51 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 16 May 2001 10:28:51 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Martin K. Petersen" <mkp@linuxcare.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: adding a new stripe to a stripeset
In-Reply-To: <yq1puda8ejy.fsf@jcb.mkp.net>
Message-ID: <Pine.LNX.4.33.0105161027030.19365-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That's the thing. Not only will the added space not be striped, you
_can't_ add space to the current strip. Regardless of the consequences.
Not a huge deal, but I'll be dealing with terabytes of storage, and I'll
have to pre-allocate that info, how many disks per vg and how many
stripes/vg, before jumping in.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 15 May 2001, Martin K. Petersen wrote:

> >>>>> "Austin" == Austin Gonyou <austin@coremetrics.com> writes:
>
> Austin> I've done this with veritas, and that's why I'm asking.
>
> Well.  Veritas VM does this by effectively concatenating two stripe
> sets.
>
> If you just add a single disk (and the rest in your volume group are
> full), the added space won't be striped.
>
>


From owner-linux-xfs@oss.sgi.com Wed May 16 08:39:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFdAE10162
	for linux-xfs-outgoing; Wed, 16 May 2001 08:39:10 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFd5F10157
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:39:09 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDF00F30Q433Y@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Wed,
 16 May 2001 10:38:28 -0500 (CDT)
Date: Wed, 16 May 2001 11:37:48 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: Re: Samba ACLs - Latest Samba & XFS CVS
In-reply-to: <3B029C19.80803@ep-ag.com>
To: "Klaus Strebel,ITS,204" <stb@ep-ag.com>
Cc: linux-xfs@oss.sgi.com, Sean Elble <s_elble@yahoo.com>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010516113748.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

No.  In the 2.2.0 release, the configuration checks things differently.  I have
asked Sean to send me the relevant configuration info to check.

On 16-May-2001 Klaus Strebel,ITS,204 wrote:
> Sean Elble wrote:
> 
>> Hello (again!),
>> 
>> I downloaded the latest Samba and XFS CVS versions
>> yesterday, and tried to compile ACL support, yet
>> again. I'm still getting the same message, that
>> doesn't specify if XFS ACL suppor is being enabled! I
>> really need some help . . . I've put the acl.h file in
>> /usr/include/linux/acl.h, and I have
>> /usr/lib/libacl.a, but it _still_ isn't working. John,
>> I thank you for all of your help, but, I really don't
>> know why this isn't working. Is there any way I can
>> force Samba to put XFS ACL support in? I'm desperate
>> at this point. One more thing; I'm using Windows 2000
>> RC2 (Beta); now, I doubt this means anything, since it
>> isn't explicitly stating the support was enabled, but,
>> just letting you know . . . Thanks again for all of
>> your valuable help.
> 
> Hi Sean,
> 
> just can't get the box i first tried it (some weeks ago, samba-2.2.0 was 
> not released then ;-) ). Have a look to the configure script of samba. 
> They are checking for IRIX platform ACLs only if on irix, because 
> xfs-acls are irix acls, you have to convince configure for this test, 
> that it is on irix platform. This should bild samba with xfs-acl 
> support, but i couldn't test it by now, no spare time (sigh).
> 
> If you don't find how to cheat it, let me know, i'll try to find it 
> tomorrow.
> 
> Bye
> Klaus

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Wed May 16 08:44:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFiO310283
	for linux-xfs-outgoing; Wed, 16 May 2001 08:44:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFiNF10280
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:44:23 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA09880
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:44:22 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1832057; Wed, 16 May 2001 10:43:05 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA58231; Wed, 16 May 2001 10:43:05 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GFikL17705; Wed, 16 May 2001 10:44:46 -0500
Message-Id: <200105161544.f4GFikL17705@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Chris Mason <mason@suse.com>
cc: Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS 
In-Reply-To: Message from Chris Mason <mason@suse.com> 
   of "Wed, 16 May 2001 11:18:04 EDT." <114230000.990026284@tiny> 
Date: Wed, 16 May 2001 10:44:46 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> On Wednesday, May 16, 2001 09:51:38 AM -0500 Steve Lord <lord@sgi.com>
> wrote:
> 
> > 
> > Thanks for the info, I just took a look at the reiserfs archive,
> > and subscribed to the list. Interesting that no one on the xfs
> > list was contacted about this with questions such as how to configure
> > xfs etc (I could say mindcraft here but that might be inflamatory ;-).
> 
> I hope everyone on the reiserfs lists realizes how informal these
> benchmarks are.  If you want a real idea of how <foofs> performs, you've
> got to talk with someone who knows a lot about foofs to make sure things
> are fair.

Thanks Chris, I totally agree, and at the moment I am much too busy to spend
time in a performance competition. I should also state that I have never
regarded the different filesystem on Linux as being in direct competition
with each other, there will always be benefits to using each different
filesystem for their strong points. Plus having several filesystems under
active development means that there will be a tendency for the developers
to make theirs the best, the implementations improve, and everyone wins.


> 
> > It would certainly be interesting to see which config options were
> > used in the filesystem part of the kernel compile. The RPMs were
> > shipped with all features turned on which will impact performance,
> > turning off quotas and acls would be a good thing.
> 
> reiserfs acls are so fast, its like they aren't even there ;-)

XFS ones will be fast too - if they fit in the inode, which can be
achieved if you know what you are doing (inode size is a mkfs option). 

Steve



From owner-linux-xfs@oss.sgi.com Wed May 16 08:49:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFnA310383
	for linux-xfs-outgoing; Wed, 16 May 2001 08:49:10 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFnAF10380
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:49:10 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4GFmvk03117;
	Wed, 16 May 2001 10:48:57 -0500 (CDT)
Message-ID: <3B02A208.9194F451@sgi.com>
Date: Wed, 16 May 2001 10:51:36 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: werner maes <werner.maes@cc.kuleuven.ac.be>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS & Kickstart installation
References: <3.0.6.32.20010514172946.007a3740@mail.cc.kuleuven.ac.be>
	 <3.0.6.32.20010514183217.007ab100@mail.cc.kuleuven.ac.be>
	 <3.0.6.32.20010515114656.007b0e60@mail.cc.kuleuven.ac.be> <3.0.6.32.20010516124515.007e84b0@mail.cc.kuleuven.ac.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

werner maes wrote:
 
> insmod of xfs_support.o
> insmod of xfs.o
> 
> THESE modules were not loaded when I started from floppy. WHY?
> Because I used RedHat's boot disk instead of the boot image provided by SGI.

Um..... yes, don't do that.  :)

Glad it works.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 08:54:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFsRB10453
	for linux-xfs-outgoing; Wed, 16 May 2001 08:54:27 -0700
Received: from roc-24-169-102-121.rochester.rr.com (roc-24-169-102-121.rochester.rr.com [24.169.102.121])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFsQF10449
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:54:26 -0700
Received: from localhost ([127.0.0.1] helo=tiny)
	by roc-24-169-102-121.rochester.rr.com with esmtp (Exim 3.16 #4)
	id 1503bg-0001KL-00; Wed, 16 May 2001 10:53:00 -0500
Date: Wed, 16 May 2001 11:53:00 -0400
From: Chris Mason <mason@suse.com>
To: Steve Lord <lord@sgi.com>
cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS 
Message-ID: <156560000.990028380@tiny>
In-Reply-To: <200105161544.f4GFikL17705@jen.americas.sgi.com>
X-Mailer: Mulberry/2.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



On Wednesday, May 16, 2001 10:44:46 AM -0500 Steve Lord <lord@sgi.com>
wrote:

>> 
>> I hope everyone on the reiserfs lists realizes how informal these
>> benchmarks are.  If you want a real idea of how <foofs> performs, you've
>> got to talk with someone who knows a lot about foofs to make sure things
>> are fair.
> 
> Thanks Chris, I totally agree, and at the moment I am much too busy to
> spend time in a performance competition. I should also state that I have
> never regarded the different filesystem on Linux as being in direct
> competition with each other, there will always be benefits to using each
> different filesystem for their strong points. Plus having several
> filesystems under active development means that there will be a tendency
> for the developers to make theirs the best, the implementations improve,
> and everyone wins.

Grin, Steve and I have the benefit of having had this conversation before. 

Just so everyone on the list(s) knows....we really do agree on this.  The
resulting changes to the linux kernel from all these filesystems should
eventually make linux a very strong system for i/o heavy applications.
Plus, the ability to compare these different filesystems under the same
kernel is just plain cool.

>> reiserfs acls are so fast, its like they aren't even there ;-)
> 
> XFS ones will be fast too - if they fit in the inode, which can be
> achieved if you know what you are doing (inode size is a mkfs option). 

Really, the reiserfs acls aren't even there.  Anyone doing benchmarks
should think about the XFS features reiserfs doesn't have, turn some off
(acls), and leave some on (delayed allocation, O_DIRECT).

-chris


From owner-linux-xfs@oss.sgi.com Wed May 16 08:57:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFvEp10489
	for linux-xfs-outgoing; Wed, 16 May 2001 08:57:14 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFvCF10486
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:57:13 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA06810
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:28:46 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1824842; Wed, 16 May 2001 10:27:29 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA93892; Wed, 16 May 2001 10:27:28 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GFTAf17647; Wed, 16 May 2001 10:29:10 -0500
Message-Id: <200105161529.f4GFTAf17647@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: pac@fortuitous.com
cc: linux-xfs@oss.sgi.com
Subject: Re: vmware file locking problem: 
In-Reply-To: Message from pac@fortuitous.com 
   of "Wed, 16 May 2001 10:18:03 CDT." <20010516101803.A32539@bistro.marx> 
Date: Wed, 16 May 2001 10:29:10 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


It appears that vmware has hardcoded filesystem recognition code, and
it does not recognize xfs. The 0x58465342 number is the magic number
out of the xfs superblock which is returned in f_type by statfs
 'BSFX' or 'XFSB' on a little endian box.

I know there are people on the list who have vmware working on XFS,
Tom Duffy being one of them. He is in California so you will have to
wait a few hours....

Steve

>  Quoting from Zao Yang (zyang@ubicom.com):
> ---------------------------------------------------
> 
> my home directory and the .vmware directory are on a XFS
> filesystem. when I start vmware 2.0.3, it complains about not being able
> to detect if file locking is supported on the filesystem. it wants me to
> put the following line in the configuration file:
> 
> host.FSSupportLocking1 = 0x58465342
> 
> I tried that. but vmware still complains with same message. 
> 
> vmware used to work when my home directory is on ext2 filesystem. 
> 
> I also tried vmware 2.0.4 and had same problem. does anyone know where
> the problems might be, and if vmware supports XFS?
> 
> --------------------------------------------------------------
> 
>  I run vmware 2.0.4 and have the same trouble. Any ideas?
>  I had my vmware on Reiser before XFS and it worked ok.
>   Thanks,
> 
>   -Phil C.
> .---------------------------------------------------------
> | P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
> | Fortuitous Technologies Inc. |  http://fortuitous.com   |
> | Linux Training Services      |  Tel : 1-512 467-2154    |
> | Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
>  ---------------------------------------------------------



From owner-linux-xfs@oss.sgi.com Wed May 16 08:59:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GFxQA10525
	for linux-xfs-outgoing; Wed, 16 May 2001 08:59:26 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GFxPF10522
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:59:25 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA06216
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 08:58:01 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1834464; Wed, 16 May 2001 10:58:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA12773; Wed, 16 May 2001 10:58:07 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GFxmB17760; Wed, 16 May 2001 10:59:48 -0500
Message-Id: <200105161559.f4GFxmB17760@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Chris Mason <mason@suse.com>
cc: Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS 
In-Reply-To: Message from Chris Mason <mason@suse.com> 
   of "Wed, 16 May 2001 11:53:00 EDT." <156560000.990028380@tiny> 
Date: Wed, 16 May 2001 10:59:48 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> >> reiserfs acls are so fast, its like they aren't even there ;-)
> > 
> > XFS ones will be fast too - if they fit in the inode, which can be
> > achieved if you know what you are doing (inode size is a mkfs option). 
> 
> Really, the reiserfs acls aren't even there.  Anyone doing benchmarks
> should think about the XFS features reiserfs doesn't have, turn some off
> (acls), and leave some on (delayed allocation, O_DIRECT).
> 
> -chris


See, shows how much I know about reiserfs and why I am not qualified to
to do real benchmarks on it ;-).

Steve



From owner-linux-xfs@oss.sgi.com Wed May 16 09:12:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GGCmn10811
	for linux-xfs-outgoing; Wed, 16 May 2001 09:12:48 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GGClF10808
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 09:12:47 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA08600
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 09:12:31 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA48303; Wed, 16 May 2001 11:11:16 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4GGAFe20163;
	Wed, 16 May 2001 12:10:15 -0400
Message-ID: <3B02A666.DAFB3D8A@thebarn.com>
Date: Wed, 16 May 2001 12:10:14 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: lmj@homemail.com, linux-xfs@oss.sgi.com
Subject: Re: Patch problem
References: <0105161150400R.03500@weba2.iname.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

lmj@homemail.com wrote:

> Hello
>
> Thank you for your reply.
>
> Now I tried this with the same results.
> Untar linux-2.4.4. This creates /usr/src/linux/...
> Rename to /usr/src/linux-2.4.4
> cd /usr/src
> patch -p0 < linux-2.4.4-xfs-cvs-05152001.patch
>

mkdir linux-xfs
cd linux-xfs
tar xvfz linux-2.4.4.tar.gz
patch -p1 < linux-2.4.4-xfs-cvs-05152001.patch

I might suggest that you read the documentation for the development tree
before
you start working with it.
The cvs seed patch is not guaranteed to be stable or well tested, and
keeping up to date via
cvs update is  required.


> Thanks
> Magnus
>
> lmj@homemail.com wrote:
>
> > Hello
> >
> > This is practically identical to a question posted by
> > Jan Jonasson on 2 May. Using the answers posted in that
> > mail thread I still have a problem with this new patch
> > for 2.4.4.
> >
> > I'm trying to apply the
> > linux-2.4.4-xfs-cvs-05152001.patch.gz on a 2.4.4 kernel
> > according to the instructions at
> > http://linux-xfs.sgi.com/projects/xfs/1.0_source.html .
>
> Those instructions do not apply to this patch
>
> were where you when applied the patch?
> you should be one level up from the linux base.
> Look at the path names in the patch should make more
> sense after that.
>
> ------------------------------------------------------
> Get the Latest News at CNN Interactive: http://CNN.com

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 16 09:19:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GGJHl10991
	for linux-xfs-outgoing; Wed, 16 May 2001 09:19:17 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GGJGF10988
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 09:19:16 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4GGHUF19949
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 11:17:30 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 16 May 2001 11:17:30 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: LVM/XFS Bug?
Message-ID: <Pine.LNX.4.33.0105161056580.19365-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On the system I've been testing LVM+XFS with, I've run into a bit of a
dilemma. If I try to resize the a volume more than once, I get the
following error message:

-------begin problem-------
[root@core /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda6               260240    120336    139904  47% /
/dev/sda1                19264     12616      6648  66% /boot
/dev/sda10             1167912       184   1167728   1% /home
/dev/sda9              1167912    871764    296148  75% /usr
/dev/sda7               260240     17848    242392   7% /var
/dev/oracle/oravol1    8383808       144   8383664   1% /oracle
/dev/web/webvol1       7859520       144   7859376   1% /web
[root@core /root]# lvextend -L +100M /dev/web/webvol1
lvextend -- rounding size to physical extent boundary
lvextend -- rounding size 7995392 KB to stripe boundary size 8126464 KB
lvextend -- extending logical volume "/dev/web/webvol1" to 7.75 GB
lvextend -- doing automatic backup of volume group "web"
lvextend -- logical volume "/dev/web/webvol1" successfully extended

[root@core /root]# xfs_growfs /web/
meta-data=/web                   isize=256    agcount=8, agsize=245760
blks
data     =                       bsize=4096   blocks=1966080, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 1966080 to 2031616
[root@core /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda6               260240    120284    139956  47% /
/dev/sda1                19264     12616      6648  66% /boot
/dev/sda10             1167912       184   1167728   1% /home
/dev/sda9              1167912    871764    296148  75% /usr
/dev/sda7               260240     17848    242392   7% /var
/dev/oracle/oravol1    8383808       144   8383664   1% /oracle
/dev/web/webvol1       8121664       160   8121504   1% /web

[root@core /root]# lvextend -L +100M /dev/web/webvol1
lvextend -- rounding size to physical extent boundary
lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
lvextend -- doing automatic backup of volume group "web"
lvextend -- logical volume "/dev/web/webvol1" successfully extended

[root@core /root]# xfs_growfs /web/
meta-data=/web                   isize=256    agcount=9, agsize=245760
blks
data     =                       bsize=4096   blocks=2031616, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
--------End Problem------

Ok, so now let's reformat that partition and remount it.

------begin reformat------
[root@core /root]# umount /web/
[root@core /root]# mkfs.xfs /dev/web/webvol1  -f
meta-data=/dev/web/webvol1       isize=256    agcount=8, agsize=262144
blks
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
[root@core /root]# mount -a
[root@core /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda6               260240    120304    139936  47% /
/dev/sda1                19264     12616      6648  66% /boot
/dev/sda10             1167912       184   1167728   1% /home
/dev/sda9              1167912    871764    296148  75% /usr
/dev/sda7               260240     17848    242392   7% /var
/dev/oracle/oravol1    8383808       144   8383664   1% /oracle
/dev/web/webvol1       8383808       144   8383664   1% /web

------End Reformat-------

Is this a known bug? This problem isn't actually size dependant, as in the
ammount of the resize itself, as in here:


----begin example----
[root@core /root]# lvextend -L +2M /dev/web/webvol1
lvextend -- rounding size to physical extent boundary
lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
lvextend -- doing automatic backup of volume group "web"
lvextend -- logical volume "/dev/web/webvol1" successfully extended

[root@core /root]# xfs_growfs /web/
meta-data=/web                   isize=256    agcount=8, agsize=253952
blks
data     =                       bsize=4096   blocks=2031616, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 2031616 to 2097152
[root@core /root]# lvextend -L +2M /dev/web/webvol1
lvextend -- rounding size to physical extent boundary
lvextend -- rounding size 8519680 KB to stripe boundary size 8650752 KB
lvextend -- extending logical volume "/dev/web/webvol1" to 8.25 GB
lvextend -- doing automatic backup of volume group "web"
lvextend -- logical volume "/dev/web/webvol1" successfully extended

[root@core /root]# xfs_growfs /web/
meta-data=/web                   isize=256    agcount=9, agsize=253952
blks
data     =                       bsize=4096   blocks=2097152, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990

----end example-----

I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
from SGI to install the box. Using LVM 0.9.1-b7 tools.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Wed May 16 09:21:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GGLs811183
	for linux-xfs-outgoing; Wed, 16 May 2001 09:21:54 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GGLqF11178
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 09:21:53 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4GGIwT19957;
	Wed, 16 May 2001 11:18:58 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 16 May 2001 11:18:58 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, <reiserfs-list@namesys.com>
Subject: Re: Benchmarking ReiserFS, ext2, XFS 
In-Reply-To: <200105161451.f4GEpcj17003@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105161118440.19365-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Don't forget, small file tests are what big slow db's are made of. :)

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 16 May 2001, Steve Lord wrote:

>
> Thanks for the info, I just took a look at the reiserfs archive,
> and subscribed to the list. Interesting that no one on the xfs
> list was contacted about this with questions such as how to configure
> xfs etc (I could say mindcraft here but that might be inflamatory ;-).
> It would certainly be interesting to see which config options were
> used in the filesystem part of the kernel compile. The RPMs were
> shipped with all features turned on which will impact performance,
> turning off quotas and acls would be a good thing.
>
> Anyway, I am not surprised reiserfs wins on small file
> tests, someone independent might want to ask what happens if you
> pull the power in the middle of the test. I suspect the answer on
> reiserfs is that almost nothing is on the disk after reboot, the file
> creation/removal part of bonnie++ (30000 files created and removed
> twice) can complete without disk I/O on reiserfs.
>
> I will download the mongo tests and try them out myself.
>
> As for the ac kernels - I challenge anyone who is working for a living
> and has other things to do to keep something the size of XFS upto date
> with Alan's kernels - I have seen 3 of those in one day. Plus changes
> tend to come and go, and XFS does have its fingers in the VM system,
> getting those in sync is not always straight forward, so it is not a
> matter of apply a patch and go.
>
> Steve
>
> p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend
> this:
>
>     if ( $FILESYSTEM eq "xfs" ) {
>         system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
>         system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;
>     }
>
> This increases the journal size from the default, mounts with 4 in core log
> buffers instead of 2 and makes sure that O_SYNC has the same behavior as
> it does on ext2. For the release kernel I would also add biosize=13 to
> the mount options, this no longer makes a difference in the cvs kernels.
>
>
> > Hi everyone,
> >
> > Following the link that Ed McKenzie <eem12@cornell.edu> sent, I read the
> > ReiserFS list archives searching for benchmarks comparing the performance
> > of ReiserFS, ext2, and XFS.
> >
> > Here are results of benchmarks comparing the three using mongo.pl (what
> > seems to be a pretty extensive benchmark test suite that is has been used
> > by the ReiserFS development team to measure the performance of their
> > filesystem since they started, it seems).
> >
> > <http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ext2-reiserfs-xfs.
> > html>
> >
> > These test were done on a machine running RedHat 7.1 with the Linux kernel
> > 2.4.3, with a Duron 700MHz CPU, 128MB RAM, and a 9GB SCSI HDD. Filesystem
> > versions compared are: Ext2 version 0.5b, ReiserFS version 3.6.25, and XFS
> > version 1.0.
>
> I would ask exactly what was done to apply the 1.0 patches to 2.4.3, this
> is not what we released, was this actually the rpm, or was it downloaded
> from the cvs tree?
>
> >
> > Perhaps the XFS developers would have something to say about the test
> > results? Speculations on how much better the latest CVS copy of XFS will
> > perform on Linux 2.4.4?
> >
> > I do not have a machine to do benchmarks, but if someone out there has, it
> > would be great to see an updated comparison.
> >
> > Also I'd like to relay the comments of someone on IRC that I got to chat
> > with when trying to find someone to talk to about these benchmarks. He/she
> > said that his/her only real irk with XFS is that the developers aren't
> > able to keep track of the -ac patches. As a consequence, he is in constant
> > need of fixing patch rej's. ReiserFS is at an advantage here, because it
> > has been incorporated into the Linux 2.4 kernel tree.
> >
> > Comments?
> >
> >  --> Jijo
> >
> > --
> > Linux, MS-DOS, and Windows NT ...
> > ... also known as the Good, the Bad, and the Ugly
>


From owner-linux-xfs@oss.sgi.com Wed May 16 09:43:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GGhkI11938
	for linux-xfs-outgoing; Wed, 16 May 2001 09:43:46 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GGhgF11931
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 09:43:43 -0700
Received: [from blizbor (blizbor.ima.pl [195.117.13.88])
                               by ima.pl with SMTP id f4GGeIZ32677;
                               Wed, 16 May 2001 18:40:18 +0200]
Message-ID: <003401c0de26$d1e8eac0$020010ac@ima.pl>
From: "Blizbor (i)" <tb670725@ima.pl>
To: "Steve Lord" <lord@sgi.com>
Cc: <reiserfs-list@namesys.com>,
   "Linux XFS Mailing List" <linux-xfs@oss.sgi.com>
References: <Pine.LNX.4.21.0105161929390.1579-100000@kalapati.jijo.local> <200105161451.f4GEpcj17003@jen.americas.sgi.com>
Subject: Odp: Benchmarking ReiserFS, ext2, XFS 
Date: Wed, 16 May 2001 18:39:47 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2417.2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


----- Original Message -----
From: Steve Lord <lord@sgi.com>

> p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend
> this:
>
>     if ( $FILESYSTEM eq "xfs" ) {
>         system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
>         system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;
>     }


   Could these mount options can be also applied on production server ?
   (i.e. mail, web and sql db server ?)

   Is there possibility to limit memory used for disk/file cacheing ?

   How mkfs.xfs calculates values for agcount and agsize ?
   (I have spent some time trying to find apropriate "-l SIZE"
   for each created fs)

   On 15GB filesystem, did it makes big difference that it was created
   with "-l" value twice as you suggest ?

   Am I wrong thinking that noatime, nodiratime mount options also are
   tweaking XFS performance (as for ext2fs) ? (I dont need these info at
all).

Regards,
Blizbor


From owner-linux-xfs@oss.sgi.com Wed May 16 10:00:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GH07P12166
	for linux-xfs-outgoing; Wed, 16 May 2001 10:00:07 -0700
Received: from www.quasihorse.com (cs666825-126.austin.rr.com [66.68.25.126])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GH06F12163
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 10:00:06 -0700
Received: by www.quasihorse.com (Postfix, from userid 500)
	id 31BC51F3; Wed, 16 May 2001 11:58:00 -0500 (CDT)
Date: Wed, 16 May 2001 11:58:00 -0500
From: pac@fortuitous.com
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: vmware file locking problem:
Message-ID: <20010516115800.A2576@bistro.marx>
Reply-To: pac@fortuitous.com
References: <20010516101803.A32539@bistro.marx> <200105161529.f4GFTAf17647@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <200105161529.f4GFTAf17647@jen.americas.sgi.com>; from lord@sgi.com on Wed, May 16, 2001 at 10:29:10AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> It appears that vmware has hardcoded filesystem recognition code, and
> it does not recognize xfs. The 0x58465342 number is the magic number
> out of the xfs superblock which is returned in f_type by statfs
>  'BSFX' or 'XFSB' on a little endian box.
> 
> I know there are people on the list who have vmware working on XFS,
> Tom Duffy being one of them. He is in California so you will have to
> wait a few hours....
 
 I fixed the problem. I misunderstood the definition of "config" file.
 My earlier failed attempt where to modify ~/.vmware/preferences
  and /path/to/vmware/data/nt4.cfg 

 Solution:
 
 0. Drink a strong cup of Expresso

 1. Add the following line to /etc/vmware/config: 
    host.FSSupportLocking1 = 0x58465342

 2. Start vmware

  -Phil C.
.---------------------------------------------------------
| P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
| Fortuitous Technologies Inc. |  http://fortuitous.com   |
| Linux Training Services      |  Tel : 1-512 467-2154    |
| Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
 ---------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Wed May 16 10:31:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GHVrO12866
	for linux-xfs-outgoing; Wed, 16 May 2001 10:31:53 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GHVkF12853
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 10:31:46 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA03878
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 10:31:35 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1833356; Wed, 16 May 2001 12:29:26 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA62803; Wed, 16 May 2001 12:29:26 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4GHV6Z20019; Wed, 16 May 2001 12:31:06 -0500
Message-Id: <200105161731.f4GHV6Z20019@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Blizbor (i)" <tb670725@ima.pl>
cc: "Linux XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: Re: Odp: Benchmarking ReiserFS, ext2, XFS 
In-Reply-To: Message from "Blizbor (i)" <tb670725@ima.pl> 
   of "Wed, 16 May 2001 18:39:47 +0200." <003401c0de26$d1e8eac0$020010ac@ima.pl> 
Date: Wed, 16 May 2001 12:31:05 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Removed reiserfs list from cc - getting a bit xfs specific here.

> 
> ----- Original Message -----
> From: Steve Lord <lord@sgi.com>
> 
> > p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend
> > this:
> >
> >     if ( $FILESYSTEM eq "xfs" ) {
> >         system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
> >         system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;
> >     }
> 
> 
>    Could these mount options can be also applied on production server ?
>    (i.e. mail, web and sql db server ?)

Yes, they apply anywhere, look at this message for a bit more of
an explaination:

	http://linux-xfs.sgi.com/projects/xfs/mail_archive/0105/msg00663.html

> 
>    Is there possibility to limit memory used for disk/file cacheing ?

Not really - this is a linux thing not an xfs thing.

> 
>    How mkfs.xfs calculates values for agcount and agsize ?
>    (I have spent some time trying to find apropriate "-l SIZE"
>    for each created fs)

If you take the latest cvs tree it has just had some code merged from Irix
which adds new mkfs options which make controlling the agsize simpler. 

> 
>    On 15GB filesystem, did it makes big difference that it was created
>    with "-l" value twice as you suggest ?
> 
>    Am I wrong thinking that noatime, nodiratime mount options also are
>    tweaking XFS performance (as for ext2fs) ? (I dont need these info at
> all).


Also only in the cvs tree (as of yesterday) noatime was not getting passed
on to xfs correctly. nodiratime does not mean anything to xfs.

> 
> Regards,
> Blizbor

Steve




From owner-linux-xfs@oss.sgi.com Wed May 16 10:38:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GHcAX13187
	for linux-xfs-outgoing; Wed, 16 May 2001 10:38:10 -0700
Received: from fwb.asi.srs.com (asifwb.cybertron.com [204.49.174.220])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GHc8F13183
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 10:38:09 -0700
Received: from tombrowd [10.0.1.203] by fwb.asi.srs.com [204.49.174.220]
	with SMTP (MDaemon.v2.84.R)
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 12:39:06 -0500
From: "Tom Browder" <tom2@fwb.asi.srs.com>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: Re: How to Use Red Hat Install CD..........
Date: Wed, 16 May 2001 12:39:00 -0500
Message-ID: <01c0de2f$1775d000$cb01000a@tombrowd>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com
X-Return-Path: tom2@fwb.asi.srs.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric, thanks.

I tried the  dd (and rawrite) thing with the boot.img as usual, but the problem
is in the image I got from the internet.  Looks like a bad download. (The files
are listed OK on the CD I burned, and they have the right file sizes (using "ls -l"),
but running "od" on them show a one-character file whose single byte is zero.)

I'll try again tonight to download the image file and burn it again.

Tom Browder




From owner-linux-xfs@oss.sgi.com Wed May 16 10:51:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GHpLH13721
	for linux-xfs-outgoing; Wed, 16 May 2001 10:51:21 -0700
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GHpKF13718
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 10:51:20 -0700
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
	id 1505S0-000LnR-0C; Wed, 16 May 2001 17:51:18 +0000
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP
	id 7DFA227F1; Wed, 16 May 2001 18:50:39 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 61251125E6; Wed, 16 May 2001 18:50:12 +0100 (BST)
Date: Wed, 16 May 2001 18:50:12 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[2]: Benchmarking ReiserFS, ext2, XFS 
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
In-Reply-To: <Pine.LNX.4.33.0105161118440.19365-100000@UberGeek.coremetrics.com>
References: <Pine.LNX.4.33.0105161118440.19365-100000@UberGeek.coremetrics.com>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010516175012.61251125E6@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f4GHpLF13719
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 16 May 2001 11:18:58 -0500 (CDT) Austin Gonyou <Austin Gonyou <austin@coremetrics.com>> wrote:

> Don't forget, small file tests are what big slow db's are made of. :)
> 
> -- 


Just what sort of db are you talking about ?


--
Keith Matthews

Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Wed May 16 11:23:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GINB514850
	for linux-xfs-outgoing; Wed, 16 May 2001 11:23:11 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GIN6F14845
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 11:23:07 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4GIKc520773;
	Wed, 16 May 2001 13:20:38 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 16 May 2001 13:20:38 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Keith Matthews <keith_m@sweeney.demon.co.uk>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>,
   <reiserfs-list@namesys.com>
Subject: Re[2]: Benchmarking ReiserFS, ext2, XFS 
In-Reply-To: <20010516175012.61251125E6@rebutia.sweeney.demon.co.uk>
Message-ID: <Pine.LNX.4.33.0105161311520.19365-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Most DB's, regardless of actuall size are using many rows. Currently we
run oracle, and each field in a row is a specific size. As we populate the
DB, over time it slows down. This is because there are NO long contiguous
writes. Even with long contiguous writes slow down would occurr, but in a
different manner. Not all DBs are created equally, I understand, but so
far, there seems to be that one factor all DBs have in common, the amount
of data that can be inserted into the db in at one time. This of course is
a combination of OS, FS, and DB tuning, and retuning. So, that's why I say
that. It's not as though the IRS's databases are huge contiguous tables,
they're all split into rows, columns, and fields. As well as different
partitions, which can help with performance, but that's usually making a
large job smaller to manage it better. Thus, smaller writes are again more
prominent. The contrast I use here is say, reading a huge data file, a
ripped DVD or cd perhaps? A lot of contiguous data in a single file in one
format type. That is a long contiguous read/write operation to access
that file. (as in creation/manipulation) Thus, when playing a ripped dvd
through some kind of player, or streaming that info out to a network host,
you'd expect to get pretty decent throuput from the system. Databases,
until tweaked a lot, usually get I/O bound and have problems getting the
data from point A-B. Again, this relates to read/writes. Reads aren't too
slow for this kind of data anyway, querries are pretty quick, but in the
event that you do bulk inserts, then you'd see a major slowdown, and have
to retune your system.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 16 May 2001, Keith Matthews wrote:

> On Wed, 16 May 2001 11:18:58 -0500 (CDT) Austin Gonyou <Austin Gonyou <austin@coremetrics.com>> wrote:
>
> > Don't forget, small file tests are what big slow db's are made of. :)
> >
> > --
>
>
> Just what sort of db are you talking about ?
>
>
> --
> Keith Matthews
>
> Frequentous Consultants  - Linux Services,
> 		Oracle development & database administration
>


From owner-linux-xfs@oss.sgi.com Wed May 16 13:05:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GK5TJ17000
	for linux-xfs-outgoing; Wed, 16 May 2001 13:05:29 -0700
Received: from phase1.unl.edu (phase1.unl.edu [129.93.40.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GK5RF16997
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:05:28 -0700
Received: from localhost (furukawa@localhost)
	by phase1.unl.edu (SGI-8.9.3/8.9.3) with SMTP id PAA60713
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:06:46 -0500 (CDT)
Date: Wed, 16 May 2001 15:06:46 -0500 (CDT)
From: Mako Furukawa <furukawa@phase1.unl.edu>
To: linux-xfs@oss.sgi.com
Subject: ISO
Message-ID: <Pine.SGI.3.96.1010516150438.163499B-100000@phase1.unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,
I just downloaded the ISO image and burned a CD twice and had the same
problems with the installer. It starts up okay but as soon as it gets past
the initial screen (where you hit enter to start the install), it freezes
up the keyboard and the monitor turns blank.  Any ideas?

Mako Furukawa


----------------------------------------------------------------------------
Mako Furukawa                   |  furukawa@phase1.unl.edu
Research Assistant              |  mako@wrestlingmat.com
Department of Chemistry         |  http://www.wrestlingmat.com/makohome
Hamilton Hall, 536              |  http://amateurwrestle.about.com
University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
Lincoln, NE 68588-0304          |   winner can never allow himself to be
(402) 472-9982                  |   discouraged." -- D.A. Chapple
----------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 16 13:07:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GK72C17298
	for linux-xfs-outgoing; Wed, 16 May 2001 13:07:02 -0700
Received: from phase1.unl.edu (phase1.unl.edu [129.93.40.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GK72F17295
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:07:02 -0700
Received: from localhost (furukawa@localhost)
	by phase1.unl.edu (SGI-8.9.3/8.9.3) with SMTP id PAA64466
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:08:20 -0500 (CDT)
Date: Wed, 16 May 2001 15:08:20 -0500 (CDT)
From: Mako Furukawa <furukawa@phase1.unl.edu>
To: linux-xfs@oss.sgi.com
Subject: also...
Message-ID: <Pine.SGI.3.96.1010516150710.162162A-100000@phase1.unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Also, does the XFS allow for files greater than 2GB? If not, any ideas of
when this might be sovled?

I appreciate your time,

Mako Furukawa


----------------------------------------------------------------------------
Mako Furukawa                   |  furukawa@phase1.unl.edu
Research Assistant              |  mako@wrestlingmat.com
Department of Chemistry         |  http://www.wrestlingmat.com/makohome
Hamilton Hall, 536              |  http://amateurwrestle.about.com
University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
Lincoln, NE 68588-0304          |   winner can never allow himself to be
(402) 472-9982                  |   discouraged." -- D.A. Chapple
----------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 16 13:13:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GKDHE17721
	for linux-xfs-outgoing; Wed, 16 May 2001 13:13:17 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GKDGF17718
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:13:16 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4GKDEb18679;
	Wed, 16 May 2001 15:13:14 -0500 (CDT)
Message-ID: <3B02DFDD.B7A48A1F@sgi.com>
Date: Wed, 16 May 2001 15:15:25 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mako Furukawa <furukawa@phase1.unl.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <Pine.SGI.3.96.1010516150438.163499B-100000@phase1.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mako Furukawa wrote:
> 
> Hello,
> I just downloaded the ISO image and burned a CD twice and had the same
> problems with the installer. It starts up okay but as soon as it gets past
> the initial screen (where you hit enter to start the install), it freezes
> up the keyboard and the monitor turns blank.  Any ideas?

Regarding the install freeze, please first check the MD5SUM on the iso
image to make sure your download went ok.

And yes, XFS can handle files > 2GB, as long as the underlying system
can handle them - and in the Red Hat 7.1 case, this is (mostly) a yes. 
(Some applications have exhibited problems, but in general things work)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 13:25:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GKPfJ18346
	for linux-xfs-outgoing; Wed, 16 May 2001 13:25:41 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GKPcF18337
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:25:38 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id WAA33655
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 22:25:24 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA92136; Wed, 16 May 2001 15:24:08 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4GKN8e06835;
	Wed, 16 May 2001 16:23:08 -0400
Message-ID: <3B02E1AC.BAB1D5F@thebarn.com>
Date: Wed, 16 May 2001 16:23:08 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mako Furukawa <furukawa@phase1.unl.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <Pine.SGI.3.96.1010516150438.163499B-100000@phase1.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mako Furukawa wrote:

> Hello,
> I just downloaded the ISO image and burned a CD twice and had the same
> problems with the installer. It starts up okay but as soon as it gets past
> the initial screen (where you hit enter to start the install), it freezes
> up the keyboard and the monitor turns blank.  Any ideas?

Could be a vid card issue, try text mode.


>
>
> Mako Furukawa
>
> ----------------------------------------------------------------------------
> Mako Furukawa                   |  furukawa@phase1.unl.edu
> Research Assistant              |  mako@wrestlingmat.com
> Department of Chemistry         |  http://www.wrestlingmat.com/makohome
> Hamilton Hall, 536              |  http://amateurwrestle.about.com
> University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
> Lincoln, NE 68588-0304          |   winner can never allow himself to be
> (402) 472-9982                  |   discouraged." -- D.A. Chapple
> ----------------------------------------------------------------------------

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 16 13:29:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GKTFK18707
	for linux-xfs-outgoing; Wed, 16 May 2001 13:29:15 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GKTEF18704
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:29:14 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4GKQNB21561;
	Wed, 16 May 2001 15:26:23 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 16 May 2001 15:26:23 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Mako Furukawa <furukawa@phase1.unl.edu>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: also...
In-Reply-To: <Pine.SGI.3.96.1010516150710.162162A-100000@phase1.unl.edu>
Message-ID: <Pine.LNX.4.33.0105161526190.19365-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yes it does.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 16 May 2001, Mako Furukawa wrote:

> Also, does the XFS allow for files greater than 2GB? If not, any ideas of
> when this might be sovled?
>
> I appreciate your time,
>
> Mako Furukawa
>
>
> ----------------------------------------------------------------------------
> Mako Furukawa                   |  furukawa@phase1.unl.edu
> Research Assistant              |  mako@wrestlingmat.com
> Department of Chemistry         |  http://www.wrestlingmat.com/makohome
> Hamilton Hall, 536              |  http://amateurwrestle.about.com
> University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
> Lincoln, NE 68588-0304          |   winner can never allow himself to be
> (402) 472-9982                  |   discouraged." -- D.A. Chapple
> ----------------------------------------------------------------------------
>


From owner-linux-xfs@oss.sgi.com Wed May 16 13:39:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GKdg719229
	for linux-xfs-outgoing; Wed, 16 May 2001 13:39:42 -0700
Received: from phase1.unl.edu (phase1.unl.edu [129.93.40.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GKdfF19225
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:39:41 -0700
Received: from localhost (furukawa@localhost)
	by phase1.unl.edu (SGI-8.9.3/8.9.3) with SMTP id PAA63239;
	Wed, 16 May 2001 15:40:53 -0500 (CDT)
Date: Wed, 16 May 2001 15:40:52 -0500 (CDT)
From: Mako Furukawa <furukawa@phase1.unl.edu>
To: Eric Sandeen <sandeen@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: ISO
In-Reply-To: <3B02DFDD.B7A48A1F@sgi.com>
Message-ID: <Pine.SGI.3.96.1010516153930.148554A-100000@phase1.unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 16 May 2001, Eric Sandeen wrote:

> Mako Furukawa wrote:
> > 
> > Hello,
> > I just downloaded the ISO image and burned a CD twice and had the same
> > problems with the installer. It starts up okay but as soon as it gets past
> > the initial screen (where you hit enter to start the install), it freezes
> > up the keyboard and the monitor turns blank.  Any ideas?
> 
> Regarding the install freeze, please first check the MD5SUM on the iso
> image to make sure your download went ok.
> 
The download looks okay but just to make sure, I did redownload it.  I
just tried it again in text mode and it went fine until it go to the
following:

calibrating APIC timer
..... CPU clock speed is 1495.5702 MHz
..... host bus clock speed is 0.0000 MHz
cpu: 0, clocks: 0, slice: 0

-Mako

----------------------------------------------------------------------------
Mako Furukawa                   |  furukawa@phase1.unl.edu
Research Assistant              |  mako@wrestlingmat.com
Department of Chemistry         |  http://www.wrestlingmat.com/makohome
Hamilton Hall, 536              |  http://amateurwrestle.about.com
University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
Lincoln, NE 68588-0304          |   winner can never allow himself to be
(402) 472-9982                  |   discouraged." -- D.A. Chapple
----------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 16 13:41:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GKfj819536
	for linux-xfs-outgoing; Wed, 16 May 2001 13:41:45 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GKfiF19533
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 13:41:44 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4GKffW28172;
	Wed, 16 May 2001 15:41:41 -0500 (CDT)
Message-ID: <3B02E68A.54929FDA@sgi.com>
Date: Wed, 16 May 2001 15:43:54 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mako Furukawa <furukawa@phase1.unl.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <Pine.SGI.3.96.1010516153930.148554A-100000@phase1.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mako Furukawa wrote:

> The download looks okay but just to make sure, I did redownload it.  I
> just tried it again in text mode and it went fine until it go to the
> following:
> 
> calibrating APIC timer
> ..... CPU clock speed is 1495.5702 MHz
> ..... host bus clock speed is 0.0000 MHz
> cpu: 0, clocks: 0, slice: 0

Wow, no CPUs eh?  :)

Try booting with "noapic" on the command line.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 14:08:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GL8DY20418
	for linux-xfs-outgoing; Wed, 16 May 2001 14:08:13 -0700
Received: from phase1.unl.edu (phase1.unl.edu [129.93.40.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GL8CF20415
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 14:08:12 -0700
Received: from localhost (furukawa@localhost)
	by phase1.unl.edu (SGI-8.9.3/8.9.3) with SMTP id QAA65019;
	Wed, 16 May 2001 16:09:28 -0500 (CDT)
Date: Wed, 16 May 2001 16:09:28 -0500 (CDT)
From: Mako Furukawa <furukawa@phase1.unl.edu>
To: Eric Sandeen <sandeen@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: ISO
In-Reply-To: <3B02E68A.54929FDA@sgi.com>
Message-ID: <Pine.SGI.3.96.1010516160713.150796C-100000@phase1.unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 16 May 2001, Eric Sandeen wrote:

> Mako Furukawa wrote:
> 
> > The download looks okay but just to make sure, I did redownload it.  I
> > just tried it again in text mode and it went fine until it go to the
> > following:
> > 
> > calibrating APIC timer
> > ..... CPU clock speed is 1495.5702 MHz
> > ..... host bus clock speed is 0.0000 MHz
> > cpu: 0, clocks: 0, slice: 0
> 
> Wow, no CPUs eh?  :)
> 
> Try booting with "noapic" on the command line.
> 
Yep...no clock speed either. :)  Unfortunately, I still get the same error
even with the noapic command.  I may end up just doing the 7.1 install
first, then adding XFS on to it if nothing works.

-Mako

----------------------------------------------------------------------------
Mako Furukawa                   |  furukawa@phase1.unl.edu
Research Assistant              |  mako@wrestlingmat.com
Department of Chemistry         |  http://www.wrestlingmat.com/makohome
Hamilton Hall, 536              |  http://amateurwrestle.about.com
University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
Lincoln, NE 68588-0304          |   winner can never allow himself to be
(402) 472-9982                  |   discouraged." -- D.A. Chapple
----------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 16 14:37:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GLbTa21213
	for linux-xfs-outgoing; Wed, 16 May 2001 14:37:29 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GLbSF21210
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 14:37:28 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id OAA07478
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 14:37:23 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA87190; Wed, 16 May 2001 16:36:07 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4GLZ7w26555;
	Wed, 16 May 2001 17:35:07 -0400
Message-ID: <3B02F28A.F96794E2@thebarn.com>
Date: Wed, 16 May 2001 17:35:06 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mako Furukawa <furukawa@phase1.unl.edu>
CC: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <Pine.SGI.3.96.1010516160713.150796C-100000@phase1.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mako Furukawa wrote:

> On Wed, 16 May 2001, Eric Sandeen wrote:
>
> > Mako Furukawa wrote:
> >
> > > The download looks okay but just to make sure, I did redownload it.  I
> > > just tried it again in text mode and it went fine until it go to the
> > > following:
> > >
> > > calibrating APIC timer
> > > ..... CPU clock speed is 1495.5702 MHz
> > > ..... host bus clock speed is 0.0000 MHz
> > > cpu: 0, clocks: 0, slice: 0
> >
> > Wow, no CPUs eh?  :)
> >
> > Try booting with "noapic" on the command line.
> >
> Yep...no clock speed either. :)  Unfortunately, I still get the same error
> even with the noapic command.  I may end up just doing the 7.1 install
> first, then adding XFS on to it if nothing works.

You could try a floppy image from
ftp://oss.sgi.com/projects/xfs/download/archive/Release-1.0-test2/RH7.1-SGI-XFS-0.10.3/images/

those kernels did not have APIC enabled.



>
>
> -Mako
>
> ----------------------------------------------------------------------------
> Mako Furukawa                   |  furukawa@phase1.unl.edu
> Research Assistant              |  mako@wrestlingmat.com
> Department of Chemistry         |  http://www.wrestlingmat.com/makohome
> Hamilton Hall, 536              |  http://amateurwrestle.about.com
> University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
> Lincoln, NE 68588-0304          |   winner can never allow himself to be
> (402) 472-9982                  |   discouraged." -- D.A. Chapple
> ----------------------------------------------------------------------------

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 16 15:27:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GMRtI22252
	for linux-xfs-outgoing; Wed, 16 May 2001 15:27:55 -0700
Received: from phase1.unl.edu (phase1.unl.edu [129.93.40.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GMRsF22249
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:27:54 -0700
Received: from localhost (furukawa@localhost)
	by phase1.unl.edu (SGI-8.9.3/8.9.3) with SMTP id RAA59811;
	Wed, 16 May 2001 17:29:02 -0500 (CDT)
Date: Wed, 16 May 2001 17:29:01 -0500 (CDT)
From: Mako Furukawa <furukawa@phase1.unl.edu>
To: Russell Cattelan <cattelan@thebarn.com>
cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: ISO
In-Reply-To: <3B02F28A.F96794E2@thebarn.com>
Message-ID: <Pine.SGI.3.96.1010516172511.159364B-100000@phase1.unl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> You could try a floppy image from
> ftp://oss.sgi.com/projects/xfs/download/archive/Release-1.0-test2/RH7.1-SGI-XFS-0.10.3/images/
> 
> those kernels did not have APIC enabled.
> 
This worked but when it went to installing the system, I got this error
message:

"Error mounting device hda5 as /:
No such device

This most likely means this partition has not been formatted.

Press OK to reboot your system."

I did choose to format all the partitions.  I thank you guys for all your
help and appreciate any more information you can give me.

-Mako

----------------------------------------------------------------------------
Mako Furukawa                   |  furukawa@phase1.unl.edu
Research Assistant              |  mako@wrestlingmat.com
Department of Chemistry         |  http://www.wrestlingmat.com/makohome
Hamilton Hall, 536              |  http://amateurwrestle.about.com
University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
Lincoln, NE 68588-0304          |   winner can never allow himself to be
(402) 472-9982                  |   discouraged." -- D.A. Chapple
----------------------------------------------------------------------------


From owner-linux-xfs@oss.sgi.com Wed May 16 15:32:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GMWge22627
	for linux-xfs-outgoing; Wed, 16 May 2001 15:32:42 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GMWgF22623
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:32:42 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA13901
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:31:18 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA39551; Wed, 16 May 2001 17:31:25 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4GMUOw04968;
	Wed, 16 May 2001 18:30:25 -0400
Message-ID: <3B02FF7E.1DF765E7@thebarn.com>
Date: Wed, 16 May 2001 18:30:23 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Mako Furukawa <furukawa@phase1.unl.edu>
CC: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <Pine.SGI.3.96.1010516172511.159364B-100000@phase1.unl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mako Furukawa wrote:

> >
> > You could try a floppy image from
> > ftp://oss.sgi.com/projects/xfs/download/archive/Release-1.0-test2/RH7.1-SGI-XFS-0.10.3/images/
> >
> > those kernels did not have APIC enabled.
> >

You really need the stage2.img to match up with the boot floppy.

The modules in stage2 are not compatible with the kernel on the older boot floppy.

You will probably need to grab the entire iso use it.



>
> This worked but when it went to installing the system, I got this error
> message:
>
> "Error mounting device hda5 as /:
> No such device
>
> This most likely means this partition has not been formatted.
>
> Press OK to reboot your system."
>
> I did choose to format all the partitions.  I thank you guys for all your
> help and appreciate any more information you can give me.
>
> -Mako
>
> ----------------------------------------------------------------------------
> Mako Furukawa                   |  furukawa@phase1.unl.edu
> Research Assistant              |  mako@wrestlingmat.com
> Department of Chemistry         |  http://www.wrestlingmat.com/makohome
> Hamilton Hall, 536              |  http://amateurwrestle.about.com
> University of Nebraska-Lincoln  |  "It is alright to be disappointed, but a
> Lincoln, NE 68588-0304          |   winner can never allow himself to be
> (402) 472-9982                  |   discouraged." -- D.A. Chapple
> ----------------------------------------------------------------------------

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 16 15:34:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GMYBf22902
	for linux-xfs-outgoing; Wed, 16 May 2001 15:34:11 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GMYAF22899
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:34:10 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1509rg-0007wT-00; Thu, 17 May 2001 10:33:56 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Russell Cattelan" <cattelan@thebarn.com>
Cc: "Eric Sandeen" <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: RE: ISO
Date: Thu, 17 May 2001 10:33:18 +1200
Message-ID: <KPECIILENDDLPCNIMLOFAEIJCEAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.SGI.3.96.1010516172511.159364B-100000@phase1.unl.edu>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: This worked but when it went to installing the system, I got this error
:: message:
:: 
:: "Error mounting device hda5 as /:
:: No such device
:: 
:: This most likely means this partition has not been formatted.
:: 
:: Press OK to reboot your system."

Heh... so which one of the XFS developers used to work with Windows then?

-- Juha

From owner-linux-xfs@oss.sgi.com Wed May 16 15:43:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GMhQl23346
	for linux-xfs-outgoing; Wed, 16 May 2001 15:43:26 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GMhPF23343
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 15:43:26 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4GMhIx28592;
	Wed, 16 May 2001 17:43:18 -0500 (CDT)
Message-ID: <3B030309.539B4796@sgi.com>
Date: Wed, 16 May 2001 17:45:29 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Saarinen <juha@saarinen.org>
CC: Russell Cattelan <cattelan@thebarn.com>, linux-xfs@oss.sgi.com
Subject: Re: ISO
References: <KPECIILENDDLPCNIMLOFAEIJCEAA.juha@saarinen.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Juha Saarinen wrote:

 
> Heh... so which one of the XFS developers used to work with Windows then?
> 
> -- Juha

Hey, watch it...!

(Anyway, we inherited that error message from Red Hat.)

  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 16:05:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GN5NO23949
	for linux-xfs-outgoing; Wed, 16 May 2001 16:05:23 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GN5MF23946
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:05:23 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id QAA07932
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:05:19 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00598; Thu, 17 May 2001 09:04:03 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA96760;
	Thu, 17 May 2001 09:04:02 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105170904.ZM96971@wobbly.melbourne.sgi.com>
Date: Thu, 17 May 2001 09:04:01 -0500
In-Reply-To: Dana Soward <dragon@thegoop.com>
        "Memory and quota issues." (May 15,  1:47pm)
References: <Pine.LNX.4.21.0105151337520.15848-100000@daffy.thegoop.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Dana Soward <dragon@thegoop.com>
Subject: Re: Memory and quota issues.
Cc: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi Dana,

On May 15,  1:47pm, Dana Soward wrote:
> Subject: Memory and quota issues.
> ... It *might* be something to do with debian woody,
> ... Also, i cant seem to get quota working. ...
> when i switched to XFS kernels i started getting this error from quota:
> 
> fudd:/home# /etc/init.d/quota start
> Checking quotas...done.
> Turning on quotas.
> quotaon: using /home/quota.group on
> /dev/ide/host2/bus0/target0/lun0/part9: Invalid argument
> quotaon: using /home/quota.user on
> /dev/ide/host2/bus0/target0/lun0/part9: Invalid argument
> 
> Any ideas? I dont know if its XFS, but id like to atleast rule it out.
> 

I think the problem here would be that the quota tools in
woody (testing) are version 2.00-9 - you'll need the tools
from sid (unstable) which are version 3.xx.  I suggest also
reading /usr/share/doc/xfsprogs/README.quota if you plan on
using quota with XFS.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 16 16:07:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GN7NL24239
	for linux-xfs-outgoing; Wed, 16 May 2001 16:07:23 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GN7MF24235
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:07:22 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA18392
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:05:57 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00625; Thu, 17 May 2001 09:06:02 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA97148;
	Thu, 17 May 2001 09:06:01 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105170906.ZM96892@wobbly.melbourne.sgi.com>
Date: Thu, 17 May 2001 09:06:00 -0500
In-Reply-To: Takayuki Sasaki <sasaki@bsd.tnes.nec.co.jp>
        "cmd/xfstests/032 failed" (May 16,  4:35pm)
References: <3B022DAF.C679F51@bsd.tnes.nec.co.jp>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Takayuki Sasaki <sasaki@bsd.tnes.nec.co.jp>, linux-xfs@oss.sgi.com
Subject: Re: cmd/xfstests/032 failed
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 16,  4:35pm, Takayuki Sasaki wrote:
> Subject: cmd/xfstests/032 failed
> 
> > mkfs.xfs: Use the -f option to force overwrite
> > Failed - overwrote fs type jfs!
> Failures: 032
> Failed 1 of 1 tests
> 
> I checked cmd/xfsprogs/mkfs/mountinfo.c, and I guess this may be caused
> by
> fstype() which does not check whether the file system is jfs or not.
> 
> Any sugestions?
> 

Yes, this was discussed a little while ago in the context of
detecting reiserfs.  The answer is the same - the mountinfo.c
code is the same as the code in:
	util-linux-2.XX/mount/mount_guess_fstype.c
if you add support for detection of jfs/reiserfs/... in mount,
it will find its way into mkfs.xfs soon thereafter.

There's a little program in the xfsprogs/mkfs subdirectory which
can help with testing - 
	# cd cmd/xfsprogs; make; cd mkfs; make fstyp
Unfortunately, I don't know anything about the jfs/reiserfs
superblock locations, magic numbers, etc, so I can't help out
here... the folk on the jfs/reiserfs lists should be able to
help you though.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 16 16:25:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GNPDR24796
	for linux-xfs-outgoing; Wed, 16 May 2001 16:25:13 -0700
Received: from web10406.mail.yahoo.com (web10406.mail.yahoo.com [216.136.130.98])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4GNPCF24793
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:25:12 -0700
Message-ID: <20010516232506.97800.qmail@web10406.mail.yahoo.com>
Received: from [66.25.21.199] by web10406.mail.yahoo.com; Wed, 16 May 2001 16:25:06 PDT
Date: Wed, 16 May 2001 16:25:06 -0700 (PDT)
From: John <jsh_45@yahoo.com>
Subject: mkfs.xfs primary bootable partition issue
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello all,

I'm trying to hack an XFS Debian potato install and I
have gotten pretty far but have ran into a wall.

My partitions are set up with cfdisk as follows:

/dev/hda   (boot flag set primary) /boot
/dev/hda5  (logical)               /
/dev/hda6  (logical)               /swap
/dev/hda7  (logical)               /var 

when I run mkfs.xfs on /dev/hda I get some strange
results


#mkfs.xfs -l size-32768 -f /dev/hda1
 size 32768 too large for internal log

but this same command works on /dev/hda5 and
/dev/hda7?

so I tried mkfs without the -l argument and it worked,
but when I try to mount /dev/hda1 things are not
working too well:

#mount -t xfs /dev/hda1 /boot
 Mounting /dev/hda1 on /boot failed: No such file or
directory

mounting /dev/hda5 and /dev/hda7 is all good though? 
Is there something I'm missing about the boot flag or
primary partitions?  Please help, I'm lost.


Best Regards,

John Herrington

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Wed May 16 16:59:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4GNx2M26031
	for linux-xfs-outgoing; Wed, 16 May 2001 16:59:02 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4GNx1F26028
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 16:59:01 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4GNx1x12412;
	Wed, 16 May 2001 18:59:01 -0500 (CDT)
Message-ID: <3B0314C7.27C776CB@sgi.com>
Date: Wed, 16 May 2001 19:01:11 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: John <jsh_45@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs primary bootable partition issue
References: <20010516232506.97800.qmail@web10406.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

John wrote:

> when I run mkfs.xfs on /dev/hda I get some strange
> results
> 
> #mkfs.xfs -l size-32768 -f /dev/hda1
>  size 32768 too large for internal log
> 
> but this same command works on /dev/hda5 and
> /dev/hda7?

My guess is that /dev/sda1 is a small partition, and 32768 filesystem
blocks is too big?  You can just let mkfs.xfs select a log size for you,
it will do a decent job.

> so I tried mkfs without the -l argument and it worked,
> but when I try to mount /dev/hda1 things are not
> working too well:
> 
> #mount -t xfs /dev/hda1 /boot
>  Mounting /dev/hda1 on /boot failed: No such file or
> directory

Ok, silly question maybe... does /boot exist?
 
> mounting /dev/hda5 and /dev/hda7 is all good though?
> Is there something I'm missing about the boot flag or
> primary partitions?  Please help, I'm lost.

the boot flag shouldn't have anything to do with it...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 16 17:53:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H0rGq27261
	for linux-xfs-outgoing; Wed, 16 May 2001 17:53:16 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H0rFF27258
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:53:15 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4H0rAs22832
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:53:14 -0700
Date: Wed, 16 May 2001 17:53:10 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: linux-xfs@oss.sgi.com
Subject: Very scary bug or feature....
Message-ID: <Pine.LNX.4.21.0105161741210.15848-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello again, i have a very disturbing story...

This morning i attempted to convert my / partition (hde5) from ext2 to
xfs.  I had everything all set, i was using my /home/ftp (hde8) partition
(as it was empty) to make the switch.  I coppied / over, then rebooted,
using hde8 as / this time, all went well, i then did a mkfs.xfs /dev/hde5
and mounted hde5 to /home/ftp. This is where i shot myself in the foot.  I
had errored in fstab, both / and /home/ftp were set to mount hde8, so when
i did a mount /home/ftp, it mounted hde8 *again*, but it didnt error or
tell me this.  Needless to say, the result was disasterous, i coppied /
over itself, and noticed some wierd stuff from cp, so i decided to use
tar.  I did an rm -r * in /home/ftp and blew away my /...humourous in a
sick way, i know. Anyway, the actual question is "Should mount allow me to
mount a partition more than once at the same time, (i dont recall this
being an option with ext2) or is this a nasty bug?"  I havent been able to
test things yet, as im am still recovering the system. I'll post tests as
soon as i have them, unless some one beats me to it. Sorry for the
wordiness...:P

Dana


From owner-linux-xfs@oss.sgi.com Wed May 16 17:54:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H0sGU27509
	for linux-xfs-outgoing; Wed, 16 May 2001 17:54:16 -0700
Received: from james.kalifornia.com (root@james.kalifornia.com [208.179.59.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H0sGF27506
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:54:16 -0700
Received: from kalifornia.com (linux4all@sc-24-130-146-204.socal.rr.com [24.130.146.204])
	(authenticated (0 bits))
	by james.kalifornia.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4H0s9XI004781
	(using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO);
	Wed, 16 May 2001 17:54:09 -0700
Message-ID: <3B032086.2050202@kalifornia.com>
Date: Wed, 16 May 2001 17:51:18 -0700
From: Ben Ford <ben@kalifornia.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en
MIME-Version: 1.0
To: John <jsh_45@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs primary bootable partition issue
References: <20010516232506.97800.qmail@web10406.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

John wrote:

>Hello all,
>
>I'm trying to hack an XFS Debian potato install and I
>have gotten pretty far but have ran into a wall.
>
>My partitions are set up with cfdisk as follows:
>
>/dev/hda   (boot flag set primary) /boot
>/dev/hda5  (logical)               /
>/dev/hda6  (logical)               /swap
>/dev/hda7  (logical)               /var 
>
>when I run mkfs.xfs on /dev/hda I get some strange
>results
>

One question . . . you did mean /dev/hda1, didn't you??

/dev/hda is the disk and /dev/hda1 is the first partition.

-b


-- 
 "One trend that bothers me is the glorification of
stupidity, that the media is reassuring people it's 
alright not to know anything. That to me is far more 
dangerous than a little pornography on the Internet." 
  - Carl Sagan




From owner-linux-xfs@oss.sgi.com Wed May 16 17:59:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H0xOG27928
	for linux-xfs-outgoing; Wed, 16 May 2001 17:59:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H0xNF27925
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:59:23 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id RAA09247
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 17:59:21 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01545; Thu, 17 May 2001 10:58:04 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA97694;
	Thu, 17 May 2001 10:58:03 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105171058.ZM94309@wobbly.melbourne.sgi.com>
Date: Thu, 17 May 2001 10:58:01 -0500
In-Reply-To: Dana Soward <dragon@thegoop.com>
        "Very scary bug or feature...." (May 16,  5:53pm)
References: <Pine.LNX.4.21.0105161741210.15848-100000@daffy.thegoop.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: Dana Soward <dragon@thegoop.com>, linux-xfs@oss.sgi.com
Subject: Re: Very scary bug or feature....
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On May 16,  5:53pm, Dana Soward wrote:
> Subject: Very scary bug or feature....
> ... Anyway, the actual question is "Should mount allow me to
> mount a partition more than once at the same time, (i dont recall this
> being an option with ext2) or is this a nasty bug?"

Yes - this is a feature of the Linux 2.4.x VFS layer
(ie. has nothing to do with either XFS or ext2).

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 16 20:06:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H36J729845
	for linux-xfs-outgoing; Wed, 16 May 2001 20:06:19 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H36GF29839
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:06:16 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA38781
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 05:06:14 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id WAA1840186 for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 22:04:57 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA20596 for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 22:04:57 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4H36U000923; Wed, 16 May 2001 22:06:30 -0500
Message-Id: <200105170306.f4H36U000923@jen.americas.sgi.com>
Date: Wed, 16 May 2001 22:06:30 -0500
Subject: TAKE - implement xfs snapshotting
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This adds support for lvm snapshotting to xfs - a separate patch is
needed from the lvm sources to make lvm snapshotting work without
extra user space commands. Note that once a snapshot has been
created it needs to be made writeable and the xfs uuid changed
with the xfs_db command.

The xfs_freeze command is also supplied to pause a filesystem
and resume activity without the use of the LVM patch. Note if
you freeze the root filesystem, or the filesystem with the
command on it, you may be toast!

Date:  Wed May 16 19:58:46 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-base

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95149a
cmd/xfsprogs/freeze/xfs_freeze.c - 1.1
	- New command to pause and unpause an active filesystem, intended for
	  use with snapshot capable hardware.

cmd/xfsprogs/freeze/Makefile - 1.1
	- Makefile for new xfs_freeze command

cmd/xfsprogs/man/man8/xfs_freeze.8 - 1.1
	- Man page for xfs_freeze

linux/fs/xfs/xfsidbg.c - 1.162
	- Dump new mount fields.

linux/fs/xfs/xfs_log.c - 1.237
	- Skip writing idle log records from sync activity when filesystem freeze
	  is in effect, prevents sync thread from getting blocked.

linux/fs/xfs/xfs_mount.h - 1.128
	- prototypes and extra mount structures for freeze/thaw implementation.

linux/fs/xfs/xfs_mount.c - 1.256
	- Add freeze synchronization implementation.

linux/fs/xfs/xfs_trans.c - 1.120
	- Add freeze synchronization points to trans_alloc, trans_dup and trans_free
	  calls.

linux/fs/xfs/linux/xfs_lrw.c - 1.99
	- Add freeze syncronization point to write path

linux/fs/xfs/linux/xfs_super.c - 1.123
	- Add write_super_lockfs and unlockfs methods to XFS - these call the
	  FREEZE and THAW ioctl calls. With an LVM patch these calls can be used
	  by lvm snapshotting to pause modifications during the snapshot creation.

linux/include/linux/xfs_fs.h - 1.24
	- Add new ioctl call definitions.

linux/fs/xfs/linux/xfs_ioctl.c - 1.37
	- Add new FREEZE and THAW ioctl calls. The FREEZE call will pause all
	  activity in the filesystem which causes modifications, and flush all
	  state out to disk. The thaw ioctl allows modifications again.

cmd/xfsprogs/include/xfs_mount.h - 1.4
	- Add new fields for filesystem freeze synchronisation

cmd/xfsprogs/include/xfs_fs.h - 1.5
	- Add new ioctl commands to freeze and unfreeze a filesystem.

cmd/xfsprogs/Makefile - 1.3
	- Add new freeze subdirectory

cmd/xfsprogs/VERSION - 1.18
	- Bump version



From owner-linux-xfs@oss.sgi.com Wed May 16 20:12:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H3CTI30232
	for linux-xfs-outgoing; Wed, 16 May 2001 20:12:29 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H3CTF30229
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:12:29 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA11399
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:11:04 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02344 for <@larry.melbourne.sgi.com:linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:11:10 +1000
Received: (from dxm@localhost) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) id NAA59455 for linux-xfs@oss.sgi.com; Thu, 17 May 2001 13:11:09 +1000 (EST)
Date: Thu, 17 May 2001 13:11:09 +1000 (EST)
From: dxm@clouds.melbourne.sgi.com (Daniel Moore)
Message-Id: <200105170311.NAA59455@clouds.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - fix xfs as modules
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Wed May 16 20:10:40 PDT 2001
Workarea:  clouds.melbourne.sgi.com:/hosts/snort/home/dxm/isms/slinx-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95151a
linux/fs/xfs_support/support.c - 1.4
	- replace removed line



From owner-linux-xfs@oss.sgi.com Wed May 16 20:35:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H3ZXk30793
	for linux-xfs-outgoing; Wed, 16 May 2001 20:35:33 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H3ZXF30790
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:35:33 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id UAA04323
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:46:29 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA02462 for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:34:14 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA97986
	for linux-xfs@oss.sgi.com; Thu, 17 May 2001 13:34:13 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105171334.ZM78876@wobbly.melbourne.sgi.com>
Date: Thu, 17 May 2001 13:34:12 -0500
In-Reply-To: Steve Lord <lord@sgi.com>
        "TAKE - implement xfs snapshotting" (May 16, 10:06pm)
References: <200105170306.f4H36U000923@jen.americas.sgi.com>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: linux-xfs@oss.sgi.com
Subject: Re: TAKE - implement xfs snapshotting
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On May 16, 10:06pm, Steve Lord wrote:
> Subject: TAKE - implement xfs snapshotting
> This adds support for lvm snapshotting to xfs - a separate patch is
> needed from the lvm sources to make lvm snapshotting work without
> extra user space commands. Note that once a snapshot has been
> created it needs to be made writeable and the xfs uuid changed
> with the xfs_db command.
> 

# xfs_admin -U generate /dev/<snapshot>

should do the trick too, without needing to know anything
about how xfs_db works.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 16 20:50:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H3ocm31222
	for linux-xfs-outgoing; Wed, 16 May 2001 20:50:38 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H3obF31219
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:50:37 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA14032
	for <linux-xfs@oss.sgi.com>; Wed, 16 May 2001 20:49:12 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA30389
	for linux-xfs@oss.sgi.com; Thu, 17 May 2001 13:49:18 +1000 (EST)
Date: Thu, 17 May 2001 13:49:18 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105170349.NAA30389@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - quota-3.01-pre6
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Wed May 16 03:25:13 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95048a
cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.6
	- fix version 1 vs. version 2 as default directory type.


Date:  Wed May 16 20:23:53 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95152a
cmd/xfsprogs/freeze/xfs_freeze.c - 1.2
	- fix a compiler warning - return zero on success at end of main().


Date:  Wed May 16 20:48:08 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95154a
SOURCES/quota-3.01-pre6.tar.gz - 1.1
	- new version of quota tools.

SPECS/quota.spec - 1.6
	- use the pre6 tarball now.  this includes the repquota infinite
	  loop fix, so drop that patch now.

SOURCES/quota-3.01-pre5.tar.gz - 1.2
SOURCES/quotaloop.patch - 1.2
	- removed, moving up to pre6 quota tools.



From owner-linux-xfs@oss.sgi.com Thu May 17 00:05:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H75Ki01894
	for linux-xfs-outgoing; Thu, 17 May 2001 00:05:20 -0700
Received: from web10407.mail.yahoo.com (web10407.mail.yahoo.com [216.136.130.99])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4H75KF01891
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 00:05:20 -0700
Message-ID: <20010517070519.58433.qmail@web10407.mail.yahoo.com>
Received: from [24.27.105.33] by web10407.mail.yahoo.com; Thu, 17 May 2001 00:05:19 PDT
Date: Thu, 17 May 2001 00:05:19 -0700 (PDT)
From: John <jsh_45@yahoo.com>
Subject: Re: mkfs.xfs primary bootable partition issue
To: Ben Ford <ben@kalifornia.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B032086.2050202@kalifornia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

--- Ben Ford <ben@kalifornia.com> wrote:

> One question . . . you did mean /dev/hda1, didn't
> you??
> 
> /dev/hda is the disk and /dev/hda1 is the first
> partition.


correct, I flubered that up when I wrote to the list

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Thu May 17 00:19:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H7JP102704
	for linux-xfs-outgoing; Thu, 17 May 2001 00:19:25 -0700
Received: from web10404.mail.yahoo.com (web10404.mail.yahoo.com [216.136.130.96])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4H7JOF02701
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 00:19:24 -0700
Message-ID: <20010517071924.2411.qmail@web10404.mail.yahoo.com>
Received: from [24.27.105.33] by web10404.mail.yahoo.com; Thu, 17 May 2001 00:19:24 PDT
Date: Thu, 17 May 2001 00:19:24 -0700 (PDT)
From: John <jsh_45@yahoo.com>
Subject: Re: mkfs.xfs primary bootable partition issue
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B0314C7.27C776CB@sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

--- Eric Sandeen <sandeen@sgi.com> wrote:
> > #mount -t xfs /dev/hda1 /boot
> >  Mounting /dev/hda1 on /boot failed: No such file
> or
> > directory
> 
> Ok, silly question maybe... does /boot exist?


Those silly user errors :)  Well the installer is
mounting / on a ram drive and I guess /var existed
cause that didn't error (but /boot did).  After
steeping back and taking a look at what the install
was doing I figured it out.  The installer mounts the
root hard drive /target (so I just mkdir /target/boot
and the same for var) and mounted the three mount
points AOK.

Thanks for the user error alert!  It got me thinking
right.

John  

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Thu May 17 00:21:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H7LqT02999
	for linux-xfs-outgoing; Thu, 17 May 2001 00:21:52 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H7LmF02992
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 00:21:52 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA29177
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 00:20:24 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id CAA28314 for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 02:20:31 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f4H7JVN06969
	for linux-xfs@oss.sgi.com; Thu, 17 May 2001 03:19:31 -0400
Date: Thu, 17 May 2001 03:19:31 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105170719.f4H7JVN06969@gibble.americas.sgi.com>
Subject: TAKE - 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May 17 00:19:19 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95158a
linux/kdb/modules/kdbm_pg.c - 1.36
	- Wrong printf format.



From owner-linux-xfs@oss.sgi.com Thu May 17 00:26:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H7QYO03360
	for linux-xfs-outgoing; Thu, 17 May 2001 00:26:34 -0700
Received: from gw.solid.fi (gw.solid.fi [193.65.201.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H7QWF03357
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 00:26:32 -0700
Received: from solidtech.com 
	by gw.solid.fi (8.9.1/8.9.1) with ESMTP id KAA29442
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 10:37:17 +0300 (EET DST)
Received: from lauri-ibm (lauri-ibm.solid.fi [192.168.1.184])
	by solidtech.com (8.9.3/8.9.3) with SMTP id KAA84401
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 10:26:26 +0300 (EEST)
	(envelope-from lauri@solidtech.com)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Lauri Ojantakanen <lauri@solidtech.com>
Organization: Solid
To: linux-xfs@oss.sgi.com
Subject: Questions about recovery
Date: Thu, 17 May 2001 10:26:21 +0300
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01051710262100.02801@lauri-ibm>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I am very happy using xfs (converted everything to xfs:). Usually everything 
goes fine with the system but there is one kinda scary thing: sometimes some 
files seem to be getting filled with null's after recovery. I mean that after 
one recovery one opera's bookmark file was still there but the contents of 
the file was just  '\0'. File was not truncated but its contents were "gone". 
I just would like to know whether this kind of behaviour is to be considered 
as a feature rather than a bug. I also would like to know what I could do to 
minimize the possibility for this to happen.

Rgrds,

//lauri

From owner-linux-xfs@oss.sgi.com Thu May 17 01:50:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H8oUj05212
	for linux-xfs-outgoing; Thu, 17 May 2001 01:50:30 -0700
Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H8oTF05209
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 01:50:29 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f4H8oPw11679;
	Thu, 17 May 2001 10:50:26 +0200
Message-Id: <4.3.2.7.2.20010517104520.0315b8d8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 May 2001 10:50:32 +0200
To: Lauri Ojantakanen <lauri@solidtech.com>, linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: Questions about recovery
In-Reply-To: <01051710262100.02801@lauri-ibm>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 10:26 17-5-2001 +0300, Lauri Ojantakanen wrote:
>Hi,
>
>I am very happy using xfs (converted everything to xfs:). Usually everything
>goes fine with the system but there is one kinda scary thing: sometimes some
>files seem to be getting filled with null's after recovery. I mean that after
>one recovery one opera's bookmark file was still there but the contents of
>the file was just  '\0'. File was not truncated but its contents were "gone".
>I just would like to know whether this kind of behaviour is to be considered
>as a feature rather than a bug. I also would like to know what I could do to
>minimize the possibility for this to happen.

hmmm... I remember that at some point kupdate got stuck on my machine and I 
could not reboot the machine or sync the filessystem.
If that happened I noticed that files that were edited ot touched after the 
kupdate hung would get a "\0" in it after recovery. In the case of 
/etc/fstab it gave some very weird results.
It took some time to notice because the rest of the system continued to 
function.

The cause of it was eventually lead back to a bad ram stick.
The 2.2 kernel before that obviously was not pushing the ram hard enough to 
expose it. I have not seen it after replacing the bad ram stick.

This may not be the case here but I am just giving a explanation of what I 
did to make it produce those errors.

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 17 02:17:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H9HQQ05980
	for linux-xfs-outgoing; Thu, 17 May 2001 02:17:26 -0700
Received: from akira.ep-ka.de (akira.ep-ag.com [194.120.231.250])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H9HOF05977
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 02:17:24 -0700
Received: from ep-ag.com (sol10.ep-ka.de [194.120.231.11])
	by akira.ep-ka.de (8.9.1/8.9.3) with ESMTP id LAA26478;
	Thu, 17 May 2001 11:17:22 +0200
Received: from ep-ag.com (stb@crusher.ep-ka.de [194.120.231.18])
	by ep-ag.com (8.9.3/8.9.3) with ESMTP id LAA23841;
	Thu, 17 May 2001 11:17:21 +0200 (MET DST)
Message-ID: <3B039720.6020104@ep-ag.com>
Date: Thu, 17 May 2001 11:17:20 +0200
From: "Klaus Strebel,ITS,204" <stb@ep-ag.com>
Organization: EIGNER+PARTNER AG
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-XFS i686; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: de, en
MIME-Version: 1.0
To: jtrostel@connex.com, Sean Elble <s_elble@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Samba ACLs - Latest Samba & XFS CVS
References: <XFMail.20010516113748.jtrostel@connex.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

John Trostel wrote:

> No.  In the 2.2.0 release, the configuration checks things differently.  I have
> asked Sean to send me the relevant configuration info to check.
> 
> On 16-May-2001 Klaus Strebel,ITS,204 wrote:
> 
>>Sean Elble wrote:
>>
>>
>>>Hello (again!),
>>>
>>>I downloaded the latest Samba and XFS CVS versions
>>>yesterday, and tried to compile ACL support, 
>>
>>just can't get the box i first tried it (some weeks ago, samba-2.2.0 was 
>>not released then ;-) ). Have a look to the configure script of samba. 
>>They are checking for IRIX platform ACLs only if on irix, because 
>>xfs-acls are irix acls, you have to convince configure for this test, 
>>that it is on irix platform. This should bild samba with xfs-acl 
>>support, but i couldn't test it by now, no spare time (sigh).
>>
>>If you don't find how to cheat it, let me know, i'll try to find it 
>>tomorrow.

ok, just updated samba-2.2.0 from cvs and had a look to the 
configure-script, search for

                         ;;
                 *irix*)
                         echo "$ac_t""Using IRIX ACLs" 1>&6
                         cat >> confdefs.h <<\EOF
#define HAVE_IRIX_ACLS 1
EOF

and change it to

                         ;;
                 *irix*)
                 *linux*)
                         echo "$ac_t""Using IRIX ACLs" 1>&6
                         cat >> confdefs.h <<\EOF
#define HAVE_IRIX_ACLS 1
EOF

now it should know which acl.h and functions to use.

Cheers
Klaus


From owner-linux-xfs@oss.sgi.com Thu May 17 02:47:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4H9lTl06774
	for linux-xfs-outgoing; Thu, 17 May 2001 02:47:29 -0700
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4H9lSF06771
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 02:47:28 -0700
Received: from bt02e0.god.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f4H9lDq17005
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 11:47:13 +0200 (MET DST)
Received: from god.bel.alcatel.be (bt02e1.god.bel.alcatel.be [138.203.145.14])
	by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id LAA25608
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 11:46:50 +0200 (MET DST)
Message-ID: <3B039DE7.3C469BE@god.bel.alcatel.be>
Date: Thu, 17 May 2001 11:46:15 +0200
From: kris buggenhout <buggenkr@god.bel.alcatel.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: trouble benchmarking
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

          262144    8192   12910   16615     7342     7215   25470  
29877   12400  153435   16287    22309    16208    7186     7061
          262144   16384   16570   16905     7009     7096   14807  
29554   11928  152983  160876    25201    12663    7068     7254
          524288      64    8471   11197
Error reading block 8023 0
read: Bad file descriptor



(scsi1:A:2:0): Locking max tag count at 127
SCSI disk error : host 1 channel 0 id 2 lun 0 return code = 8000002
Info fld=0x4e7dde, Current sd08:10: sense key Recovered Error
Additional sense indicates Recovered data - data auto-reallocated
 I/O error: dev 08:10, sector 5143848

it looks like a scsi error .. but when I do the same test on the same
drive with ext2 i get no error.

very strange ...

this is the only info I get 

details :

(scsi1:A:2): 10.000MB/s transfers (10.000MHz, offset 15)
  Vendor: FUJITSU   Model: M2949ESP SUN9.0G  Rev: 2545
  Type:   Direct-Access                      ANSI SCSI revision: 02

kernel and xfs from 10 may cvs tree
RH7.1 installed from RH cd's ...

From owner-linux-xfs@oss.sgi.com Thu May 17 03:36:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HAadD08141
	for linux-xfs-outgoing; Thu, 17 May 2001 03:36:39 -0700
Received: from mail.crc.dk (mail.crc.dk [130.226.184.8])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HAacF08137
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 03:36:38 -0700
Received: from crc.dk (k020-03.crc.dk [130.226.182.195])
	by mail.crc.dk (8.9.3/8.9.3) with ESMTP id MAA02424;
	Thu, 17 May 2001 12:36:36 +0200
Message-ID: <3B03A9B4.5AD5409@crc.dk>
Date: Thu, 17 May 2001 12:36:36 +0200
From: Mogens Kjaer <mk@crc.dk>
Organization: Carlsberg Laboratory
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2nfs i686)
X-Accept-Language: da, en, de
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: trouble benchmarking
References: <3B039DE7.3C469BE@god.bel.alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kris buggenhout wrote:
...
> SCSI disk error : host 1 channel 0 id 2 lun 0 return code = 8000002
> Info fld=0x4e7dde, Current sd08:10: sense key Recovered Error
> Additional sense indicates Recovered data - data auto-reallocated
>  I/O error: dev 08:10, sector 5143848
> 
> it looks like a scsi error .. but when I do the same test on the same
> drive with ext2 i get no error.
...

Looks like a bad block on the disk. This block has now
been replaced, so you won't see the error again.

Have you tried XFS more than once?

Mogens
-- 
Mogens Kjaer, Carlsberg Laboratory, Dept. of Chemistry
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk@crc.dk Homepage: http://www.crc.dk

From owner-linux-xfs@oss.sgi.com Thu May 17 04:09:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HB9J409176
	for linux-xfs-outgoing; Thu, 17 May 2001 04:09:19 -0700
Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HB9HF09161
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 04:09:17 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f4HB92P02128;
	Thu, 17 May 2001 13:09:02 +0200
Message-Id: <4.3.2.7.2.20010517130519.038d0c88@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 17 May 2001 13:08:58 +0200
To: kris buggenhout <buggenkr@god.bel.alcatel.be>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: trouble benchmarking
In-Reply-To: <3B039DE7.3C469BE@god.bel.alcatel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 11:46 17-5-2001 +0200, kris buggenhout wrote:
>it looks like a scsi error .. but when I do the same test on the same
>drive with ext2 i get no error.

ext2 probably handles bad blocks better. The XFS filesystem shuts down on 
error. Ext2 may stay up and note that the sector is moved and the data is ok.
It might be possible that xfs could be made to respect this re allocation 
of a bad sector and perhaps not shut down.

Can you verify that the filesystem was shutdown on error or not?
dmesg would verify that if that is the case.

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 17 06:47:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HDlC513332
	for linux-xfs-outgoing; Thu, 17 May 2001 06:47:12 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HDlBF13329
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 06:47:11 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4HDl1n10662;
	Thu, 17 May 2001 08:47:01 -0500 (CDT)
Message-ID: <3B03D6DD.9E31A922@sgi.com>
Date: Thu, 17 May 2001 08:49:17 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lauri Ojantakanen <lauri@solidtech.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Questions about recovery
References: <01051710262100.02801@lauri-ibm>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Lauri Ojantakanen wrote:
> 
> Hi,
> 
> I am very happy using xfs (converted everything to xfs:). Usually everything
> goes fine with the system but there is one kinda scary thing: sometimes some
> files seem to be getting filled with null's after recovery. I mean that after
> one recovery one opera's bookmark file was still there but the contents of
> the file was just  '\0'. 

This has been discussed a few times on the list.  (See the "might have
found a bug..." thread from this week).  The short answer is that it's a
feature, and specifying synchronous writes at mount time will minimize
it, but will also kill your performance.  You can also tune the bdflush
daemon to flush writes more often - also reducing performance.  It's a
tradeoff.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 17 07:47:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HElqp14818
	for linux-xfs-outgoing; Thu, 17 May 2001 07:47:52 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HElqF14815
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 07:47:52 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA07620
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 07:58:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1847720; Thu, 17 May 2001 09:46:34 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14595; Thu, 17 May 2001 09:46:34 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4HElu921491; Thu, 17 May 2001 09:47:56 -0500
Message-Id: <200105171447.f4HElu921491@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Eric Sandeen <sandeen@sgi.com>
cc: Lauri Ojantakanen <lauri@solidtech.com>, linux-xfs@oss.sgi.com
Subject: Re: Questions about recovery 
In-Reply-To: Message from Eric Sandeen <sandeen@sgi.com> 
   of "Thu, 17 May 2001 08:49:17 CDT." <3B03D6DD.9E31A922@sgi.com> 
Date: Thu, 17 May 2001 09:47:56 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Lauri Ojantakanen wrote:
> > 
> > Hi,
> > 
> > I am very happy using xfs (converted everything to xfs:). Usually everythin
> g
> > goes fine with the system but there is one kinda scary thing: sometimes som
> e
> > files seem to be getting filled with null's after recovery. I mean that aft
> er
> > one recovery one opera's bookmark file was still there but the contents of
> > the file was just  '\0'. 
> 
> This has been discussed a few times on the list.  (See the "might have
> found a bug..." thread from this week).  The short answer is that it's a
> feature, and specifying synchronous writes at mount time will minimize
> it, but will also kill your performance.  You can also tune the bdflush
> daemon to flush writes more often - also reducing performance.  It's a
> tradeoff.
> 
> -Eric
> 

I should also add here that the difference between what happens with XFS in
this scenario and what would happen with ext2 is that with ext2 you probably
would not see the new file at all - or the old one, but it depends on what
got synced and what did not. The reason files show up with no data in xfs
is that the delayed allocation code which reserves space during a write call
has to bump the inode size - this size is making it out to disk, however,
the allocation of real extents and the flush of the data is not. If delayed
allocation was not being used you would get a file with garbage read off
the disk, since the disk space would be allocated during the write call,
but the data would still not be written out into it.

Having a journalled filesystem does not in general mean you go pulling
the plug without shutting the machine down, recovery is there for dealing
with accidents and crashes, not so you can use the power button to
shutdown ;-)

Steve



From owner-linux-xfs@oss.sgi.com Thu May 17 07:56:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HEu1j15343
	for linux-xfs-outgoing; Thu, 17 May 2001 07:56:01 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HEu0F15340
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 07:56:00 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 3FC421E24E; Thu, 17 May 2001 16:55:59 +0200 (MEST)
Date: Thu, 17 May 2001 16:55:23 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: Eric Sandeen <sandeen@sgi.com>, Lauri Ojantakanen <lauri@solidtech.com>,
   linux-xfs@oss.sgi.com
Subject: Re: Questions about recovery
Message-ID: <20010517165523.A4718@gruyere.muc.suse.de>
References: <sandeen@sgi.com> <200105171447.f4HElu921491@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105171447.f4HElu921491@jen.americas.sgi.com>; from lord@sgi.com on Thu, May 17, 2001 at 09:47:56AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 17, 2001 at 09:47:56AM -0500, Steve Lord wrote:
> I should also add here that the difference between what happens with XFS in
> this scenario and what would happen with ext2 is that with ext2 you probably
> would not see the new file at all - or the old one, but it depends on what
> got synced and what did not. The reason files show up with no data in xfs
> is that the delayed allocation code which reserves space during a write call
> has to bump the inode size - this size is making it out to disk, however,
> the allocation of real extents and the flush of the data is not. If delayed
> allocation was not being used you would get a file with garbage read off
> the disk, since the disk space would be allocated during the write call,
> but the data would still not be written out into it.

It would be nice if there was at least an mount option to truncate
the files in this case to the size without the unwritten extent. 
The people here seem to object to the zeroes ("garbage") in the holes,
and I guess they would be more happy with truncated files.
[I realize that it's somewhat hard to implement as it would need to keep
a list somewhere about files that are candidates for such truncation; similar
to the delete-on-recovery list needed for close after unlink]

-Andi

From owner-linux-xfs@oss.sgi.com Thu May 17 08:06:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HF6xe15823
	for linux-xfs-outgoing; Thu, 17 May 2001 08:06:59 -0700
Received: from chimta02 (chimta02.algx.net [216.99.233.77])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HF6wF15820
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 08:06:58 -0700
Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26])
 by chimmx02.algx.net
 (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id
 <0GDH00F73JBLVO@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Thu,
 17 May 2001 10:06:57 -0500 (CDT)
Date: Thu, 17 May 2001 11:06:18 -0400 (EDT)
From: John Trostel <jtrostel@connex.com>
Subject: Re: Samba ACLs - Latest Samba & XFS CVS
In-reply-to: <3B039720.6020104@ep-ag.com>
To: "Klaus Strebel,ITS,204" <stb@ep-ag.com>
Cc: linux-xfs@oss.sgi.com, Sean Elble <s_elble@yahoo.com>
Reply-to: jtrostel@connex.com
Message-id: <XFMail.20010517110618.jtrostel@connex.com>
Organization: Connex
MIME-version: 1.0
X-Mailer: XFMail 1.4.8 on Linux
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Priority: 3 (Normal)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

No !!!

The configure scripts should properly find the linux XFS ACL stuff if the
system is set up correctly.  Sean finally got the Samba to compile correctly by
making sure that he had the following components in the right spot:

1. libacl.a (from the SGI Linux XFS)
        /usr/lib/libacl.a

2. acl.h (from the same SGI Linux XFS .... It has the SGI (c) notice)
        /usr/include/acl/acl.h

The following caveats must also be borne in mind.

1. The kernel needs to be compiled with both 'posix acls' and 'xfs file
support' enabled.

2. The ACL components need to be compiled and installed
        a. these are in .../cmds/acl in the CVS download (or tarballs)
        b. these require the acl-devel RPM from the rpms.

If those components are NOT in the right spots, the configuration script will
(properly) NOT configure in support for XFS ACLs.

If you use the 'fix' below, it will use the components designed for IRIX (not
Linux) XFS ACLs.  Since Linux XFS ACLs are based on IRIX ACLs, this _may_
actually work... for awhile.  If you get the configuration of your system
right, and use the correct parameters, you can get Samba running with the code
designed for Linux XFS.  I would think that this would be the preferable course
of action.

On 17-May-2001 Klaus Strebel,ITS,204 wrote:
> 
> ok, just updated samba-2.2.0 from cvs and had a look to the 
> configure-script, search for
> 
>                          ;;
>                  *irix*)
>                          echo "$ac_t""Using IRIX ACLs" 1>&6
>                          cat >> confdefs.h <<\EOF
>#define HAVE_IRIX_ACLS 1
> EOF
> 
> and change it to
> 
>                          ;;
>                  *irix*)
>                  *linux*)
>                          echo "$ac_t""Using IRIX ACLs" 1>&6
>                          cat >> confdefs.h <<\EOF
>#define HAVE_IRIX_ACLS 1
> EOF
> 
> now it should know which acl.h and functions to use.
> 
> Cheers
> Klaus

-- 
John M. Trostel
Linux OS Engineer
Connex
jtrostel@connex.com

From owner-linux-xfs@oss.sgi.com Thu May 17 08:31:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HFVwt16441
	for linux-xfs-outgoing; Thu, 17 May 2001 08:31:58 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HFVuF16438
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 08:31:56 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA03512
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 08:42:47 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1842249; Thu, 17 May 2001 10:30:29 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA57927; Thu, 17 May 2001 10:30:29 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4HFVqM21545; Thu, 17 May 2001 10:31:52 -0500
Message-Id: <200105171531.f4HFVqM21545@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Andi Kleen <ak@suse.de>
cc: Steve Lord <lord@sgi.com>, Eric Sandeen <sandeen@sgi.com>,
   Lauri Ojantakanen <lauri@solidtech.com>, linux-xfs@oss.sgi.com
Subject: Re: Questions about recovery 
In-Reply-To: Message from Andi Kleen <ak@suse.de> 
   of "Thu, 17 May 2001 16:55:23 +0200." <20010517165523.A4718@gruyere.muc.suse.de> 
Date: Thu, 17 May 2001 10:31:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Thu, May 17, 2001 at 09:47:56AM -0500, Steve Lord wrote:
> > I should also add here that the difference between what happens with XFS in
> > this scenario and what would happen with ext2 is that with ext2 you probabl
> y
> > would not see the new file at all - or the old one, but it depends on what
> > got synced and what did not. The reason files show up with no data in xfs
> > is that the delayed allocation code which reserves space during a write cal
> l
> > has to bump the inode size - this size is making it out to disk, however,
> > the allocation of real extents and the flush of the data is not. If delayed
> > allocation was not being used you would get a file with garbage read off
> > the disk, since the disk space would be allocated during the write call,
> > but the data would still not be written out into it.
> 
> It would be nice if there was at least an mount option to truncate
> the files in this case to the size without the unwritten extent. 
> The people here seem to object to the zeroes ("garbage") in the holes,
> and I guess they would be more happy with truncated files.
> [I realize that it's somewhat hard to implement as it would need to keep
> a list somewhere about files that are candidates for such truncation; similar
> to the delete-on-recovery list needed for close after unlink]
> 
> -Andi

Hey, you have the code.... ;-)

I suspect a simpler method of doing this would be keep size extensions
to the file which are only delayed allocate in an in memory only inode
size, the size synced out to disk or recorded in transactions would 
reflect where the last real extent was written out to. You do have to
be careful though, since it is legal to have a hole at the end of a file
it is only when you do delalloc writes that this in memory size would
differ from the on disk one. The end result would be that after recovery
the size would return to the last one pushed out to disk - which would
tend to represent where there was real data in the file not zeros.

Steve




From owner-linux-xfs@oss.sgi.com Thu May 17 11:46:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HIkGB20618
	for linux-xfs-outgoing; Thu, 17 May 2001 11:46:16 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HIkEF20615
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 11:46:14 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4HIiSQ29600
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:44:28 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 17 May 2001 13:44:28 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <Pine.LNX.4.33.0105161056580.19365-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.33.0105171344060.28169-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Has ANYONE looked into this? It seems pretty serious. Anyone?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 16 May 2001, Austin Gonyou wrote:

> On the system I've been testing LVM+XFS with, I've run into a bit of a
> dilemma. If I try to resize the a volume more than once, I get the
> following error message:
>
> -------begin problem-------
> [root@core /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/sda6               260240    120336    139904  47% /
> /dev/sda1                19264     12616      6648  66% /boot
> /dev/sda10             1167912       184   1167728   1% /home
> /dev/sda9              1167912    871764    296148  75% /usr
> /dev/sda7               260240     17848    242392   7% /var
> /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> /dev/web/webvol1       7859520       144   7859376   1% /web
> [root@core /root]# lvextend -L +100M /dev/web/webvol1
> lvextend -- rounding size to physical extent boundary
> lvextend -- rounding size 7995392 KB to stripe boundary size 8126464 KB
> lvextend -- extending logical volume "/dev/web/webvol1" to 7.75 GB
> lvextend -- doing automatic backup of volume group "web"
> lvextend -- logical volume "/dev/web/webvol1" successfully extended
>
> [root@core /root]# xfs_growfs /web/
> meta-data=/web                   isize=256    agcount=8, agsize=245760
> blks
> data     =                       bsize=4096   blocks=1966080, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 1966080 to 2031616
> [root@core /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/sda6               260240    120284    139956  47% /
> /dev/sda1                19264     12616      6648  66% /boot
> /dev/sda10             1167912       184   1167728   1% /home
> /dev/sda9              1167912    871764    296148  75% /usr
> /dev/sda7               260240     17848    242392   7% /var
> /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> /dev/web/webvol1       8121664       160   8121504   1% /web
>
> [root@core /root]# lvextend -L +100M /dev/web/webvol1
> lvextend -- rounding size to physical extent boundary
> lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> lvextend -- doing automatic backup of volume group "web"
> lvextend -- logical volume "/dev/web/webvol1" successfully extended
>
> [root@core /root]# xfs_growfs /web/
> meta-data=/web                   isize=256    agcount=9, agsize=245760
> blks
> data     =                       bsize=4096   blocks=2031616, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
> --------End Problem------
>
> Ok, so now let's reformat that partition and remount it.
>
> ------begin reformat------
> [root@core /root]# umount /web/
> [root@core /root]# mkfs.xfs /dev/web/webvol1  -f
> meta-data=/dev/web/webvol1       isize=256    agcount=8, agsize=262144
> blks
> data     =                       bsize=4096   blocks=2097152, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> [root@core /root]# mount -a
> [root@core /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/sda6               260240    120304    139936  47% /
> /dev/sda1                19264     12616      6648  66% /boot
> /dev/sda10             1167912       184   1167728   1% /home
> /dev/sda9              1167912    871764    296148  75% /usr
> /dev/sda7               260240     17848    242392   7% /var
> /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> /dev/web/webvol1       8383808       144   8383664   1% /web
>
> ------End Reformat-------
>
> Is this a known bug? This problem isn't actually size dependant, as in the
> ammount of the resize itself, as in here:
>
>
> ----begin example----
> [root@core /root]# lvextend -L +2M /dev/web/webvol1
> lvextend -- rounding size to physical extent boundary
> lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> lvextend -- doing automatic backup of volume group "web"
> lvextend -- logical volume "/dev/web/webvol1" successfully extended
>
> [root@core /root]# xfs_growfs /web/
> meta-data=/web                   isize=256    agcount=8, agsize=253952
> blks
> data     =                       bsize=4096   blocks=2031616, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 2031616 to 2097152
> [root@core /root]# lvextend -L +2M /dev/web/webvol1
> lvextend -- rounding size to physical extent boundary
> lvextend -- rounding size 8519680 KB to stripe boundary size 8650752 KB
> lvextend -- extending logical volume "/dev/web/webvol1" to 8.25 GB
> lvextend -- doing automatic backup of volume group "web"
> lvextend -- logical volume "/dev/web/webvol1" successfully extended
>
> [root@core /root]# xfs_growfs /web/
> meta-data=/web                   isize=256    agcount=9, agsize=253952
> blks
> data     =                       bsize=4096   blocks=2097152, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
>
> ----end example-----
>
> I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
> Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
> from SGI to install the box. Using LVM 0.9.1-b7 tools.
>
>


From owner-linux-xfs@oss.sgi.com Thu May 17 11:58:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HIwXB21066
	for linux-xfs-outgoing; Thu, 17 May 2001 11:58:33 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HIwVF21063
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 11:58:32 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA111683
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 20:58:29 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1855138; Thu, 17 May 2001 13:57:12 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA86615; Thu, 17 May 2001 13:57:12 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4HIwX712081; Thu, 17 May 2001 13:58:33 -0500
Message-Id: <200105171858.f4HIwX712081@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LVM/XFS Bug? 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Thu, 17 May 2001 13:44:28 CDT." <Pine.LNX.4.33.0105171344060.28169-100000@UberGeek.coremetrics.com> 
Date: Thu, 17 May 2001 13:58:33 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Has ANYONE looked into this? It seems pretty serious. Anyone?

Not yet - patience, if this was a commercial release you would have
to wait several months for a fix ;-)

Steve

> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Wed, 16 May 2001, Austin Gonyou wrote:
> 
> > On the system I've been testing LVM+XFS with, I've run into a bit of a
> > dilemma. If I try to resize the a volume more than once, I get the
> > following error message:
> >
> > -------begin problem-------
> > [root@core /root]# df
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/sda6               260240    120336    139904  47% /
> > /dev/sda1                19264     12616      6648  66% /boot
> > /dev/sda10             1167912       184   1167728   1% /home
> > /dev/sda9              1167912    871764    296148  75% /usr
> > /dev/sda7               260240     17848    242392   7% /var
> > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > /dev/web/webvol1       7859520       144   7859376   1% /web
> > [root@core /root]# lvextend -L +100M /dev/web/webvol1
> > lvextend -- rounding size to physical extent boundary
> > lvextend -- rounding size 7995392 KB to stripe boundary size 8126464 KB
> > lvextend -- extending logical volume "/dev/web/webvol1" to 7.75 GB
> > lvextend -- doing automatic backup of volume group "web"
> > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> >
> > [root@core /root]# xfs_growfs /web/
> > meta-data=/web                   isize=256    agcount=8, agsize=245760
> > blks
> > data     =                       bsize=4096   blocks=1966080, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > data blocks changed from 1966080 to 2031616
> > [root@core /root]# df
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/sda6               260240    120284    139956  47% /
> > /dev/sda1                19264     12616      6648  66% /boot
> > /dev/sda10             1167912       184   1167728   1% /home
> > /dev/sda9              1167912    871764    296148  75% /usr
> > /dev/sda7               260240     17848    242392   7% /var
> > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > /dev/web/webvol1       8121664       160   8121504   1% /web
> >
> > [root@core /root]# lvextend -L +100M /dev/web/webvol1
> > lvextend -- rounding size to physical extent boundary
> > lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> > lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> > lvextend -- doing automatic backup of volume group "web"
> > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> >
> > [root@core /root]# xfs_growfs /web/
> > meta-data=/web                   isize=256    agcount=9, agsize=245760
> > blks
> > data     =                       bsize=4096   blocks=2031616, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
> > --------End Problem------
> >
> > Ok, so now let's reformat that partition and remount it.
> >
> > ------begin reformat------
> > [root@core /root]# umount /web/
> > [root@core /root]# mkfs.xfs /dev/web/webvol1  -f
> > meta-data=/dev/web/webvol1       isize=256    agcount=8, agsize=262144
> > blks
> > data     =                       bsize=4096   blocks=2097152, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal log           bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > [root@core /root]# mount -a
> > [root@core /root]# df
> > Filesystem           1k-blocks      Used Available Use% Mounted on
> > /dev/sda6               260240    120304    139936  47% /
> > /dev/sda1                19264     12616      6648  66% /boot
> > /dev/sda10             1167912       184   1167728   1% /home
> > /dev/sda9              1167912    871764    296148  75% /usr
> > /dev/sda7               260240     17848    242392   7% /var
> > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > /dev/web/webvol1       8383808       144   8383664   1% /web
> >
> > ------End Reformat-------
> >
> > Is this a known bug? This problem isn't actually size dependant, as in the
> > ammount of the resize itself, as in here:
> >
> >
> > ----begin example----
> > [root@core /root]# lvextend -L +2M /dev/web/webvol1
> > lvextend -- rounding size to physical extent boundary
> > lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> > lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> > lvextend -- doing automatic backup of volume group "web"
> > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> >
> > [root@core /root]# xfs_growfs /web/
> > meta-data=/web                   isize=256    agcount=8, agsize=253952
> > blks
> > data     =                       bsize=4096   blocks=2031616, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > data blocks changed from 2031616 to 2097152
> > [root@core /root]# lvextend -L +2M /dev/web/webvol1
> > lvextend -- rounding size to physical extent boundary
> > lvextend -- rounding size 8519680 KB to stripe boundary size 8650752 KB
> > lvextend -- extending logical volume "/dev/web/webvol1" to 8.25 GB
> > lvextend -- doing automatic backup of volume group "web"
> > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> >
> > [root@core /root]# xfs_growfs /web/
> > meta-data=/web                   isize=256    agcount=9, agsize=253952
> > blks
> > data     =                       bsize=4096   blocks=2097152, imaxpct=25
> >          =                       sunit=0      swidth=0 blks, unwritten=0
> > naming   =version 2              bsize=4096
> > log      =internal               bsize=4096   blocks=1200
> > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
> >
> > ----end example-----
> >
> > I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
> > Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
> > from SGI to install the box. Using LVM 0.9.1-b7 tools.
> >
> >



From owner-linux-xfs@oss.sgi.com Thu May 17 12:20:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HJKfn21779
	for linux-xfs-outgoing; Thu, 17 May 2001 12:20:41 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HJKdF21776
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 12:20:39 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4HJIMq29860;
	Thu, 17 May 2001 14:18:22 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 17 May 2001 14:18:21 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug? 
In-Reply-To: <200105171858.f4HIwX712081@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105171417250.28169-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yeah..I know, but this seems pretty severe. Usually things of this
severity seem to get talked about on the list immediately, so I didn't
know if anyone was listening out there or not. Sorry for the bother!
Thanks for the reply!

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 17 May 2001, Steve Lord wrote:

> > Has ANYONE looked into this? It seems pretty serious. Anyone?
>
> Not yet - patience, if this was a commercial release you would have
> to wait several months for a fix ;-)
>
> Steve
>
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
> > On Wed, 16 May 2001, Austin Gonyou wrote:
> >
> > > On the system I've been testing LVM+XFS with, I've run into a bit of a
> > > dilemma. If I try to resize the a volume more than once, I get the
> > > following error message:
> > >
> > > -------begin problem-------
> > > [root@core /root]# df
> > > Filesystem           1k-blocks      Used Available Use% Mounted on
> > > /dev/sda6               260240    120336    139904  47% /
> > > /dev/sda1                19264     12616      6648  66% /boot
> > > /dev/sda10             1167912       184   1167728   1% /home
> > > /dev/sda9              1167912    871764    296148  75% /usr
> > > /dev/sda7               260240     17848    242392   7% /var
> > > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > > /dev/web/webvol1       7859520       144   7859376   1% /web
> > > [root@core /root]# lvextend -L +100M /dev/web/webvol1
> > > lvextend -- rounding size to physical extent boundary
> > > lvextend -- rounding size 7995392 KB to stripe boundary size 8126464 KB
> > > lvextend -- extending logical volume "/dev/web/webvol1" to 7.75 GB
> > > lvextend -- doing automatic backup of volume group "web"
> > > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> > >
> > > [root@core /root]# xfs_growfs /web/
> > > meta-data=/web                   isize=256    agcount=8, agsize=245760
> > > blks
> > > data     =                       bsize=4096   blocks=1966080, imaxpct=25
> > >          =                       sunit=0      swidth=0 blks, unwritten=0
> > > naming   =version 2              bsize=4096
> > > log      =internal               bsize=4096   blocks=1200
> > > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > > data blocks changed from 1966080 to 2031616
> > > [root@core /root]# df
> > > Filesystem           1k-blocks      Used Available Use% Mounted on
> > > /dev/sda6               260240    120284    139956  47% /
> > > /dev/sda1                19264     12616      6648  66% /boot
> > > /dev/sda10             1167912       184   1167728   1% /home
> > > /dev/sda9              1167912    871764    296148  75% /usr
> > > /dev/sda7               260240     17848    242392   7% /var
> > > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > > /dev/web/webvol1       8121664       160   8121504   1% /web
> > >
> > > [root@core /root]# lvextend -L +100M /dev/web/webvol1
> > > lvextend -- rounding size to physical extent boundary
> > > lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> > > lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> > > lvextend -- doing automatic backup of volume group "web"
> > > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> > >
> > > [root@core /root]# xfs_growfs /web/
> > > meta-data=/web                   isize=256    agcount=9, agsize=245760
> > > blks
> > > data     =                       bsize=4096   blocks=2031616, imaxpct=25
> > >          =                       sunit=0      swidth=0 blks, unwritten=0
> > > naming   =version 2              bsize=4096
> > > log      =internal               bsize=4096   blocks=1200
> > > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > > xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
> > > --------End Problem------
> > >
> > > Ok, so now let's reformat that partition and remount it.
> > >
> > > ------begin reformat------
> > > [root@core /root]# umount /web/
> > > [root@core /root]# mkfs.xfs /dev/web/webvol1  -f
> > > meta-data=/dev/web/webvol1       isize=256    agcount=8, agsize=262144
> > > blks
> > > data     =                       bsize=4096   blocks=2097152, imaxpct=25
> > >          =                       sunit=0      swidth=0 blks, unwritten=0
> > > naming   =version 2              bsize=4096
> > > log      =internal log           bsize=4096   blocks=1200
> > > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > > [root@core /root]# mount -a
> > > [root@core /root]# df
> > > Filesystem           1k-blocks      Used Available Use% Mounted on
> > > /dev/sda6               260240    120304    139936  47% /
> > > /dev/sda1                19264     12616      6648  66% /boot
> > > /dev/sda10             1167912       184   1167728   1% /home
> > > /dev/sda9              1167912    871764    296148  75% /usr
> > > /dev/sda7               260240     17848    242392   7% /var
> > > /dev/oracle/oravol1    8383808       144   8383664   1% /oracle
> > > /dev/web/webvol1       8383808       144   8383664   1% /web
> > >
> > > ------End Reformat-------
> > >
> > > Is this a known bug? This problem isn't actually size dependant, as in the
> > > ammount of the resize itself, as in here:
> > >
> > >
> > > ----begin example----
> > > [root@core /root]# lvextend -L +2M /dev/web/webvol1
> > > lvextend -- rounding size to physical extent boundary
> > > lvextend -- rounding size 8257536 KB to stripe boundary size 8388608 KB
> > > lvextend -- extending logical volume "/dev/web/webvol1" to 8 GB
> > > lvextend -- doing automatic backup of volume group "web"
> > > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> > >
> > > [root@core /root]# xfs_growfs /web/
> > > meta-data=/web                   isize=256    agcount=8, agsize=253952
> > > blks
> > > data     =                       bsize=4096   blocks=2031616, imaxpct=25
> > >          =                       sunit=0      swidth=0 blks, unwritten=0
> > > naming   =version 2              bsize=4096
> > > log      =internal               bsize=4096   blocks=1200
> > > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > > data blocks changed from 2031616 to 2097152
> > > [root@core /root]# lvextend -L +2M /dev/web/webvol1
> > > lvextend -- rounding size to physical extent boundary
> > > lvextend -- rounding size 8519680 KB to stripe boundary size 8650752 KB
> > > lvextend -- extending logical volume "/dev/web/webvol1" to 8.25 GB
> > > lvextend -- doing automatic backup of volume group "web"
> > > lvextend -- logical volume "/dev/web/webvol1" successfully extended
> > >
> > > [root@core /root]# xfs_growfs /web/
> > > meta-data=/web                   isize=256    agcount=9, agsize=253952
> > > blks
> > > data     =                       bsize=4096   blocks=2097152, imaxpct=25
> > >          =                       sunit=0      swidth=0 blks, unwritten=0
> > > naming   =version 2              bsize=4096
> > > log      =internal               bsize=4096   blocks=1200
> > > realtime =none                   extsz=65536  blocks=0, rtextents=0
> > > xfs_growfs: ioctl failed - XFS_IOC_FSGROWFSDATA: Unknown error 990
> > >
> > > ----end example-----
> > >
> > > I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
> > > Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
> > > from SGI to install the box. Using LVM 0.9.1-b7 tools.
> > >
> > >
>


From owner-linux-xfs@oss.sgi.com Thu May 17 13:04:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HK4TM23011
	for linux-xfs-outgoing; Thu, 17 May 2001 13:04:29 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.68.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4HK4RF23008
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:04:28 -0700
Received: (qmail 31704 invoked by uid 3995); 17 May 2001 20:04:26 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Two problems with a new installation
Date: 17 May 2001 16:04:26 -0400
Message-ID: <wx0eltng2t1.fsf@sws5.ctd.ornl.gov>
Lines: 67
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I installed XFS 1.0 + Red Hat 7.1 via the SGI installer on a 2-proc
Dell server with 2 x 250GB AMI MegaRAID's. The installation went
smoothly, but I've been getting occasional messages like:

May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
May 17 03:42:52 daacsnfs kernel: __alloc_pages: 0-order allocation failed.

What do these messages mean?

I'm migrating one of the RAID's to xfs and it's going rather slowly
(6 hrs to untar 18 GB so far). Watching the disk space used on the xfs
raid, I see lots of periods with no obvious activity. E.g., at
5-second intervals:

                     248533712  13932188 234601524   6% /smm1
                     248533712  13934712 234599000   6% /smm1
                     248533712  13936248 234597464   6% /smm1
                     248533712  13936248 234597464   6% /smm1
                     248533712  13936248 234597464   6% /smm1
                     248533712  13936780 234596932   6% /smm1
                     248533712  13951096 234582616   6% /smm1
                     248533712  13951096 234582616   6% /smm1
                     248533712  13962360 234571352   6% /smm1
                     248533712  13974288 234559424   6% /smm1
                     248533712  13974328 234559384   6% /smm1
                     248533712  13974328 234559384   6% /smm1
                     248533712  13974328 234559384   6% /smm1
                     248533712  13974328 234559384   6% /smm1
                     248533712  13974328 234559384   6% /smm1
                     248533712  13993080 234540632   6% /smm1

The __alloc_pages errors are much less frequent than the I/O pauses,
so they could be two separate problems.

hinv says:

Main memory size: 896 Mbytes
2 GenuineIntel Pentium III (Katmai) processors
1 vga+ graphics device
1 keyboard
PCI bus devices:
    ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
    IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
    USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
    Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
    VGA compatible controller: ATI Technologies Inc 3D Rage Pro (rev 92).
    PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (rev 3).
    PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (#2) (rev 3).
    PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (#3) (rev 3).
    I2O: Intel Corporation 80960RP [i960RP Microprocessor] (rev 3).
    I2O: Intel Corporation 80960RP [i960RP Microprocessor] (#2) (rev 3).
    I2O: Intel Corporation 80960RP [i960RP Microprocessor] (#3) (rev 3).
    Host bridge: Intel Corporation 450NX - 82451NX Memory & I/O Controller (rev 3).
    SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (rev 0).
    SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (#2) (rev 0).
    SCSI storage controller: Adaptec AIC-7860 (rev 3).
    Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8).
    Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8).
    Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (rev 4).
    Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (#2) (rev 4).
    Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (#3) (rev 4).

-- 
Dave Sill <MaxFreedom@sws5.ctd.ornl.gov>       <http://web.infoave.net/~dsill>
Oak Ridge National Lab, Workstation Support
<http://www.lifewithqmail.org>: almost everything you always wanted to know.

From owner-linux-xfs@oss.sgi.com Thu May 17 13:56:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HKugD24828
	for linux-xfs-outgoing; Thu, 17 May 2001 13:56:42 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HKufF24824
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:56:41 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id NAA00892
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 13:56:37 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1855342 for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 15:55:22 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA30468 for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 15:55:22 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4HKugK22792; Thu, 17 May 2001 15:56:42 -0500
Message-Id: <200105172056.f4HKugK22792@jen.americas.sgi.com>
Date: Thu, 17 May 2001 15:56:42 -0500
Subject: TAKE - Reduce the number of times we do revalidate
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

XFS has an inode revalidate call since it keeps the 'master' copy of
a lot of inode state in its own structures. This reduces the times
we actually go extract the data from the xfs inode and propogate it
to the linux inode to the times when we know they are different.

Date:  Thu May 17 13:53:29 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95200a
linux/fs/xfs/linux/xfs_file.c - 1.47
	- Add call to VMODIFY to ioctl path - we do not know what we did to the
	  inode.

linux/fs/xfs/linux/xfs_vnode.c - 1.62
	- Clear VMODIFIED flag when we update the linux inode attributes from
	  the xfs inode.

linux/fs/xfs/linux/xfs_super.c - 1.124
	- When creating the root inode on a filesystem, make sure we fill in its
	  attributes.

linux/fs/xfs/linux/xfs_iops.c - 1.105
	- Use VMODIFIED flag in vnode to determine when the revalidate call has
	  work to do. Set the VMODIFIED flag in all the right places.

linux/fs/xfs/linux/xfs_vnode.h - 1.19
	- Add VMODIFIED flag and macros to manipulate it.



From owner-linux-xfs@oss.sgi.com Thu May 17 14:21:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HLL0P25766
	for linux-xfs-outgoing; Thu, 17 May 2001 14:21:00 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HLKrF25761
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 14:20:53 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA116880
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 23:20:40 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA75310; Thu, 17 May 2001 16:19:24 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4HLINw07876;
	Thu, 17 May 2001 17:18:23 -0400
Message-ID: <3B04401F.3166BEC1@thebarn.com>
Date: Thu, 17 May 2001 17:18:23 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mdkinstall <install@mandrakesoft.com>,
   Chmouel Boudjnah <chmouel@mandrakesoft.com>, Pixel <pixel@mandrakesoft.com>,
   "Venables, Michael" <Michael.Venables@compaq.com>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Mandrake installer
Content-Type: multipart/mixed;
 boundary="------------C3286EDD9ADC67DB6D09B4CB"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.
--------------C3286EDD9ADC67DB6D09B4CB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've managed to create a Mandrake 8.0 + xfs install CD

I'm waiting for the kernel to rebuild with the nfsd_ops patch included.

Once this is done I will change out the kernel rpm's and toss the iso
image
on my ftp server
ftp.thebarn.com

I would put it on oss but since it contains crypto code it's not allowed
there.

I'm sure there will be a lot of rough edges but it the basic
functionality is there.

I'll include the current set of changes to the installer, some of them
are
just local path changes.
Note I had change all the strings of "xfs" to lower case, mixing the
cases does
not work.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.



--------------C3286EDD9ADC67DB6D09B4CB
Content-Type: text/plain; charset=us-ascii;
 name="patch2"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch2"

? .main
? patch
? patch2
Index: Makefile
===================================================================
RCS file: /cooker/gi/Makefile,v
retrieving revision 1.115
diff -u -r1.115 Makefile
--- Makefile	2001/04/15 18:01:44	1.115
+++ Makefile	2001/05/17 21:15:33
@@ -25,7 +25,7 @@
 endif
 DIRS = tools mdk-stage1 perl-install
 
-ROOTDEST = /export
+ROOTDEST = /export/bounce/xfscook
 UPLOAD_DEST_ = ~/cooker
 UPLOAD_DEST = $(UPLOAD_DEST_)/cooker
 UPLOAD_DEST_CONTRIB = $(UPLOAD_DEST_)/contrib
Index: make_boot_img
===================================================================
RCS file: /cooker/gi/make_boot_img,v
retrieving revision 1.75
diff -u -r1.75 make_boot_img
--- make_boot_img	2001/05/01 12:54:46	1.75
+++ make_boot_img	2001/05/17 21:15:33
@@ -67,11 +67,12 @@
 sub initrd {
     my ($mnt, $img) = @_;
     my ($ltype, $I) = $type =~ /(.*?)(64)/; $ltype ||= $type;
-    my $tmp = "$ENV{HOME}/tmp/initrd";
+    #    my $tmp = "$ENV{HOME}/tmp/initrd";
+        my $tmp = "/tmp/initrd";
     my $tar = "$instdir/stage1-data/stage1.tar.bz2";
 
     __ "$sudo umount $tmp $mnt 2>/dev/null";
-    _ "dd if=/dev/zero of=$tmp bs=1k count=" . ($type eq "all" ? 4000 : 2000);
+    _ "dd if=/dev/zero of=$tmp bs=1k count=" . ($type eq "all" ? 16000 : 8000);
     _ "$mke2fs $tmp";
     _ "$sudo mount -t ext2 $tmp $mnt -o loop";
 
Index: update_kernel
===================================================================
RCS file: /cooker/gi/update_kernel,v
retrieving revision 1.67
diff -u -r1.67 update_kernel
--- update_kernel	2001/04/11 11:51:40	1.67
+++ update_kernel	2001/05/17 21:15:33
@@ -71,7 +71,8 @@
 HD_MODULES="       $DOSMODULES $SCSI_DRIVERS $DISK_DRIVERS loop.o isofs.o reiserfs.o"
 PCMCIA_MODULES="   $DOSMODULES $PCMCIA_DRIVERS"
 BIG_MODULES="      $BIG_DRIVERS"
-ALL_MODULES="      $DOSMODULES $ALL_DRIVERS loop.o isofs.o reiserfs.o"
+#ALL_MODULES="      $DOSMODULES $ALL_DRIVERS loop.o isofs.o reiserfs.o"
+ALL_MODULES="      $DOSMODULES $ALL_DRIVERS loop.o isofs.o reiserfs.o pagebuf.o xfs_support.o xfs.o"
 NOT_USEFULL_IN_STAGE1="nls_*.o parport_probe.o raid*.o serial.o smbfs.o usb-*.o"
 
 GENERIC_MODULES="isa-pnp.o floppy.o"
Index: perl-install/Makefile.config
===================================================================
RCS file: /cooker/gi/perl-install/Makefile.config,v
retrieving revision 1.22
diff -u -r1.22 Makefile.config
--- perl-install/Makefile.config	2001/04/07 23:00:23	1.22
+++ perl-install/Makefile.config	2001/05/17 21:15:35
@@ -8,7 +8,7 @@
 STANDALONEPMS= diskdrake XFdrake mousedrake printerdrake keyboarddrake draknet net_monitor tinyfirewall drakxconf drakxservices draksec drakboot adduserdrake drakgw livedrake
 PMS	   += $(STANDALONEPMS:%=standalone/%)
 REP4PMS     = /usr/bin/perl-install
-ROOTDEST    = /export
+ROOTDEST    = /export/bounce/xfscook
 DEST        = $(ROOTDEST)/Mandrake/mdkinst
 STAGE2      = $(ROOTDEST)/Mandrake/base/mdkinst_stage2
 BASE        = $(ROOTDEST)/Mandrake/base
Index: perl-install/partition_table.pm
===================================================================
RCS file: /cooker/gi/perl-install/partition_table.pm,v
retrieving revision 1.98
diff -u -r1.98 partition_table.pm
--- perl-install/partition_table.pm	2001/05/16 16:02:06	1.98
+++ perl-install/partition_table.pm	2001/05/17 21:15:35
@@ -18,7 +18,7 @@
 if (arch() =~ /ppc/) {
     @important_types = ('Linux native', 'Linux swap', 'Apple HFS Partition', 'Apple Bootstrap');
 } else {
-	@important_types = ('Linux native', 'Linux swap', if_(arch() =~ /i.86/, 'ReiserFS', 'DOS FAT16', 'Win98 FAT32'));
+	@important_types = ('Linux native', 'Linux swap', if_(arch() =~ /i.86/, 'ReiserFS', 'xfs', 'DOS FAT16', 'Win98 FAT32'));
 }
 @important_types2 = ('Linux RAID', 'Linux Logical Volume Manager partition');
 
@@ -34,7 +34,7 @@
   0x402	=> 'Apple HFS Partition',
 ) : arch() =~ /^i.86/ ? (
   0x183 => 'ReiserFS',
-  0x283 => 'XFS',
+  0x283 => 'xfs',
 ) : arch() =~ /^sparc/ ? (
   0x1 => 'SunOS boot',
   0x2 => 'SunOS root',
@@ -187,7 +187,7 @@
   0x1e => 'vfat',
   0x82 => 'swap',
   0x83 => 'ext2',
-  0x183=> 'reiserfs',
+  0x183=> 'ReiserFS',
   0x283=> 'xfs',
   0x401 => 'apple',
   0x402 => 'hfs',
@@ -221,7 +221,7 @@
 sub isLVMBased { $_[0]{LVMname} }
 sub isSwap($) { $type2fs{$_[0]{type}} eq 'swap' }
 sub isExt2($) { $type2fs{$_[0]{type}} eq 'ext2' }
-sub isReiserfs($) { $type2fs{$_[0]{type}} eq 'reiserfs' }
+sub isReiserfs($) { $type2fs{$_[0]{type}} eq 'ReiserFS' }
 sub isXfs($) { $type2fs{$_[0]{type}} eq 'xfs' }
 sub isDos($) { arch() !~ /^sparc/ && $ {{ 1=>1, 4=>1, 6=>1 }}{$_[0]{type}} }
 sub isWin($) { $ {{ 0xb=>1, 0xc=>1, 0xe=>1, 0x1b=>1, 0x1c=>1, 0x1e=>1 }}{$_[0]{type}} }
Index: perl-install/share/list
===================================================================
RCS file: /cooker/gi/perl-install/share/list,v
retrieving revision 1.71
diff -u -r1.71 list
--- perl-install/share/list	2001/04/14 12:42:42	1.71
+++ perl-install/share/list	2001/05/17 21:15:35
@@ -14,6 +14,7 @@
 /sbin/fdisk
 /sbin/insmod
 /sbin/mkraid
+/sbin/mkfs.xfs
 /sbin/mkreiserfs
 /sbin/mke2fs
 /sbin/raidstart
Index: rescue/Makefile
===================================================================
RCS file: /cooker/gi/rescue/Makefile,v
retrieving revision 1.4
diff -u -r1.4 Makefile
--- rescue/Makefile	2001/02/22 21:10:58	1.4
+++ rescue/Makefile	2001/05/17 21:15:36
@@ -1,4 +1,4 @@
-ROOTDEST = /export
+ROOTDEST = /export/bounce/xfscook
 
 install: rescue_stage2.bz2
 	cp -f $< $(ROOTDEST)/Mandrake/base
Index: tools/Makefile
===================================================================
RCS file: /cooker/gi/tools/Makefile,v
retrieving revision 1.40
diff -u -r1.40 Makefile
--- tools/Makefile	2001/04/02 20:59:26	1.40
+++ tools/Makefile	2001/05/17 21:15:36
@@ -1,4 +1,4 @@
-ROOTDEST    = /export
+ROOTDEST    = /export/bounce/xfscook
 DEST        = $(ROOTDEST)/Mandrake/mdkinst
 RPMS        = $(wildcard $(ROOTDEST)/Mandrake/RPMS/*.rpm)
 DIRS	    = ddcprobe serial_probe

--------------C3286EDD9ADC67DB6D09B4CB--


From owner-linux-xfs@oss.sgi.com Thu May 17 14:32:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HLWYI26462
	for linux-xfs-outgoing; Thu, 17 May 2001 14:32:34 -0700
Received: from exchange.concordia.ab.ca (exchange.concordia.ab.ca [199.185.120.34])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HLWXF26459
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 14:32:33 -0700
Received: from strobe (strobe.concordia.ab.ca [199.185.121.61]) by exchange.concordia.ab.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id KVDRTPZR; Thu, 17 May 2001 15:36:44 -0600
Message-ID: <030b01c0df18$eea56600$3d79b9c7@admin.concordia.ab.ca>
From: "Ed Boraas" <ed@boraas.ca>
To: <linux-xfs@oss.sgi.com>
Subject: Debian packages now available in testing (Woody)
Date: Thu, 17 May 2001 15:32:54 -0600
Organization: http://www.ed.boraas.ca
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi, everyone.

Just a followup note to my earlier announcement about the XFS patches being
made available in Debian unstable (Sid): A day or two ago, those packages
were made available in the testing (Woody) distribution as well.

Those of you who are using Woody may now do an "apt-get install
kernel-patch-xfs" to get the patches automatically downloaded and ready for
kernel building.

As before, the packages are "kernel-patch-xfs-core" and "kernel-patch-xfs".
(The latter depends upon the former, and apt-get and dselect will recognize
this.)

Also worth noting is that Woody will become the next stable release of
Debian ("When it's ready", of course), so this means XFS is now officially
slated for inclusion in the next stable release of Debian, at least in patch
form. While I don't believe there are any plans for the Debian installer or
the default Debian kernels to support XFS, I think this is good news.


Take care,

Ed Boraas
Debian XFS kernel patch maintainer


From owner-linux-xfs@oss.sgi.com Thu May 17 14:40:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HLes426993
	for linux-xfs-outgoing; Thu, 17 May 2001 14:40:54 -0700
Received: from neptune.phys.ufl.edu (neptune-gw.phys.ufl.edu [128.227.64.7])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HLerF26990
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 14:40:53 -0700
Received: from neptune-gw.phys.ufl.edu (neptune-gw.phys.ufl.edu [128.227.64.7])
	by neptune.phys.ufl.edu (8.9.3/8.9.3) with ESMTP id RAA24258
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 17:40:48 -0400 (EDT)
Date: Thu, 17 May 2001 17:40:48 -0400 (EDT)
From: Brent A Nelson <brent@phys.ufl.edu>
To: linux-xfs@oss.sgi.com
Subject: dump/restore and setuid/setgid files
Message-ID: <Pine.GSO.4.21.0105171734300.22735-100000@neptune.phys.ufl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm using an xfsdump piped to an xfsrestore to copy files from my root
partition to a logical volume (as part of a convoluted script I'm using
after Kickstart, since RedHat doesn't include LVM support in their
installer).  One thing I noticed, though, is that the setuid and setgid
bits aren't preserved on the restored files.  Is there any way around
this?

Thanks,

Brent Nelson
Director of Computing
Dept. of Physics
University of Florida


From owner-linux-xfs@oss.sgi.com Thu May 17 14:46:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HLke927445
	for linux-xfs-outgoing; Thu, 17 May 2001 14:46:40 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HLkdF27442
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 14:46:40 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4HLkcY24194;
	Thu, 17 May 2001 16:46:38 -0500 (CDT)
Message-ID: <3B044744.EBAC2218@sgi.com>
Date: Thu, 17 May 2001 16:48:52 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent A Nelson <brent@phys.ufl.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: dump/restore and setuid/setgid files
References: <Pine.GSO.4.21.0105171734300.22735-100000@neptune.phys.ufl.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Brent A Nelson wrote:
> 
> I'm using an xfsdump piped to an xfsrestore to copy files from my root
> partition to a logical volume (as part of a convoluted script I'm using
> after Kickstart, since RedHat doesn't include LVM support in their
> installer).  One thing I noticed, though, is that the setuid and setgid
> bits aren't preserved on the restored files.  Is there any way around
> this?

This is fixed in the devel tree, you can look at cvsweb on
oss.sgi.com/projects/xfs to extract the patches you need, or just grab
the whole devel tree...

-Eric

from checkin announcement:

> This fixes the problem with xfsrestore not restoring the suid or guid
> modes on a file.
> It occurred because a chown was done after the chmod when restoring
> the files and the chown was clearing these mode bits even running as root.
> On IRIX, as root, this is not the case.
> The Linux man page indicates that this behavior for root is dependent
> on the kernel version. 
> Anyway, I have changed the ordering so that the chown is done before
> the chmod and test 056 now passes.

> Date:  Mon May 14 21:05:35 PDT 2001
> Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
> 
> 
> Modid:  2.4.x-xfs:slinx:94886a

<snip>

> cmd/xfsdump/restore/tree.c - 1.4
>         - Make chown come before chmod so that suid and guid bits are not cleared
>           when restoring directories.
> 
> cmd/xfsdump/common/arch_xlate.c - 1.4
>         - Add some diags for ino and mode on bstat translation.
> 
> cmd/xfsdump/restore/content.c - 1.7
>         - Make chown come before chmod so that suid and guid bits are not cleared
>           when restoring regular files.


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 17 15:08:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HM81728285
	for linux-xfs-outgoing; Thu, 17 May 2001 15:08:01 -0700
Received: from smtp-server2.tampabay.rr.com (smtp-server2.tampabay.rr.com [65.32.1.39])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HM7xF28282
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 15:08:00 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server2.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f4HM7kv05507;
	Thu, 17 May 2001 18:07:46 -0400 (EDT)
Message-ID: <3B044CEE.16BEE674@cfl.rr.com>
Date: Thu, 17 May 2001 18:13:02 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: kris buggenhout <buggenkr@god.bel.alcatel.be>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: trouble benchmarking
References: <4.3.2.7.2.20010517130519.038d0c88@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:
> 
> At 11:46 17-5-2001 +0200, kris buggenhout wrote:
> >it looks like a scsi error .. but when I do the same test on the same
> >drive with ext2 i get no error.
> 
> ext2 probably handles bad blocks better. The XFS filesystem shuts down on
> error. Ext2 may stay up and note that the sector is moved and the data is ok.
> It might be possible that xfs could be made to respect this re allocation
> of a bad sector and perhaps not shut down.

The scsi drives "page-1 mode-select" error recovery page should be set
to not
report recovered errors. This can be changed with any decent scsi disc
utility
and does not require and reformat or lost data after the change. No
body's driver/
filesystem should have to worry about that. You shouldn't see the
message again
unless youv'e got more bad spots and don't change page-1 to not post
recovered
errors.

Regards

-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Thu May 17 16:15:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HNFsO29755
	for linux-xfs-outgoing; Thu, 17 May 2001 16:15:54 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HNFrF29752
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 16:15:53 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4HNFp528113
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 16:15:52 -0700
Date: Thu, 17 May 2001 16:15:51 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: linux-xfs@oss.sgi.com
Subject: nfsd_ops patch
Message-ID: <Pine.LNX.4.21.0105171612250.28031-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't remember seeing any posts about this, but it seems i am in need of
it.  Where can i go to get it?  I'm getting *a lot* of undefineds with the
latest CVS...even with a make mrproper and a .config from scratch.

Thanks,

Dana


From owner-linux-xfs@oss.sgi.com Thu May 17 16:31:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HNVK830484
	for linux-xfs-outgoing; Thu, 17 May 2001 16:31:20 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HNVJF30479
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 16:31:19 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4HNVAl22715;
	Thu, 17 May 2001 18:31:10 -0500 (CDT)
Message-ID: <3B045FC3.33F3E5D7@sgi.com>
Date: Thu, 17 May 2001 18:33:23 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dana Soward <dragon@thegoop.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: nfsd_ops patch
References: <Pine.LNX.4.21.0105171612250.28031-100000@daffy.thegoop.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dana Soward wrote:
> 
> I don't remember seeing any posts about this, but it seems i am in need of
> it.  Where can i go to get it?  I'm getting *a lot* of undefineds with the
> latest CVS...even with a make mrproper and a .config from scratch.
> 
> Thanks,
> 
> Dana

Courtesy of Jan:

but CVS code shouldn't need this...

--- linux/fs/xfs/linux/xfs_iops.c.orig  Wed May  2 01:10:46 2001
+++ linux/fs/xfs/linux/xfs_iops.c       Fri May  4 01:33:05 2001
@@ -174,8 +174,55 @@
                linvfs_set_inode_ops(ip);
                error = linvfs_revalidate_core(ip, ATTR_COMM);
        }
+
+       if (ip)
+               return d_splice_alias(ip, dentry);
+
        d_add(dentry, ip);      /* Negative entry goes in if ip is NULL
*/
        return NULL;
+}
+
+
+struct dentry * linvfs_get_parent(struct dentry *child)
+{
+       int             error;
+       vnode_t         *vp, *cvp;
+       pathname_t      pn;
+       pathname_t      *pnp = &pn;
+       struct inode    *ip = NULL;
+       struct dentry   *parent;
+
+       vp = LINVFS_GET_VP(child->d_inode);
+       ASSERT(vp);
+
+       /*
+        * Initialize a pathname_t to pass down.
+        */
+       bzero(pnp, sizeof(pathname_t));
+       pnp->pn_complen = 2;
+       pnp->pn_path = "..";
+
+       cvp = NULL;
+
+       VOP_LOOKUP(vp, "..", &cvp, pnp, 0, NULL, NULL, error);
+       if (!error) {
+               ASSERT(cvp);
+               ip = LINVFS_GET_IP(cvp);
+               if (!ip) {
+                       VN_RELE(cvp);
+                       return ERR_PTR(-EACCES);
+               }
+               linvfs_set_inode_ops(ip);
+               error = linvfs_revalidate_core(ip, ATTR_COMM);
+       }
+
+       parent = d_make_alias(ip);
+       if (!parent) {
+               VN_RELE(cvp);
+               parent = ERR_PTR(-ENOMEM);
+       }
+
+       return parent;
 }
 
 
--- linux/fs/xfs/linux/xfs_super.c.orig Wed May  2 01:10:46 2001
+++ linux/fs/xfs/linux/xfs_super.c      Fri May  4 01:35:49 2001
@@ -38,6 +38,7 @@
 #include <linux/blkdev.h>
 #include <linux/init.h>
 #include <linux/page_buf.h>
+#include <linux/nfsd/interface.h>
 
 /* xfs_vfs[ops].c */
 extern void vfsinit(void);
@@ -49,6 +50,12 @@
 
 static struct super_operations linvfs_sops;
 
+extern struct dentry *linvfs_get_parent(struct dentry *child);
+
+static struct nfsd_operations xfs_nfsd_operations = {
+       get_parent:     linvfs_get_parent,
+};
+
 
 #define        MS_DATA         0x04
 
@@ -414,6 +421,7 @@
        set_blocksize(sb->s_dev, 512);
 
        sb->s_op = &linvfs_sops;
+       sb->s_nfsd_op = &xfs_nfsd_operations;
        sb->dq_op = NULL;
 
        LINVFS_SET_VFS(sb, vfsp);


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 17 16:36:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4HNaBm30871
	for linux-xfs-outgoing; Thu, 17 May 2001 16:36:11 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4HNaAF30868
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 16:36:10 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA07181
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 16:34:46 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA97213; Thu, 17 May 2001 18:34:53 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4HNXrw04888;
	Thu, 17 May 2001 19:33:53 -0400
Message-ID: <3B045FDF.583DD37F@thebarn.com>
Date: Thu, 17 May 2001 19:33:51 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mdkinstall <install@mandrakesoft.com>,
   Chmouel Boudjnah <chmouel@mandrakesoft.com>, Pixel <pixel@mandrakesoft.com>,
   "Venables, Michael" <Michael.Venables@compaq.com>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Mandrake installer
References: <3B04401F.3166BEC1@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:

> I've managed to create a Mandrake 8.0 + xfs install CD
>
> I'm waiting for the kernel to rebuild with the nfsd_ops patch included.
>
> Once this is done I will change out the kernel rpm's and toss the iso
> image
> on my ftp server
> ftp.thebarn.com
>

Ok  it's up
ftp://ftp.thebarn.com/SGI/Mandrake-XFS1.0/1-Cooker-XFS-i586.iso

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Thu May 17 17:30:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I0Uac31944
	for linux-xfs-outgoing; Thu, 17 May 2001 17:30:36 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I0UXF31941
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 17:30:34 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA09259
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 17:30:32 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA91824;
	Fri, 18 May 2001 10:29:14 +1000 (EST)
Date: Fri, 18 May 2001 10:29:14 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105180029.KAA91824@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Cc: marchuk@ee.washington.edu
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

First pass at a fix for the quotacheck memory consumption problem.
Be interested to see how this goes for you, Walter -- thanks.

cheers.


Date:  Thu May 17 17:20:50 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95232a
linux/fs/xfs/xfs_qm.c - 1.68
	- reintroduce xfs_qm_shake to free up dquots under low memory
	  conditions, particularly during quotacheck.  init zones for
	  dquot/dqtrx's with names consistent with the rest of XFS.

linux/fs/xfs/linux/xfs_linux.h - 1.50
	- add swap.h for free_shortage() prototype.



From owner-linux-xfs@oss.sgi.com Thu May 17 17:41:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I0f2U32378
	for linux-xfs-outgoing; Thu, 17 May 2001 17:41:02 -0700
Received: from kernelpanix.aura.of.mankind (pD901E20F.dip.t-dialin.net [217.1.226.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I0ewF32370
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 17:40:58 -0700
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4I00rB23567
	for linux-xfs@oss.sgi.com; Fri, 18 May 2001 02:00:53 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Fri, 18 May 2001 02:00:53 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: linux-xfs@oss.sgi.com
Subject: Recovery failed after crash
Message-ID: <20010518020053.A23229@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--sdtB3X0nJg68CQEu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi

After a crash with the new nvidia driver, my system at home does boot
anymore. It's a CVS kernel from 2001-05-16. Older kernels dont boot too.
It was only a X server crash, I synced a few times and boot with sysrq.

The recovery of the root fs failed:


Start mounting filesystem: ide0(3,6)
XFS: WARNING: recovery required on readonly filesystem.
XFS: write access will be enabled during mount.
Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
XFS: xlog_recover_process_data: bad clientid
XFS: log mount/recovery failed
XFS: log mount failed
Kernel panic: VFS: Unable to mount root fs on 03:06

Entering kdb (current=0xc144a000, pid 1) due to panic
kdb> bt
Stack is not in kernel space, backtrace not available
kdb> ps
Task Addr  Pid      Parent   [*] cpu  State Thread     Command
0xc144a000 00000001 00000000  0  000  run   0xc144a260*swapper
0xc1452000 00000002 00000001  0  000  stop  0xc1452260 keventd
0xc1450000 00000003 00000001  0  000  stop  0xc1450260 kswapd
0xc147e000 00000004 00000001  0  000  stop  0xc147e260 kreclaimd
0xc147c000 00000005 00000001  0  000  stop  0xc147c260 bdflush
0xc147a000 00000006 00000001  0  000  stop  0xc147a260 kupdated
0xc14cc000 00000007 00000001  0  000  stop  0xc14cc260 pagebuf_daemon
kdb> bta
Stack traceback for pid 1
    EBP       EIP         Function(args)
0xc1449b60 0xc01105f2 schedule+0x2d2 (0x0, 0xc0333f80, 0xc144b9dc, 0xc144b9df, 0xc144b9dc)
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
           0xc01e410b scrup+0x6b (0xc0333f80, 0xc144b9de, 0xffffffff, 0x4, 0xc144b9ac)
                               kernel .text 0xc0100000 0xc01e40a0 0xc01e41a8
           0xc01d5cc6 kdb_printf+0xd2 (0xc02e88e0, 0xc0100000, 0xc02609bb, 0xc02f8d38, 0xc01d5bf4)
                               kernel .text 0xc0100000 0xc01d5bf4 0xc01d5e30
           0xc01d5cc6 kdb_printf+0xd2 (0xc0281fe0, 0xc14cc000, 0x7, 0x1, 0x0)
                               kernel .text 0xc0100000 0xc01d5bf4 0xc01d5e30
           0xc01d58b7 kdb_ps+0x9f (0x0, 0xc144bd34, 0xc0332964, 0xc144bdac)
                               kernel .text 0xc0100000 0xc01d5818 0xc01d58cc
           0xc01d3d75 kdb_parse+0x1a9 (0xc144bde8)
                               kernel .text 0xc0100000 0xc01d3bcc 0xc01d3e38
           0xc01d41ef kdb_local+0x343 (0xc01d4309, 0xd, 0x0, 0xc144bdac, 0x4)
                               kernel .text 0xc0100000 0xc01d3eac 0xc01d4240
           0xc0116488 tasklet_hi_action+0x3c (0xc03329f0, 0x0, 0x0)
                               kernel .text 0xc0100000 0xc011644c 0xc01164ac
           0xc011b4ee notifier_call_chain+0x1e (0xc03935b0, 0x0, 0x0)
                               kernel .text 0xc0100000 0xc011b4d0 0xc011b508
           0xc01125c8 panic+0x78 (0xc026d080, 0xc037ef60, 0x306, 0x10f00)
                               kernel .text 0xc0100000 0xc0112550 0xc0112630
more> 
           0xc034b466 mount_root+0x196
                               kernel .text.init 0xc0344000 0xc034b2d0 0xc034b640
           0xc0344981 do_basic_setup+0x35
                               kernel .text.init 0xc0344000 0xc034494c 0xc0344990
           0xc0105007 init+0x7
                               kernel .text 0xc0100000 0xc0105000 0xc0105150
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 2
    EBP       EIP         Function(args)
0xc1453fa8 0xc01105f2 schedule+0x2d2
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
           0xc011d676 context_thread+0x10a
                               kernel .text 0xc0100000 0xc011d56c 0xc011d71c
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 3
    EBP       EIP         Function(args)
0xc1451f90 0xc01105f2 schedule+0x2d2 (0xc1451fa4)
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
0xc1451fb8 0xc01102ef schedule_timeout+0x73 (0x10f00, 0xc026b231)
                               kernel .text 0xc0100000 0xc011027c 0xc0110310
0xc1451fdc 0xc011094a interruptible_sleep_on_timeout+0x46
                               kernel .text 0xc0100000 0xc0110904 0xc0110968
           0xc0128ef5 kswapd+0xed
                               kernel .text 0xc0100000 0xc0128e08 0xc0128f18
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 4
    EBP       EIP         Function(args)
0xc147ffb0 0xc01105f2 schedule+0x2d2 (0x10f00, 0x0, 0xc147e000, 0xc032d9dc, 0xc032d9dc)
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
0xc147ffcc 0xc01108ec interruptible_sleep_on+0x40
                               kernel .text 0xc0100000 0xc01108ac 0xc0110904
           0xc0128fbb kreclaimd+0x5b
                               kernel .text 0xc0100000 0xc0128f60 0xc0129040
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 5
    EBP       EIP         Function(args)
0xc147dfd8 0xc01105f2 schedule+0x2d2
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
           0xc0132cce bdflush+0xd6
                               kernel .text 0xc0100000 0xc0132bf8 0xc0132cd8
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 6
    EBP       EIP         Function(args)
0xc147bfb0 0xc01105f2 schedule+0x2d2 (0xc147bfc4)
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
0xc147bfd8 0xc01102ef schedule_timeout+0x73
                               kernel .text 0xc0100000 0xc011027c 0xc0110310
           0xc0132d64 kupdate+0x8c
                               kernel .text 0xc0100000 0xc0132cd8 0xc0132dc0
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
Stack traceback for pid 7
    EBP       EIP         Function(args)
0xc14cdf90 0xc01105f2 schedule+0x2d2 (0xc14cc000, 0x0, 0xc14cc000, 0xc0331eb4, 0xc0331eb4)
                               kernel .text 0xc0100000 0xc0110320 0xc0110750
0xc14cdfac 0xc01108ec interruptible_sleep_on+0x40 (0xc14cdfdc, 0xc14cdfdc)
                               kernel .text 0xc0100000 0xc01108ac 0xc0110904
           0xc0165a18 pagebuf_daemon+0xd0
                               kernel .text 0xc0100000 0xc0165948 0xc0165b70
           0xc010544f kernel_thread+0x23
                               kernel .text 0xc0100000 0xc010542c 0xc010545c
Enter <q> to end, <cr> to continue:
kdb> 
kdb> reboot





I booted the computer on an ext2 root partition and run xfs_logprint:

bash-2.04# xfs_logprint /dev/hda6
xfs_logprint:
xfs_logprint: warning - cannot set blocksize on block device /dev/hda6: Input/output error
    data device: 0x306
    log device: 0x306 daddr: 2409760 length: 9600

Header 0x186 wanted 0xfeedbabe
**********************************************************************
* ERROR: header cycle=390         block=9421                         *
**********************************************************************
Bad log record header




Then I run xfs_check. The Output is attached.

Mountig the partition failed (of course):

bash-2.04# mount -t xfs /dev/hda6 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/hda6,
       or too many mounted file systems



I saved the first 40MB of the partiton to a file.

What should i do? Running xfs_repair or keep it for diagnosis.
Note: there are no important data on it.



utz

--sdtB3X0nJg68CQEu
Content-Type: application/x-bzip2
Content-Disposition: attachment; filename="minicom-20010517-2.cap.bz2"
Content-Transfer-Encoding: base64

QlpoOTFBWSZTWc1PD0gAIhl/gEoQAgBId//ykmCQAL/v3/BgED7AAF98Aj4whKvZ2enPKZDM
mMl2GezLe5xMke8AAKMAAAAANBoA0A0BEbQbVSKmkD9FAAAAAAEp5SSaEpAAwmgaAA0BoCU/
VJSMmpAAA0GgAaAAEUiIfqTU000yBhABoAAAUpTU0CU8E9BKaAAGRtIxPFLQyZvbRk1duWl9
vwqxKrpjg4eLc48PJpmZmZmZmZmZAAAAAAAAmd3d3M0AAAAAAABJIAAAG2222AAAAAADbbbb
AAAbbb3Rtt96wBttttgAAAAAAAkkAAAAAAAAAAAAAAAAAAC14+3hl68t2zu7t3VU773E3dvG
2223o222wBIG3mNm7d2G7pu5mYGGZmXtU9mAqldvHjzNx7uj0bbbmZY3u7phl2ZmbmZbx7u7
mZl3r1ytQO5tzWjdw+5iNu7mbx3cqNJuEm+7B3Li8QxMqdyqq9ZLyWyWK2bZgwAAAAAAAAAA
AACZ3d3czQAAAAAAAEkgAAAbbbbYAAAAAANtttsAABttvdG233rAG2222AAAAAAACSQAAAAA
AAAAAAAAAAEzMzMzZiy4KxfX4wX7UQiMl1lYdeOm4bNABe4rTJ5eO2dOnf97wvH/ns44DQPk
thB283at97EQYEBEZQBFBBGBAQAAEAAQAAAAGBAAEBgAAGBAEEkBWGBBhFEEAQQQEBAAEAAE
AEEAYEEBBEAYAAFAEGGeGUjbBmINbazWmwayMxlkOYNtt96RNqtYWwsmChvmtTFGNZa4ZHvs
+Lq5v4OkThTr3afd38onf5/DsfN9+tpHaRqRRqFRRqRRRqR5SO1tbVX4K+atrlIooo1I7Qu0
ijUijtI7VSKU+N4MJzdRERERE3dRERETd1ERERERERETd3m6ic3UREREhETd3d1ERERESN3U
o1Iooo/ipFHqnnUbykUUeV3XVcqrlVbX2qFRRq8UijtIptzxze6R6pEUXunx4t80iiKij466
4cR5SKPKRRqRRRqRRN3URERE3dRERERN3URETd1E3dRETaqRR2kURUUUdpFGpGpERN3d3URE
RESObu7Ioooioo1bSNXP6nAAcz2BEfXyORyIjn1Znv179/T37+oAAAAAAA9/c+fPkzLMpwAA
AAAAAAAAZblZWRZYVllWdINf9842EH8fptIHssQGZMjv3ec5EfTyF8OJXr5fL4+Pj4+z8fHw
AAAAAAAbu7u7oAAAAAZmZmYAAff985yIv58+vQXOpDtQ6djsGbuLOm/vU36U60LzWxgcuAUO
CyOf7jnahzznOe8+fzuGe6qqr7f07SlAA7CqRPQDUksnGXLym3sWOqqqDtKUAD8W7rpVXN51
8OvXrZ4ePO4SCsqoADpZVV2zMsreGMCYFu6AH92cM3V6palczDA8uZ8OvIpla3TMPRgACYa8
vhrdV2tHUwNcczBnLGaxObm7u7u0YYYYYYYeRWpVi2KiqNValWoRqEalWpVqVahG5uqu0q3k
Ovfrwh75VVVeedpSgAcUlCBJJ9JG2iMgustZFhVVVM7SlAA/I55MxyORzne85ERGefPmrz58
99+buqyqPIjdGAAbqrtKtBKqqvWZhgczN0R5pmZuiu6ZmblGZllGZjvVlVXOuWb0Blk4uLi4
uLi4uO9VVO5hnQDnNVSwPEyy5wLbMzdDo5WbZVLKc4FyrO9lUs5wOhyzM5wOOZZf6yunHe9F
y+8jkb2OPy68jWkl56hTJAAVUsuQmZIZjhpI3Ju7g1JIcKZIADyPO85HG1llnbt23d7du3fr
6M8uB4eUgAAAAAAHeyzdDbLdDbLnFW5xVsyhGwIDOcVbwmZm6qxnsMDN3qqoOnDDrnNqq6DD
MN3aqvZgbu/GtutVVUgd4BmB8Ac3lMzM1HI5u4/Ua1MvOnfIKGbUhczVhBQ7o2qV3k3UApnc
6+kFDNzfOc5LczLfmeT5mm+Q3dqq9GAFKqKqiq6GBlKvjs3VXuhFRFRH+HyfHx354d+t3d9m
9Sn1BYF3M9CZkLjABTGbbV72s2Da1rXFiwxWtJJtmZsExwIxCqxCtsKNIXFUxcDMUDFzFzO+
7m7u99+/OPvysV7Dhm8eFLVLFe8DP1mYdoB3kBjmZ48eClvXDMznOFLcOGZnOcKW4cMDnOLF
cN3VitNlWKEY8c9e+Xn38PrviS88fUp2CwIqkr6FJIyZNobmjIqcvKzoUkgfUp2CwNr13vfO
8kCkkg2Mjsd4OlSOnIjffMzN2qW+Kq6hHDfMXo0MDdVfXCMANfJS6buzTaeuGi6OJ6vSqaMI
x1gBju9+udd+Onx65qTH26paYDmZBJIwuqCrnCqKvtq86FJIH26paYD/TFdl+oAmZDfSEu97
3zl9gOkznBGzClWPAGYBuiOlKumAaa1mZmzhKprWZmadBQ1QHJOXms3LGKyYrJjLGc0OXS5w
71Q42deRjSS9et7dUvRgN9qtReSoLbndyQWXr2ay8gxJLTe3VIMB8731yPOtuZu+++x7MwGE
fJ3uqulKseDA3vlVXDd0pbxw3DOPKqtAgw0dWK27eGYjgIAvJpkwjHFiKYhO9msur8qqqvPN
uqrwwHd1VNKd73M3NpCCZW3uZZVVVabdVQYDVrvnjTmZx6972OwQGtkd6myPKbI42R15lVm8
A5zLMzLnAbZS1EYROzEQ6bebtVVV55SSAB0kgqqXegZlaM11KlvNKqqoKSQAPyN3Zmd3d87H
Y7EPLdQYd7ttwYbWZngrK78ugw6LZR6vjVm3ER2qWojxWokoidd8y4iNvZ96+X3fXvT4eh47
5sr4r49Lx9MePR6kBd1DVANsKiA0vbgA50PY/fuDMBztA55G4O5rnJReLL92VGz0+X2UBxxw
P9g/Q84/PSTzyIPltxJZUZhL7Ad2wNhQvNcPx4fpvzUUMv7LieHp2fMGpFDpnrG0kL6vpuJx
beHzx5b1HYk56UheWuXdce98Wk2qPT79qqS9skhbZk93rmTPKOd3cQeixw/A6+HN4JUcVUl4
nT0jucRB1yMUZEyZUYIPDOWoQwH2x7g6g96KPjv4Gd4O6OUajyyIOmevwv11GfOOEgeTW/Vp
Kj61G8IdWlUltUeT+dR9XGDdkemzblhZ17USbiDmqktl0uXX11s9lVF9ffYHOJsDpkZlM7NV
H7xH21Hj9Dx73Fs7WVVF+zbbx71IX7TQOz3+Dk8uW4PZQNl8XVwuD1j4cHhQ3B0ebvqOEY96
VIbRNCoURoAHJnzXYSFUZVG2wKOqcLaoz7jPHGOFR17vUR08X/xdyRThQkM1PD0g

--sdtB3X0nJg68CQEu--

From owner-linux-xfs@oss.sgi.com Thu May 17 19:27:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I2RMs03116
	for linux-xfs-outgoing; Thu, 17 May 2001 19:27:22 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I2RKF03113
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 19:27:21 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id EAA124087
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 04:27:17 +0200 (CEST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10608 for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 12:26:00 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: Re: Recovery failed after crash 
In-reply-to: Your message of "Fri, 18 May 2001 02:00:53 +0200."
             <20010518020053.A23229@s2y4n2c.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 May 2001 12:26:00 +1000
Message-ID: <24635.990152760@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 18 May 2001 02:00:53 +0200, 
utz lehmann <xfs@s2y4n2c.de> wrote:
>After a crash with the new nvidia driver, my system at home does boot
>anymore. It's a CVS kernel from 2001-05-16. Older kernels dont boot too.
>Starting XFS recovery on filesystem: ide0(3,6) (dev: 3/6)
>XFS: xlog_recover_process_data: bad clientid
>XFS: log mount/recovery failed
>XFS: log mount failed
>Kernel panic: VFS: Unable to mount root fs on 03:06
>
>Entering kdb (current=0xc144a000, pid 1) due to panic
>[lots of kdb data deleted]

FYI, there is not much point in doing kdb diagostics after message
"VFS: Unable to mount root fs".  The panic is a side effect of the
failing mount of root and by the time the kernel panics, the real
problem has gone.  For most kernel panics, kdb data is useful, but not
for this particular error message.


From owner-linux-xfs@oss.sgi.com Thu May 17 23:30:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I6UFW07202
	for linux-xfs-outgoing; Thu, 17 May 2001 23:30:15 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.4])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I6UDF07199
	for <linux-xfs@oss.sgi.com>; Thu, 17 May 2001 23:30:14 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA29201;
	Fri, 18 May 2001 08:30:09 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id IAA10008;
	Fri, 18 May 2001 08:30:07 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 278EB57306; Fri, 18 May 2001 08:39:15 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 3EE9425835; Fri, 18 May 2001 08:40:18 +0200 (CEST)
Message-ID: <3B04C26A.4E0436D3@ch.sauter-bc.com>
Date: Fri, 18 May 2001 08:34:18 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Dave Sill <ds-linux-xfs@sws5.ctd.ornl.gov>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: Two problems with a new installation
References: <wx0eltng2t1.fsf@sws5.ctd.ornl.gov>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

I can not speak about XFS on DELL with AMI MegaRAID but I'm using
RedHat 6.2 on some machines and they are terrible slow. I also
downloaded
the custom kernel from the DELL support page but nothing changed.
I remember that when I installed the first machine I wanted to call
DELL support so they replace the machine. But later I found out that
every machine was the same.
The only thing I can say is: Don't use any hardware RAID if you want
to get most perfomance out of your disks. Some years ago hardware did
improve performance but with the CPU power we have today, software RAID
is the fastet.
That's my experience, anyone to comment on this?

Simon

Dave Sill schrieb:
> 
> I installed XFS 1.0 + Red Hat 7.1 via the SGI installer on a 2-proc
> Dell server with 2 x 250GB AMI MegaRAID's. The installation went
> smoothly, but I've been getting occasional messages like:
> 
> May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
> May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
> May 17 03:42:52 daacsnfs kernel: __alloc_pages: 0-order allocation failed.
> 
> What do these messages mean?
> 
> I'm migrating one of the RAID's to xfs and it's going rather slowly
> (6 hrs to untar 18 GB so far). Watching the disk space used on the xfs
> raid, I see lots of periods with no obvious activity. E.g., at
> 5-second intervals:
> 
>                      248533712  13932188 234601524   6% /smm1
>                      248533712  13934712 234599000   6% /smm1
>                      248533712  13936248 234597464   6% /smm1
>                      248533712  13936248 234597464   6% /smm1
>                      248533712  13936248 234597464   6% /smm1
>                      248533712  13936780 234596932   6% /smm1
>                      248533712  13951096 234582616   6% /smm1
>                      248533712  13951096 234582616   6% /smm1
>                      248533712  13962360 234571352   6% /smm1
>                      248533712  13974288 234559424   6% /smm1
>                      248533712  13974328 234559384   6% /smm1
>                      248533712  13974328 234559384   6% /smm1
>                      248533712  13974328 234559384   6% /smm1
>                      248533712  13974328 234559384   6% /smm1
>                      248533712  13974328 234559384   6% /smm1
>                      248533712  13993080 234540632   6% /smm1
> 
> The __alloc_pages errors are much less frequent than the I/O pauses,
> so they could be two separate problems.
> 
> hinv says:
> 
> Main memory size: 896 Mbytes
> 2 GenuineIntel Pentium III (Katmai) processors
> 1 vga+ graphics device
> 1 keyboard
> PCI bus devices:
>     ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 2).
>     IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 1).
>     USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 1).
>     Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 2).
>     VGA compatible controller: ATI Technologies Inc 3D Rage Pro (rev 92).
>     PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (rev 3).
>     PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (#2) (rev 3).
>     PCI bridge: Intel Corporation 80960RP [i960 RP Microprocessor/Bridge] (#3) (rev 3).
>     I2O: Intel Corporation 80960RP [i960RP Microprocessor] (rev 3).
>     I2O: Intel Corporation 80960RP [i960RP Microprocessor] (#2) (rev 3).
>     I2O: Intel Corporation 80960RP [i960RP Microprocessor] (#3) (rev 3).
>     Host bridge: Intel Corporation 450NX - 82451NX Memory & I/O Controller (rev 3).
>     SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (rev 0).
>     SCSI storage controller: Adaptec AHA-2940U2/W / 7890 (#2) (rev 0).
>     SCSI storage controller: Adaptec AIC-7860 (rev 3).
>     Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 8).
>     Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (#2) (rev 8).
>     Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (rev 4).
>     Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (#2) (rev 4).
>     Host bridge: Intel Corporation 450NX - 82454NX/84460GX PCI Expander Bridge (#3) (rev 4).
> 
> --
> Dave Sill <MaxFreedom@sws5.ctd.ornl.gov>       <http://web.infoave.net/~dsill>
> Oak Ridge National Lab, Workstation Support
> <http://www.lifewithqmail.org>: almost everything you always wanted to know.

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Fri May 18 00:42:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I7gph08932
	for linux-xfs-outgoing; Fri, 18 May 2001 00:42:51 -0700
Received: from bastjon.mgm-net.de (bastjon.mgm-net.de [195.254.50.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I7gnF08928
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 00:42:50 -0700
Received: from cepheus.mgm-net.de (IDENT:root@cepheus.mgm-net.de [192.168.1.2])
	by bastjon.mgm-net.de (8.9.3/8.9.3) with ESMTP id JAA25496;
	Fri, 18 May 2001 09:42:45 +0200 (CEST)
Received: from gilmour.mgm-net.de (IDENT:root@gilmour.mgm-net.de [192.168.1.37])
	by cepheus.mgm-net.de (8.9.3/8.9.3) with ESMTP id JAA21191;
	Fri, 18 May 2001 09:42:45 +0200
Received: (from js@localhost)
	by gilmour.mgm-net.de (8.11.0/8.11.0) id f4I7gj422752;
	Fri, 18 May 2001 09:42:45 +0200
From: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15108.53876.723238.542757@gilmour.mgm-net.de>
Date: Fri, 18 May 2001 09:42:44 +0200 (CEST)
To: Austin Gonyou <austin@coremetrics.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <Pine.LNX.4.33.0105171344060.28169-100000@UberGeek.coremetrics.com>
References: <Pine.LNX.4.33.0105161056580.19365-100000@UberGeek.coremetrics.com>
	<Pine.LNX.4.33.0105171344060.28169-100000@UberGeek.coremetrics.com>
X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou writes:
> Has ANYONE looked into this? It seems pretty serious. Anyone?

> > I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
> > Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
> > from SGI to install the box. Using LVM 0.9.1-b7 tools.

What kernel is this? The "official" LVM 1.0 uses LVM 0.9.1-beta6! I
have a home-grown RedHat 7.0 with kernel 2.4.3-XFS plus LVM
0.9.1-beta7 (including kernel patch) and on this system it goes like
this:

[root@gilmour /root]# mkfs -t xfs -f /dev/vg01/test
mkfs.xfs: warning - cannot set blocksize on block device /dev/vg01/test: Invalid argument
meta-data=/dev/vg01/test         isize=256    agcount=8, agsize=16000 blks
data     =                       bsize=4096   blocks=128000, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
[root@gilmour /root]# mount /dev/vg01/test /mnt/tmp
[root@gilmour /root]# mount
/dev/sda1 on / type ext2 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/vg01/tmp on /tmp type xfs (rw)
/dev/vg01/var-xfs on /var type xfs (rw)
/dev/vg01/usr-xfs on /usr type xfs (rw)
/dev/vg01/ftp-rfs on /var/ftp type reiserfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
automount(pid8197) on /remote type autofs (rw,fd=5,pgrp=8197,minproto=2,maxproto=3)
automount(pid8255) on /- type autofs (rw,fd=5,pgrp=8255,minproto=2,maxproto=3)
automount(pid8226) on /home type autofs (rw,fd=5,pgrp=8226,minproto=2,maxproto=3)
automount(pid8185) on /misc type autofs (rw,fd=5,pgrp=8185,minproto=2,maxproto=3)
cepheus:/export/home/js on /home/js type nfs (rw,addr=192.168.1.2)
cepheus:/export/mail on /remote/mail type nfs (rw,addr=192.168.1.2)
/dev/vg01/test on /mnt/tmp type xfs (rw)
[root@gilmour /root]# lvextend -L 600 /dev/vg01/test
lvextend -- extending logical volume "/dev/vg01/test" to 600 MB
lvextend -- doing automatic backup of volume group "vg01"
lvextend -- logical volume "/dev/vg01/test" successfully extended

[root@gilmour /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda1              2016016   1642956    270648  86% /
/dev/vg01/tmp           507200       280    506920   1% /tmp
/dev/vg01/var-xfs       507200     76744    430456  16% /var
/dev/vg01/usr-xfs      3067200   2652836    414364  87% /usr
/dev/vg01/ftp-rfs      2047932   1592760    455172  78% /var/ftp
cepheus:/export/home/js
                       8603615   7924063    233349  98% /home/js
cepheus:/export/mail   8603615   7924063    233349  98% /remote/mail
/dev/vg01/test          507200       144    507056   1% /mnt/tmp
[root@gilmour /root]# xfs_growfs /mnt/tmp       
meta-data=/mnt/tmp               isize=256    agcount=8, agsize=16000 blks
data     =                       bsize=4096   blocks=128000, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 128000 to 153600
[root@gilmour /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
[...]
/dev/vg01/test          609600       176    609424   1% /mnt/tmp
[root@gilmour /root]# lvextend -L 700 /dev/vg01/test
lvextend -- extending logical volume "/dev/vg01/test" to 700 MB
lvextend -- doing automatic backup of volume group "vg01"
lvextend -- logical volume "/dev/vg01/test" successfully extended

[root@gilmour /root]# xfs_growfs /mnt/tmp
meta-data=/mnt/tmp               isize=256    agcount=10, agsize=16000 blks
data     =                       bsize=4096   blocks=153600, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 153600 to 179200
[root@gilmour /root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
[...]
/dev/vg01/test          712000       208    711792   1% /mnt/tmp
[root@gilmour /root]# lvextend -L +2M /dev/vg01/test
lvextend -- rounding size to physical extent boundary
lvextend -- extending logical volume "/dev/vg01/test" to 704 MB
lvextend -- doing automatic backup of volume group "vg01"
lvextend -- logical volume "/dev/vg01/test" successfully extended

[root@gilmour /root]# xfs_growfs /mnt/tmp
meta-data=/mnt/tmp               isize=256    agcount=12, agsize=16000 blks
data     =                       bsize=4096   blocks=179200, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=0
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=1200
realtime =none                   extsz=65536  blocks=0, rtextents=0
data blocks changed from 179200 to 180224
[root@gilmour /root]# df
[...]
/dev/vg01/test          716096       208    715888   1% /mnt/tmp


Bye,
Jochen

-- 
----------------------------------------------------------------
Nextra Baden-Wuerttemberg           | Jochen Scharrlach
Communication Service Provider GmbH | Technik
Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
----------------------------------------------------------------

  "An innovation a day keeps the monopolist away" -- Alan Cox

From owner-linux-xfs@oss.sgi.com Fri May 18 00:47:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I7ltu09336
	for linux-xfs-outgoing; Fri, 18 May 2001 00:47:55 -0700
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I7lsF09333
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 00:47:54 -0700
Received: from bt02e0.god.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f4I7lg305340
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 09:47:42 +0200 (MET DST)
Received: from god.bel.alcatel.be (bt02e1.god.bel.alcatel.be [138.203.145.14])
	by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id JAA00617
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 09:47:18 +0200 (MET DST)
Message-ID: <3B04D361.CFDDB218@god.bel.alcatel.be>
Date: Fri, 18 May 2001 09:46:41 +0200
From: kris buggenhout <buggenkr@god.bel.alcatel.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
References: <Pine.LNX.4.33.0105171417250.28169-100000@UberGeek.coremetrics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Austin Gonyou wrote:
> 
> Yeah..I know, but this seems pretty severe. Usually things of this
> severity seem to get talked about on the list immediately, so I didn't
> know if anyone was listening out there or not. Sorry for the bother!
> Thanks for the reply!
> 
> --
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Thu, 17 May 2001, Steve Lord wrote:
> 
> > > Has ANYONE looked into this? It seems pretty serious. Anyone?
> >
> > Not yet - patience, if this was a commercial release you would have
> > to wait several months for a fix ;-)
> >
> > Steve
> >
> > >
> > > On Wed, 16 May 2001, Austin Gonyou wrote:
> > >
> > > > On the system I've been testing LVM+XFS with, I've run into a bit of a
> > > > dilemma. If I try to resize the a volume more than once, I get the
> > > > following error message:

I've had the same problem .. 

workaround : run an xfs_repair on it and it doesnt throw any errors. I
tried this multiple times.
the resize leave's the fs in a non consistent state... I think an
umount/mount could also fix the prob.. ( replaying the log ...)

From owner-linux-xfs@oss.sgi.com Fri May 18 00:49:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I7n1K09602
	for linux-xfs-outgoing; Fri, 18 May 2001 00:49:01 -0700
Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I7mwF09598
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 00:48:59 -0700
Received: from spike (spike.csee.uq.edu.au [130.102.66.71])
	by gum.csee.uq.edu.au (8.11.3/8.11.3) with SMTP id f4I7mtZ20983
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 17:48:55 +1000 (EST)
Message-ID: <052201c0df6e$fd0abd70$47426682@csee.uq.edu.au>
From: "Chris Pascoe" <c.pascoe@csee.uq.edu.au>
To: <linux-xfs@oss.sgi.com>
Subject: kdb documentation bug
Date: Fri, 18 May 2001 17:48:54 +1000
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_051F_01C0DFC2.CE8D9A90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_051F_01C0DFC2.CE8D9A90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

After many hours of trying to get a serial console up so I can use kdb to
track down a crash while running the stress tests (against the current CVS
tree), I discovered that the kdb manual page linux/Documentation/kdb.mm has
an error.

It specifies you need to specify the serial device as "/dev/ttyS0" - whereas
you really need to put just plain "ttyS0".  The /dev/ at the start makes the
machine just hang silently at boot time for me.

A patch is attached to correct this and save others going through the same
grief that I did :).  linux/Documentation/serial-console.txt shows the
device without the "/dev/" also, this makes the kdb documentation consistent
with this (even if it somehow works with the /dev/ in some kernels, but I
don't think it can in 2.4 at least after examining the console setup code).

Chris

------=_NextPart_000_051F_01C0DFC2.CE8D9A90
Content-Type: application/octet-stream;
	name="kdb.mm.diff"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="kdb.mm.diff"

Index: kdb.mm=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: /cvs/linux-2.4-xfs/linux/Documentation/kdb/kdb.mm,v=0A=
retrieving revision 1.11=0A=
diff -u -r1.11 kdb.mm=0A=
--- kdb.mm      2001/02/27 05:07:04     1.11=0A=
+++ kdb.mm      2001/05/18 07:33:06=0A=
@@ -58,7 +58,7 @@=0A=
 Define both video and serial consoles with boot parameters=0A=
 .P=0A=
 .nf=0A=
-  console=3Dtty0 console=3D/dev/ttyS0,38400=0A=
+  console=3Dtty0 console=3DttyS0,38400=0A=
 .fi=0A=
 .P=0A=
 Any kdb data entered on the keyboard or the serial console will be =
echoed=0A=

------=_NextPart_000_051F_01C0DFC2.CE8D9A90--


From owner-linux-xfs@oss.sgi.com Fri May 18 02:36:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4I9aQb13171
	for linux-xfs-outgoing; Fri, 18 May 2001 02:36:26 -0700
Received: from bunce.bitecomm.co.uk (IDENT:domino@bunce.bitecomm.co.uk [193.82.143.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4I9aPF13168
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 02:36:25 -0700
Subject: Re: Two problems with a new installation
To: linux-xfs@oss.sgi.com
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <OFFEE790C5.42B06865-ON00256A50.00339272@bitecomm.co.uk>
From: "James Carrier" <james.carrier@bulletonline.com>
Date: Fri, 18 May 2001 10:24:57 +0100
X-MIMETrack: Serialize by Router on bunce.bitecomm.co.uk/Bite/GB(Release 5.0.7 |March 21, 2001) at
 05/18/2001 09:24:50 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hello Dave

I can't comment on your specific problem, but have you upgraded the
MegaRAID's firmware to the latest version available from AMI's web site? I
had many many problems installing both a clean 7.1 system and an XFS 7.1
system until I traced back to the Mega's firmware. Earlier versions of the
code are seriously screwed!

Just my 0.02 :-)

james



                                                                                                                            
                    "Dave Sill"                                                                                             
                    <ds-linux-xfs@sws5.ctd        To:     linux-xfs@oss.sgi.com                                             
                    .ornl.gov>                    cc:                                                                       
                    Sent by:                      Subject:     Two problems with a new installation                         
                    owner-linux-xfs@oss.sg                                                                                  
                    i.com                                                                                                   
                                                                                                                            
                                                                                                                            
                    17/05/2001 21:04                                                                                        
                                                                                                                            
                                                                                                                            




I installed XFS 1.0 + Red Hat 7.1 via the SGI installer on a 2-proc
Dell server with 2 x 250GB AMI MegaRAID's. The installation went
smoothly, but I've been getting occasional messages like:

May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
May 17 03:39:08 daacsnfs kernel: __alloc_pages: 2-order allocation failed.
May 17 03:42:52 daacsnfs kernel: __alloc_pages: 0-order allocation failed.

What do these messages mean?



From owner-linux-xfs@oss.sgi.com Fri May 18 03:12:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IACSI14121
	for linux-xfs-outgoing; Fri, 18 May 2001 03:12:28 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4IACPF14115
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 03:12:26 -0700
Received: (qmail 28667 invoked from network); 18 May 2001 10:12:22 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 18 May 2001 10:12:22 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Chris Pascoe" <c.pascoe@csee.uq.edu.au>
cc: linux-xfs@oss.sgi.com
Subject: Re: kdb documentation bug 
In-reply-to: Your message of "Fri, 18 May 2001 17:48:54 +1000."
             <052201c0df6e$fd0abd70$47426682@csee.uq.edu.au> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 18 May 2001 20:12:21 +1000
Message-ID: <32451.990180741@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 18 May 2001 17:48:54 +1000, 
"Chris Pascoe" <c.pascoe@csee.uq.edu.au> wrote:
>I discovered that the kdb manual page linux/Documentation/kdb.mm has
>an error.
>It specifies you need to specify the serial device as "/dev/ttyS0" - whereas
>you really need to put just plain "ttyS0".  The /dev/ at the start makes the
>machine just hang silently at boot time for me.

Oops, thats what I get for typing docs from memory instead of copying a
working file.  Thanks.


From owner-linux-xfs@oss.sgi.com Fri May 18 03:37:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IAbuB15111
	for linux-xfs-outgoing; Fri, 18 May 2001 03:37:56 -0700
Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IAbsF15106
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 03:37:54 -0700
Received: from bt02e0.god.bel.alcatel.be (localhost [127.0.0.1])
	by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id f4IAbfL25577;
	Fri, 18 May 2001 12:37:41 +0200 (MET DST)
Received: from god.bel.alcatel.be (bt02e1.god.bel.alcatel.be [138.203.145.14])
	by bt02e0.god.bel.alcatel.be (8.9.3+Sun/8.9.3/1.1) with ESMTP id MAA08494;
	Fri, 18 May 2001 12:37:18 +0200 (MET DST)
Message-ID: <3B04FB3A.27F88ED0@god.bel.alcatel.be>
Date: Fri, 18 May 2001 12:36:42 +0200
From: kris buggenhout <buggenkr@god.bel.alcatel.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
CC: dmarkh@cfl.rr.com
Subject: Re: trouble benchmarking
References: <4.3.2.7.2.20010517130519.038d0c88@pop.xs4all.nl> <3B044CEE.16BEE674@cfl.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mark Hounschell wrote:
> 
> Seth Mos wrote:
> >
> > At 11:46 17-5-2001 +0200, kris buggenhout wrote:
> > >it looks like a scsi error .. but when I do the same test on the same
> > >drive with ext2 i get no error.
> >
> > ext2 probably handles bad blocks better. The XFS filesystem shuts down on
> > error. Ext2 may stay up and note that the sector is moved and the data is ok.
> > It might be possible that xfs could be made to respect this re allocation
> > of a bad sector and perhaps not shut down.
> 
> The scsi drives "page-1 mode-select" error recovery page should be set
> to not
> report recovered errors. This can be changed with any decent scsi disc
> utility
where can I find that for linux? or do I have to install windows to only
change that..?

From owner-linux-xfs@oss.sgi.com Fri May 18 04:02:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IB2hW15950
	for linux-xfs-outgoing; Fri, 18 May 2001 04:02:43 -0700
Received: from smtp-server1.tampabay.rr.com (smtp-server1.cfl.rr.com [65.32.2.68])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IB2eF15947
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 04:02:41 -0700
Received: from cfl.rr.com (ubr-35.87.175.wmelbourne.cfl.rr.com [65.35.87.175])
	by smtp-server1.tampabay.rr.com (8.11.2/8.11.2) with ESMTP id f4IB2K519707;
	Fri, 18 May 2001 07:02:24 -0400 (EDT)
Message-ID: <3B050275.1F15AAFF@cfl.rr.com>
Date: Fri, 18 May 2001 07:07:33 -0400
From: Mark Hounschell <dmarkh@cfl.rr.com>
Reply-To: dmarkh@cfl.rr.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: kris buggenhout <buggenkr@god.bel.alcatel.be>
CC: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: trouble benchmarking
References: <4.3.2.7.2.20010517130519.038d0c88@pop.xs4all.nl> <3B044CEE.16BEE674@cfl.rr.com> <3B04FB3A.27F88ED0@god.bel.alcatel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kris buggenhout wrote:
> 
> Mark Hounschell wrote:
> >
> > Seth Mos wrote:
> > >
> > > At 11:46 17-5-2001 +0200, kris buggenhout wrote:
> > > >it looks like a scsi error .. but when I do the same test on the same
> > > >drive with ext2 i get no error.
> > >
> > > ext2 probably handles bad blocks better. The XFS filesystem shuts down on
> > > error. Ext2 may stay up and note that the sector is moved and the data is ok.
> > > It might be possible that xfs could be made to respect this re allocation
> > > of a bad sector and perhaps not shut down.
> >
> > The scsi drives "page-1 mode-select" error recovery page should be set
> > to not
> > report recovered errors. This can be changed with any decent scsi disc
> > utility
> where can I find that for linux? or do I have to install windows to only
> change that..?

Most if not all of them I've seen are in the bios of the scsi
controller. But there
is one for linux called scsiinfo. It is in this package
"scsi-1.7_2.22_000630-0 ".
It came with my SuSE dis. Be sure to read the man pages CAREFULLY before
using.
I havn't actually used this one but looks like it will do it. Again be
CAREFULL.
Misuse could cause lost data.... 

Regards


-- 
Mark Hounschell
dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Fri May 18 04:08:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IB8df16325
	for linux-xfs-outgoing; Fri, 18 May 2001 04:08:39 -0700
Received: from gw.solid.fi (gw.solid.fi [193.65.201.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IB8ZF16322
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 04:08:36 -0700
Received: from solidtech.com 
	by gw.solid.fi (8.9.1/8.9.1) with ESMTP id OAA10450;
	Fri, 18 May 2001 14:19:40 +0300 (EET DST)
Received: from lauri-ibm (lauri-ibm.solid.fi [192.168.1.184])
	by solidtech.com (8.9.3/8.9.3) with SMTP id OAA17181;
	Fri, 18 May 2001 14:08:34 +0300 (EEST)
	(envelope-from lauri@solidtech.com)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Lauri Ojantakanen <lauri@solidtech.com>
Organization: Solid
To: Steve Lord <lord@sgi.com>
Subject: Re: Questions about recovery
Date: Fri, 18 May 2001 14:08:27 +0300
X-Mailer: KMail [version 1.2]
Cc: linux-xfs@oss.sgi.com
References: <200105171447.f4HElu921491@jen.americas.sgi.com>
In-Reply-To: <200105171447.f4HElu921491@jen.americas.sgi.com>
MIME-Version: 1.0
Message-Id: <01051814082702.06686@lauri-ibm>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

My intention is neither to unplug the machine (it would not hurt as I am 
using xfs in my laptop:) nor to leave out proper shutdown procedures. 
However, my situation is such that I have problems with pppd (my machine 
hangs with it ). I just would like to know what to do to minimize the amount 
of damage if I want to study more this pppd problem.

Rgrds,

//lauri

On Thursday 17 May 2001 17:47, Steve Lord wrote:
> > Lauri Ojantakanen wrote:
> > > Hi,
> > >
> > > I am very happy using xfs (converted everything to xfs:). Usually
> > > everythin
> >
> > g
> >
> > > goes fine with the system but there is one kinda scary thing: sometimes
> > > som
> >
> > e
> >
> > > files seem to be getting filled with null's after recovery. I mean that
> > > aft
> >
> > er
> >
> > > one recovery one opera's bookmark file was still there but the contents
> > > of the file was just  '\0'.
> >
> > This has been discussed a few times on the list.  (See the "might have
> > found a bug..." thread from this week).  The short answer is that it's a
> > feature, and specifying synchronous writes at mount time will minimize
> > it, but will also kill your performance.  You can also tune the bdflush
> > daemon to flush writes more often - also reducing performance.  It's a
> > tradeoff.
> >
> > -Eric
>
> I should also add here that the difference between what happens with XFS in
> this scenario and what would happen with ext2 is that with ext2 you
> probably would not see the new file at all - or the old one, but it depends
> on what got synced and what did not. The reason files show up with no data
> in xfs is that the delayed allocation code which reserves space during a
> write call has to bump the inode size - this size is making it out to disk,
> however, the allocation of real extents and the flush of the data is not.
> If delayed allocation was not being used you would get a file with garbage
> read off the disk, since the disk space would be allocated during the write
> call, but the data would still not be written out into it.
>
> Having a journalled filesystem does not in general mean you go pulling
> the plug without shutting the machine down, recovery is there for dealing
> with accidents and crashes, not so you can use the power button to
> shutdown ;-)
>
> Steve

From owner-linux-xfs@oss.sgi.com Fri May 18 07:51:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IEpLv28998
	for linux-xfs-outgoing; Fri, 18 May 2001 07:51:21 -0700
Received: from mail.compro.net (cpe-66-1-218-52.fl.sprintbbd.net [66.1.218.52])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IEpGF28993
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 07:51:16 -0700
Received: from compro.net (PC120.compro.net [10.10.10.120])
	by mail.compro.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA06393;
	Fri, 18 May 2001 10:55:15 -0500
X-Authentication-Warning: mail.compro.net: Host PC120.compro.net [10.10.10.120] claimed to be compro.net
Message-ID: <3B053739.F19CE818@compro.net>
Date: Fri, 18 May 2001 10:52:41 -0400
From: Mark Hounschell <markh@compro.net>
Reply-To: markh@compro.net
Organization: Compro Computer Svcs.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: dmarkh@cfl.rr.com
CC: kris buggenhout <buggenkr@god.bel.alcatel.be>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: trouble benchmarking
References: <4.3.2.7.2.20010517130519.038d0c88@pop.xs4all.nl> <3B044CEE.16BEE674@cfl.rr.com> <3B04FB3A.27F88ED0@god.bel.alcatel.be> <3B050275.1F15AAFF@cfl.rr.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Mark Hounschell wrote:
> 
> kris buggenhout wrote:
> >
> > Mark Hounschell wrote:
> > >
> > > Seth Mos wrote:
> > > >
> > > > At 11:46 17-5-2001 +0200, kris buggenhout wrote:
> > > > >it looks like a scsi error .. but when I do the same test on the same
> > > > >drive with ext2 i get no error.
> > > >
> > > > ext2 probably handles bad blocks better. The XFS filesystem shuts down on
> > > > error. Ext2 may stay up and note that the sector is moved and the data is ok.
> > > > It might be possible that xfs could be made to respect this re allocation
> > > > of a bad sector and perhaps not shut down.
> > >
> > > The scsi drives "page-1 mode-select" error recovery page should be set
> > > to not
> > > report recovered errors. This can be changed with any decent scsi disc
> > > utility
> > where can I find that for linux? or do I have to install windows to only
> > change that..?
> 
> Most if not all of them I've seen are in the bios of the scsi
> controller. But there
> is one for linux called scsiinfo. It is in this package
> "scsi-1.7_2.22_000630-0 ".
> It came with my SuSE dis. Be sure to read the man pages CAREFULLY before
> using.
> I havn't actually used this one but looks like it will do it. Again be
> CAREFULL.
> Misuse could cause lost data....

Try scsi-config. It's better. It's from xscsi-1.7_2.22_000630-0 package.
Don't forget... BE CAREFULL.....

> 
> --
> Mark Hounschell
> dmarkh@cfl.rr.com

From owner-linux-xfs@oss.sgi.com Fri May 18 08:49:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IFn0830853
	for linux-xfs-outgoing; Fri, 18 May 2001 08:49:00 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IFmxF30850
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 08:48:59 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4IFkN906892;
	Fri, 18 May 2001 10:46:23 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 18 May 2001 10:46:23 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: kris buggenhout <buggenkr@god.bel.alcatel.be>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <3B04D361.CFDDB218@god.bel.alcatel.be>
Message-ID: <Pine.LNX.4.33.0105181045330.6821-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've unmounted/remounted it and that doesn't fix crap. I'll try the
xfs_repair, and while that COULD work, it's not a real fix, but at least
it's a work around! Thanks a lot!

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 18 May 2001, kris buggenhout wrote:

> Austin Gonyou wrote:
> >
> > Yeah..I know, but this seems pretty severe. Usually things of this
> > severity seem to get talked about on the list immediately, so I didn't
> > know if anyone was listening out there or not. Sorry for the bother!
> > Thanks for the reply!
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
> > On Thu, 17 May 2001, Steve Lord wrote:
> >
> > > > Has ANYONE looked into this? It seems pretty serious. Anyone?
> > >
> > > Not yet - patience, if this was a commercial release you would have
> > > to wait several months for a fix ;-)
> > >
> > > Steve
> > >
> > > >
> > > > On Wed, 16 May 2001, Austin Gonyou wrote:
> > > >
> > > > > On the system I've been testing LVM+XFS with, I've run into a bit of a
> > > > > dilemma. If I try to resize the a volume more than once, I get the
> > > > > following error message:
>
> I've had the same problem ..
>
> workaround : run an xfs_repair on it and it doesnt throw any errors. I
> tried this multiple times.
> the resize leave's the fs in a non consistent state... I think an
> umount/mount could also fix the prob.. ( replaying the log ...)
>


From owner-linux-xfs@oss.sgi.com Fri May 18 08:51:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IFprG31167
	for linux-xfs-outgoing; Fri, 18 May 2001 08:51:53 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IFpqF31160
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 08:51:52 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4IFmKk06908;
	Fri, 18 May 2001 10:48:20 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 18 May 2001 10:48:20 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <15108.53876.723238.542757@gilmour.mgm-net.de>
Message-ID: <Pine.LNX.4.33.0105181047350.6821-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Interesting. The kernel I'm using is the one from the devel tree. Very
interesting. Perhaps this is scsi specific?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 18 May 2001, Jochen Scharrlach wrote:

> Austin Gonyou writes:
> > Has ANYONE looked into this? It seems pretty serious. Anyone?
>
> > > I'm currently running on a Dell 1550, x3 9GB scsi drives, dual 933Mhz P3,
> > > Adaptec AIC-7899 controller, and 512Mb ram. I used the RH 7.1 installer
> > > from SGI to install the box. Using LVM 0.9.1-b7 tools.
>
> What kernel is this? The "official" LVM 1.0 uses LVM 0.9.1-beta6! I
> have a home-grown RedHat 7.0 with kernel 2.4.3-XFS plus LVM
> 0.9.1-beta7 (including kernel patch) and on this system it goes like
> this:
>
> [root@gilmour /root]# mkfs -t xfs -f /dev/vg01/test
> mkfs.xfs: warning - cannot set blocksize on block device /dev/vg01/test: Invalid argument
> meta-data=/dev/vg01/test         isize=256    agcount=8, agsize=16000 blks
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal log           bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> [root@gilmour /root]# mount /dev/vg01/test /mnt/tmp
> [root@gilmour /root]# mount
> /dev/sda1 on / type ext2 (rw)
> none on /proc type proc (rw)
> usbdevfs on /proc/bus/usb type usbdevfs (rw)
> /dev/vg01/tmp on /tmp type xfs (rw)
> /dev/vg01/var-xfs on /var type xfs (rw)
> /dev/vg01/usr-xfs on /usr type xfs (rw)
> /dev/vg01/ftp-rfs on /var/ftp type reiserfs (rw)
> none on /dev/pts type devpts (rw,gid=5,mode=620)
> automount(pid8197) on /remote type autofs (rw,fd=5,pgrp=8197,minproto=2,maxproto=3)
> automount(pid8255) on /- type autofs (rw,fd=5,pgrp=8255,minproto=2,maxproto=3)
> automount(pid8226) on /home type autofs (rw,fd=5,pgrp=8226,minproto=2,maxproto=3)
> automount(pid8185) on /misc type autofs (rw,fd=5,pgrp=8185,minproto=2,maxproto=3)
> cepheus:/export/home/js on /home/js type nfs (rw,addr=192.168.1.2)
> cepheus:/export/mail on /remote/mail type nfs (rw,addr=192.168.1.2)
> /dev/vg01/test on /mnt/tmp type xfs (rw)
> [root@gilmour /root]# lvextend -L 600 /dev/vg01/test
> lvextend -- extending logical volume "/dev/vg01/test" to 600 MB
> lvextend -- doing automatic backup of volume group "vg01"
> lvextend -- logical volume "/dev/vg01/test" successfully extended
>
> [root@gilmour /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> /dev/sda1              2016016   1642956    270648  86% /
> /dev/vg01/tmp           507200       280    506920   1% /tmp
> /dev/vg01/var-xfs       507200     76744    430456  16% /var
> /dev/vg01/usr-xfs      3067200   2652836    414364  87% /usr
> /dev/vg01/ftp-rfs      2047932   1592760    455172  78% /var/ftp
> cepheus:/export/home/js
>                        8603615   7924063    233349  98% /home/js
> cepheus:/export/mail   8603615   7924063    233349  98% /remote/mail
> /dev/vg01/test          507200       144    507056   1% /mnt/tmp
> [root@gilmour /root]# xfs_growfs /mnt/tmp
> meta-data=/mnt/tmp               isize=256    agcount=8, agsize=16000 blks
> data     =                       bsize=4096   blocks=128000, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 128000 to 153600
> [root@gilmour /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> [...]
> /dev/vg01/test          609600       176    609424   1% /mnt/tmp
> [root@gilmour /root]# lvextend -L 700 /dev/vg01/test
> lvextend -- extending logical volume "/dev/vg01/test" to 700 MB
> lvextend -- doing automatic backup of volume group "vg01"
> lvextend -- logical volume "/dev/vg01/test" successfully extended
>
> [root@gilmour /root]# xfs_growfs /mnt/tmp
> meta-data=/mnt/tmp               isize=256    agcount=10, agsize=16000 blks
> data     =                       bsize=4096   blocks=153600, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 153600 to 179200
> [root@gilmour /root]# df
> Filesystem           1k-blocks      Used Available Use% Mounted on
> [...]
> /dev/vg01/test          712000       208    711792   1% /mnt/tmp
> [root@gilmour /root]# lvextend -L +2M /dev/vg01/test
> lvextend -- rounding size to physical extent boundary
> lvextend -- extending logical volume "/dev/vg01/test" to 704 MB
> lvextend -- doing automatic backup of volume group "vg01"
> lvextend -- logical volume "/dev/vg01/test" successfully extended
>
> [root@gilmour /root]# xfs_growfs /mnt/tmp
> meta-data=/mnt/tmp               isize=256    agcount=12, agsize=16000 blks
> data     =                       bsize=4096   blocks=179200, imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096
> log      =internal               bsize=4096   blocks=1200
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> data blocks changed from 179200 to 180224
> [root@gilmour /root]# df
> [...]
> /dev/vg01/test          716096       208    715888   1% /mnt/tmp
>
>
> Bye,
> Jochen
>
>


From owner-linux-xfs@oss.sgi.com Fri May 18 08:56:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IFuaO31558
	for linux-xfs-outgoing; Fri, 18 May 2001 08:56:36 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IFuZF31555
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 08:56:35 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4IFrLa06955;
	Fri, 18 May 2001 10:53:21 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 18 May 2001 10:53:21 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: kris buggenhout <buggenkr@god.bel.alcatel.be>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <3B04D361.CFDDB218@god.bel.alcatel.be>
Message-ID: <Pine.LNX.4.33.0105181050590.6821-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

After running an xfs_repair, that FS seems to be all good in general now.
I'm going to perform one more test. In this test I'll blow away the
volume, recreate it as a 6GB volume, run xfs_repair immediately, mount,
then extend, grow, repeat. I'll post results and specifications when done.
Thanks for helping guys!

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 18 May 2001, kris buggenhout wrote:

> Austin Gonyou wrote:
> >
> > Yeah..I know, but this seems pretty severe. Usually things of this
> > severity seem to get talked about on the list immediately, so I didn't
> > know if anyone was listening out there or not. Sorry for the bother!
> > Thanks for the reply!
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
> > On Thu, 17 May 2001, Steve Lord wrote:
> >
> > > > Has ANYONE looked into this? It seems pretty serious. Anyone?
> > >
> > > Not yet - patience, if this was a commercial release you would have
> > > to wait several months for a fix ;-)
> > >
> > > Steve
> > >
> > > >
> > > > On Wed, 16 May 2001, Austin Gonyou wrote:
> > > >
> > > > > On the system I've been testing LVM+XFS with, I've run into a bit of a
> > > > > dilemma. If I try to resize the a volume more than once, I get the
> > > > > following error message:
>
> I've had the same problem ..
>
> workaround : run an xfs_repair on it and it doesnt throw any errors. I
> tried this multiple times.
> the resize leave's the fs in a non consistent state... I think an
> umount/mount could also fix the prob.. ( replaying the log ...)
>


From owner-linux-xfs@oss.sgi.com Fri May 18 09:02:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IG2o132013
	for linux-xfs-outgoing; Fri, 18 May 2001 09:02:50 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IG2nF32010
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 09:02:49 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4IG0o506993;
	Fri, 18 May 2001 11:00:50 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 18 May 2001 11:00:50 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: kris buggenhout <buggenkr@god.bel.alcatel.be>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: LVM/XFS Bug?
In-Reply-To: <Pine.LNX.4.33.0105181050590.6821-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.33.0105181059330.6821-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok, I ran the test and it still fails. xfs_repair must be run after
growing the volume 1 time. While that saves me from having to worry about
destroying my data, it's not a fully acceptable fix. I'll try this again
with the b6 tools, but I seriously doubt that it will work.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 18 May 2001, Austin Gonyou wrote:

> After running an xfs_repair, that FS seems to be all good in general now.
> I'm going to perform one more test. In this test I'll blow away the
> volume, recreate it as a 6GB volume, run xfs_repair immediately, mount,
> then extend, grow, repeat. I'll post results and specifications when done.
> Thanks for helping guys!
>
>


From owner-linux-xfs@oss.sgi.com Fri May 18 10:39:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IHdwN01606
	for linux-xfs-outgoing; Fri, 18 May 2001 10:39:58 -0700
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IHdvF01603
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 10:39:57 -0700
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 150oDv-000LFR-0A
	for linux-xfs@oss.sgi.com; Fri, 18 May 2001 17:39:46 +0000
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 49FAD27EF
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 08:41:50 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 3E034125E7; Fri, 18 May 2001 08:41:50 +0100 (BST)
Date: Fri, 18 May 2001 08:41:50 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[2]: Two problems with a new installation
To: linux-xfs <linux-xfs@oss.sgi.com>
In-Reply-To: <3B04C26A.4E0436D3@ch.sauter-bc.com>
References: <wx0eltng2t1.fsf@sws5.ctd.ornl.gov>,
 <3B04C26A.4E0436D3@ch.sauter-bc.com>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010518074150.3E034125E7@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f4IHdwF01604
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 18 May 2001 08:34:18 +0200 Simon Matter <Simon Matter <simon.matter@ch.sauter-bc.com>> wrote:

> Hi
> 
> I can not speak about XFS on DELL with AMI MegaRAID but I'm using
> RedHat 6.2 on some machines and they are terrible slow. I also
> downloaded
> the custom kernel from the DELL support page but nothing changed.
> I remember that when I installed the first machine I wanted to call
> DELL support so they replace the machine. But later I found out that
> every machine was the same.
> The only thing I can say is: Don't use any hardware RAID if you want
> to get most perfomance out of your disks. Some years ago hardware did
> improve performance but with the CPU power we have today, software RAID
> is the fastet.
> That's my experience, anyone to comment on this?
> 
What happens if the system breaks before the cached blocks are written
away ?

--
Keith Matthews

Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Fri May 18 11:28:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IISEi02804
	for linux-xfs-outgoing; Fri, 18 May 2001 11:28:14 -0700
Received: from neptune.phys.ufl.edu (neptune-gw.phys.ufl.edu [128.227.64.7])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IISDF02801
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 11:28:13 -0700
Received: from neptune-gw.phys.ufl.edu (neptune-gw.phys.ufl.edu [128.227.64.7])
	by neptune.phys.ufl.edu (8.9.3/8.9.3) with ESMTP id OAA15762;
	Fri, 18 May 2001 14:28:08 -0400 (EDT)
Date: Fri, 18 May 2001 14:28:08 -0400 (EDT)
From: Brent A Nelson <brent@phys.ufl.edu>
To: Eric Sandeen <sandeen@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: dump/restore and setuid/setgid files
In-Reply-To: <3B044744.EBAC2218@sgi.com>
Message-ID: <Pine.GSO.4.21.0105181405520.13836-100000@neptune.phys.ufl.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Okay, to fix this problem I grabbed the xfsdump directory in CVS and
proceeded to create an xfsdump-1.0.9 RPM from it.  The build went well
until the linking of xfsdump itself:

gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS
-DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs
-I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -I/usr/include/xfs
-I/usr/include/attr  -c -o var.o var.c
gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS
-DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs
-I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64
-D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfsdump
arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o
drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o
mlog.o openutil.o qlock.o path.o ring.o stkchk.o stream.o util.o sproc.o
attr.o inv_api.o inv_core.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o
content.o inomap.o var.o   -lhandle /usr/lib/libuuid.a ../librmt/librmt.a
/usr/lib/libattr.a  
arch_xlate.o: In function `xlate_global_hdr':
/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:67: undefined
reference to `__fswab64'
/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:67: undefined
reference to `__fswab64'
arch_xlate.o: In function `xlate_content_inode_hdr':
/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:252: undefined
reference to `__fswab64'
/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:252: undefined
reference to `__fswab64'
/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:253: undefined
reference to `__fswab64'
arch_xlate.o:/usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:253: more
undefined references to `__fswab64' follow
collect2: ld returned 1 exit status
make[1]: *** [xfsdump] Error 1
make: *** [default] Error 2

This is on an Intel machine running with the SGI-modified RedHat 7.1, and
all partitions moved over to LVM.

Suggestions?

Thanks,

Brent


From owner-linux-xfs@oss.sgi.com Fri May 18 14:12:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ILCQP07452
	for linux-xfs-outgoing; Fri, 18 May 2001 14:12:26 -0700
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ILCPF07449
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 14:12:25 -0700
Received: from smui02.slb.mindspring.net (smui02.slb.mindspring.net [199.174.114.25])
	by tisch.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id RAA29775
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 17:12:21 -0400 (EDT)
From: heliosc@mindspring.com
Received: by smui02.slb.mindspring.net id RAA0000026542; Fri, 18 May 2001 17:12:21 -0400 (EDT)
Date: Fri, 18 May 2001 17:12:21 -0400
To: linux-xfs@oss.sgi.com
Subject: Low latency patches.
Message-ID: <Springmail.105.990220341.0.17542300@www.springmail.com>
X-Originating-IP: 63.49.151.213
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'd just like to congratulate you guys on a great job with XFS. I've been using it for the last month or two, and it has been just wonderful. I was just wondering if there are any conflicts with the XFS kernel tree and Ingo Molnar's low latency patches to 2.4.x. I use Linux mainly on my desktop system, and have found the low-latency patches to be very useful. Thanks in advance.

From owner-linux-xfs@oss.sgi.com Fri May 18 14:47:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ILltj08325
	for linux-xfs-outgoing; Fri, 18 May 2001 14:47:55 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ILlrF08322
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 14:47:54 -0700
Received: from dendennis.saarinen.org ([192.168.1.2] helo=dendennis)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 150s6C-00017P-00
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 09:47:52 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Linux-Xfs@Oss. Sgi. Com" <linux-xfs@oss.sgi.com>
Subject: About to do the deed... 
Date: Sat, 19 May 2001 09:47:40 +1200
Message-ID: <KPECIILENDDLPCNIMLOFIELJCEAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

OK, it's time. I'm going to build a new server here, with XFS as the file
system.

I'm planning on doing the install through the System Installer ISO image
from oss.sgi.com. Just wondering if there's anything I need to look out
for -- have been following the list, and it seems that XFS is ready to roll
so... touch wood.

The system: dual P3-500, 200MB RAM, 1 x 4GB, 1 x 9GB SCSI UW drives, Symbios
adapter, Tyan Tiger 133 motherboard (VIA Apollo Pro chip set).

--
Juha

The malformed orange
Fails to satisfy the eye:
Segmentation fault.



From owner-linux-xfs@oss.sgi.com Fri May 18 15:39:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IMdlg09564
	for linux-xfs-outgoing; Fri, 18 May 2001 15:39:47 -0700
Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IMdkF09560
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 15:39:46 -0700
Received: from erich (helo=trillium)
	by trillium-hollow.org with local-esmtp (Exim 3.20 #1)
	id 150sos-0000nE-00
	for linux-xfs@oss.sgi.com; Fri, 18 May 2001 15:34:02 -0700
To: linux-xfs@oss.sgi.com
Subject: Problems with SMP version of XFS RH 7.1 installer
Date: Fri, 18 May 2001 15:34:02 -0700
From: erich@uruk.org
Message-Id: <E150sos-0000nE-00@trillium-hollow.org>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


First of all, great job, guys!  Even through all my SMP woes, I haven't
lost data, and it's great not having it FSCK the 40GB XFS partition I
have.  ;)

I have an SMP machine which is crashing or hanging after I've installed
the XFS RH 7.1 set:

  --  dual celeron 550
  --  768MB of RAM
  --  IDE HPT366 w/42GB disk and one large XFS partition.
  --  Intel EEPro 10/100 network

It works fine with XFS RH 7.1 UP, but the SMP kernel appears to be
somewhat buggy (yes, it worked fine on other SMP OSes, and several
prior RH SMP versions).  The problem, in general, only seems to appear
when I try to move my data from another system to this one over the network
(a few times it crashed from untarring/retarring the large >8GB fileset
I'm working with, but I'm not 100% sure there was no network interaction
going on...).

Symptom: try to ftp my 8.5GB tar file from another box to this one, it
would always either:

  --  hang the network card, so no packets are transmitted anymore, and
      occasional errors like "NETWORK TRANSMIT failure" would be in the
      log.
  --  hang the disk drive, but everything else including the network
      is still responding.
  --  occasionally, hang the whole machine.

I tried changing controller and network card types, presuming it might
have been a driver problem, but no dice, identical results.

The overall result makes me think it's some kind of linux 2.4.2 SMP
stability problem, but I'm not sure what other kernel w/XFS to try...

--
    Erich Stefan Boleyn     <erich@uruk.org>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"

From owner-linux-xfs@oss.sgi.com Fri May 18 15:50:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IMow309990
	for linux-xfs-outgoing; Fri, 18 May 2001 15:50:58 -0700
Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IMowF09987
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 15:50:58 -0700
Received: from erich (helo=trillium)
	by trillium-hollow.org with local-esmtp (Exim 3.20 #1)
	id 150szi-0000or-00
	for linux-xfs@oss.sgi.com; Fri, 18 May 2001 15:45:14 -0700
To: linux-xfs@oss.sgi.com
Subject: Interested in adding XFS support to GRUB bootloader...
Date: Fri, 18 May 2001 15:45:14 -0700
From: erich@uruk.org
Message-Id: <E150szi-0000or-00@trillium-hollow.org>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Is there a good source these days about the XFS on-disk structures/format?

I'm interested in adding XFS support to the GRUB bootloader, and want
to know if there's anything better than the early XFS documents and
reverse-engineering to go by?  (I suppose I could just ask a lot of
questions as I go?  ;)

--
    Erich Stefan Boleyn     <erich@uruk.org>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"

From owner-linux-xfs@oss.sgi.com Fri May 18 16:09:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4IN9SN10567
	for linux-xfs-outgoing; Fri, 18 May 2001 16:09:28 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4IN9RF10564
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 16:09:28 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4IN9PU02432;
	Fri, 18 May 2001 18:09:25 -0500 (CDT)
Message-ID: <3B05AC36.7C0FAB19@sgi.com>
Date: Fri, 18 May 2001 18:11:50 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: erich@uruk.org
CC: linux-xfs@oss.sgi.com
Subject: Re: Interested in adding XFS support to GRUB bootloader...
References: <E150szi-0000or-00@trillium-hollow.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

erich@uruk.org wrote:
> 
> Is there a good source these days about the XFS on-disk structures/format?
> 
> I'm interested in adding XFS support to the GRUB bootloader, and want
> to know if there's anything better than the early XFS documents and
> reverse-engineering to go by?  (I suppose I could just ask a lot of
> questions as I go?  ;)

"A good source?"  How about the source?  :)

If you want an overview of how XFS works, then the early docs and some
of the talks that have been given have some good info (although also
some out of date info).

If you need detailed things like superblock magic numbers, then of
course the source is the way to go.   This is a pretty easy way to
navigate the tree: 
http://innominate.org/~graichen/projects/lxr/source/?v=xfs (or cscope,
of course).

I'm not familiar w/ GRUB, so I'm not sure what all you need, but feel
free to ask questions, I'm sure we can help with whatever you need.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Fri May 18 22:11:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4J5B3i17778
	for linux-xfs-outgoing; Fri, 18 May 2001 22:11:03 -0700
Received: from idiom.com (root@idiom.com [216.240.32.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J5B2F17775
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 22:11:03 -0700
Received: from namesys.com (pm3-3-41.dynamic.idiom.com [216.240.35.137])
	by idiom.com (8.9.3/8.9.3) with ESMTP id WAA07950;
	Fri, 18 May 2001 22:10:55 -0700 (PDT)
Message-ID: <3B06003E.9C5C44B@namesys.com>
Date: Fri, 18 May 2001 22:10:22 -0700
From: Hans Reiser <reiser@namesys.com>
Organization: Namesys
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en, ru
MIME-Version: 1.0
To: Eric Whiting <ewhiting@amis.com>
CC: Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com,
   Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS
References: <Pine.LNX.4.21.0105161929390.1579-100000@kalapati.jijo.local> <200105161451.f4GEpcj17003@jen.americas.sgi.com> <3B029987.4DBE7E7B@amis.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Whiting wrote:
>  Pretty slow results compared to what I'd expect for
> any hard disk less than 2 years old.

We will be getting a completely new set of workstations for our programmers this
summer, assuming funding comes through as planned.

If you are referring to Yura's hard drive, it probably is at least two years
old.

Hans

From owner-linux-xfs@oss.sgi.com Fri May 18 22:20:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4J5KBv18212
	for linux-xfs-outgoing; Fri, 18 May 2001 22:20:11 -0700
Received: from idiom.com (root@idiom.com [216.240.32.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J5KBF18208
	for <linux-xfs@oss.sgi.com>; Fri, 18 May 2001 22:20:11 -0700
Received: from namesys.com (pm3-3-41.dynamic.idiom.com [216.240.35.137])
	by idiom.com (8.9.3/8.9.3) with ESMTP id WAA09646;
	Fri, 18 May 2001 22:15:00 -0700 (PDT)
Message-ID: <3B060131.48917575@namesys.com>
Date: Fri, 18 May 2001 22:14:25 -0700
From: Hans Reiser <reiser@namesys.com>
Organization: Namesys
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i686)
X-Accept-Language: en, ru
MIME-Version: 1.0
To: Chris Mason <mason@suse.com>
CC: Steve Lord <lord@sgi.com>, Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS
References: <156560000.990028380@tiny>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Chris Mason wrote:

> > Thanks Chris, I totally agree, and at the moment I am much too busy to
> > spend time in a performance competition. I should also state that I have
> > never regarded the different filesystem on Linux as being in direct
> > competition with each other, there will always be benefits to using each
> > different filesystem for their strong points. Plus having several
> > filesystems under active development means that there will be a tendency
> > for the developers to make theirs the best, the implementations improve,
> > and everyone wins.

reiser4's architecture will be strongly influenced by the XFS pioneered delayed
allocation concept, and I would like to thank the XFS team for aggressively
ensuring that I understood the benefits of it.

Hans

From owner-linux-xfs@oss.sgi.com Sat May 19 01:14:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4J8EMe21068
	for linux-xfs-outgoing; Sat, 19 May 2001 01:14:22 -0700
Received: from metastasis.f00f.org (f00f.stub.clear.net.nz [203.167.224.51])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J8ELF21065
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 01:14:22 -0700
Received: by metastasis.f00f.org (Postfix, from userid 1000)
	id EDD6AA894; Sat, 19 May 2001 21:14:27 +1200 (NZST)
Date: Sat, 19 May 2001 21:14:27 +1200
From: Chris Wedgwood <cw@f00f.org>
To: Hans Reiser <reiser@namesys.com>
Cc: Chris Mason <mason@suse.com>, Steve Lord <lord@sgi.com>,
   Federico Sevilla III <jijo@i-manila.com.ph>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>, reiserfs-list@namesys.com
Subject: Re: [reiserfs-list] Re: Benchmarking ReiserFS, ext2, XFS
Message-ID: <20010519211427.A4745@metastasis.f00f.org>
References: <156560000.990028380@tiny> <3B060131.48917575@namesys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B060131.48917575@namesys.com>; from reiser@namesys.com on Fri, May 18, 2001 at 10:14:25PM -0700
X-No-Archive: Yes
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 18, 2001 at 10:14:25PM -0700, Hans Reiser wrote:

    reiser4's architecture will be strongly influenced by the XFS
    pioneered delayed allocation concept, and I would like to thank
    the XFS team for aggressively ensuring that I understood the
    benefits of it.

So what are the 'advantageous' you see in reiser4 over XFS when it is
available?



  --cw

From owner-linux-xfs@oss.sgi.com Sat May 19 01:54:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4J8sFD21828
	for linux-xfs-outgoing; Sat, 19 May 2001 01:54:15 -0700
Received: from yog-sothoth.sgi.com ([192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J8sDF21825
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 01:54:13 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id KAA217668
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 10:52:44 +0200 (CEST)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA18502; Sat, 19 May 2001 18:50:08 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA03805;
	Sat, 19 May 2001 18:50:07 +1000 (EST)
Date: Sat, 19 May 2001 18:50:06 +1000
From: Nathan Scott <nathans@sgi.com>
To: Brent A Nelson <brent@phys.ufl.edu>
Cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: dump/restore and setuid/setgid files
Message-ID: <20010519185006.A102436@wobbly.melbourne.sgi.com>
References: <3B044744.EBAC2218@sgi.com> <Pine.GSO.4.21.0105181405520.13836-100000@neptune.phys.ufl.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <Pine.GSO.4.21.0105181405520.13836-100000@neptune.phys.ufl.edu>; from brent@phys.ufl.edu on Fri, May 18, 2001 at 02:28:08PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi there,

On Fri, May 18, 2001 at 02:28:08PM -0400, Brent A Nelson wrote:
> Okay, to fix this problem I grabbed the xfsdump directory in CVS and
> proceeded to create an xfsdump-1.0.9 RPM from it.  The build went well
> until the linking of xfsdump itself:
> 

You'll need to build against a current xfsprogs-devel package.
In particular, the versions of libxfs.h and platform_defs.h in
earlier versions of xfsprogs had to be changed to fix some
portability problems.

> arch_xlate.o: In function `xlate_global_hdr':
> /usr/src/redhat/BUILD/xfsdump-1.0.9/dump/arch_xlate.c:67: undefined
> reference to `__fswab64'
> 
> This is on an Intel machine running with the SGI-modified RedHat 7.1, and
> all partitions moved over to LVM.
> 

This recipe should get you where you want to be...

# cd cmd/xfsprogs
# ./Makepkgs
# rpm -Uvh build/rpm/*.i386.rpm

# cd ../xfsdump
# ./Makepkgs
# rpm -Uvh build/rpm/*.i386.rpm


cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Sat May 19 02:21:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4J9LID22493
	for linux-xfs-outgoing; Sat, 19 May 2001 02:21:18 -0700
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4J9LGF22490
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 02:21:16 -0700
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1)
	id 1512vC-000HDF-0W
	for linux-xfs@oss.sgi.com; Sat, 19 May 2001 10:21:14 +0100
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 84EE027EF
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 10:20:50 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 48388125E6; Sat, 19 May 2001 10:20:49 +0100 (BST)
Date: Sat, 19 May 2001 10:20:48 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[2]: Interested in adding XFS support to GRUB bootloader... 
To: linux-xfs@oss.sgi.com
In-Reply-To: <200105190114.f4J1E9f08990@jen.americas.sgi.com>
References: <E150szi-0000or-00@trillium-hollow.org> <3B05AC36.7C0FAB19@sgi.com>,
 <200105190114.f4J1E9f08990@jen.americas.sgi.com>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010519092049.48388125E6@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f4J9LHF22491
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 18 May 2001 20:14:09 -0500 Steve Lord <Steve Lord <lord@sgi.com>> wrote:

> 

> > If you want an overview of how XFS works, then the early docs and some
> > of the talks that have been given have some good info (although also
> > some out of date info).
> > 
> > If you need detailed things like superblock magic numbers, then of
> > course the source is the way to go.   This is a pretty easy way to
> > navigate the tree: 
> > http://innominate.org/~graichen/projects/lxr/source/?v=xfs (or cscope,
> > of course).
> 
> This is probably gone as Thomas does not work for innominate anymore.
> 

It is kaput unfortunately. I have other contacts at Innominate, I may try
them to see if the stuff is still available internally. Thomas, I think
you are still on the list from another address, do you have it data there ? 


Steve, I've mailed Erich the stuff you sent me.

--
Keith Matthews

Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Sat May 19 08:19:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4JFJew28279
	for linux-xfs-outgoing; Sat, 19 May 2001 08:19:40 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JFJdF28276
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 08:19:39 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:61432 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S42585AbRESPTS>;
	Sat, 19 May 2001 17:19:18 +0200
Message-Id: <4.3.2.7.2.20010519171440.02fb5160@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Sat, 19 May 2001 17:19:25 +0200
To: erich@uruk.org, linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: Problems with SMP version of XFS RH 7.1 installer
In-Reply-To: <E150sos-0000nE-00@trillium-hollow.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 15:34 18-5-2001 -0700, erich@uruk.org wrote:

>First of all, great job, guys!  Even through all my SMP woes, I haven't
>lost data, and it's great not having it FSCK the 40GB XFS partition I
>have.  ;)
>
>I have an SMP machine which is crashing or hanging after I've installed
>the XFS RH 7.1 set:
>
>   --  dual celeron 550
>   --  768MB of RAM
>   --  IDE HPT366 w/42GB disk and one large XFS partition.
>   --  Intel EEPro 10/100 network
>
>It works fine with XFS RH 7.1 UP, but the SMP kernel appears to be
>somewhat buggy (yes, it worked fine on other SMP OSes, and several
>prior RH SMP versions).  The problem, in general, only seems to appear
>when I try to move my data from another system to this one over the network
>(a few times it crashed from untarring/retarring the large >8GB fileset
>I'm working with, but I'm not 100% sure there was no network interaction
>going on...).
>
>Symptom: try to ftp my 8.5GB tar file from another box to this one, it
>would always either:
>
>   --  hang the network card, so no packets are transmitted anymore, and
>       occasional errors like "NETWORK TRANSMIT failure" would be in the
>       log.
>   --  hang the disk drive, but everything else including the network
>       is still responding.
>   --  occasionally, hang the whole machine.
>
>I tried changing controller and network card types, presuming it might
>have been a driver problem, but no dice, identical results.
>
>The overall result makes me think it's some kind of linux 2.4.2 SMP
>stability problem, but I'm not sure what other kernel w/XFS to try...

Try the latest development CVS tree which is currently 2.4.4 based and see 
if that helps or not. It's 2 releases later then the release-1.0 tree.
It also does not contain any redhat kernel patches which might just be a 
good idea in reducing the number of options.

See the CVS information page on
http://linux-xfs.sgi.com/projects/xfs/cvs_download.html

Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Sat May 19 12:04:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4JJ4r031744
	for linux-xfs-outgoing; Sat, 19 May 2001 12:04:53 -0700
Received: from oker.escape.de (uucp@oker.escape.de [194.120.234.254])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JJ4pF31741
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 12:04:51 -0700
Received: from tengu.escape.de (uucp@localhost)
	by oker.escape.de (8.11.3/8.11.3/$Revision: 1.26 $) with UUCP-tengu id f4JJ4j705858
	for linux-xfs@oss.sgi.com; Sat, 19 May 2001 21:04:45 +0200
Received: (from ipaschke@localhost)
	by zeno.tengu.escape.de (8.9.1/8.9.1) id VAA22415
	for linux-xfs@oss.sgi.com; Sat, 19 May 2001 21:03:26 +0200 (MET DST)
Date: Sat, 19 May 2001 21:03:25 +0200
From: Ingo Paschke <ipaschke@tengu.escape.de>
To: linux-xfs@oss.sgi.com
Subject: strange fsr messages...
Message-ID: <20010519210325.A22401@tengu.escape.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I'm using RedHat 7.1/xfs on my desktop-box for several weeks now without any
problems (great work, btw), but today running "xfs_fsr" produced the
following kernel-messages (one for each xfs_fsr-pass):

fsr[1539]: xfs_fsr -m /etc/mtab -t 7200 -f /var/tmp/.fsrlast_xfs ... 
fsr[1540]: / startino=0 
kernel: kernel BUG at dcache.c:128!
kernel: invalid operand: 0000
kernel: CPU:    0
kernel: EIP:    0010:[<c0144178>]
kernel: EFLAGS: 00010282
kernel: eax: 0000001c   ebx: c21634c0   ecx: caebfb00   edx: fffffffe
kernel: esi: c21634c0   edi: ffffffe6   ebp: ca844000   esp: ca845bcc
kernel: ds: 0018   es: 0018   ss: 0018
kernel: Process xfs_fsr (pid: 1540, stackpage=ca845000)
kernel: Stack: c02a14e9 c02a1569 00000080 00000006 c21634c0 c01db477 c21634c0 cfe9d680 
kernel:        bfffdb88 cfe84000 c01c586b cee01400 cfecd800 00000000 00000000 00000002 
kernel:        bfffdbc8 00000018 00000000 00000000 83ed41a1 3d1c37f6 0000000e 00000000 
kernel: Call Trace: [<c02a14e9>] [<c02a1569>] [<c01db477>] [<c01c586b>] [<c01dc5ad>]
                    [<c01c586b>] [<c01c586b>] 

After that, I rebooted into the install-CD-rescue mode and ran xfs_check which
didn't find any inconsistencies. Just to make sure, I also tried xfs_repair
-n, it didn't want to modify the filesystem.

But if I run fsr now, I get the following errors:

[root@xlan /root]# /usr/sbin/xfs_fsr 
xfs_fsr -m /etc/mtab -t 7200 -f /var/tmp/.fsrlast_xfs ...
/ startino=0
sync failed: ino=5303235: Invalid argument
sync failed: ino=5299225: Invalid argument
sync failed: ino=5299227: Invalid argument
sync failed: ino=5299226: Invalid argument
sync failed: ino=5299228: Invalid argument
sync failed: ino=5299231: Invalid argument
[... etc, about 100 messages]

This is on an Athlon-System with KT133 chipset (ASUS A7V), the XFS-filesystem
is on a disk connected to the Promise-controller. I installed RedHat 7.1 using
the XFS-1.0 install-CD, Kernel 2.4.2-XFS-1.0, compiled using egcs-2.91.66.

Has anyone else run into this problem yet?

If you need more info, feel free to ask.

Ciao,
Ingo.

From owner-linux-xfs@oss.sgi.com Sat May 19 15:54:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4JMstc03087
	for linux-xfs-outgoing; Sat, 19 May 2001 15:54:55 -0700
Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JMslF03082
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 15:54:53 -0700
Received: by bobas.nowytarg.top.pl with BSMTP id <S188560AbRESTs5>;
	Sat, 19 May 2001 21:48:57 +0200
Received: by witch.underley.eu.org id <S5279503AbRESSEq>;
	Sat, 19 May 2001 20:04:46 +0200
Date:   Sat, 19 May 2001 20:04:46 +0200
From: Daniel Podlejski <underley@underley.eu.org>
To: linux-xfs@oss.sgi.com
Subject: Re: Interested in adding XFS support to GRUB bootloader...
Message-ID: <20010519200446.A24444@witch.underley.eu.org>
References: <E150szi-0000or-00@trillium-hollow.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <E150szi-0000or-00@trillium-hollow.org>; from erich@uruk.org on Fri, May 18, 2001 at 03:45:14PM -0700
X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9  66 AD F6 EA C9 17 CD 82
X-GPG-Fingerprint: 299F 1820 582B 283A 5F50  37D9 AA0B 6E10 03D4 EA5D
X-Homepage: http://www.underley.eu.org/
X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

erich@uruk.org wrote:
[...]
: I'm interested in adding XFS support to the GRUB bootloader, and want
: to know if there's anything better than the early XFS documents and
: reverse-engineering to go by?  (I suppose I could just ask a lot of
: questions as I go?  ;)

I have started to write grub xfs module, but now I have no enought
time to finish it.

Good place to see how to read xfs is source of xfsutils, and
experiments with xfs_db, for example - we have kernel in
/boot/vmlinuz-2.4.4-ac8-xfs-kdb, rootfs is on /dev/hdb1,
so try:

root@wizard:~:# xfs_db /dev/hdb1
xfs_db: inode 128
xfs_db: print
[...]
u.sfdir2.hdr.count = 1
u.sfdir2.hdr.i8count = 0
u.sfdir2.hdr.parent.i4 = 128
u.sfdir2.list[0].namelen = 4
u.sfdir2.list[0].offset = 0x30
u.sfdir2.list[0].name = "boot"
u.sfdir2.list[0].inumber.i4 = 131
xfs_db: inode 131
xfs_db: print
[...]
u.sfdir2.hdr.count = 1
u.sfdir2.hdr.i8count = 0
u.sfdir2.hdr.parent.i4 = 128
u.sfdir2.list[0].namelen = 25
u.sfdir2.list[0].offset = 0x30
u.sfdir2.list[0].name = "vmlinuz-2.4.4-ac8-xfs-kdb"
u.sfdir2.list[0].inumber.i4 = 132
xfs_db: inode 132
xfs_db: print
core.magic = 0x494e
core.mode = 0100644
core.version = 1
core.format = 2 (extents)
core.nlinkv1 = 1
core.uid = 0
core.gid = 0
core.atime.sec = Sat May 19 19:34:36 2001
core.atime.nsec = 365138000
core.mtime.sec = Sat May 19 19:34:36 2001
core.mtime.nsec = 415138000
core.ctime.sec = Sat May 19 19:34:36 2001
core.ctime.nsec = 415138000
core.size = 1126036
core.nblocks = 275
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.gen = 0
next_unlinked = null
u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,12,275,0]

Root inode is usualy 128, in this inode boot ditrectory is in 131
inode, and vmlinuz-2.4.4-ac8-xfs-kdb file in 132 inode.
File starst on block 12 and occupy  275 blocks.

In grub should be done:

- in stage2/disk_io.c - entry for xfs in fsys_table, this table
  contains functions pointers to xfs_mount, xfs_read and xfs_dir

- stage2/fsys_xfs.c - file with this functions
  

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... When you're talkin to yourself and nobody's home
   You can fool yourself, you came in this world alone ...

From owner-linux-xfs@oss.sgi.com Sat May 19 15:58:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4JMw6Q03146
	for linux-xfs-outgoing; Sat, 19 May 2001 15:58:06 -0700
Received: from oker.escape.de (uucp@oker.escape.de [194.120.234.254])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4JMw4F03143
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 15:58:05 -0700
Received: from tengu.escape.de (uucp@localhost)
	by oker.escape.de (8.11.3/8.11.3/$Revision: 1.26 $) with UUCP-tengu id f4JMw2325909
	for linux-xfs@oss.sgi.com; Sun, 20 May 2001 00:58:02 +0200
Received: (from ipaschke@localhost)
	by zeno.tengu.escape.de (8.9.1/8.9.1) id AAA23695
	for linux-xfs@oss.sgi.com; Sun, 20 May 2001 00:57:33 +0200 (MET DST)
Date: Sun, 20 May 2001 00:57:32 +0200
From: Ingo Paschke <ipaschke@tengu.escape.de>
To: linux-xfs@oss.sgi.com
Subject: Re: strange fsr messages...
Message-ID: <20010520005732.A23691@tengu.escape.de>
References: <20010519210325.A22401@tengu.escape.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010519210325.A22401@tengu.escape.de>; from ipaschke@tengu.escape.de on Sat, May 19, 2001 at 09:03:25PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

Hm, now I'm seeing that message on random processes... Afterwards, they're
stuck and can't be killed...

Anyway: Here's the backtrace I forgot to include in the previous mail:

Process xfs_fsr (pid: 1470, stackpage=c7323000)
Stack: c02a14e9 c02a1569 00000080 00000005 ca278440 c01db477 ca278440 cfe9d680 
       bfffd828 cfe84000 c01c586b c671f400 cfecd800 00000000 00000000 00000002 
       bfffd868 00000018 00000000 00000000 83ed41a1 3d1c37f6 0000000e 00000000 
Call Trace: [<c02a14e9>] [<c02a1569>] [<c01db477>] [<c01c586b>] [<c01dc5ad>] [<c01c586b>] [<c01c586b>] 
       [<c01790d4>] [<c01790d4>] [<c019b9c3>] [<c019242c>] [<c0192564>] [<c01079c6>] [<c01e8ac4>] [<c01e8b6c>] 
       [<c01079c6>] [<c01e8ac4>] [<c01e8b6c>] [<c01e9b80>] [<c021bd12>] [<c0220968>] [<d084be06>] [<c01dadef>] 
       [<c01c586b>] [<c01dadc0>] [<c01c586b>] [<c01402d7>] [<c01c586b>] [<c0108eeb>] [<c01c586b>] 
Code: 0f 0b 83 c4 0c 8d 76 00 ff 0b 0f 94 c0 84 c0 0f 84 35 01 00 

>>EIP; c0144178 <dput+28/180>   <=====
Trace; c02a14e9 <error_table+8945/f324>
Trace; c02a1569 <error_table+89c5/f324>
Trace; c01db477 <xfs_open_by_handle+277/2d0>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c01dc5ad <xfs_ioctl+bbd/f00>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c01790d4 <avl_remove+d4/f0>
Trace; c01790d4 <avl_remove+d4/f0>
Trace; c019b9c3 <xfs_bmbt_get_state+33/40>
Trace; c019242c <xfs_bmap_do_search_extents+2dc/3c0>
Trace; c0192564 <xfs_bmap_search_extents+54/60>
Trace; c01079c6 <__up+16/20>
Trace; c01e8ac4 <account_io_end+34/40>
Trace; c01e8b6c <req_finished_io+3c/50>
Trace; c01079c6 <__up+16/20>
Trace; c01e8ac4 <account_io_end+34/40>
Trace; c01e8b6c <req_finished_io+3c/50>
Trace; c01e9b80 <end_that_request_last+20/130>
Trace; c021bd12 <ide_end_request+52/60>
Trace; c0220968 <ide_dma_intr+68/a0>
Trace; d084be06 <[emu10k1]emu10k1_interrupt+66/80>
Trace; c01dadef <linvfs_ioctl+2f/40>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c01dadc0 <linvfs_ioctl+0/40>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c01402d7 <sys_ioctl+1f7/210>
Trace; c01c586b <xlog_do_recover+8b/100>
Trace; c0108eeb <system_call+33/38>
Trace; c01c586b <xlog_do_recover+8b/100>
Code;  c0144178 <dput+28/180>

Any ideas?

HTH,
Ingo.

From owner-linux-xfs@oss.sgi.com Sat May 19 19:58:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4K2wnG06176
	for linux-xfs-outgoing; Sat, 19 May 2001 19:58:49 -0700
Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4K2wlF06173
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 19:58:48 -0700
Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com
          (InterMail vM.4.01.02.00 201-229-116) with SMTP
          id <20010520025846.JUKR4073.mail.rdc1.tn.home.com@CX376762B>
          for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 19:58:46 -0700
Message-ID: <00d401c0e0d8$84915a50$98520c18@CX376762B>
Reply-To: "Tom Browder" <TBrowder@home.com>
From: "Tom Browder" <tbrowder@home.com>
To: <linux-xfs@oss.sgi.com>
Subject: RH 7.1 XFZ CD Image and LS-120
Date: Sat, 19 May 2001 21:56:50 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've successfully installed an XFS system using the
release 1 CD image, but the new devfs doesn't recognize my
LS-120 drive.

If anyone has any suggestions for this situation I would
appreciate
it (I tried turning off devfs during boot with
"devfs=nomount"
option to kernel but it didn't seem to work).

Thanks.

Tom Browder


From owner-linux-xfs@oss.sgi.com Sat May 19 20:38:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4K3csO06544
	for linux-xfs-outgoing; Sat, 19 May 2001 20:38:54 -0700
Received: from joshua.netcurrents.com (208.184.224.2.netcurrents.com [208.184.224.2] (may be forged))
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4K3crF06541
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 20:38:53 -0700
Received: from localhost (blauer@localhost)
	by joshua.netcurrents.com (8.11.0/8.9.1) with ESMTP id f4K3VEJ06239;
	Sat, 19 May 2001 20:31:14 -0700
Date: Sat, 19 May 2001 20:31:14 -0700 (PDT)
From: "Brian A. Lauer" <blauer@netcurrents.com>
To: tbrowder@home.com
cc: linux-xfs@oss.sgi.com
Subject: Re: RH 7.1 XFZ CD Image and LS-120
Message-ID: <Pine.LNX.4.21.0105192029270.5670-100000@joshua.netcurrents.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Does it show up in your dmesg?  I had a similar problem with a cdrom
drive, devfs would not create
the node under the appropriate /dev directory (ide or /dev/cdroms).  To
get around this, I simply issued
a mknod command for the proper major and minor number and it worked fine.

When you used devfs=nomount, it should have been accessible from
/dev/hd[a-d] depending on
which channel you had it installed on.  Hope that helps so you can at
least use the device.

Brian.


>>I've successfully installed an XFS system using the
>>release 1 CD image, but the new devfs doesn't recognize my
>>LS-120 drive.
>>
>>If anyone has any suggestions for this situation I would
>>appreciate
>>it (I tried turning off devfs during boot with
>>"devfs=nomount"
>>option to kernel but it didn't seem to work).
>>
>>Thanks.
-- 


From owner-linux-xfs@oss.sgi.com Sun May 20 03:25:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KAPJd12440
	for linux-xfs-outgoing; Sun, 20 May 2001 03:25:19 -0700
Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KAPIF12436
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 03:25:18 -0700
Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com
          (InterMail vM.4.01.02.00 201-229-116) with SMTP
          id <20010520102514.JVHM4073.mail.rdc1.tn.home.com@CX376762B>
          for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 03:25:14 -0700
Message-ID: <012b01c0e116$e31cf5f0$98520c18@CX376762B>
Reply-To: "Tom Browder" <TBrowder@home.com>
From: "Tom Browder" <tbrowder@home.com>
To: <linux-xfs@oss.sgi.com>
References: <200105200330.XAA00146@acorn.net>
Subject: Re: Re: RH 7.1 XFZ [sic] CD Image and LS-120
Date: Sun, 20 May 2001 05:23:17 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks, Brian:

I messed up, I do see the drive and it works fine.

Tom Browder

----- Original Message -----
From: "Brian A. Lauer" <aj416@acorn.net>
To: <tbrowder@home.com>
Cc: <linux-xfs@oss.sgi.com>
Sent: Saturday, May 19, 2001 10:30 PM
Subject: Re: RH 7.1 XFZ CD Image and LS-120


> Does it show up in your dmesg?  I had a similar problem
with a cdrom drive, devfs would not create
> the node under the appropriate /dev directory (ide or
/dev/cdroms).  To get around this, I simply issued
> a mknod command for the proper major and minor number and
it worked fine.
>
> When you used devfs=nomount, it should have been
accessible from /dev/hd[a-d] depending on
> which channel you had it installed on.  Hope that helps so
you can at least use the device.
>
> Brian.
>
>
> >>I've successfully installed an XFS system using the
> >>release 1 CD image, but the new devfs doesn't recognize
my
> >>LS-120 drive.
> >>
> >>If anyone has any suggestions for this situation I would
> >>appreciate
> >>it (I tried turning off devfs during boot with
> >>"devfs=nomount"
> >>option to kernel but it didn't seem to work).
> >>
> >>Thanks.
> --
>


From owner-linux-xfs@oss.sgi.com Sun May 20 03:44:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KAiNT12703
	for linux-xfs-outgoing; Sun, 20 May 2001 03:44:23 -0700
Received: from mail.rdc1.tn.home.com (imail@ha1.rdc1.tn.home.com [24.2.7.66])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KAiMF12700
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 03:44:22 -0700
Received: from CX376762B ([24.12.82.152]) by mail.rdc1.tn.home.com
          (InterMail vM.4.01.02.00 201-229-116) with SMTP
          id <20010520104421.JVIE4073.mail.rdc1.tn.home.com@CX376762B>
          for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 03:44:21 -0700
Message-ID: <001c01c0e119$8f1fecc0$98520c18@CX376762B>
Reply-To: "Tom Browder" <TBrowder@home.com>
From: "Tom Browder" <tbrowder@home.com>
To: <linux-xfs@oss.sgi.com>
References: <200105200330.XAA00146@acorn.net>
Subject: devfs and fstab
Date: Sun, 20 May 2001 05:42:25 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2462.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Devfs is brand new to me.  I just got used to using ext2
labels in
my fstab file and now devfs seems to not like them (although
everyting seems to get mounted OK).   A couple of questions:

What, exactly should be used to name a device in fstab when
using devfs?

And what is the relation, if any, between ext2 labels and
devfs?

Thanks.

Tom Browder


From owner-linux-xfs@oss.sgi.com Sun May 20 04:44:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KBiwp14239
	for linux-xfs-outgoing; Sun, 20 May 2001 04:44:58 -0700
Received: from sisa.i-manila.com.ph ([208.155.152.18])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4KBivF14235
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 04:44:57 -0700
Received: from kalapati ([203.167.2.133]) by sisa.i-manila.com.ph ; Sat, 19 May 2001 23:44:58 +0800 GMT
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 156F546A190
	for <linux-xfs@oss.sgi.com>; Sat, 19 May 2001 23:44:46 +0800 (PHT)
Date: Sat, 19 May 2001 23:44:46 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Daily XFS CVS snapshots?
Message-ID: <Pine.LNX.4.21.0105192341020.881-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I wonder if it would be possible to write a script so that we can have
daily snapshots of the XFS CVS development tree for download as compressed
patches (similar to the one we have for download at increments which seem
to be done manually when deemed necessary).

Why? I don't know about the rest of the list members, but I don't have
enough bandwidth to do CVS updates using CVS. It'll simply take too long.
I heard CVSup is a more efficient way of doing things, but I followed the
instructions in the XFS website and did a CVSup but found that it was
downloading a LOT of files too many. Why? I investigated and found it was
downloading every file in the tree with a ",v" appended at the end of the
filename. So again this fails for someone with as lean a connection to the
'Net as I do.

I hope those of you in a position to work on a daily XFS CVS snapshot
system will see the relevance of my plight (hehehe). Thanks a lot in
advance! :)

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sun May 20 06:29:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KDT7w15662
	for linux-xfs-outgoing; Sun, 20 May 2001 06:29:07 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4KDT4F15659
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 06:29:04 -0700
Received: (qmail 15973 invoked from network); 20 May 2001 13:29:00 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 20 May 2001 13:29:00 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Daily XFS CVS snapshots? 
In-reply-to: Your message of "Sat, 19 May 2001 23:44:46 +0800."
             <Pine.LNX.4.21.0105192341020.881-100000@kalapati.jijo.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 20 May 2001 23:28:59 +1000
Message-ID: <2599.990365339@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, 19 May 2001 23:44:46 +0800 (PHT), 
Federico Sevilla III <jijo@i-manila.com.ph> wrote:
>I heard CVSup is a more efficient way of doing things, but I followed the
>instructions in the XFS website and did a CVSup but found that it was
>downloading a LOT of files too many. Why? I investigated and found it was
>downloading every file in the tree with a ",v" appended at the end of the
>filename.

Those are the CVS history files for each source file.  If you are going
to use a CVS based system then you have to accept that download the
first time.  After that you only get the changes, either by cvs update
or CVSup.


From owner-linux-xfs@oss.sgi.com Sun May 20 06:31:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KDVVu15706
	for linux-xfs-outgoing; Sun, 20 May 2001 06:31:31 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4KDVTF15701
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 06:31:29 -0700
Received: (qmail 16002 invoked from network); 20 May 2001 13:31:27 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 20 May 2001 13:31:27 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Tom Browder" <TBrowder@home.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: devfs and fstab 
In-reply-to: Your message of "Sun, 20 May 2001 05:42:25 EST."
             <001c01c0e119$8f1fecc0$98520c18@CX376762B> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 20 May 2001 23:31:26 +1000
Message-ID: <2622.990365486@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 20 May 2001 05:42:25 -0500, 
"Tom Browder" <tbrowder@home.com> wrote:
>What, exactly should be used to name a device in fstab when
>using devfs?
>
>And what is the relation, if any, between ext2 labels and
>devfs?

While this is a legitimate question, you are asking in the wrong place.
Start at http://www.atnf.csiro.au/~rgooch/linux/docs/devfs.html and if
you still have questions about devfs, ask the author or on
linux-kernel.


From owner-linux-xfs@oss.sgi.com Sun May 20 06:41:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KDf7x15869
	for linux-xfs-outgoing; Sun, 20 May 2001 06:41:07 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KDf6F15863
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 06:41:06 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 0A8B51E0CD; Sun, 20 May 2001 15:41:06 +0200 (MEST)
Date: Sun, 20 May 2001 15:40:18 +0200
From: Andi Kleen <ak@suse.de>
To: Federico Sevilla III <jijo@i-manila.com.ph>
Cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Daily XFS CVS snapshots?
Message-ID: <20010520154018.A21713@gruyere.muc.suse.de>
References: <Pine.LNX.4.21.0105192341020.881-100000@kalapati.jijo.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0105192341020.881-100000@kalapati.jijo.local>; from jijo@i-manila.com.ph on Sat, May 19, 2001 at 11:44:46PM +0800
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, May 19, 2001 at 11:44:46PM +0800, Federico Sevilla III wrote:
> Why? I don't know about the rest of the list members, but I don't have
> enough bandwidth to do CVS updates using CVS. It'll simply take too long.

It only takes that long until your file modification dates are in sync with
CVS, i.e. usually one time only. After that a CVS update works pretty quick.

-Andi

From owner-linux-xfs@oss.sgi.com Sun May 20 07:05:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KE5JQ16160
	for linux-xfs-outgoing; Sun, 20 May 2001 07:05:19 -0700
Received: from ente.berdmann.de (p3E9E737D.dip.t-dialin.net [62.158.115.125])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KE5GF16157
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 07:05:16 -0700
Received: from ente.berdmann.de ([192.168.1.6] helo=berdmann.de)
	by ente.berdmann.de with esmtp (Exim 3.16 #2)
	id 151TpW-0000PE-00
	for linux-xfs@oss.sgi.com; Sun, 20 May 2001 16:05:10 +0200
Message-ID: <3B07CF14.2182D913@berdmann.de>
Date: Sun, 20 May 2001 16:05:08 +0200
From: "Bernhard R. Erdmann" <be@berdmann.de>
Organization: Bernhard Erdmann Communication & Network Solutions
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i586)
X-Accept-Language: de, en, fr
MIME-Version: 1.0
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: getbmapx 1 ino 955713 mode 0x000081b4 offset 0 failed: Inappropriate 
 ioctl for device
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

using linux-2.4-xfs (Kernel 2.4.4) from CVS (checkout yesterday) I get
strange warnings using xfsdump on my /var/spool/news: (all operations
are done on a fs mounted r/o)

# /usr/sbin/xfsdump -f /dumps/news/news.xfsd -J -L news -M m0 /dev/hdc6
/usr/sbin/xfsdump: version 3.0 - Running single-threaded
/usr/sbin/xfsdump: level 0 dump of ente:/var/spool/news
/usr/sbin/xfsdump: dump date: Sun May 20 15:50:53 2001
/usr/sbin/xfsdump: session id: b4d3e86c-96f1-422f-94f7-37e96a4c55ef
/usr/sbin/xfsdump: session label: "news"
/usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified)
/usr/sbin/xfsdump: ino map phase 2: constructing initial dump list
/usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary)
/usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2)
/usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream)
/usr/sbin/xfsdump: ino map construction complete
/usr/sbin/xfsdump: estimated dump size: 4459349760 bytes
/usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
/usr/sbin/xfsdump: dumping ino map
/usr/sbin/xfsdump: dumping directories
/usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
131: Not a directory
/usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
789: Not a directory
/usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
11456: Not a directory
/usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
42252: Not a directory
/usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
67213: Not a directory
[...]
/usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955713 mode 0x000081b4 offset
0 failed: Inappropriate ioctl for device
/usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955714 mode 0x000081b4 offset
0 failed: Inappropriate ioctl for device
/usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955715 mode 0x000081b4 offset
0 failed: Inappropriate ioctl for device
/usr/sbin/xfsdump: WARNING: getbmapx 1 ino 963144 mode 0x000081b4 offset
0 failed: Inappropriate ioctl for device
[...]

# /usr/sbin/xfs_ncheck -i 131 /dev/hdc6
        131 leaf.node/.
[root@ente news]# find . -inum 131 -ls
   131    4 drwxrwxr-x   2 news     news         4096 May 20 14:24
./leaf.node

# stat ./leaf.node
  File: "./leaf.node"
  Size: 4096         Filetype: Directory
  Mode: (0775/drwxrwxr-x)         Uid: (    9/    news)  Gid: (   13/   
news)
Device: 22,6   Inode: 131       Links: 2    
Access: Sun May 20 14:34:33 2001(00000.01:29:24)
Modify: Sun May 20 14:24:28 2001(00000.01:39:29)
Change: Sun May 20 14:24:28 2001(00000.01:39:29)

# /usr/sbin/xfs_ncheck -i 963144 /dev/hdc6
     963144 message.id/398/<9bhsc6$1ql4$1@stargate1.inet.it>
# find . -inum 963144 -ls
963144    4 -rw-rw-r--   2 news     news         1543 Apr 17 22:47
./message.id/398/<9bhsc6$1ql4$1@stargate1.inet.it>
963144    4 -rw-rw-r--   2 news     news         1543 Apr 17 22:47
./comp/os/linux/misc/101753

No output from xfs_check, so it's ok:
# /usr/sbin/xfs_check /dev/hdc6        

In contrast, when using linux-2.4-xfs-r1.0 (Kernel 2.4.2) none of these
warnings are printed.
These kernels have been compiled with egcs-1.1.2-24 (RH 6.1).

The xfs-fs /var/spool/news was populated from the former ext2-fs using
tar:
mkfs -t xfs /dev/hdc6
mount /dev/hdc6 /mnt/news && cd /mnt
(cd /var/spool && tar cf - news) | tar xpf -

From owner-linux-xfs@oss.sgi.com Sun May 20 07:37:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KEbBF16548
	for linux-xfs-outgoing; Sun, 20 May 2001 07:37:11 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KEbAF16544
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 07:37:10 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA290389
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 16:37:07 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1867477; Sun, 20 May 2001 09:35:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA74625; Sun, 20 May 2001 09:35:49 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4KEadr19400; Sun, 20 May 2001 09:36:39 -0500
Message-Id: <200105201436.f4KEadr19400@jen.americas.sgi.com>
To: "Bernhard R. Erdmann" <be@berdmann.de>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: getbmapx 1 ino 955713 mode 0x000081b4 offset 0 failed: Inappropriate ioctl for device 
References: <3B07CF14.2182D913@berdmann.de>
Comments: In-reply-to "Bernhard R. Erdmann" <be@berdmann.de>
   message dated "Sun, 20 May 2001 16:05:08 +0200."
Date: Sun, 20 May 2001 09:36:39 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


OK, I think I know what happened here, and I can replicate this.

Steve

> Hi,
> 
> using linux-2.4-xfs (Kernel 2.4.4) from CVS (checkout yesterday) I get
> strange warnings using xfsdump on my /var/spool/news: (all operations
> are done on a fs mounted r/o)
> 
> # /usr/sbin/xfsdump -f /dumps/news/news.xfsd -J -L news -M m0 /dev/hdc6
> /usr/sbin/xfsdump: version 3.0 - Running single-threaded
> /usr/sbin/xfsdump: level 0 dump of ente:/var/spool/news
> /usr/sbin/xfsdump: dump date: Sun May 20 15:50:53 2001
> /usr/sbin/xfsdump: session id: b4d3e86c-96f1-422f-94f7-37e96a4c55ef
> /usr/sbin/xfsdump: session label: "news"
> /usr/sbin/xfsdump: ino map phase 1: skipping (no subtrees specified)
> /usr/sbin/xfsdump: ino map phase 2: constructing initial dump list
> /usr/sbin/xfsdump: ino map phase 3: skipping (no pruning necessary)
> /usr/sbin/xfsdump: ino map phase 4: skipping (size estimated in phase 2)
> /usr/sbin/xfsdump: ino map phase 5: skipping (only one dump stream)
> /usr/sbin/xfsdump: ino map construction complete
> /usr/sbin/xfsdump: estimated dump size: 4459349760 bytes
> /usr/sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
> /usr/sbin/xfsdump: dumping ino map
> /usr/sbin/xfsdump: dumping directories
> /usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
> 131: Not a directory
> /usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
> 789: Not a directory
> /usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
> 11456: Not a directory
> /usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
> 42252: Not a directory
> /usr/sbin/xfsdump: WARNING: unable to read dirents (1) for directory ino
> 67213: Not a directory
> [...]
> /usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955713 mode 0x000081b4 offset
> 0 failed: Inappropriate ioctl for device
> /usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955714 mode 0x000081b4 offset
> 0 failed: Inappropriate ioctl for device
> /usr/sbin/xfsdump: WARNING: getbmapx 1 ino 955715 mode 0x000081b4 offset
> 0 failed: Inappropriate ioctl for device
> /usr/sbin/xfsdump: WARNING: getbmapx 1 ino 963144 mode 0x000081b4 offset
> 0 failed: Inappropriate ioctl for device
> [...]

From owner-linux-xfs@oss.sgi.com Sun May 20 07:55:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KEtBZ16776
	for linux-xfs-outgoing; Sun, 20 May 2001 07:55:11 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KEtAF16773
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 07:55:10 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA07435
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 07:55:09 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1879581; Sun, 20 May 2001 09:53:53 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA73510; Sun, 20 May 2001 09:53:53 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4KEsgk19449; Sun, 20 May 2001 09:54:42 -0500
Message-Id: <200105201454.f4KEsgk19449@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: erich@uruk.org
cc: linux-xfs@oss.sgi.com
Subject: Re: Problems with SMP version of XFS RH 7.1 installer 
In-Reply-To: Message from erich@uruk.org 
   of "Fri, 18 May 2001 15:34:02 PDT." <E150sos-0000nE-00@trillium-hollow.org> 
Date: Sun, 20 May 2001 09:54:42 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> First of all, great job, guys!  Even through all my SMP woes, I haven't
> lost data, and it's great not having it FSCK the 40GB XFS partition I
> have.  ;)
> 
> Symptom: try to ftp my 8.5GB tar file from another box to this one, it
> would always either:
> 
>   --  hang the network card, so no packets are transmitted anymore, and
>       occasional errors like "NETWORK TRANSMIT failure" would be in the
>       log.
>   --  hang the disk drive, but everything else including the network
>       is still responding.
>   --  occasionally, hang the whole machine.
> 
> I tried changing controller and network card types, presuming it might
> have been a driver problem, but no dice, identical results.
> 
> The overall result makes me think it's some kind of linux 2.4.2 SMP
> stability problem, but I'm not sure what other kernel w/XFS to try...
> 

If you do try the development cvs tree, please let us know if it fixes
you problem, also for general redhat 7.1 issues please look at this 
page for issues redhat has found:

http://www.redhat.com/support/docs/gotchas/7.1/gotchas-71.html

However, since your problems show up copying large amounts of data,
there is chance this is xfs chewing up all the memory on your machine
and not letting go for some reason.

Steve



From owner-linux-xfs@oss.sgi.com Sun May 20 08:39:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KFdoD17632
	for linux-xfs-outgoing; Sun, 20 May 2001 08:39:50 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KFdnF17629
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 08:39:49 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA00595
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 08:39:48 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1878852; Sun, 20 May 2001 10:35:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA95730; Sun, 20 May 2001 10:35:04 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4KFZrW19658; Sun, 20 May 2001 10:35:53 -0500
Message-Id: <200105201535.f4KFZrW19658@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Ingo Paschke <ipaschke@tengu.escape.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: strange fsr messages... 
In-Reply-To: Message from Ingo Paschke <ipaschke@tengu.escape.de> 
   of "Sun, 20 May 2001 00:57:32 +0200." <20010520005732.A23691@tengu.escape.de> 
Date: Sun, 20 May 2001 10:35:53 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Are you definitely using the released rpm and not the CVS development tree?
I just fixed a bug in open_by_handle which has been there about a week,
but only in the cvs tree. That bug could well have caused these problems.

Steve


> Hi!
> 
> Hm, now I'm seeing that message on random processes... Afterwards, they're
> stuck and can't be killed...
> 
> Anyway: Here's the backtrace I forgot to include in the previous mail:
> 
> Process xfs_fsr (pid: 1470, stackpage=c7323000)
> Stack: c02a14e9 c02a1569 00000080 00000005 ca278440 c01db477 ca278440 cfe9d68
> 0 
>        bfffd828 cfe84000 c01c586b c671f400 cfecd800 00000000 00000000 0000000
> 2 
>        bfffd868 00000018 00000000 00000000 83ed41a1 3d1c37f6 0000000e 0000000
> 0 
> Call Trace: [<c02a14e9>] [<c02a1569>] [<c01db477>] [<c01c586b>] [<c01dc5ad>] 
> [<c01c586b>] [<c01c586b>] 
>        [<c01790d4>] [<c01790d4>] [<c019b9c3>] [<c019242c>] [<c0192564>] [<c01
> 079c6>] [<c01e8ac4>] [<c01e8b6c>] 
>        [<c01079c6>] [<c01e8ac4>] [<c01e8b6c>] [<c01e9b80>] [<c021bd12>] [<c02
> 20968>] [<d084be06>] [<c01dadef>] 
>        [<c01c586b>] [<c01dadc0>] [<c01c586b>] [<c01402d7>] [<c01c586b>] [<c01
> 08eeb>] [<c01c586b>] 
> Code: 0f 0b 83 c4 0c 8d 76 00 ff 0b 0f 94 c0 84 c0 0f 84 35 01 00 
> 
> >>EIP; c0144178 <dput+28/180>   <=====
> Trace; c02a14e9 <error_table+8945/f324>
> Trace; c02a1569 <error_table+89c5/f324>
> Trace; c01db477 <xfs_open_by_handle+277/2d0>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c01dc5ad <xfs_ioctl+bbd/f00>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c01790d4 <avl_remove+d4/f0>
> Trace; c01790d4 <avl_remove+d4/f0>
> Trace; c019b9c3 <xfs_bmbt_get_state+33/40>
> Trace; c019242c <xfs_bmap_do_search_extents+2dc/3c0>
> Trace; c0192564 <xfs_bmap_search_extents+54/60>
> Trace; c01079c6 <__up+16/20>
> Trace; c01e8ac4 <account_io_end+34/40>
> Trace; c01e8b6c <req_finished_io+3c/50>
> Trace; c01079c6 <__up+16/20>
> Trace; c01e8ac4 <account_io_end+34/40>
> Trace; c01e8b6c <req_finished_io+3c/50>
> Trace; c01e9b80 <end_that_request_last+20/130>
> Trace; c021bd12 <ide_end_request+52/60>
> Trace; c0220968 <ide_dma_intr+68/a0>
> Trace; d084be06 <[emu10k1]emu10k1_interrupt+66/80>
> Trace; c01dadef <linvfs_ioctl+2f/40>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c01dadc0 <linvfs_ioctl+0/40>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c01402d7 <sys_ioctl+1f7/210>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Trace; c0108eeb <system_call+33/38>
> Trace; c01c586b <xlog_do_recover+8b/100>
> Code;  c0144178 <dput+28/180>
> 
> Any ideas?
> 
> HTH,
> Ingo.



From owner-linux-xfs@oss.sgi.com Sun May 20 10:48:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KHmdV20162
	for linux-xfs-outgoing; Sun, 20 May 2001 10:48:39 -0700
Received: from ente.berdmann.de (p3E9E737D.dip.t-dialin.net [62.158.115.125])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KHmbF20159
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 10:48:38 -0700
Received: from ente.berdmann.de ([192.168.1.6] helo=berdmann.de)
	by ente.berdmann.de with esmtp (Exim 3.16 #2)
	id 151XJe-0000N3-00; Sun, 20 May 2001 19:48:30 +0200
Message-ID: <3B08036D.404E171B@berdmann.de>
Date: Sun, 20 May 2001 19:48:29 +0200
From: "Bernhard R. Erdmann" <be@berdmann.de>
Organization: Bernhard Erdmann Communication & Network Solutions
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i586)
X-Accept-Language: de, en, fr
MIME-Version: 1.0
To: Steve Lord <lord@sgi.com>, Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: getbmapx 1 ino 955713 mode 0x000081b4 offset 0 failed: Inappropriate 
 ioctl for device
References: <3B07CF14.2182D913@berdmann.de> <200105201525.f4KFPb619598@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> A fix should show up in cvs within an hour - presuming the auto updates are
> working this weekend.

They are working and your fix helps:

--- /usr/src/linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c	Thu May 17
04:58:46 2001
+++ src/linux-2.4-xfs/linux/fs/xfs/linux/xfs_ioctl.c	Sun May 20 18:39:46
2001
@@ -346,6 +346,13 @@
 	inode = XFS_ITOV(ip)->v_inode;
 	xfs_iunlock(ip, XFS_ILOCK_SHARED);
 
+	linvfs_set_inode_ops(inode);
+	error = linvfs_revalidate_core(inode, ATTR_COMM);
+	if (error) {
+		iput(inode);
+		return -XFS_ERROR(error);
+	}
+
 	/*
 	 * Restrict handle operations to directories & regular files.
          */

From owner-linux-xfs@oss.sgi.com Sun May 20 11:46:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KIkeL20927
	for linux-xfs-outgoing; Sun, 20 May 2001 11:46:40 -0700
Received: from oker.escape.de (uucp@oker.escape.de [194.120.234.254])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KIkcF20924
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 11:46:38 -0700
Received: from tengu.escape.de (uucp@localhost)
	by oker.escape.de (8.11.3/8.11.3/$Revision: 1.26 $) with UUCP-tengu id f4KIkXj08419;
	Sun, 20 May 2001 20:46:33 +0200
Received: (from ipaschke@localhost)
	by zeno.tengu.escape.de (8.9.1/8.9.1) id UAA28125;
	Sun, 20 May 2001 20:44:43 +0200 (MET DST)
Date: Sun, 20 May 2001 20:44:43 +0200
From: Ingo Paschke <ipaschke@tengu.escape.de>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange fsr messages...
Message-ID: <20010520204443.A27711@tengu.escape.de>
References: <ipaschke@tengu.escape.de> <200105201535.f4KFZrW19658@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105201535.f4KFZrW19658@jen.americas.sgi.com>; from lord@sgi.com on Sun, May 20, 2001 at 10:35:53AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 20, 2001 at 10:35:53AM -0500, Steve Lord wrote:

> Are you definitely using the released rpm and not the CVS development tree?
> I just fixed a bug in open_by_handle which has been there about a week,
> but only in the cvs tree. That bug could well have caused these problems.

Yes, I'm running a self-compiled 1.0-release 2.4.2 kernel here with a fresh
install of Redhat-7.1/XFS.

But I just tried the supplied kernel with the same results:

[ipaschke@xlan ipaschke]$ uname -a
Linux xlan 2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i686 unknown

ipaschke@xlan ipaschke]$ ls -l /usr/sbin/xfs_fsr 
-rwxr-xr-x    1 root     root        34704 Apr 13 00:01 /usr/sbin/xfs_fsr

[ipaschke@xlan ipaschke]$ md5sum /usr/sbin/xfs_fsr 
6bcfc0fc888d6aedcd50accb401c71ff  /usr/sbin/xfs_fsr

[ipaschke@xlan ipaschke]$ df -k
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hde3             20343696   7506588  12837108  37% /           <- xfs
/dev/hde1               127351      8338    112438   7% /boot       <- ext2
/dev/hda2              3070400   2707340    363060  89% /mnt/hda2   <- vfat
/dev/hda5              8241264   7547504    693760  92% /mnt/hda5   <- vfat
/dev/hde6             23910460  22083756    612092  98% /mnt/space  <- ext2

[root@xlan /]# /usr/sbin/xfs_fsr -v
xfs_fsr -m /etc/mtab -t 7200 -f /var/tmp/.fsrlast_xfs ...
/ startino=0
ino=16777347
ino=16777347 already fully defragmented.
ino=16777349
ino=16777349 already fully defragmented.
ino=25625978
ino=25625978 already fully defragmented.
   [repeat 10 times...]
Completed all 10 passes

[root@xlan /]# dmesg | ksymoops

[...]
kernel BUG at dcache.c:128!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01450b8>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210282
eax: 0000001c   ebx: c3de38a0   ecx: c1737e60   edx: 00000007
esi: c3de38a0   edi: ffffffe6   ebp: c52f6000   esp: c52f7bcc
ds: 0018   es: 0018   ss: 0018
Process xfs_fsr (pid: 1559, stackpage=c52f7000)
Stack: c029011d c02901bd 00000080 00000005 c3de38a0 c01d34d7 c3de38a0 cfeb8060 
       bfffd828 c1483000 c01c586b cd428400 c14f5e00 00000000 00000000 00000002 
       bfffd868 00000018 00000000 00000000 83ed41a1 3d1c37f6 0000000e 00000000 
Call Trace: [<c029011d>] [<c02901bd>] [<c01d34d7>] [<c01c586b>] [<c01d45fd>] [<c01c586b>] [<c01c586b>] 
       [<c01b5b2d>] [<c01c5abb>] [<c029c649>] [<c01807a6>] [<c029c63c>] [<c029c63c>] [<c019564b>] [<c018c39c>] 
       [<c018c4c9>] [<c012cd75>] [<c012cd75>] [<c012216b>] [<c011d28c>] [<c011d39a>] [<c011d41c>] [<c01188b4>] 
       [<c011d685>] [<c011c2bb>] [<c0113638>] [<c01d2e93>] [<c01c586b>] [<c01d2e64>] [<c01c586b>] [<c0141387>] 
       [<c01c586b>] [<c0108eab>] [<c01c586b>] 
Code: 0f 0b 83 c4 0c 8d 76 00 ff 0b 0f 94 c0 84 c0 0f 84 35 01 00 

>>EIP; c01450b8 <dput+28/178>   <=====
Trace; c029011d <error_table+a801/b798>
Trace; c02901bd <error_table+a8a1/b798>
Trace; c01d34d7 <xfs_open_by_handle+273/2cc>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c01d45fd <xfs_ioctl+bb5/ef8>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c01b5b2d <xfs_inode_item_unpin+d/14>
Trace; c01c5abb <xfs_trans_chunk_committed+1a7/1dc>
Trace; c029c649 <dmattr_prefix+b2d/de0>
Trace; c01807a6 <xfs_attr_fetch+76/f0>
Trace; c029c63c <dmattr_prefix+b20/de0>
Trace; c029c63c <dmattr_prefix+b20/de0>
Trace; c019564b <xfs_bmbt_get_state+33/3c>
Trace; c018c39c <xfs_bmap_do_search_extents+2e0/3c0>
Trace; c018c4c9 <xfs_bmap_search_extents+4d/54>
Trace; c012cd75 <__alloc_pages+8d/2b0>
Trace; c012cd75 <__alloc_pages+8d/2b0>
Trace; c012216b <do_wp_page+3ab/3d8>
Trace; c011d28c <send_signal+2c/f0>
Trace; c011d39a <deliver_signal+4a/50>
Trace; c011d41c <send_sig_info+7c/a0>
Trace; c01188b4 <it_real_fn+0/48>
Trace; c011d685 <send_sig+1d/24>
Trace; c011c2bb <__run_timers+bb/ec>
Trace; c0113638 <schedule+2e0/438>
Trace; c01d2e93 <linvfs_ioctl+2f/3c>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c01d2e64 <linvfs_ioctl+0/3c>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c0141387 <sys_ioctl+1fb/214>
Trace; c01c586b <xfs_trans_cancel+97/98>
Trace; c0108eab <system_call+33/38>
Trace; c01c586b <xfs_trans_cancel+97/98>
Code;  c01450b8 <dput+28/178>
00000000 <_EIP>:
Code;  c01450b8 <dput+28/178>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c01450ba <dput+2a/178>
   2:   83 c4 0c                  add    $0xc,%esp
Code;  c01450bd <dput+2d/178>
   5:   8d 76 00                  lea    0x0(%esi),%esi
Code;  c01450c0 <dput+30/178>
   8:   ff 0b                     decl   (%ebx)
Code;  c01450c2 <dput+32/178>
   a:   0f 94 c0                  sete   %al
Code;  c01450c5 <dput+35/178>
   d:   84 c0                     test   %al,%al
Code;  c01450c7 <dput+37/178>
   f:   0f 84 35 01 00 00         je     14a <_EIP+0x14a> c0145202 <dput+172/178>

Ciao,
Ingo.

From owner-linux-xfs@oss.sgi.com Sun May 20 13:12:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4KKCuk22142
	for linux-xfs-outgoing; Sun, 20 May 2001 13:12:56 -0700
Received: from oker.escape.de (uucp@oker.escape.de [194.120.234.254])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4KKCtF22139
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 13:12:55 -0700
Received: from tengu.escape.de (uucp@localhost)
	by oker.escape.de (8.11.3/8.11.3/$Revision: 1.26 $) with UUCP-tengu id f4KKCoE14846;
	Sun, 20 May 2001 22:12:50 +0200
Received: (from ipaschke@localhost)
	by zeno.tengu.escape.de (8.9.1/8.9.1) id WAA28546;
	Sun, 20 May 2001 22:11:39 +0200 (MET DST)
Date: Sun, 20 May 2001 22:11:38 +0200
From: Ingo Paschke <ipaschke@tengu.escape.de>
To: Steve Lord <lord@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: strange fsr messages...
Message-ID: <20010520221138.A28530@tengu.escape.de>
References: <ipaschke@tengu.escape.de> <200105201535.f4KFZrW19658@jen.americas.sgi.com> <20010520204443.A27711@tengu.escape.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010520204443.A27711@tengu.escape.de>; from ipaschke@tengu.escape.de on Sun, May 20, 2001 at 08:44:43PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I just tried the newest kernel and xfsdump from the CVS-tree: It seems to work
just fine now. Now I can run fsr without any kernel or fsr-error-messages.

If you'd like to investigate the 1.0-problem, I'll be glad to help anyway...

Thanks again,
Ingo.

From owner-linux-xfs@oss.sgi.com Sun May 20 17:42:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L0gkb26118
	for linux-xfs-outgoing; Sun, 20 May 2001 17:42:46 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4L0gjF26115
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 17:42:45 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA02993
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 17:53:43 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA21586
	for linux-xfs@oss.sgi.com; Mon, 21 May 2001 10:41:25 +1000 (EST)
Date: Mon, 21 May 2001 10:41:25 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105210041.KAA21586@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - xfsrestore + ea/acl man pages
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Sun May 20 17:35:02 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95514a
cmd/xfsdump/restore/content.c - 1.8
	- fixes a qa-found problem - we were only restoring user quota
	  dump file, not the group quota file.


Date:  Sun May 20 17:39:09 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95515a
cmd/attr/man/man3/attr_set.3 - 1.2
cmd/attr/VERSION - 1.4
cmd/attr/debian/changelog - 1.3
cmd/attr/doc/CHANGES - 1.4
cmd/attr/man/man3/attr_remove.3 - 1.2
cmd/attr/man/man3/attr_get.3 - 1.2
cmd/attr/man/man3/attr_list.3 - 1.2
cmd/attr/man/man3/attr_multi.3 - 1.2
cmd/acl/man/man3/acl_get_file.3 - 1.2
cmd/acl/man/man3/acl_size.3 - 1.2
cmd/acl/man/man3/acl_get_fd.3 - 1.2
cmd/acl/man/man3/acl_from_text.3 - 1.2
cmd/acl/man/man3/acl_free.3 - 1.2
cmd/acl/man/man3/acl_dup.3 - 1.2
cmd/acl/man/man3/acl_delete_def_file.3 - 1.2
cmd/acl/man/man3/acl_valid.3 - 1.2
cmd/acl/man/man3/acl_copy_ext.3 - 1.2
cmd/acl/man/man2/acl_set.2 - 1.2
cmd/acl/man/man2/acl_get.2 - 1.2
cmd/acl/VERSION - 1.3
cmd/acl/debian/changelog - 1.2
cmd/acl/doc/CHANGES - 1.3
	- correct the include file location in each man page.



From owner-linux-xfs@oss.sgi.com Sun May 20 22:18:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L5I7q32193
	for linux-xfs-outgoing; Sun, 20 May 2001 22:18:07 -0700
Received: from web10406.mail.yahoo.com (web10406.mail.yahoo.com [216.136.130.98])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4L5I7F32190
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 22:18:07 -0700
Message-ID: <20010521051806.83102.qmail@web10406.mail.yahoo.com>
Received: from [66.25.21.14] by web10406.mail.yahoo.com; Sun, 20 May 2001 22:18:06 PDT
Date: Sun, 20 May 2001 22:18:06 -0700 (PDT)
From: John <jsh_45@yahoo.com>
Subject: lilo -R
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello people,

I've been trying to convert my root file system  I got
everything copied to the xfs partitions but lilo is
giving me fits.

What I've done so far.  I have two drives partitioned
the same way, hda and hdc.  My linux install resides
on hda on ext2 and I have formated hdc with xfs.  I
mounted the XFS disk under /mnt and did <find / -mount
-print | cpio -pdm /mnt>.  Same goes for /boot and
/var (so I have all my data on the xfs disk).  I then
went to clean up the fstab @ /mnt/etc/fstab.  OK all
is good till I try to run <lilo -R /mnt> (reports
there is no image at /mnt).  Is there a way to cp the
MBR from hda to hdc?  Any ideas of what I should do to
finish this?


Best Regards,

John Herrington

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Sun May 20 23:37:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L6bnv01028
	for linux-xfs-outgoing; Sun, 20 May 2001 23:37:49 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4L6bmF01025
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 23:37:48 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id XAA01460
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 23:37:46 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27391; Mon, 21 May 2001 16:36:26 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: John <jsh_45@yahoo.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: lilo -R 
In-reply-to: Your message of "Sun, 20 May 2001 22:18:06 MST."
             <20010521051806.83102.qmail@web10406.mail.yahoo.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 May 2001 16:36:26 +1000
Message-ID: <1190.990426986@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 20 May 2001 22:18:06 -0700 (PDT), 
John <jsh_45@yahoo.com> wrote:
>What I've done so far.  I have two drives partitioned
>the same way, hda and hdc.  My linux install resides
>on hda on ext2 and I have formated hdc with xfs.  I
>mounted the XFS disk under /mnt and did <find / -mount
>-print | cpio -pdm /mnt>.  Same goes for /boot and
>/var (so I have all my data on the xfs disk).  I then
>went to clean up the fstab @ /mnt/etc/fstab.  OK all
>is good till I try to run <lilo -R /mnt> (reports
>there is no image at /mnt).  Is there a way to cp the
>MBR from hda to hdc?  Any ideas of what I should do to
>finish this?

lilo -R selects an existing (installed) image, you have to run lilo
normally first to create the MBR and boot map.  Edit lilo.conf to set

  boot=/dev/hdc
  root=/dev/hdc<n>

then run

  ROOT=/mnt lilo -C /mnt/etc/lilo.conf

That will write the lilo MBR to hdc, using the specification in the hdc
version of lilo.conf and the boot files from /mnt/boot.

How are you going to boot from hdc, by telling the bios to use hdc or
by moving hdc to be the first disk (hdc -> hda)?  If you boot from hdc
by using the bios then you need to tell lilo where the boot disk was,
by adding these lines to lilo.conf.

disk=/dev/hdc
  bios=0x80

If you move hdc to become hda then you should be able to boot lilo from
the new hda, without the bios=0x80 setting.  You will almost certainly
have to specify a root=/dev/hda<n> parameter because lilo will have
installed using a root from hdc.  After booting successfully, edit
lilo.conf to set boot=/dev/hda and root=current then rerun lilo.


From owner-linux-xfs@oss.sgi.com Sun May 20 23:55:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L6tRJ01255
	for linux-xfs-outgoing; Sun, 20 May 2001 23:55:27 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4L6tQF01250
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 23:55:26 -0700
Received: (qmail 10913 invoked by uid 0); 21 May 2001 06:55:24 -0000
Received: from adsl-3-165.adsl.easynet.fr (HELO mail.gmx.de) (212.11.27.165)
  by mail.gmx.net (mp002-rz3) with SMTP; 21 May 2001 06:55:24 -0000
Message-ID: <200105210854310202.0D1AE6F7@mail.gmx.de>
In-Reply-To: <20010521051806.83102.qmail@web10406.mail.yahoo.com>
References: <20010521051806.83102.qmail@web10406.mail.yahoo.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Mon, 21 May 2001 08:54:31 +0200
From: "linux" <dahouet@gmx.net>
To: "John" <jsh_45@yahoo.com>, linux-xfs@oss.sgi.com
Subject: Re: lilo -R
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4L6tRF01253
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Le 20/05/2001 à 22:18 John a écrit :

>is good till I try to run <lilo -R /mnt> (reports
>there is no image at /mnt).  Is there a way to cp the
>MBR from hda to hdc?  Any ideas of what I should do to
>finish this?

yes 
i think there is an little error on the web page
you should better type : lilo -r /mnt
and it will work fine

@++
nico


From owner-linux-xfs@oss.sgi.com Mon May 21 01:32:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L8WpQ02917
	for linux-xfs-outgoing; Mon, 21 May 2001 01:32:51 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4L8WmF02914
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 01:32:49 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP id 3DC521E0FB
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 10:32:48 +0200 (MEST)
Date: Mon, 21 May 2001 10:31:57 +0200
From: Andi Kleen <ak@suse.de>
To: linux-xfs@oss.sgi.com
Subject: SLAB_PAGE_IO and highmem
Message-ID: <20010521103157.A914@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


SLAB_PAGE_IO has __GFP_HIGHMEM set. Some functions in fs/pagebuf/*.c
directly use it to allocate from a slab cache and 
afterwards access it directly without ever calling kmap.  This works by
chance when there was no highmem page allocated, but not otherwise.
Here is a patch.

-Andi

--- include/linux/slab.h-o	Fri May 18 18:32:49 2001
+++ include/linux/slab.h	Mon May 21 10:38:27 2001
@@ -21,7 +21,7 @@
 #define	SLAB_KERNEL		GFP_KERNEL
 #define	SLAB_NFS		GFP_NFS
 #define	SLAB_DMA		GFP_DMA
-#define SLAB_PAGE_IO		GFP_PAGE_IO
+#define SLAB_PAGE_IO		(GFP_PAGE_IO & ~(__GFP_HIGH))
 
 #define SLAB_LEVEL_MASK		(__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_PAGE_IO)
 #define	SLAB_NO_GROW		0x00001000UL	/* don't grow a cache */


From owner-linux-xfs@oss.sgi.com Mon May 21 02:28:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4L9SED03941
	for linux-xfs-outgoing; Mon, 21 May 2001 02:28:14 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4L9SEF03938
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 02:28:14 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA25665
	for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 08:20:29 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1880866 for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 10:20:39 -0500 (CDT)
Received: from laptop.americas.sgi.com (lord-h1.americas.sgi.com [206.11.101.42]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA77048 for <linux-xfs@oss.sgi.com>; Sun, 20 May 2001 10:20:38 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by laptop.americas.sgi.com (8.11.2/SGI-client-1.7) id f4KFIIZ01193; Sun, 20 May 2001 10:18:18 -0500
Message-Id: <200105201518.f4KFIIZ01193@laptop.americas.sgi.com>
Date: Sun, 20 May 2001 10:18:18 -0500
Subject: TAKE - fix open by handle for xfsdump
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Looks like our test cases didn't catch this one, a recent change to
the open by handle code used by xfsdump was not setting up the
inodes correctly when they were being initialized on this path.
The tests create a set of files to dump just before the dump -
which made this code unneccesary.

Date:  Sun May 20 08:18:20 PDT 2001
Workarea:  lord-h1.americas.sgi.com:/src/lord/xfs-linux-2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95500a
linux/fs/xfs/linux/xfs_ioctl.c - 1.38
	- Fix xfsdump - open by handle was not setting inode ops correctly after
	  the previous change.



From owner-linux-xfs@oss.sgi.com Mon May 21 03:00:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LA0OR04493
	for linux-xfs-outgoing; Mon, 21 May 2001 03:00:24 -0700
Received: from fsnif.neuroinformatik.ruhr-uni-bochum.de (fsnif.neuroinformatik.ruhr-uni-bochum.de [134.147.176.16])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LA0MF04489
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 03:00:23 -0700
Received: from berlin (berlin.zn.ruhr-uni-bochum.de [134.147.254.1])
	by fsnif.neuroinformatik.ruhr-uni-bochum.de (8.11.2/8.11.2) with SMTP id f4LA0Jl20374
	for <@fsnif.neuroinformatik.ruhr-uni-bochum.de:linux-xfs@oss.sgi.com>; Mon, 21 May 2001 12:00:19 +0200 (MEST)
Received: from zn-ag.com (cognac [134.147.254.148]) by berlin (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA05035 for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 11:57:54 +0200
Message-ID: <3B08E551.CAF9A28E@zn-ag.com>
Date: Mon, 21 May 2001 11:52:17 +0200
From: Matthias Schwartz <matthias.schwartz@zn-ag.com>
Organization: ZN Vision Technologies AG
X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.0-4GB i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: XFS with Samba-2.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

just a few questions about the xfs filesystem for linux.

o Do I have to except problems with xfs when using samba-2.2 ?
o What's the max. filesize ?
o Is it possible to boot from a xfs filesystem ?


   Thank you very much !


      Matthias Schwartz


-- 
____________________________________________________________________

  Dipl.-Ing. Matthias Schwartz    mailto:matthias.schwartz@zn-ag.com
  Manager                         Tel.: +49 / 234 / 9787-67
  Research & Development          Fax.: +49 / 234 / 9787-77
  ZN Vision Technologies AG		
  Universitaetsstrasse 160        http://www.visiomed.de
  44801 Bochum Germany            http://www.zn-ag.com
____________________________________________________________________

From owner-linux-xfs@oss.sgi.com Mon May 21 07:28:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LESwO10899
	for linux-xfs-outgoing; Mon, 21 May 2001 07:28:58 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LESvF10896
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 07:28:57 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4LEQdw17621;
	Mon, 21 May 2001 09:26:39 -0500 (CDT)
Message-ID: <3B09262B.216DE511@sgi.com>
Date: Mon, 21 May 2001 09:28:59 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux <dahouet@gmx.net>
CC: John <jsh_45@yahoo.com>, linux-xfs@oss.sgi.com
Subject: Re: lilo -R
References: <20010521051806.83102.qmail@web10406.mail.yahoo.com> <200105210854310202.0D1AE6F7@mail.gmx.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux wrote:
 
> yes
> i think there is an little error on the web page
> you should better type : lilo -r /mnt
> and it will work fine

oops!  Thanks, I updated this.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 21 07:42:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LEgiX11174
	for linux-xfs-outgoing; Mon, 21 May 2001 07:42:44 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LEghF11171
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 07:42:43 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA02524
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 07:53:43 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1889830; Mon, 21 May 2001 09:41:24 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA82820; Mon, 21 May 2001 09:41:24 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4LEic401602; Mon, 21 May 2001 09:44:38 -0500
Message-Id: <200105211444.f4LEic401602@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Ingo Paschke <ipaschke@tengu.escape.de>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: strange fsr messages... 
In-Reply-To: Message from Ingo Paschke <ipaschke@tengu.escape.de> 
   of "Sun, 20 May 2001 22:11:38 +0200." <20010520221138.A28530@tengu.escape.de> 
Date: Mon, 21 May 2001 09:44:38 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi!
> 
> I just tried the newest kernel and xfsdump from the CVS-tree: It seems to wor
> k
> just fine now. Now I can run fsr without any kernel or fsr-error-messages.
> 
> If you'd like to investigate the 1.0-problem, I'll be glad to help anyway...
> 
> Thanks again,
> Ingo.

If you want, try the fs/xfs/linux/xfs_ioctl.c file from the cvs tree in
the 1.0 tree. You will need to delete the XFS_IOC_FREEZE and XFS_IOC_THAW
cases from the case statement in xfs_ioctl, but you can keep the rest of
the code.

If I am correct, this will fix the problem in 1.0, but there again, I only
spent 2 minutes thinking about this, so maybe not.

Steve



From owner-linux-xfs@oss.sgi.com Mon May 21 07:50:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LEo6911311
	for linux-xfs-outgoing; Mon, 21 May 2001 07:50:06 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LEo6F11308
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 07:50:06 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP id 201CD1E1D5
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 16:50:05 +0200 (MEST)
Date: Mon, 21 May 2001 16:49:14 +0200
From: Andi Kleen <ak@suse.de>
To: linux-xfs@oss.sgi.com
Subject: XFS_IOC_SET_RESBLKS and quota
Message-ID: <20010521164914.A9376@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


The interaction between XFS_IOC_SET_RESBLKS and quotas seems to be very 
strange. It doesn't check the current user quota when allowing reserves
(so you can set arbitarily high values), but when you try to write to the
reserved file after the big reservation it doesn't allow any writes even
when the user is really not out of quota.


-Andi



From owner-linux-xfs@oss.sgi.com Mon May 21 08:10:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFAS011862
	for linux-xfs-outgoing; Mon, 21 May 2001 08:10:28 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFAPF11859
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:10:25 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA406685
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:10:22 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1886523; Mon, 21 May 2001 10:09:03 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA85677; Mon, 21 May 2001 10:09:03 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4LFCHi01994; Mon, 21 May 2001 10:12:17 -0500
Message-Id: <200105211512.f4LFCHi01994@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Andi Kleen <ak@suse.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS_IOC_SET_RESBLKS and quota 
In-Reply-To: Message from Andi Kleen <ak@suse.de> 
   of "Mon, 21 May 2001 16:49:14 +0200." <20010521164914.A9376@gruyere.muc.suse.de> 
Date: Mon, 21 May 2001 10:12:17 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> The interaction between XFS_IOC_SET_RESBLKS and quotas seems to be very 
> strange. It doesn't check the current user quota when allowing reserves
> (so you can set arbitarily high values), but when you try to write to the
> reserved file after the big reservation it doesn't allow any writes even
> when the user is really not out of quota.
> 
> 
> -Andi
> 

Hmmm, that call looks like it needs some more security on it, it was
added for data migration (dmapi), and has nothing to do with actual file data.
Basically data migration has a problem in that it needs to be able to
migrate a file out to tape from a completely full filesystem, moving
the data involves writing an extended attribute to say where it has
gone, and this can require space. So this call was added to steal some
space from the superblock and it is only supposed to be used for a
special user space application. I think it needs at least this added
to it:

                if (!capable(CAP_SYS_ADMIN))
                        return -EPERM;

Steve



From owner-linux-xfs@oss.sgi.com Mon May 21 08:12:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFC9f11955
	for linux-xfs-outgoing; Mon, 21 May 2001 08:12:09 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFC7F11946
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:12:07 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4LFC1T13754
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:12:01 -0700
Date: Mon, 21 May 2001 08:12:01 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: linux-xfs@oss.sgi.com
Subject: Memory issues again
Message-ID: <Pine.LNX.4.21.0105210800220.12990-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello again,

I seem to be having memory problems again.  Removing the debug from the
kernel help alot, it slowed down the loss of memory.  I still topped out
at about 190MB used though, which is way more than this machine should
use.  I just updated from CVS last night an built a new kernel, same
config, and booted it this morning, and within about 7 minutes, it jumped
to 132MB, and held there.  If no one else is having trouble like this,
i'll start looking into applications...but i wanted to check here
first.  My servers info is at www.linuxboxen.org/phpSysInfo

Thanks

Dana


From owner-linux-xfs@oss.sgi.com Mon May 21 08:22:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFMOh12286
	for linux-xfs-outgoing; Mon, 21 May 2001 08:22:24 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFMNF12281
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:22:23 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id B372F1E1E9; Mon, 21 May 2001 17:22:22 +0200 (MEST)
Date: Mon, 21 May 2001 17:21:36 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: Andi Kleen <ak@suse.de>, linux-xfs@oss.sgi.com
Subject: Re: XFS_IOC_SET_RESBLKS and quota
Message-ID: <20010521172136.A9957@gruyere.muc.suse.de>
References: <ak@suse.de> <200105211512.f4LFCHi01994@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105211512.f4LFCHi01994@jen.americas.sgi.com>; from lord@sgi.com on Mon, May 21, 2001 at 10:12:17AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 21, 2001 at 10:12:17AM -0500, Steve Lord wrote:
> Hmmm, that call looks like it needs some more security on it, it was
> added for data migration (dmapi), and has nothing to do with actual file data.
> Basically data migration has a problem in that it needs to be able to
> migrate a file out to tape from a completely full filesystem, moving
> the data involves writing an extended attribute to say where it has
> gone, and this can require space. So this call was added to steal some
> space from the superblock and it is only supposed to be used for a
> special user space application. I think it needs at least this added
> to it:
> 
>                 if (!capable(CAP_SYS_ADMIN))
>                         return -EPERM;

Thanks for the clarification (although I guess a CAP_DMAPI would be better)

-Andi

From owner-linux-xfs@oss.sgi.com Mon May 21 08:44:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFi0712672
	for linux-xfs-outgoing; Mon, 21 May 2001 08:44:00 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFhwF12669
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:43:59 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA401508
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:43:56 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1859413; Mon, 21 May 2001 10:42:38 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA33362; Mon, 21 May 2001 10:42:38 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4LFjq502041; Mon, 21 May 2001 10:45:52 -0500
Message-Id: <200105211545.f4LFjq502041@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dana Soward <dragon@thegoop.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory issues again 
In-Reply-To: Message from Dana Soward <dragon@thegoop.com> 
   of "Mon, 21 May 2001 08:12:01 PDT." <Pine.LNX.4.21.0105210800220.12990-100000@daffy.thegoop.com> 
Date: Mon, 21 May 2001 10:45:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hello again,
> 
> I seem to be having memory problems again.  Removing the debug from the
> kernel help alot, it slowed down the loss of memory.  I still topped out
> at about 190MB used though, which is way more than this machine should
> use.  I just updated from CVS last night an built a new kernel, same
> config, and booted it this morning, and within about 7 minutes, it jumped
> to 132MB, and held there.  If no one else is having trouble like this,
> i'll start looking into applications...but i wanted to check here
> first.  My servers info is at www.linuxboxen.org/phpSysInfo
> 
> Thanks
> 
> Dana

Can you send the output of 

	cat /proc/slabinfo

when you hit this case.

Thanks

    Steve




From owner-linux-xfs@oss.sgi.com Mon May 21 08:53:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFrHF12922
	for linux-xfs-outgoing; Mon, 21 May 2001 08:53:17 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFrGF12919
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:53:16 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4LFrAq13868;
	Mon, 21 May 2001 08:53:10 -0700
Date: Mon, 21 May 2001 08:53:09 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory issues again 
In-Reply-To: <200105211545.f4LFjq502041@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105210851450.12990-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

cat /proc/slabinfo:

slabinfo - version: 1.1
kmem_cache            74     78    100    2    2    1
xfs_dqtrx              0     80    192    0    4    1
xfs_dquots            34     44    348    4    4    1
tcp_tw_bucket          1     30    128    1    1    1
tcp_bind_bucket       10    113     32    1    1    1
tcp_open_request       0     40     96    0    1    1
inet_peer_cache        0      0     64    0    0    1
ip_fib_hash            9    113     32    1    1    1
ip_dst_cache           7     24    160    1    1    1
arp_cache              2     30    128    1    1    1
xfs_chashlist       3285   3434     16   17   17    1
xfs_ili              245    252    136    9    9    1
xfs_ifork              0      0     56    0    0    1
xfs_efi_item           0     15    260    0    1    1
xfs_efd_item           0     15    260    0    1    1
xfs_buf_item           0    104    148    0    4    1
xfs_dabuf              0    202     16    0    1    1
xfs_da_state           0     11    340    0    1    1
xfs_trans              0     84    320    0    7    1
xfs_inode          95643  95688    468 11961 11961    1
xfs_btree_cur          0     28    140    0    1    1
xfs_bmap_free_item      0    202     16    0    1    1
page_buf_t            24    680    192    2   34    1
page_buf_reg_t         5     40     96    1    1    1
avl_object_t           5    113     32    1    1    1
avl_entry_t            4    678     32    1    6    1
nfs_read_data          0      0    384    0    0    1
nfs_write_data         0      0    384    0    0    1
nfs_page               0      0     96    0    0    1
blkdev_requests     3072   3840     96   77   96    1
dnotify cache          0      0     20    0    0    1
file lock cache        1     42     92    1    1    1
fasync cache           0      0     16    0    0    1
uid_cache              4    113     32    1    1    1
skbuff_head_cache     84     96    160    4    4    1
sock                  23     36    928    8    9    1
inode_cache        96527  96536    480 12067 12067    1
bdev_cache          3290   3304     64   56   56    1
sigqueue               0     29    132    0    1    1
dentry_cache       97531  97560    128 3252 3252    1
dquot                  0      0     96    0    0    1
filp                 374    400     96   10   10    1
names_cache            0      3   4096    0    3    1
buffer_head         8305   8400     96  208  210    1
mm_struct             33     60    128    2    2    1
vm_area_struct      1760   1888     64   30   32    1
fs_cache              32     59     64    1    1    1
files_cache           32     36    416    4    4    1
signal_act            35     39   1312   12   13    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072            0      1 131072    0    1   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536            11     11  65536   11   11   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             0      1  32768    0    1    8
size-16384(DMA)        0      0  16384    0    0    4
size-16384             4      5  16384    4    5    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192              1      1   8192    1    1    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096             37     38   4096   37   38    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048             74     92   2048   38   46    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             41     44   1024   11   11    1
size-512(DMA)          0      0    512    0    0    1
size-512             317    328    512   40   41    1
size-256(DMA)          0      0    256    0    0    1
size-256             674    690    256   45   46    1
size-128(DMA)          0      0    128    0    0    1
size-128            3244   3270    128  109  109    1
size-64(DMA)           0      0     64    0    0    1
size-64             8162   8201     64  139  139    1
size-32(DMA)           0      0     32    0    0    1
size-32            32888  32996     32  292  292    1

Thanks

Dana

On Mon, 21 May 2001, Steve Lord wrote:

> > Hello again,
> > 
> > I seem to be having memory problems again.  Removing the debug from the
> > kernel help alot, it slowed down the loss of memory.  I still topped out
> > at about 190MB used though, which is way more than this machine should
> > use.  I just updated from CVS last night an built a new kernel, same
> > config, and booted it this morning, and within about 7 minutes, it jumped
> > to 132MB, and held there.  If no one else is having trouble like this,
> > i'll start looking into applications...but i wanted to check here
> > first.  My servers info is at www.linuxboxen.org/phpSysInfo
> > 
> > Thanks
> > 
> > Dana
> 
> Can you send the output of 
> 
> 	cat /proc/slabinfo
> 
> when you hit this case.
> 
> Thanks
> 
>     Steve
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Mon May 21 08:55:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LFtrt13009
	for linux-xfs-outgoing; Mon, 21 May 2001 08:55:53 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LFtrF13006
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 08:55:53 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4LFtqv16390
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 10:55:52 -0500 (CDT)
Message-ID: <3B093B15.DC540D2F@sgi.com>
Date: Mon, 21 May 2001 10:58:13 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - minor code cleanup in xfs_iget_core
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 21 08:53:42 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

This doesn't fix anything, but it makes the logic in xfs_iget_core a
little easier to follow.  :)

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95571a
linux/fs/xfs/xfs_iget.c - 1.141
        - Minor code cleanup - no fix, just easier to read


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 21 09:03:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LG3Og13728
	for linux-xfs-outgoing; Mon, 21 May 2001 09:03:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LG3OF13686
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 09:03:24 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA02635
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 09:03:14 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1887508; Mon, 21 May 2001 11:01:56 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA48818; Mon, 21 May 2001 11:01:56 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4LG59t02659; Mon, 21 May 2001 11:05:09 -0500
Message-Id: <200105211605.f4LG59t02659@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Dana Soward <dragon@thegoop.com>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Memory issues again 
In-Reply-To: Message from Dana Soward <dragon@thegoop.com> 
   of "Mon, 21 May 2001 08:53:09 PDT." <Pine.LNX.4.21.0105210851450.12990-100000@daffy.thegoop.com> 
Date: Mon, 21 May 2001 11:05:09 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


You have 98 Mbytes chewed up in inode caches, I just happen to be looking into
problems in this area at the moment. XFS is not releasing inodes in the
same manner as other filesystems. Try this patch and let me know what
happens.

Steve


===========================================================================
Index: linux/fs/xfs/xfs_vnodeops.c
===========================================================================

--- /usr/tmp/TmpDir.2645-0/linux/fs/xfs/xfs_vnodeops.c_1.502	Mon May 21 11:00:44 2001
+++ linux/fs/xfs/xfs_vnodeops.c	Mon May 21 10:50:35 2001
@@ -5133,6 +5133,10 @@
 	vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip));
 	mrunlock(&ih->ih_lock);
 
+	if (!ip->i_update_core && (ip->i_itemp == NULL)) {
+		return xfs_finish_reclaim(ip, locked);
+	}
+
 	if (locked) {
 		xfs_ifunlock(ip);
 		xfs_iunlock(ip, XFS_ILOCK_EXCL);




From owner-linux-xfs@oss.sgi.com Mon May 21 09:11:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LGBFg14153
	for linux-xfs-outgoing; Mon, 21 May 2001 09:11:15 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LGBFF14150
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 09:11:15 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 58E2D1E1E9; Mon, 21 May 2001 18:11:14 +0200 (MEST)
Date: Mon, 21 May 2001 18:10:27 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: Dana Soward <dragon@thegoop.com>, linux-xfs@oss.sgi.com
Subject: Re: Memory issues again
Message-ID: <20010521181027.A10660@gruyere.muc.suse.de>
References: <dragon@thegoop.com> <200105211605.f4LG59t02659@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105211605.f4LG59t02659@jen.americas.sgi.com>; from lord@sgi.com on Mon, May 21, 2001 at 11:05:09AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 21, 2001 at 11:05:09AM -0500, Steve Lord wrote:
> 
> You have 98 Mbytes chewed up in inode caches, I just happen to be looking into
> problems in this area at the moment. XFS is not releasing inodes in the
> same manner as other filesystems. Try this patch and let me know what
> happens.

This problem has been also observed in non XFS 2.4 kernels, so it is at least
somewhat generic. Inode/dcache expire is not aggressive enough.  What is strange
is that the dcache slab has about the same size as the inode slab, the standard
2.4 inode fragmentation "leak" mostly consists of the inodes with no dentry.

-Andi

From owner-linux-xfs@oss.sgi.com Mon May 21 10:47:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LHl5V16914
	for linux-xfs-outgoing; Mon, 21 May 2001 10:47:05 -0700
Received: from daffy.thegoop.com (root@daffy.thegoop.com [206.58.79.242])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LHl4F16911
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 10:47:04 -0700
Received: from localhost (dragon@localhost)
	by daffy.thegoop.com (8.10.2/8.10.2) with ESMTP id f4LHkqn14128;
	Mon, 21 May 2001 10:46:52 -0700
Date: Mon, 21 May 2001 10:46:52 -0700 (PDT)
From: Dana Soward <dragon@thegoop.com>
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory issues again 
In-Reply-To: <200105211605.f4LG59t02659@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105211045350.12990-100000@daffy.thegoop.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That seems to have done it.  Its been up for 40 mins and is holding at
about 26MB used. I'll let you know if it's the same tomorrow. Thanks a
bunch!  You guys are doing a bang up job with this, its awesome.

Dana

On Mon, 21 May 2001, Steve Lord wrote:

> 
> You have 98 Mbytes chewed up in inode caches, I just happen to be looking into
> problems in this area at the moment. XFS is not releasing inodes in the
> same manner as other filesystems. Try this patch and let me know what
> happens.
> 
> Steve
> 
> 
> ===========================================================================
> Index: linux/fs/xfs/xfs_vnodeops.c
> ===========================================================================
> 
> --- /usr/tmp/TmpDir.2645-0/linux/fs/xfs/xfs_vnodeops.c_1.502	Mon May 21 11:00:44 2001
> +++ linux/fs/xfs/xfs_vnodeops.c	Mon May 21 10:50:35 2001
> @@ -5133,6 +5133,10 @@
>  	vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip));
>  	mrunlock(&ih->ih_lock);
>  
> +	if (!ip->i_update_core && (ip->i_itemp == NULL)) {
> +		return xfs_finish_reclaim(ip, locked);
> +	}
> +
>  	if (locked) {
>  		xfs_ifunlock(ip);
>  		xfs_iunlock(ip, XFS_ILOCK_EXCL);
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Mon May 21 11:26:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LIQvF17690
	for linux-xfs-outgoing; Mon, 21 May 2001 11:26:57 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LIQsF17687
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 11:26:54 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA07909
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 11:37:54 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA72392; Mon, 21 May 2001 13:25:37 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4LIOXw25915;
	Mon, 21 May 2001 14:24:37 -0400
Message-ID: <3B095D60.89D2E87A@thebarn.com>
Date: Mon, 21 May 2001 14:24:32 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Swartzendruber <dswartz@druber.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Feedback
References: <200105211802.f4LI2MD17193@oss.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dan Swartzendruber wrote:

> This message was sent from http://linux-xfs.sgi.com/projects/xfs/
>
> ----
>
> I just installed Mandrake 8.0 using the XFS Cooker ISO image from thebarn.com.  All went well except for two glitches:
>
> 1. Although the kernel installed by the
>    CDROM supports XFS, the CDROM itself
>    doesn't \(in rescue mode, I mean\).
>    This makes one of my favorite things
>    unusable \(using the CDROM that way\).

type modprobe xfs from the rescue shell... that will
load the xfs modules into the kernel.

and xfs capable kernel is to big to fit on a floppy as such
the xfs modules are part of the second stage located on the CD.

>
>
> 2. More serious: the grub installed by
>    this CDROM doesn't support XFS!  The
>    way this seems to manifest is that
>    even if you specify GRUB during the
>    'install bootloader' phase, it will
>    install lilo.  If you later try to
>    install grub, it tells you that
>    partitition X has an unsupported
>    filesystem type.

Yes grub does not support XFS yet (somebody from the
grub camp has started work on it) you must
use lilo at this time if your kernel is on an xfs partition.

Note one option if grub is mandatory is to make /boot ext2 and the rest of the
system xfs.



--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May 21 14:05:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LL5tN20315
	for linux-xfs-outgoing; Mon, 21 May 2001 14:05:55 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LL5rF20312
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 14:05:53 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA427538
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 23:05:50 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA96945; Mon, 21 May 2001 16:04:34 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4LL3Xw26358;
	Mon, 21 May 2001 17:03:33 -0400
Message-ID: <3B0982A2.D15F0FE@thebarn.com>
Date: Mon, 21 May 2001 17:03:31 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>, lcooker@mandrake.com,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Mandrake installer
References: <8C91B010B3B7994C88A266E1A72184D3C88FFF@cceexc19.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Venables, Michael" wrote:

> I passed XFS Mandrake off to a couple of people here and happened to be
> around when they hit the same package install problems I did. The specific
> error was "bad package, unable to be installed" but I noticed that they
> begin on disk 2--so you're off the hook. Figured you'd want to know before
> you wasted any time.
>

Ok quick caveat here, I have not spend a lot of time making sure everything
is perfectly polished
So I'm nor sure the iso build script did the right thing in regards to which
package is on which
CD. I think the original mandrake 8.0 disc 2 and 3 should work when selecting
packages from
them, but I have not tested that so I'm not sure.
If need be I can put the disc 2 and 3 iso's that I generated on the ftp site.

I'm hoping the Mandrake folks will eventually help out with cleaning up these
details,
but for the moment all I have to time to do is make sure the basic install
works.

BTW yes the mkinitrd is failing... seems it is trying to be smart and include
any
file systems that are not ext2 as a module.
Since xfs is compiled into the kernel mkinitrd can not find the module and
exits.
The Q&D fix is to go in and comment out the exit at line 100 in mkinitrd and
rerun the cmd by hand.


>  michael

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May 21 14:49:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LLn5X21289
	for linux-xfs-outgoing; Mon, 21 May 2001 14:49:05 -0700
Received: from cairn-gorm.cragtech.com (mail.connex.com [216.100.236.3])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LLn4F21286
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 14:49:04 -0700
Received: by cairn-gorm.cragtech.com with Internet Mail Service (5.5.2650.21)
	id <KG97QBGM>; Mon, 21 May 2001 14:47:57 -0700
Message-ID: <B14BF8753E65D211ABCA00104B301EF501C02B92@cairn-gorm.cragtech.com>
From: Dale Stephenson <Steph@Connex.com>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Cc: "'linux-lvm@sistina.com'" <linux-lvm@sistina.com>
Subject: LVM writeable snapshot patch for use with XFS
Date: Mon, 21 May 2001 14:47:50 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Here is a replacement for the writeable snapshot patch I posted earlier to
these lists.  Its intended use is for changing the UUID on an XFS snapshot
so the snapshot can be mounted at the same time as the original.  This patch
is for beta 7 (the one I posted last week was beta 3) and doesn't have a bug
the earlier patch did.

A patch for lvchange follows the lvm.c patch, as snapshots are still created
read-only and must be changed to writable through lvchange.  This patch is
against an older version, but still cleanly applies to beta7 for me.

Dale J. Stephenson
Software Engineer
Connex, A Western Digital Company
steph@connex.com

--- linux/drivers/md/lvm.c.orig	Fri May 18 19:04:30 2001
+++ linux/drivers/md/lvm.c	Fri May 18 19:30:44 2001
@@ -1120,8 +1120,8 @@
 	ulong pe_start;
 	ulong size = bh->b_size >> 9;
 	ulong rsector_org = bh->b_rsector;
-	ulong rsector_map;
-	kdev_t rdev_map;
+	ulong rsector_map, rsector_sav;
+	kdev_t rdev_map, rdev_sav;
 	vg_t *vg_this = vg[VG_BLK(minor)];
 	lv_t *lv = vg_this->lv[LV_BLK(minor)];
 
@@ -1228,12 +1228,42 @@
 		goto out;
 
 	if (lv->lv_access & LV_SNAPSHOT) { /* remap snapshot */
-		if (lv->lv_block_exception)
+	  if (lv->lv_block_exception) {
+		  if (rw == WRITE || rw == WRITEA) {
+ 		    /* Start of writeable snapshot portion */
+ 		    rdev_sav = rdev_map;
+ 		    rsector_sav = rsector_map;
+ 
+ 		    if (!lvm_snapshot_remap_block(&rdev_map,
+						  &rsector_map,
+						  pe_start,
+						  lv)) {
+		      /* create a new mapping */
+		      if (lvm_snapshot_COW(rdev_map,
+					   rsector_map,
+					   pe_start,
+					   rsector_sav,
+					   vg_this,lv)) {
+			goto bad;
+		      }
+		      lvm_write_COW_table_block(vg_this,lv);
+		      rdev_map = rdev_sav;
+		      rsector_map = rsector_sav;
+		      if (!lvm_snapshot_remap_block(&rdev_map,
+						    &rsector_map,
+						    pe_start,
+						    lv)) {
+			goto bad;
+		      }
+		    }
+		    /* End of writable snapshot portion */
+		  }
+		  else
 			lvm_snapshot_remap_block(&rdev_map, &rsector_map,
 						 pe_start, lv);
-		else
+	  }
+	  else
 			goto bad;
-
 	} else if(rw == WRITE || rw == WRITEA) { /* snapshot origin */
 		lv_t *snap;
 
--- LVM_0_9/tools/lvchange.c.orig	Thu Dec 14 11:29:30 2000
+++ LVM_0_9/tools/lvchange.c	Thu Dec 14 11:36:16 2000
@@ -329,7 +330,8 @@
          continue;
       }
    
-      if ( lv->lv_access & LV_SNAPSHOT) {
+      if ( ( lv->lv_access & LV_SNAPSHOT) &&
+           ( (opt_C) || (opt_a) || (opt_r))) {
          fprintf ( stderr, "%s -- change on snapshot logical "
                            "volume \"%s\" not allowed\n", cmd, lv_name);
          continue;
@@ -370,7 +372,12 @@
    
          if ( doit > 0) {
             doit_sum++;
-            lv->lv_access = lv_access;
+            /* don't clear access flags except for LV_WRITE and LV_READ */
+            if (lv->lv_access & LV_WRITE)
+               lv->lv_access -= LV_WRITE;
+            if (lv->lv_access & LV_READ)
+               lv->lv_access -= LV_READ;
+            lv->lv_access |= lv_access;
             if ( opt_v > 0) printf ( "%s -- changing access permissions "
                                      "of logical volume \"%s\"\n",
                                      cmd, lv_name);


From owner-linux-xfs@oss.sgi.com Mon May 21 15:26:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LMQLP21908
	for linux-xfs-outgoing; Mon, 21 May 2001 15:26:21 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMQLF21905
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 15:26:21 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id 263EA108A; Mon, 21 May 2001 15:28:01 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id 66DB2E7D; Mon, 21 May 2001 15:28:01 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFT106Y>; Mon, 21 May 2001 17:26:13 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C89014@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: Russell Cattelan <cattelan@thebarn.com>, lcooker@mandrake.com,
   linux-xfs@oss.sgi.com
Subject: RE: Mandrake installer
Date: Mon, 21 May 2001 17:25:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Russell - 

Some of this is aimed more at the MDK guys, but since you CCed them, they'll
pick up the thread.

If it's not too much of a hassle, you might put discs 2 & 3 up. The copy of
disc 2 I have came from one of our internal ftp sites, and there seems to be
something wrong a bunch of the packages on it. I haven't seen disc 3 on any
of the sites I've visited.

Have you given any thought to building against the 2.4.4 kernel? From what
I've been told by one of our kernel hackers, it holds up much better on the
sort of meatgrinder tests that we'd like to stress test XFS under.

I've never had to do anything from the installer shell for Mandrake, and I
was sort of surprised that they use something other than bash. Didn't take
the time to look, but whatever it is, works hard against you doing any sort
of useful CLI work. Unlike RH, there's no mouse support or autofill.

Additionally, I was completely unable to run mkinitrd. The permissions are
fine, but for some reason, it won't execute. If you've got any theories...

More X config problems. Have a machine with a FireGL 4000. That card does
not appear in the list of supported video controllers. Also... is there no
option to function test an X configuration?


-----Original Message-----
From: Russell Cattelan [mailto:cattelan@thebarn.com]
Sent: Monday, May 21, 2001 4:04 PM
To: Venables, Michael; lcooker@mandrake.com; linux-xfs@oss.sgi.com
Subject: Re: Mandrake installer


"Venables, Michael" wrote:

> I passed XFS Mandrake off to a couple of people here and happened to be
> around when they hit the same package install problems I did. The specific
> error was "bad package, unable to be installed" but I noticed that they
> begin on disk 2--so you're off the hook. Figured you'd want to know before
> you wasted any time.
>

Ok quick caveat here, I have not spend a lot of time making sure everything
is perfectly polished
So I'm nor sure the iso build script did the right thing in regards to which
package is on which
CD. I think the original mandrake 8.0 disc 2 and 3 should work when
selecting
packages from
them, but I have not tested that so I'm not sure.
If need be I can put the disc 2 and 3 iso's that I generated on the ftp
site.

I'm hoping the Mandrake folks will eventually help out with cleaning up
these
details,
but for the moment all I have to time to do is make sure the basic install
works.

BTW yes the mkinitrd is failing... seems it is trying to be smart and
include
any
file systems that are not ext2 as a module.
Since xfs is compiled into the kernel mkinitrd can not find the module and
exits.
The Q&D fix is to go in and comment out the exit at line 100 in mkinitrd and
rerun the cmd by hand.


>  michael

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.



From owner-linux-xfs@oss.sgi.com Mon May 21 15:27:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LMRsc21926
	for linux-xfs-outgoing; Mon, 21 May 2001 15:27:54 -0700
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LMRpF21923
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 15:27:51 -0700
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id D726BBFF; Mon, 21 May 2001 15:29:32 -0700 (PDT)
Received: from exchou-gh03.cca.cpqcorp.net (exchou-gh03.cca.cpqcorp.net [16.110.248.203])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP id 46315CE5
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 15:29:32 -0700 (PDT)
Received: by exchou-gh03.cca.cpqcorp.net with Internet Mail Service (5.5.2652.78)
	id <KRFT100S>; Mon, 21 May 2001 17:27:44 -0500
Message-ID: <8C91B010B3B7994C88A266E1A72184D3C89015@cceexc19.americas.cpqcorp.net>
From: "Venables, Michael" <Michael.Venables@compaq.com>
To: linux-xfs@oss.sgi.com
Subject: XFS on Itanium
Date: Mon, 21 May 2001 17:27:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Has anyone tried to get XFS to compile and run on Itanium? Ever hear of
anyone doing that sort of testing?



Michael J. Venables
Compaq Competitive Analysis
Industry Standard Server Group

Of course I use Microsoft. Setting up a stable
UNIX network is no challenge at all...



From owner-linux-xfs@oss.sgi.com Mon May 21 16:24:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4LNOYp23965
	for linux-xfs-outgoing; Mon, 21 May 2001 16:24:34 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4LNOBF23858
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 16:24:11 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id BAA440977
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 01:24:07 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA1896260; Mon, 21 May 2001 18:22:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA19131; Mon, 21 May 2001 18:22:49 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4LNPxK06576; Mon, 21 May 2001 18:25:59 -0500
Message-Id: <200105212325.f4LNPxK06576@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Venables, Michael" <Michael.Venables@compaq.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS on Itanium 
In-Reply-To: Message from "Venables, Michael" <Michael.Venables@compaq.com> 
   of "Mon, 21 May 2001 17:27:27 CDT." <8C91B010B3B7994C88A266E1A72184D3C89015@cceexc19.americas.cpqcorp.net> 
Date: Mon, 21 May 2001 18:25:59 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> Has anyone tried to get XFS to compile and run on Itanium? Ever hear of
> anyone doing that sort of testing?


Urm, we are. If you know all the correct magic incantations and have the
correct patches for Itanium then XFS works just fine. The one restriction
which we are working on is that filesystem block size must equal the
pagesize of the hardware you are running on.

Steve

> 
> 
> 
> Michael J. Venables
> Compaq Competitive Analysis
> Industry Standard Server Group
> 
> Of course I use Microsoft. Setting up a stable
> UNIX network is no challenge at all...
> 



From owner-linux-xfs@oss.sgi.com Mon May 21 17:04:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M04Zu24887
	for linux-xfs-outgoing; Mon, 21 May 2001 17:04:35 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M04TF24879
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:04:31 -0700
Received: [from blizbor (blizbor.ima.pl [195.117.13.88])
                               by ima.pl with SMTP id f4M047210519
                               for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 02:04:07 +0200]
Message-ID: <005b01c0e252$af837ec0$020010ac@ima.pl>
From: "Blizbor (i)" <tb670725@ima.pl>
To: <linux-xfs@oss.sgi.com>
Subject: Mount option 'noexec' seems not working (Maybe 'nodev' also)
Date: Tue, 22 May 2001 02:03:52 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2417.2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I have noticed that very usefull mount option 'noexec' have no meaning
for XFS. Am I wrong ? (Probably same for option 'nodev').
If no, could I ask when it will be implemented ?

(For security reasons I doesnt allow for execution of files from /home /var
/tmp
filesystems, so for me lack of this option is a big problem. I know that
there are
workarounds, bu I know also that number of peoples knowing how to do this
is very small, so 'noexec, nodev' are usefull security tool.)

Regards,
Blizbor


From owner-linux-xfs@oss.sgi.com Mon May 21 17:27:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M0R6o25202
	for linux-xfs-outgoing; Mon, 21 May 2001 17:27:06 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M0QwF25199
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:26:59 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA446507
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 02:26:56 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA1894807; Mon, 21 May 2001 19:25:38 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA78581; Mon, 21 May 2001 19:25:38 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4M0Sld06710; Mon, 21 May 2001 19:28:47 -0500
Message-Id: <200105220028.f4M0Sld06710@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Blizbor (i)" <tb670725@ima.pl>
cc: linux-xfs@oss.sgi.com
Subject: Re: Mount option 'noexec' seems not working (Maybe 'nodev' also) 
In-Reply-To: Message from "Blizbor (i)" <tb670725@ima.pl> 
   of "Tue, 22 May 2001 02:03:52 +0200." <005b01c0e252$af837ec0$020010ac@ima.pl> 
Date: Mon, 21 May 2001 19:28:47 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> I have noticed that very usefull mount option 'noexec' have no meaning
> for XFS. Am I wrong ? (Probably same for option 'nodev').
> If no, could I ask when it will be implemented ?
> 
> (For security reasons I doesnt allow for execution of files from /home /var
> /tmp
> filesystems, so for me lack of this option is a big problem. I know that
> there are
> workarounds, bu I know also that number of peoples knowing how to do this
> is very small, so 'noexec, nodev' are usefull security tool.)
> 
> Regards,
> Blizbor

Try the CVS tree, it appears to work there:

[root@lord /]# mount -o noexec /dev/sda5 /xfs
[root@lord /]# cd /xfs
[root@lord /xfs]# ls
client.txt  lord  NBSIMULD  redhat  tmp
[root@lord /xfs]# cp /bin/ls .
[root@lord /xfs]# ls -l
total 4076
-rw-r--r--    1 root     root      4119297 May 19 09:32 client.txt
drwxr-xr-x    3 lord     root           16 May 21 10:04 lord
-rwxr-xr-x    1 root     root        45724 May 21 18:20 ls
drwx------    3 root     root         4096 May 19 09:37 NBSIMULD
drwxr-xr-x    7 root     root           67 May 21 15:30 redhat
drwxr-xr-x    2 root     root            6 May 21 17:33 tmp
[root@lord /xfs]# ./ls
bash: ./ls: Permission denied
[root@lord /xfs]# 

Steve



From owner-linux-xfs@oss.sgi.com Mon May 21 17:47:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M0l7w25478
	for linux-xfs-outgoing; Mon, 21 May 2001 17:47:07 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M0l6F25475
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:47:06 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA09980
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:47:05 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id TAA1896354 for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 19:45:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA46646 for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 19:45:49 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4M0mxS06868; Mon, 21 May 2001 19:48:59 -0500
Message-Id: <200105220048.f4M0mxS06868@jen.americas.sgi.com>
Date: Mon, 21 May 2001 19:48:59 -0500
Subject: TAKE - close up access to two ioctl calls
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

These are not generic calls, they are for dmapi user space only.

Date:  Mon May 21 17:45:00 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95628a
linux/fs/xfs/linux/xfs_ioctl.c - 1.39
	- Restrict access to XFS_IOC_SET_RESBLKS and XFS_IOC_GET_RESBLKS, these
	  are not intended for general consumption.



From owner-linux-xfs@oss.sgi.com Mon May 21 17:57:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M0vlx25609
	for linux-xfs-outgoing; Mon, 21 May 2001 17:57:47 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M0vYF25604
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:57:34 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA06043
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 17:57:12 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA82863; Mon, 21 May 2001 19:55:56 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4M0stw17609;
	Mon, 21 May 2001 20:54:56 -0400
Message-ID: <3B09B8DE.A751F34D@thebarn.com>
Date: Mon, 21 May 2001 20:54:54 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>
CC: cooker@mandrake.com, linux-xfs@oss.sgi.com
Subject: Re: Mandrake installer
References: <8C91B010B3B7994C88A266E1A72184D3C89014@cceexc19.americas.cpqcorp.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Venables, Michael" wrote:

> Russell -
>
> Some of this is aimed more at the MDK guys, but since you CCed them, they'll
> pick up the thread.
>
> If it's not too much of a hassle, you might put discs 2 & 3 up. The copy of
> disc 2 I have came from one of our internal ftp sites, and there seems to be
> something wrong a bunch of the packages on it. I haven't seen disc 3 on any
> of the sites I've visited.

Ok will do, I'm remaking everything right now with a patched version of
mkinitrd.
Your best bet will be to use rysnc to "update" your disc1 iso, should  very
little change
from the original.


>
>
> Have you given any thought to building against the 2.4.4 kernel? From what
> I've been told by one of our kernel hackers, it holds up much better on the
> sort of meatgrinder tests that we'd like to stress test XFS under.

Ok like I said I don't have bunched time right now, so...
I'll do one kernel, which one is more important right now?
2.4.3.whatever or the latest 2.4.4 in cooker.

Note any 2.4.4 version will most likely be TOT from the development tree, as
that is very close to what will be going into  XFS 1.0.1.


>
>
> I've never had to do anything from the installer shell for Mandrake, and I
> was sort of surprised that they use something other than bash. Didn't take
> the time to look, but whatever it is, works hard against you doing any sort
> of useful CLI work. Unlike RH, there's no mouse support or autofill.
>
> Additionally, I was completely unable to run mkinitrd. The permissions are
> fine, but for some reason, it won't execute. If you've got any theories...
>
> More X config problems. Have a machine with a FireGL 4000. That card does
> not appear in the list of supported video controllers. Also... is there no
> option to function test an X configuration?
>
> -----Original Message-----
> From: Russell Cattelan [mailto:cattelan@thebarn.com]
> Sent: Monday, May 21, 2001 4:04 PM
> To: Venables, Michael; lcooker@mandrake.com; linux-xfs@oss.sgi.com
> Subject: Re: Mandrake installer
>
> "Venables, Michael" wrote:
>
> > I passed XFS Mandrake off to a couple of people here and happened to be
> > around when they hit the same package install problems I did. The specific
> > error was "bad package, unable to be installed" but I noticed that they
> > begin on disk 2--so you're off the hook. Figured you'd want to know before
> > you wasted any time.
> >
>
> Ok quick caveat here, I have not spend a lot of time making sure everything
> is perfectly polished
> So I'm nor sure the iso build script did the right thing in regards to which
> package is on which
> CD. I think the original mandrake 8.0 disc 2 and 3 should work when
> selecting
> packages from
> them, but I have not tested that so I'm not sure.
> If need be I can put the disc 2 and 3 iso's that I generated on the ftp
> site.
>
> I'm hoping the Mandrake folks will eventually help out with cleaning up
> these
> details,
> but for the moment all I have to time to do is make sure the basic install
> works.
>
> BTW yes the mkinitrd is failing... seems it is trying to be smart and
> include
> any
> file systems that are not ext2 as a module.
> Since xfs is compiled into the kernel mkinitrd can not find the module and
> exits.
> The Q&D fix is to go in and comment out the exit at line 100 in mkinitrd and
> rerun the cmd by hand.
>
> >  michael
>
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Mon May 21 20:06:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M36ZK27626
	for linux-xfs-outgoing; Mon, 21 May 2001 20:06:35 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M36YF27623
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 20:06:34 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id UAA18284
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 20:05:08 -0700 (PDT)
	mail_from (kaos@ocs.com.au)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA04537 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:05:16 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@ocs.com.au>
To: linux-xfs@oss.sgi.com
Subject: New XFS, ReiserFS and Ext2 benchmarks (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 22 May 2001 13:05:16 +1000
Message-ID: <4795.990500716@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


------- Forwarded Message

From:	"Ricardo Galli" <gallir@uib.es>
To:	<linux-kernel@vger.kernel.org>
Cc:	<timothy@monkey.org>, <reiser@namesys.com>,
	"Guillem Cantallops Ramis" <guillem@cantallops.net>
Subject: New XFS, ReiserFS and Ext2 benchmarks
Date:	Tue, 22 May 2001 04:41:06 +0200
Message-ID: <LOEGIBFACGNBNCDJMJMOKEADCJAA.gallir@uib.es>

Hi,
	you can find at http://bulma.lug.net/static/ a few new benchmarks among
Reiser, XFS and Ext2 (also one with JFS).

This time there is a comprehensive Hans' Mongo benchmarks
(http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and
read/write/fsync operations tests (I was very careful of populating the
cache before the measures for the last two cases).

Regards,

- --ricardo
http://m3d.uib.es/~gallir/


------- End of Forwarded Message



From owner-linux-xfs@oss.sgi.com Mon May 21 20:22:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M3MV927902
	for linux-xfs-outgoing; Mon, 21 May 2001 20:22:31 -0700
Received: from web10404.mail.yahoo.com (web10404.mail.yahoo.com [216.136.130.96])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4M3MUF27899
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 20:22:30 -0700
Message-ID: <20010522032230.15566.qmail@web10404.mail.yahoo.com>
Received: from [66.25.21.14] by web10404.mail.yahoo.com; Mon, 21 May 2001 20:22:30 PDT
Date: Mon, 21 May 2001 20:22:30 -0700 (PDT)
From: John <jsh_45@yahoo.com>
Subject: Re: lilo -R 
To: Keith Owens <kaos@melbourne.sgi.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <1190.990426986@kao2.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is starting to get to me.  I "thought" that
pulling the /dev/hdc drives cable and putting it on
the first ide controller would be the easy thing to
do, but that has been elusive.  I've tried almost
every combination of boot= and root= and I get one of
two results.  One nothing, no LI no failed boot
attempt pleas insert boot disk, just hangs with no
message.  The other is LI 01 01 01 01 01 01 01
01...(repeating on the screen till I kill the power). 
I tried a boot disk but it tried to mount everything
as ext2 partitions (ro cause of errors) and then
mounted hdc under /mnt (and there wasn't even a hdc,
hdc should have been hda cause it was on the first
controller).  

I thought I had a good idea and replaced the kernel on
the debian rescue disk (added XFS support).  The
rescue disk boots to a initial ram disk, but it's ro
(/dev/root on / ext2 ro).  I was going to try to mount
the XFS drive after I put it on the first ide
controller (hda) but can I mount hda5 at / then mount
hda1 at /boot and hda7 at /var or do I have to
approach this another way.

Now if I can do this I would think that I should edit
the lilo.conf for root=hda5 and boot=hda and run lilo.



Thanks for all the help guys,

John Herrington

--- Keith Owens <kaos@melbourne.sgi.com> wrote:
> lilo -R selects an existing (installed) image, you
> have to run lilo
> normally first to create the MBR and boot map.  Edit
> lilo.conf to set
> 
>   boot=/dev/hdc
>   root=/dev/hdc<n>
> 
> then run
> 
>   ROOT=/mnt lilo -C /mnt/etc/lilo.conf
> 
> That will write the lilo MBR to hdc, using the
> specification in the hdc
> version of lilo.conf and the boot files from
> /mnt/boot.
> 
> How are you going to boot from hdc, by telling the
> bios to use hdc or
> by moving hdc to be the first disk (hdc -> hda)?  If
> you boot from hdc
> by using the bios then you need to tell lilo where
> the boot disk was,
> by adding these lines to lilo.conf.
> 
> disk=/dev/hdc
>   bios=0x80
> 
> If you move hdc to become hda then you should be
> able to boot lilo from
> the new hda, without the bios=0x80 setting.  You
> will almost certainly
> have to specify a root=/dev/hda<n> parameter because
> lilo will have
> installed using a root from hdc.  After booting
> successfully, edit
> lilo.conf to set boot=/dev/hda and root=current then
> rerun lilo.


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Mon May 21 23:09:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M69h830106
	for linux-xfs-outgoing; Mon, 21 May 2001 23:09:43 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M69gF30103
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 23:09:42 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id XAA02609
	for <linux-xfs@oss.sgi.com>; Mon, 21 May 2001 23:20:41 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA53023
	for linux-xfs@oss.sgi.com; Tue, 22 May 2001 16:08:21 +1000 (EST)
Date: Tue, 22 May 2001 16:08:21 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105220608.QAA53023@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - qa
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Mon May 21 21:50:41 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95642a
cmd/xfstests/src/feature.c - 1.3
	- add a check to see whether systems userspace (libc/fileutils)
	  supports chown of >2^16 uid/gid.

cmd/xfstests/054 - 1.2
	- don't attempt to run this test on systems where userspace
	  (libc/fileutils) doesn't support chown of >2^16 uid/gid.


Date:  Mon May 21 23:07:23 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95653a
cmd/xfstests/046.ugquota - 1.1
	- 046 output with user + group quota enabled.

cmd/xfstests/026.grpquota - 1.1
	- 026 output with group quota enabled.

cmd/xfstests/026.ugquota - 1.1
	- 026 output with user + group quota enabled.

cmd/xfstests/026.usrquota - 1.1
	- 026 output with user quota enabled.

cmd/xfstests/027.grpquota - 1.1
	- 027 output with group quota enabled.

cmd/xfstests/027.ugquota - 1.1
	- 027 output with user + group quota enabled.

cmd/xfstests/027.usrquota - 1.1
	- 027 output with user quota enabled.

cmd/xfstests/046.grpquota - 1.1
	- 046 output with group quota enabled.

cmd/xfstests/056.usrquota - 1.1
	- 056 output with user quota enabled.

cmd/xfstests/046.usrquota - 1.1
	- 046 output with user quota enabled.

cmd/xfstests/056.grpquota - 1.1
	- 056 output with group quota enabled.

cmd/xfstests/056.ugquota - 1.1
	- 056 output with user + group quota enabled.

cmd/xfstests/018 - 1.6
cmd/xfstests/common.rc - 1.10
cmd/xfstests/common.dump - 1.8
	- abstract out multiple quota .seq files into a shared common routine.

cmd/xfstests/check - 1.2
	- fix a typo.


From owner-linux-xfs@oss.sgi.com Tue May 22 00:22:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M7MKp31117
	for linux-xfs-outgoing; Tue, 22 May 2001 00:22:20 -0700
Received: from electre.pasteur.fr (electre.pasteur.fr [157.99.64.120])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M7MHF31111
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 00:22:17 -0700
Received: from pasteur.fr (IDENT:tru@xiii.bis.pasteur.fr [157.99.90.14])
	by electre.pasteur.fr (8.11.3/8.11.3) with ESMTP id f4M7E0v05188;
	Tue, 22 May 2001 09:14:00 +0200 (CEST)
Message-ID: <3B0A11B8.C3055F36@pasteur.fr>
Date: Tue, 22 May 2001 09:14:00 +0200
From: Tru Huynh <tru@pasteur.fr>
Organization: Institut Pasteur
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Lord <lord@sgi.com>
CC: "Blizbor (i)" <tb670725@ima.pl>, linux-xfs@oss.sgi.com
Subject: Re: Mount option 'noexec' seems not working (Maybe 'nodev' also)
References: <200105220028.f4M0Sld06710@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord wrote:
> 
> Try the CVS tree, it appears to work there:
> 
<skipped>

Same here, from the SGI cdrom install
[tru@mangouste bin]$ uname -a
Linux mangouste.bis.pasteur.fr 2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49
CDT 2001 i686 unknown

[tru@mangouste bin]$ mount | grep mangouste
/dev/ide/host0/bus0/target0/lun0/part7 on /mangouste type xfs
(rw,noexec)
[tru@mangouste bin]$ pwd
/mangouste/tru/rh71/bin
[tru@mangouste bin]$ cp /bin/ls .
[tru@mangouste bin]$ ./ls
./ls: Permission denied.

Sincerely,

Tru

From owner-linux-xfs@oss.sgi.com Tue May 22 00:43:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4M7hE231475
	for linux-xfs-outgoing; Tue, 22 May 2001 00:43:14 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4M7hDF31472
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 00:43:13 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP id D90A71E0A5
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:43:08 +0200 (MEST)
Date: Tue, 22 May 2001 09:42:19 +0200
From: Andi Kleen <ak@suse.de>
To: linux-xfs@oss.sgi.com
Subject: inode/dcache shrink and nested locks
Message-ID: <20010522094219.A24123@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



xfs_ilock as far as I can see does not use a recursive lock for exclusive
locking. xfs_release() gets an exclusive lock on the inode. It can be called
from shrink_[di]cache_memory(), which can be called from most memory
allocations inside the XFS, thus probably deadlocking. The normal linux
VFS avoids this situation for the superblock lock by checking in 
shrink_[di]cache_memory() for __GFP_IO and not doing anything when it is set.
XFS usually sets GFP_PAGE_IO though, which is not checked this way and doesn't
include __GFP_IO. 

One easy way would be to just check for __GFP_PAGE_IO in the shrink_* 
functions also, this just would have the drawback that the defragmentation
effects of shrink_* could not be used inside XFS (kmem_shake_memory would
be mostly useless). Another option would be to make xfs_ilock() recursive.

Comments?


-Andi 




From owner-linux-xfs@oss.sgi.com Tue May 22 03:12:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MACQF01728
	for linux-xfs-outgoing; Tue, 22 May 2001 03:12:26 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MACOF01725
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 03:12:25 -0700
Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 15299K-0006M0-00
	for linux-xfs@oss.sgi.com; Tue, 22 May 2001 12:12:22 +0200
Received: from pd950716e.dip.t-dialin.net ([217.80.113.110])
	by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2)
	id 15298R-00055B-00
	for linux-xfs@oss.sgi.com; Tue, 22 May 2001 12:11:27 +0200
Date: Tue, 22 May 2001 12:13:14 +0200 (CEST)
From: poldi <poldi@andreas-c.de>
X-X-Sender:  <poldi@andreas-c>
To: <linux-xfs@oss.sgi.com>
Subject: XFS-Filesystem and MOSIX-Linux-Cluster
Message-ID: <Pine.LNX.4.33.0105221209400.229-100000@andreas-c>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi there !

I try to set up a Linux Cluster with the brand new XFS-Filesystem.
But this is a problem.

The MOSIX-Patch is only for the 2.4.4 Kernel and you don't have a patch
for that new kernel-version.

If I try to do the same with 2.4.3-Version, the MOSIX-Patch failed.

Is it possible to install these two patches into the new kernel (2.4.4 or
newer) ?

When will be an update available to download on your Homepage ?

Bye
------------------------------------------
Andreas Cordes

Am Wiesenhof 145
26389 Wilhelmshaven
Germany

        Web : www.andreas-c.de
Mail @ Home : info@andreas-c.de
        UIN : 22895068
       Cell : (+49) 0177 5776932
------------------------------------------

-=- If Linux doesn't have the solution -=-
-=-     you have the wrong problem     -=-


From owner-linux-xfs@oss.sgi.com Tue May 22 03:32:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MAWip02025
	for linux-xfs-outgoing; Tue, 22 May 2001 03:32:44 -0700
Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MAWhF02022
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 03:32:43 -0700
Received: (from ragnark@localhost)
	by stine.vestdata.no (8.9.3/8.9.3) id MAA18365;
	Tue, 22 May 2001 12:32:39 +0200
Date: Tue, 22 May 2001 12:32:38 +0200
From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <xfs@ragnark.vestdata.no>
To: poldi <poldi@andreas-c.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster
Message-ID: <20010522123237.V22540@vestdata.no>
References: <Pine.LNX.4.33.0105221209400.229-100000@andreas-c>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 0.95.5i
In-Reply-To: <Pine.LNX.4.33.0105221209400.229-100000@andreas-c>; from poldi on Tue, May 22, 2001 at 12:13:14PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 22, 2001 at 12:13:14PM +0200, poldi wrote:
> Hi there !
> 
> I try to set up a Linux Cluster with the brand new XFS-Filesystem.
> But this is a problem.
> 
> The MOSIX-Patch is only for the 2.4.4 Kernel and you don't have a patch
> for that new kernel-version.
> 
> If I try to do the same with 2.4.3-Version, the MOSIX-Patch failed.
> 
> Is it possible to install these two patches into the new kernel (2.4.4 or
> newer) ?
> 
> When will be an update available to download on your Homepage ?

I tried the very same thing, but there were multiple rejects that have
to be sorted out; and they were not just line-number offsets, or simple
merges of the two patches, because both patches changed the same part of
the code. One thing that comes to mind was the compiler-flags in
Makefile.


-- 
Ragnar Kjørstad
Big Storage

From owner-linux-xfs@oss.sgi.com Tue May 22 03:50:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MAoun02285
	for linux-xfs-outgoing; Tue, 22 May 2001 03:50:56 -0700
Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MAoVF02274
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 03:50:54 -0700
Received: (from kszysiu@localhost)
	by main.braxis.co.uk (8.9.3/8.9.3) id MAA17650;
	Tue, 22 May 2001 12:39:35 +0200
Date: Tue, 22 May 2001 12:39:35 +0200
From: Krzysztof Rusocki <kszysiu@braxis.co.uk>
To: poldi <poldi@andreas-c.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster
Message-ID: <20010522123935.B16208@main.braxis.co.uk>
References: <Pine.LNX.4.33.0105221209400.229-100000@andreas-c>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0105221209400.229-100000@andreas-c>; from poldi@andreas-c.de on Tue, May 22, 2001 at 12:13:14PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi Andreas,

CVS Development snapshot is currently 2.4.4 based. So download CVS source
tree and you'll have 2.4.4 <- that what you wanted. However I don't know how
is it going to interact with Mosix patch, I think that  one of XFS
developers should say something about potential problems (if any).

Cheers,
Krzysztof


On Tue, May 22, 2001 at 12:13:14PM +0200, poldi wrote:
> Hi there !
> 
> I try to set up a Linux Cluster with the brand new XFS-Filesystem.
> But this is a problem.
> 
> The MOSIX-Patch is only for the 2.4.4 Kernel and you don't have a patch
> for that new kernel-version.
> 
> If I try to do the same with 2.4.3-Version, the MOSIX-Patch failed.
> 
> Is it possible to install these two patches into the new kernel (2.4.4 or
> newer) ?
> 
> When will be an update available to download on your Homepage ?
> 
> Bye
> ------------------------------------------
> Andreas Cordes
> 
> Am Wiesenhof 145
> 26389 Wilhelmshaven
> Germany
> 
>         Web : www.andreas-c.de
> Mail @ Home : info@andreas-c.de
>         UIN : 22895068
>        Cell : (+49) 0177 5776932
> ------------------------------------------
> 
> -=- If Linux doesn't have the solution -=-
> -=-     you have the wrong problem     -=-

From owner-linux-xfs@oss.sgi.com Tue May 22 04:02:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MB21v02508
	for linux-xfs-outgoing; Tue, 22 May 2001 04:02:01 -0700
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MB1xF02477
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:02:00 -0700
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1)
	id 1529vH-0002se-0W
	for linux-xfs@oss.sgi.com; Tue, 22 May 2001 12:01:55 +0100
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 99EC827EF
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 07:56:02 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 14AE4125E6; Tue, 22 May 2001 07:56:00 +0100 (BST)
Date: Tue, 22 May 2001 07:56:00 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[2]: lilo -R 
To: linux-xfs@oss.sgi.com
In-Reply-To: <20010522032230.15566.qmail@web10404.mail.yahoo.com>
References: <20010522032230.15566.qmail@web10404.mail.yahoo.com>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010522065600.14AE4125E6@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f4MB20F02483
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 21 May 2001 20:22:30 -0700 (PDT) John <John <jsh_45@yahoo.com>> wrote:

> This is starting to get to me.  I "thought" that
> pulling the /dev/hdc drives cable and putting it on
> the first ide controller would be the easy thing to
> do, but that has been elusive.  I've tried almost

More out of curiosity than anything, why did you want to do things this
way, as opposed to using LILO on the original configuration to boot from
hdc ?


--
Keith Matthews

Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Tue May 22 04:18:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MBIfT02975
	for linux-xfs-outgoing; Tue, 22 May 2001 04:18:41 -0700
Received: from ima.pl (mail.ima.pl [195.117.13.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MBIcF02972
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:18:38 -0700
Received: [from blizbor.ima.pl (jurek.primark.gdansk.tpnet.pl [195.117.150.37])
                               by ima.pl with ESMTP id f4MBHu231587;
                               Tue, 22 May 2001 13:17:56 +0200]
Message-Id: <5.0.0.25.0.20010522131501.0210be60@mail.ima.pl>
X-Sender: blizbor@mail.ima.pl
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 22 May 2001 13:22:26 +0200
To: Steve Lord <lord@sgi.com>
From: Blizbor <tb670725@ima.pl>
Subject: Re: Mount option 'noexec' seems not working (Maybe 'nodev'
  also) 
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <200105220028.f4M0Sld06710@jen.americas.sgi.com>
References: <Message from "Blizbor (i)" <tb670725@ima.pl>
 <005b01c0e252$af837ec0$020010ac@ima.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 5/22/01 02:28 AM, Steve Lord wrote:
>> Hi,
>
>Try the CVS tree, it appears to work there:

Thanks all guys, I have found whats going on. It's bash

[root@mail /tmp]#
[root@mail /tmp]# uname -a
Linux mail.ima.pl 2.4.2-SGI_XFS_1.0smp #1 SMP Fri Apr 27 19:07:34 CDT 2001 i686 unknown
[root@mail /tmp]# mount | grep tmp
/dev/ida/disc0/part2 on /tmp type xfs (rw,noexec,nodev,noatime,nodiratime)

[root@mail /tmp]# echo "/bin/ls" > ./ls ; chmod +x ./ls

[root@mail /tmp]# ./ls
bash: ./ls: Permission denied

[root@mail /tmp]# . ./ls
auto    ls           mcextvKCUve  procmlog                               sess_d200e8cdb441eaa4884a74c5c3527fe9  wypakowane
backup  mcextOWz6Ui  plik         sess_03cd830e3b3d96a20b9bb80d1a43cda9  STARE_STRONY

[root@mail /tmp]# cp /bin/ls .
cp: overwrite `./ls'? y
[root@mail /tmp]# ./ls
bash: ./ls: Permission denied

[root@mail /tmp]# . ./ls
bash: .: ./ls: cannot execute binary file
[root@mail /tmp]#

Cheers,
Blizbor


From owner-linux-xfs@oss.sgi.com Tue May 22 04:37:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MBbcp03265
	for linux-xfs-outgoing; Tue, 22 May 2001 04:37:38 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MBbaF03262
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:37:36 -0700
Received: (qmail 31250 invoked from network); 22 May 2001 11:37:33 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 22 May 2001 11:37:33 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Keith Matthews <keith_m@sweeney.demon.co.uk>
cc: linux-xfs@oss.sgi.com
Subject: Re: lilo -R 
In-reply-to: Your message of "Tue, 22 May 2001 07:56:00 +0100."
             <20010522065600.14AE4125E6@rebutia.sweeney.demon.co.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 22 May 2001 21:37:32 +1000
Message-ID: <9224.990531452@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001 07:56:00 +0100 (BST), 
Keith Matthews <keith_m@sweeney.demon.co.uk> wrote:
>On Mon, 21 May 2001 20:22:30 -0700 (PDT) John <John <jsh_45@yahoo.com>> wrote:
>
>> This is starting to get to me.  I "thought" that
>> pulling the /dev/hdc drives cable and putting it on
>> the first ide controller would be the easy thing to
>> do, but that has been elusive.  I've tried almost
>
>More out of curiosity than anything, why did you want to do things this
>way, as opposed to using LILO on the original configuration to boot from
>hdc ?

He is building on hdc using an existing kernel then making hdc the boot
disk, so it becomes hda in a new system.  lilo records device numbers
and gets confused by this process.

The easiest method is to create the new system on hdc, do not run lilo,
install the disk as hda, boot a kernel off an emergency floppy using
root on the new hda then run lilo to install after the disk has been
moved to hda.  The problem with that approach is fitting the kernel on
a floppy, XFS is too big.  The only ways I can see of using an
emergency floppy are by using an ext2 partition on hdc/hda or by
building XFS as a module, but that requires fiddling with initrd,
messy.


From owner-linux-xfs@oss.sgi.com Tue May 22 04:53:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MBrbl03503
	for linux-xfs-outgoing; Tue, 22 May 2001 04:53:37 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MBraF03500
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:53:36 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA29357
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:52:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1899043; Tue, 22 May 2001 06:52:16 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA70508; Tue, 22 May 2001 06:52:15 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MBtK307648; Tue, 22 May 2001 06:55:20 -0500
Message-Id: <200105221155.f4MBtK307648@jen.americas.sgi.com>
To: Keith Owens <kaos@melbourne.sgi.com>
cc: Keith Matthews <keith_m@sweeney.demon.co.uk>, linux-xfs@oss.sgi.com
Subject: Re: lilo -R 
References: <9224.990531452@ocs3.ocs-net>
Comments: In-reply-to Keith Owens <kaos@melbourne.sgi.com>
   message dated "Tue, 22 May 2001 21:37:32 +1000."
Date: Tue, 22 May 2001 06:55:20 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tue, 22 May 2001 07:56:00 +0100 (BST), 
> Keith Matthews <keith_m@sweeney.demon.co.uk> wrote:
> >On Mon, 21 May 2001 20:22:30 -0700 (PDT) John <John <jsh_45@yahoo.com>> wrot
> e:
> >
> >> This is starting to get to me.  I "thought" that
> >> pulling the /dev/hdc drives cable and putting it on
> >> the first ide controller would be the easy thing to
> >> do, but that has been elusive.  I've tried almost
> >
> >More out of curiosity than anything, why did you want to do things this
> >way, as opposed to using LILO on the original configuration to boot from
> >hdc ?
> 
> He is building on hdc using an existing kernel then making hdc the boot
> disk, so it becomes hda in a new system.  lilo records device numbers
> and gets confused by this process.
> 
> The easiest method is to create the new system on hdc, do not run lilo,
> install the disk as hda, boot a kernel off an emergency floppy using
> root on the new hda then run lilo to install after the disk has been
> moved to hda.  The problem with that approach is fitting the kernel on
> a floppy, XFS is too big.  The only ways I can see of using an
> emergency floppy are by using an ext2 partition on hdc/hda or by
> building XFS as a module, but that requires fiddling with initrd,
> messy.

The rescue mode on the cdrom supports XFS, I have fixed up lilo
this way. Also, when setting up a system with multiple roots,
I tend to keep the same boot partition and lilo configuration for
both of them, which is another way out of this.

Steve


From owner-linux-xfs@oss.sgi.com Tue May 22 04:56:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MBu6Y03569
	for linux-xfs-outgoing; Tue, 22 May 2001 04:56:06 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MBu3F03565
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:56:04 -0700
Received: (qmail 31503 invoked from network); 22 May 2001 11:56:01 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 22 May 2001 11:56:01 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Steve Lord <lord@sgi.com>
cc: Keith Matthews <keith_m@sweeney.demon.co.uk>, linux-xfs@oss.sgi.com
Subject: Re: lilo -R 
In-reply-to: Your message of "Tue, 22 May 2001 06:55:20 EST."
             <200105221155.f4MBtK307648@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 22 May 2001 21:56:00 +1000
Message-ID: <9548.990532560@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001 06:55:20 -0500, 
Steve Lord <lord@sgi.com> wrote:
>The rescue mode on the cdrom supports XFS, I have fixed up lilo
>this way.

Good news, boot off the cdrom in rescue mode, mount the root partition
on the new hda as /mnt then run

  ROOT=/mnt lilo -C /mnt/etc/lilo.conf

/mnt/etc/lilo.conf should have boot=/dev/hda and root=/dev/hda<n>.

>Also, when setting up a system with multiple roots,
>I tend to keep the same boot partition and lilo configuration for
>both of them, which is another way out of this.

As long as the disks don't move.  The problem here is the system is
being created on hdc then the disk is moved to hda, lilo always has
problems with disk numbers changing.


From owner-linux-xfs@oss.sgi.com Tue May 22 04:59:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MBxRu03709
	for linux-xfs-outgoing; Tue, 22 May 2001 04:59:27 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MBxRF03706
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 04:59:27 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id FAA03536
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:10:17 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1900356; Tue, 22 May 2001 06:57:59 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA11304; Tue, 22 May 2001 06:57:59 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MC14r07702; Tue, 22 May 2001 07:01:04 -0500
Message-Id: <200105221201.f4MC14r07702@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Krzysztof Rusocki <kszysiu@braxis.co.uk>
cc: poldi <poldi@andreas-c.de>, linux-xfs@oss.sgi.com
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster 
In-Reply-To: Message from Krzysztof Rusocki <kszysiu@braxis.co.uk> 
   of "Tue, 22 May 2001 12:39:35 +0200." <20010522123935.B16208@main.braxis.co.uk> 
Date: Tue, 22 May 2001 07:01:04 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> Hi Andreas,
> 
> CVS Development snapshot is currently 2.4.4 based. So download CVS source
> tree and you'll have 2.4.4 <- that what you wanted. However I don't know how
> is it going to interact with Mosix patch, I think that  one of XFS
> developers should say something about potential problems (if any).

Since I don't think any of us know anything about Mosix, I do not think
we can say anything one way or another. If someone can describe how Mosix
interacts with a filesystem we might be able to say something.

Steve

> 
> Cheers,
> Krzysztof
> 


From owner-linux-xfs@oss.sgi.com Tue May 22 05:07:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MC7lR03866
	for linux-xfs-outgoing; Tue, 22 May 2001 05:07:47 -0700
Received: from marraco.udl.es (gardeny.udl.es [193.144.12.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MC7jF03863
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:07:45 -0700
Received: from eup.udl.es (fermat.udl.net [10.50.54.28]) by marraco.udl.es (8.9.3/8.8.5) with ESMTP id NAA25112 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:06:11 +0200
Received: by eup.udl.es (8.8.8+Sun/SMI-SVR4)
	id OAA08534; Tue, 22 May 2001 14:07:35 +0200 (MET DST)
Date: Tue, 22 May 2001 14:07:35 +0200 (MET DST)
From: fermin@eup.udl.es (Fermin Molina)
Message-Id: <200105221207.OAA08534@eup.udl.es>
To: linux-xfs@oss.sgi.com
Subject: Growing block size??
X-Sun-Charset: US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've been experimenting a strange behaviour of XFS+NFS in my system. I
don't know if this is normal.

Server machine: NFS with homes shared (/users). Filesystem is XFS.
Quota is assigned for each user.

Client machine: mount that shared directory (/users). Also has NIS for
UID,GID mapping.

On the client machine and as a normal user, I gunzip+untar a .tgz with
many subdirectories and small files (as a kernel .tgz).

The quota grows very fast when I'm "tar zxvf" the file.
Then, on the server I get:

# ls -l testsuite.in

-rw-r--r--	1  user1	users	182853	Feb 25 19:06  testsuite.in

# du -k testsuite.in

256	testsuite.in


It's like block size were increased to 128 Kb. In some files, for a file
of 10 Kb, du -k reports 64. Instead, in other files, I can deduce they
only use 4 Kb (the normal block size for a XFS filesystem, I think).

I know that command "du -k" sometimes reports erroneous information, but
the problem is that this is reflected in the user quota, and the user
runs out of quota...

I've been using a XFS kernel 2.4.4, cvs from early May.

Is this behaviour normal?

Thanx.

/Fermin

From owner-linux-xfs@oss.sgi.com Tue May 22 05:25:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MCPhU04206
	for linux-xfs-outgoing; Tue, 22 May 2001 05:25:43 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MCPcF04203
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:25:38 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id FAA05010
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:25:32 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA1899304; Tue, 22 May 2001 07:24:15 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA44057; Tue, 22 May 2001 07:24:15 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MCRK807795; Tue, 22 May 2001 07:27:20 -0500
Message-Id: <200105221227.f4MCRK807795@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Andi Kleen <ak@suse.de>
cc: linux-xfs@oss.sgi.com
Subject: Re: inode/dcache shrink and nested locks 
In-Reply-To: Message from Andi Kleen <ak@suse.de> 
   of "Tue, 22 May 2001 09:42:19 +0200." <20010522094219.A24123@gruyere.muc.suse.de> 
Date: Tue, 22 May 2001 07:27:19 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Andi Kleen wrote:
> 
> 
> xfs_ilock as far as I can see does not use a recursive lock for exclusive
> locking. xfs_release() gets an exclusive lock on the inode. It can be called
> from shrink_[di]cache_memory(), which can be called from most memory
> allocations inside the XFS, thus probably deadlocking. The normal linux
> VFS avoids this situation for the superblock lock by checking in 
> shrink_[di]cache_memory() for __GFP_IO and not doing anything when it is set.
> XFS usually sets GFP_PAGE_IO though, which is not checked this way and doesn'
> t
> include __GFP_IO. 
> 
> One easy way would be to just check for __GFP_PAGE_IO in the shrink_* 
> functions also, this just would have the drawback that the defragmentation
> effects of shrink_* could not be used inside XFS (kmem_shake_memory would
> be mostly useless). Another option would be to make xfs_ilock() recursive.
> 
> Comments?
> 
> 
> -Andi 
> 

Hi Andi,

Hmm, I don't think you mean xfs_release, that is called from fput and
the nfs server, but the exclusive lock is obtained in the clear_inode
path though.

The only time this would be a problem is memory allocations done from
a thread holding the ilock on an inode which has a zero i_count or d_count.
I would have to do a code audit to find these, but it is a small fraction
of the xfs code base, in fact it is probably just  the xfs_iget path since
we generally do not do anything with an inode unless we have a reference
to it.

I will take a look though.

Steve




From owner-linux-xfs@oss.sgi.com Tue May 22 05:39:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MCdaO04653
	for linux-xfs-outgoing; Tue, 22 May 2001 05:39:36 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MCdaF04650
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:39:36 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA03669
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 05:38:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA1901322; Tue, 22 May 2001 07:38:19 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA27834; Tue, 22 May 2001 07:38:19 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MCfN207831; Tue, 22 May 2001 07:41:23 -0500
Message-Id: <200105221241.f4MCfN207831@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: fermin@eup.udl.es (Fermin Molina)
cc: linux-xfs@oss.sgi.com
Subject: Re: Growing block size?? 
In-Reply-To: Message from fermin@eup.udl.es (Fermin Molina) 
   of "Tue, 22 May 2001 14:07:35 +0200." <200105221207.OAA08534@eup.udl.es> 
Date: Tue, 22 May 2001 07:41:23 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


This sounds like the nfs reference cache component of XFS. When the NFS
server operates on a file, it will do the equivalent of an open/close
around each write. When XFS allocates space for a file, it preallocates
out beyond the size of the write - in anticipation of another write
coming in (that's not quite a correct description since it does not
happen on all writes). This is usually done in 64K chunks, but there
may be code which bumps this when a certain file size is reached.

This extra space is removed at close time (it is usually delalloc space
which is much cheaper to manipulate like this).

The reference cache was brought over from Irix to fix NFS write performance,
which was doing the allocate and remove extra space on each write call, it
basically postpones the release of the extra space until an inode is pushed
out of the cache by:

	o new inodes coming in
	o sync activity (very slowly)
	o unmount
	o file removal

So what is happening here is the 'temporary' extra space on the file is
sitting around on all the inodes in the nfs reference cache causing the
quota overflow. The reference cache is 512 inodes, which may be somewhat
large for a linux box, I can make this a tunable parameter.

I suspect Irix could exhibit the same behavior here, although it has
even more special case code for NFS.

You can make the effect smaller by editing fs/xfs/xfs_vfsops.c and looking
for this line:

	xfs_refcache_size = 512;

Make that a smaller number, it will have the most effect if you keep it
higher than the number of files clients are writing to in parallel.

Steve

> Hi,
> 
> I've been experimenting a strange behaviour of XFS+NFS in my system. I
> don't know if this is normal.
> 
> Server machine: NFS with homes shared (/users). Filesystem is XFS.
> Quota is assigned for each user.
> 
> Client machine: mount that shared directory (/users). Also has NIS for
> UID,GID mapping.
> 
> On the client machine and as a normal user, I gunzip+untar a .tgz with
> many subdirectories and small files (as a kernel .tgz).
> 
> The quota grows very fast when I'm "tar zxvf" the file.
> Then, on the server I get:
> 
> # ls -l testsuite.in
> 
> -rw-r--r--	1  user1	users	182853	Feb 25 19:06  testsuite.in
> 
> # du -k testsuite.in
> 
> 256	testsuite.in
> 
> 
> It's like block size were increased to 128 Kb. In some files, for a file
> of 10 Kb, du -k reports 64. Instead, in other files, I can deduce they
> only use 4 Kb (the normal block size for a XFS filesystem, I think).
> 
> I know that command "du -k" sometimes reports erroneous information, but
> the problem is that this is reflected in the user quota, and the user
> runs out of quota...
> 
> I've been using a XFS kernel 2.4.4, cvs from early May.
> 
> Is this behaviour normal?
> 
> Thanx.
> 
> /Fermin



From owner-linux-xfs@oss.sgi.com Tue May 22 06:23:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MDNma05633
	for linux-xfs-outgoing; Tue, 22 May 2001 06:23:48 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MDNlF05630
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 06:23:47 -0700
Received: from [195.20.224.204] (helo=mrvdom00.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 152C7w-0007W5-00; Tue, 22 May 2001 15:23:08 +0200
Received: from pd950716e.dip.t-dialin.net ([217.80.113.110])
	by mrvdom00.schlund.de with esmtp (Exim 2.12 #2)
	id 152C1l-00016V-00; Tue, 22 May 2001 15:16:45 +0200
Date: Tue, 22 May 2001 15:18:33 +0200 (CEST)
From: poldi <poldi@andreas-c.de>
X-X-Sender:  <poldi@andreas-c>
To: Steve Lord <lord@sgi.com>
cc: Krzysztof Rusocki <kszysiu@braxis.co.uk>, <linux-xfs@oss.sgi.com>
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster 
In-Reply-To: <200105221201.f4MC14r07702@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221517190.229-100000@andreas-c>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001, Steve Lord wrote:

> >
> > Hi Andreas,
> >
> > CVS Development snapshot is currently 2.4.4 based. So download CVS source
> > tree and you'll have 2.4.4 <- that what you wanted. However I don't know how
> > is it going to interact with Mosix patch, I think that  one of XFS
> > developers should say something about potential problems (if any).
>
> Since I don't think any of us know anything about Mosix, I do not think
> we can say anything one way or another. If someone can describe how Mosix
> interacts with a filesystem we might be able to say something.
>
> Steve
>
> >
> > Cheers,
> > Krzysztof
> >
>
>

See. www.mosix.org for more details on MOSIX and a Linux-Cluster.
There is also a description how Mosix interacts with the Linux-Filesystem.

As I read some lines, I noticed out, that there is also an other
filesystem, calles Mosix-Filesystem.
May this helps you ?

Cheers

------------------------------------------
Andreas Cordes

Am Wiesenhof 145
26389 Wilhelmshaven

        Web : www.andreas-c.de
Mail @ Home : info@andreas-c.de
        UIN : 22895068
       Cell : 0177/5776932
------------------------------------------

-=- If Linux doesn't have the solution -=-
-=-     you have the wrong problem     -=-


From owner-linux-xfs@oss.sgi.com Tue May 22 07:16:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MEGXb06637
	for linux-xfs-outgoing; Tue, 22 May 2001 07:16:33 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MEGWF06634
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 07:16:32 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA13696
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 07:15:06 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1899055; Tue, 22 May 2001 09:15:05 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA10227; Tue, 22 May 2001 09:15:05 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MEI9907928; Tue, 22 May 2001 09:18:09 -0500
Message-Id: <200105221418.f4MEI9907928@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: poldi <poldi@andreas-c.de>
cc: Steve Lord <lord@sgi.com>, Krzysztof Rusocki <kszysiu@braxis.co.uk>,
   linux-xfs@oss.sgi.com
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster 
In-Reply-To: Message from poldi <poldi@andreas-c.de> 
   of "Tue, 22 May 2001 15:18:33 +0200." <Pine.LNX.4.33.0105221517190.229-100000@andreas-c> 
Date: Tue, 22 May 2001 09:18:09 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tue, 22 May 2001, Steve Lord wrote:
> 
> > >
> > > Hi Andreas,
> > >
> > > CVS Development snapshot is currently 2.4.4 based. So download CVS source
> > > tree and you'll have 2.4.4 <- that what you wanted. However I don't know 
> how
> > > is it going to interact with Mosix patch, I think that  one of XFS
> > > developers should say something about potential problems (if any).
> >
> > Since I don't think any of us know anything about Mosix, I do not think
> > we can say anything one way or another. If someone can describe how Mosix
> > interacts with a filesystem we might be able to say something.
> >
> > Steve
> >
> > >
> > > Cheers,
> > > Krzysztof
> > >
> >
> >
> 
> See. www.mosix.org for more details on MOSIX and a Linux-Cluster.
> There is also a description how Mosix interacts with the Linux-Filesystem.
> 
> As I read some lines, I noticed out, that there is also an other
> filesystem, calles Mosix-Filesystem.
> May this helps you ?
> 
> Cheers
> 
> ------------------------------------------
> Andreas Cordes
> 

OK, someone is just going to have to try it if you want any form of answer
soon. I do not have time to wade through the mosix site and try to work
out how it functions right now. I would start with the xfs development
cvs tree and attempt to apply the mosix patches to it. If it adds a 
filesystem then there will probably be conflicts in fs.h, but it
should not be rocket science to fix those up.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 22 07:51:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MEprI07358
	for linux-xfs-outgoing; Tue, 22 May 2001 07:51:53 -0700
Received: from obi-wan.jobpilot.it ([212.177.6.190])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MEpoF07354
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 07:51:51 -0700
Received: from solo ([10.39.1.4])
	by obi-wan.jobpilot.it (8.10.2/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id f4MEm9l18693
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:48:09 +0200
X-Authentication-Warning: obi-wan.jobpilot.it: Host [10.39.1.4] claimed to be solo
Message-ID: <002801c0e2c4$4b0b8f10$0401270a@milano.jobpilot>
From: "Simon \"Drake\" Danini" <drake@jobpilot.it>
To: <linux-xfs@oss.sgi.com>
Subject: raid1 root with XFS
Date: Tue, 22 May 2001 15:37:03 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0025_01C0E2D5.0CD30000"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0025_01C0E2D5.0CD30000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all,
    i'm trying to build up a linux system with 2 software raid1 xfs =
partitions (let's say hda1 hda2) ...
i've tryed almost everything ...

patched mkinitrd (as suggested from this list)
enabling and disabling devfs
manually modifying initrd image (to arrange the /dev/md0 problem)
trying to arrange the various /dev/md0 and/or /dev/md/0

but nothing seems to work
the kernel used is the one of the 1.0 RedHat installer iso image =
downloaded from sgi

i always get the same error

raid1 personality registred
Autodetecting RAID arrays ...
autorun ...
... autorun DONE.
Ext2fs: unable to read superblock
...
XFS: SB read failed

... and then obviously the "kernel panic"

Can someone give me some hints ???

Thank a lot in advance and Ciao

                    Drake


* Simone Danini * IT Manager * jobpilot Italia srl
* mailto:drake@jobpilot.it * www.jobpilot.it * www.jobpilot.com
* Corso di Porta Romana, 68 * I-20122 Milano * Italia
* tel: + 39.02.584.574-23 * fax: + 39.02.584.574-37
* mobile: +39.348.4904057

* Europe's career market on the Internet
* Amsterdam * Bangkok * Barcelona * Brussels * Budapest * Copenhagen
* Frankfurt * Gothenburg * Kuala Lumpur * London * Milan * Oslo
* Paris * Prague * Singapore * Vienna * Warsaw * Zurich *


------=_NextPart_000_0025_01C0E2D5.0CD30000
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; i'm trying to build =
up a linux=20
system with 2 software raid1 xfs partitions (let's say hda1 hda2)=20
...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>i've tryed almost everything =
...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>patched mkinitrd (as suggested from =
this=20
list)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>enabling and disabling =
devfs</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>manually modifying initrd image (to =
arrange the=20
/dev/md0 problem)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>trying to arrange the various /dev/md0 =
and/or=20
/dev/md/0</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>but nothing seems to work</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the kernel used is the one of the 1.0 =
RedHat=20
installer iso image downloaded from sgi</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i always get the same =
error</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>raid1 personality =
registred</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Autodetecting RAID arrays =
...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>autorun ...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>... autorun DONE.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ext2fs: unable to read =
superblock</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>XFS: SB read failed<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>... and then obviously the "kernel=20
panic"</DIV></FONT>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Can someone give me some hints =
???</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank a lot in advance and =
Ciao</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Drake</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>* Simone Danini * IT Manager * jobpilot =
Italia=20
srl<BR>* <A =
href=3D"mailto:drake@jobpilot.it">mailto:drake@jobpilot.it</A> * <A=20
href=3D"http://www.jobpilot.it">www.jobpilot.it</A> * <A=20
href=3D"http://www.jobpilot.com">www.jobpilot.com</A><BR>* Corso di =
Porta Romana,=20
68 * I-20122 Milano * Italia<BR>* tel: + 39.02.584.574-23 * fax: +=20
39.02.584.574-37<BR>* mobile: +39.348.4904057</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>* Europe's career market on the =
Internet<BR>*=20
Amsterdam * Bangkok * Barcelona * Brussels * Budapest * Copenhagen<BR>*=20
Frankfurt * Gothenburg * Kuala Lumpur * London * Milan * Oslo<BR>* Paris =
*=20
Prague * Singapore * Vienna * Warsaw * Zurich =
*<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0025_01C0E2D5.0CD30000--


From owner-linux-xfs@oss.sgi.com Tue May 22 08:10:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MFAKJ07672
	for linux-xfs-outgoing; Tue, 22 May 2001 08:10:20 -0700
Received: from www.quasihorse.com (cs666826-150.austin.rr.com [66.68.26.150])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MFAJF07669
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 08:10:19 -0700
Received: by www.quasihorse.com (Postfix, from userid 500)
	id B8BE64A9; Tue, 22 May 2001 10:08:00 -0500 (CDT)
Date: Tue, 22 May 2001 10:08:00 -0500
From: pac@fortuitous.com
To: linux-xfs@oss.sgi.com
Subject: Possible bug.
Message-ID: <20010522100800.A9283@bistro.marx>
Reply-To: pac@fortuitous.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


 I deleted a few directories while still inside them in another
 xterm. When I did 

  # cd ../..

  I was put into a state where the directory label didnt match the
  actual directory contents.. ie. I wasnt where XFS thought/reported 
  I was.. I think this is easy to reproduce...

   -Phil C.
 .---------------------------------------------------------
 | P. A. Carinhas, Ph.D.        |  pac@fortuitous.com      |
 | Fortuitous Technologies Inc. |  http://fortuitous.com   |
 | Linux Training Services      |  Tel : 1-512 467-2154    |
 | Contract, In-house, & Onsite |  800 : 1-877 467-2154    |
  ---------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May 22 09:04:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MG4vf08673
	for linux-xfs-outgoing; Tue, 22 May 2001 09:04:57 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MG4uF08670
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:04:56 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MG4tb03522;
	Tue, 22 May 2001 11:04:55 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MG4tM21830;
	Tue, 22 May 2001 11:04:55 -0500 (CDT)
Date: Tue, 22 May 2001 11:04:55 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: <sandeen@sgi.com>
cc: Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: linux 2.4.2-XFS
Message-ID: <Pine.LNX.4.33.0105221057420.5964-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric,

I found your name and address on a thread about linux & xfs.  I'm also
seeing the "kernel: __alloc_pages: 0-order allocation
failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
reiserfs, and xfs with iozone.  The xfs performance was looking great (50%
better on writes than ext2 or reiserfs) until the box fell over scrolling
these errors.  It hangs the box and only a hard reset will suffice to
break out of it.

I seem to be able to reproduce the error by running iozone this way:

	iozone -s 4000m

That's a big iozone run, but the systems all have 2gig memory so I've got
to go big to get out of linux cache and see meaningful numbers.  Has there
been any progress with this bug?  If you'd like, I can get you a temporary
acct. on the system where I'm testing.

-Galen

 --
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Tue May 22 09:13:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MGDpS08872
	for linux-xfs-outgoing; Tue, 22 May 2001 09:13:51 -0700
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MGDoF08869
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:13:50 -0700
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id JAA00834
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:13:42 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id JAA29103
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:13:48 -0700 (PDT)
Received: from pipcws.ca.boeing.com by slb-hub-01.boeing.com with ESMTP; Tue, 22 May 2001 09:13:40 -0700
Received: from pipcws.ca.boeing.com (loopback [127.0.0.1])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id JAA146204;
	Tue, 22 May 2001 09:13:39 -0700
Message-Id: <3B0A9033.5EC4D92E@pipcws.ca.boeing.com>
Date: Tue, 22 May 2001 09:13:39 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
Organization: The Boeing Company
X-Mailer: Mozilla 4.76C-Boeing UNIX Kit [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: pac@fortuitous.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Possible bug.
References: <20010522100800.A9283@bistro.marx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

pac@fortuitous.com wrote:
> 
>  I deleted a few directories while still inside them in another
>  xterm. When I did
> 
>   # cd ../..
> 
>   I was put into a state where the directory label didnt match the
>   actual directory contents.. ie. I wasnt where XFS thought/reported
>   I was.. I think this is easy to reproduce...

You can do that with any *nix that I can think of.
This is not unique to SGI/XFS.

-- 
__________________________________________________________
Ric Tibbetts
Boeing Shared Services Group
UNIX System Administration
Seattle Server Operations
__________________________________________________________

From owner-linux-xfs@oss.sgi.com Tue May 22 09:21:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MGLLD09096
	for linux-xfs-outgoing; Tue, 22 May 2001 09:21:21 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MGLKF09093
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:21:20 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA00140
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:32:21 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1902551; Tue, 22 May 2001 11:20:02 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA34795; Tue, 22 May 2001 11:20:02 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MGN5S10915; Tue, 22 May 2001 11:23:05 -0500
Message-Id: <200105221623.f4MGN5S10915@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: sandeen@sgi.com, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Tue, 22 May 2001 11:04:55 CDT." <Pine.LNX.4.33.0105221057420.5964-100000@osage.ncsa.uiuc.edu> 
Mime-Version: 1.0
Content-Type: multipart/mixed ;
	boundary="==_Exmh_-18885651360"
Date: Tue, 22 May 2001 11:23:05 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This is a multipart MIME message.

--==_Exmh_-18885651360
Content-Type: text/plain


Try the attached patch - it is against the 2.4.4 development tree, but it
should work in the release tree as well. I am still benchmarking and
scratching my head about this one, but it should help memory usage in
xfs. Is it possible to send the output of cat /proc/slabcache whilst
iozone is on its way to failing?

Steve


> Eric,
> 
> I found your name and address on a thread about linux & xfs.  I'm also
> seeing the "kernel: __alloc_pages: 0-order allocation
> failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
> reiserfs, and xfs with iozone.  The xfs performance was looking great (50%
> better on writes than ext2 or reiserfs) until the box fell over scrolling
> these errors.  It hangs the box and only a hard reset will suffice to
> break out of it.
> 
> I seem to be able to reproduce the error by running iozone this way:
> 
> 	iozone -s 4000m
> 
> That's a big iozone run, but the systems all have 2gig memory so I've got
> to go big to get out of linux cache and see meaningful numbers.  Has there
> been any progress with this bug?  If you'd like, I can get you a temporary
> acct. on the system where I'm testing.
> 
> -Galen
> 
>  --
> +
> Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> National Center for Supercomputing Applications           (217) 244-3473
> 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


--==_Exmh_-18885651360
Content-Type: application/x-patch ; name="inode.patch"
Content-Description: inode.patch
Content-Disposition: attachment; filename="inode.patch"


===========================================================================
Index: linux/fs/xfs/xfs_vnodeops.c
===========================================================================

--- /usr/tmp/TmpDir.2645-0/linux/fs/xfs/xfs_vnodeops.c_1.502	Mon May 21 11:00:44 2001
+++ linux/fs/xfs/xfs_vnodeops.c	Mon May 21 10:50:35 2001
@@ -5133,6 +5133,10 @@
 	vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip));
 	mrunlock(&ih->ih_lock);
 
+	if (!ip->i_update_core && (ip->i_itemp == NULL)) {
+		return xfs_finish_reclaim(ip, locked);
+	}
+
 	if (locked) {
 		xfs_ifunlock(ip);
 		xfs_iunlock(ip, XFS_ILOCK_EXCL);

--==_Exmh_-18885651360--



From owner-linux-xfs@oss.sgi.com Tue May 22 09:30:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MGU3S09439
	for linux-xfs-outgoing; Tue, 22 May 2001 09:30:03 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MGU2F09436
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:30:02 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MGU0b04971;
	Tue, 22 May 2001 11:30:01 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MGU0M27169;
	Tue, 22 May 2001 11:30:00 -0500 (CDT)
Date: Tue, 22 May 2001 11:30:00 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <sandeen@sgi.com>, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <200105221623.f4MGN5S10915@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221127140.5964-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve,

The attached files were created with "/cat /proc/slabinfo" (my 2.4.2-XFS
doesn't show a slabcache).  slab.1 was written immediately after iozone
started, and slab.2 immediately after the first :

	__alloc_pages: 0-order allocation failed.

(approximately 10s later).

I'm looking at the patch now...

-Galen

 On Tue, 22 May 2001,
Steve Lord wrote:

>
> Try the attached patch - it is against the 2.4.4 development tree, but it
> should work in the release tree as well. I am still benchmarking and
> scratching my head about this one, but it should help memory usage in
> xfs. Is it possible to send the output of cat /proc/slabcache whilst
> iozone is on its way to failing?
>
> Steve
>
>
> > Eric,
> >
> > I found your name and address on a thread about linux & xfs.  I'm also
> > seeing the "kernel: __alloc_pages: 0-order allocation
> > failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
> > reiserfs, and xfs with iozone.  The xfs performance was looking great (50%
> > better on writes than ext2 or reiserfs) until the box fell over scrolling
> > these errors.  It hangs the box and only a hard reset will suffice to
> > break out of it.
> >
> > I seem to be able to reproduce the error by running iozone this way:
> >
> > 	iozone -s 4000m
> >
> > That's a big iozone run, but the systems all have 2gig memory so I've got
> > to go big to get out of linux cache and see meaningful numbers.  Has there
> > been any progress with this bug?  If you'd like, I can get you a temporary
> > acct. on the system where I'm testing.
> >
> > -Galen
> >
> >  --
> > +
> > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > National Center for Supercomputing Applications           (217) 244-3473
> > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Tue May 22 09:34:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MGYJZ09592
	for linux-xfs-outgoing; Tue, 22 May 2001 09:34:19 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MGYDF09586
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:34:13 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAB09486
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:34:12 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1903096; Tue, 22 May 2001 11:32:54 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA05631; Tue, 22 May 2001 11:32:54 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MGZv511029; Tue, 22 May 2001 11:35:57 -0500
Message-Id: <200105221635.f4MGZv511029@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Tue, 22 May 2001 11:30:00 CDT." <Pine.LNX.4.33.0105221127140.5964-100000@osage.ncsa.uiuc.edu> 
Date: Tue, 22 May 2001 11:35:57 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Steve,
> 
> The attached files were created with "/cat /proc/slabinfo" (my 2.4.2-XFS
> doesn't show a slabcache).  slab.1 was written immediately after iozone
> started, and slab.2 immediately after the first :

Sorry slabinfo was what I meant, Hmm, I didn't get an attachment there.

> 
> 	__alloc_pages: 0-order allocation failed.
> 
> (approximately 10s later).
> 
> I'm looking at the patch now...

I am not sure it will really help you - the memory it frees is inodes, so
unless you have lots of inodes in cache it will not make a difference.

Steve

p.s. I presume you are using a HIGHMEM kernel.

> 
> -Galen
> 
>  On Tue, 22 May 2001,
> Steve Lord wrote:
> 
> >
> > Try the attached patch - it is against the 2.4.4 development tree, but it
> > should work in the release tree as well. I am still benchmarking and
> > scratching my head about this one, but it should help memory usage in
> > xfs. Is it possible to send the output of cat /proc/slabcache whilst
> > iozone is on its way to failing?
> >
> > Steve
> >
> >
> > > Eric,
> > >
> > > I found your name and address on a thread about linux & xfs.  I'm also
> > > seeing the "kernel: __alloc_pages: 0-order allocation
> > > failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
> > > reiserfs, and xfs with iozone.  The xfs performance was looking great (50
> %
> > > better on writes than ext2 or reiserfs) until the box fell over scrolling
> > > these errors.  It hangs the box and only a hard reset will suffice to
> > > break out of it.
> > >
> > > I seem to be able to reproduce the error by running iozone this way:
> > >
> > > 	iozone -s 4000m
> > >
> > > That's a big iozone run, but the systems all have 2gig memory so I've got
> > > to go big to get out of linux cache and see meaningful numbers.  Has ther
> e
> > > been any progress with this bug?  If you'd like, I can get you a temporar
> y
> > > acct. on the system where I'm testing.
> > >
> > > -Galen
> > >
> > >  --
> > > +
> > > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > > National Center for Supercomputing Applications           (217) 244-3473
> > > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
> >
> >
> 
> -- 
> +
> Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> National Center for Supercomputing Applications           (217) 244-3473
> 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820



From owner-linux-xfs@oss.sgi.com Tue May 22 09:40:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MGeEa09706
	for linux-xfs-outgoing; Tue, 22 May 2001 09:40:14 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MGeBF09703
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 09:40:11 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MGeAb05621;
	Tue, 22 May 2001 11:40:10 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MGeAM00387;
	Tue, 22 May 2001 11:40:10 -0500 (CDT)
Date: Tue, 22 May 2001 11:40:10 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <sandeen@sgi.com>, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <200105221635.f4MGZv511029@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221136290.5964-300000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903347710-1179029972-990549610=:5964"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1903347710-1179029972-990549610=:5964
Content-Type: TEXT/PLAIN; charset=US-ASCII


oops...there you go.
The patch you sent didn't apply with patch, but I was able to paste it in
manually--building and testing the new kernel now...

-Galen

On Tue, 22 May 2001, Steve Lord wrote:

> > Steve,
> >
> > The attached files were created with "/cat /proc/slabinfo" (my 2.4.2-XFS
> > doesn't show a slabcache).  slab.1 was written immediately after iozone
> > started, and slab.2 immediately after the first :
>
> Sorry slabinfo was what I meant, Hmm, I didn't get an attachment there.
>
> >
> > 	__alloc_pages: 0-order allocation failed.
> >
> > (approximately 10s later).
> >
> > I'm looking at the patch now...
>
> I am not sure it will really help you - the memory it frees is inodes, so
> unless you have lots of inodes in cache it will not make a difference.
>
> Steve
>
> p.s. I presume you are using a HIGHMEM kernel.
>
> >
> > -Galen
> >
> >  On Tue, 22 May 2001,
> > Steve Lord wrote:
> >
> > >
> > > Try the attached patch - it is against the 2.4.4 development tree, but it
> > > should work in the release tree as well. I am still benchmarking and
> > > scratching my head about this one, but it should help memory usage in
> > > xfs. Is it possible to send the output of cat /proc/slabcache whilst
> > > iozone is on its way to failing?
> > >
> > > Steve
> > >
> > >
> > > > Eric,
> > > >
> > > > I found your name and address on a thread about linux & xfs.  I'm also
> > > > seeing the "kernel: __alloc_pages: 0-order allocation
> > > > failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
> > > > reiserfs, and xfs with iozone.  The xfs performance was looking great (50
> > %
> > > > better on writes than ext2 or reiserfs) until the box fell over scrolling
> > > > these errors.  It hangs the box and only a hard reset will suffice to
> > > > break out of it.
> > > >
> > > > I seem to be able to reproduce the error by running iozone this way:
> > > >
> > > > 	iozone -s 4000m
> > > >
> > > > That's a big iozone run, but the systems all have 2gig memory so I've got
> > > > to go big to get out of linux cache and see meaningful numbers.  Has ther
> > e
> > > > been any progress with this bug?  If you'd like, I can get you a temporar
> > y
> > > > acct. on the system where I'm testing.
> > > >
> > > > -Galen
> > > >
> > > >  --
> > > > +
> > > > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > > > National Center for Supercomputing Applications           (217) 244-3473
> > > > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
> > >
> > >
> >
> > --
> > +
> > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > National Center for Supercomputing Applications           (217) 244-3473
> > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820

---1903347710-1179029972-990549610=:5964
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="slab.2"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105221140090.5964@osage.ncsa.uiuc.edu>
Content-Description: 
Content-Disposition: attachment; filename="slab.2"

c2xhYmluZm8gLSB2ZXJzaW9uOiAxLjEgKFNNUCkNCmttZW1fY2FjaGUgICAg
ICAgICAgICA4NSAgICAgODUgICAgMjMyICAgIDUgICAgNSAgICAxIDogIDI1
MiAgMTI2DQpuZnNfcmVhZF9kYXRhICAgICAgICAgIDAgICAgICAwICAgIDM4
NCAgICAwICAgIDAgICAgMSA6ICAxMjQgICA2Mg0KbmZzX3dyaXRlX2RhdGEg
ICAgICAgICAwICAgICAgMCAgICAzODQgICAgMCAgICAwICAgIDEgOiAgMTI0
ICAgNjINCm5mc19wYWdlICAgICAgICAgICAgICAgMCAgICAgIDAgICAgIDk2
ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQp4ZnNfY2hhc2hsaXN0ICAg
ICAgICAgIDEgICAgMjAyICAgICAxNiAgICAxICAgIDEgICAgMSA6ICAyNTIg
IDEyNg0KeGZzX2lsaSAgICAgICAgICAgICAgICAzICAgICA1NiAgICAxMzYg
ICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnhmc19pZm9yayAgICAgICAg
ICAgICAgMCAgICAgIDAgICAgIDU2ICAgIDAgICAgMCAgICAxIDogIDI1MiAg
MTI2DQp4ZnNfZWZpX2l0ZW0gICAgICAgICAgIDAgICAgICAwICAgIDI2MCAg
ICAwICAgIDAgICAgMSA6ICAxMjQgICA2Mg0KeGZzX2VmZF9pdGVtICAgICAg
ICAgICAwICAgICAgMCAgICAyNjAgICAgMCAgICAwICAgIDEgOiAgMTI0ICAg
NjINCnhmc19idWZfaXRlbSAgICAgICAgICAyMyAgICAgMjYgICAgMTQ4ICAg
IDEgICAgMSAgICAxIDogIDI1MiAgMTI2DQp4ZnNfZGFidWYgICAgICAgICAg
ICAgIDAgICAgICAwICAgICAxNiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEy
Ng0KeGZzX2RhX3N0YXRlICAgICAgICAgICAwICAgICAgMCAgICAzNDAgICAg
MCAgICAwICAgIDEgOiAgMTI0ICAgNjINCnhmc19nYXAgICAgICAgICAgICAg
ICAgMCAgICAgIDAgICAgIDE2ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2
DQp4ZnNfdHJhbnMgICAgICAgICAgICAgMTIgICAgIDEyICAgIDMyMCAgICAx
ICAgIDEgICAgMSA6ICAxMjQgICA2Mg0KeGZzX2lub2RlICAgICAgICAgICAg
ICAzICAgICAgNyAgICA1MzYgICAgMSAgICAxICAgIDEgOiAgMTI0ICAgNjIN
Cnhmc19idHJlZV9jdXIgICAgICAgICAyOCAgICAgMjggICAgMTQwICAgIDEg
ICAgMSAgICAxIDogIDI1MiAgMTI2DQp4ZnNfYm1hcF9mcmVlX2l0ZW0gICAg
ICAwICAgICAgMCAgICAgMTYgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYN
CnRjcF90d19idWNrZXQgICAgICAgICAgMCAgICAgIDAgICAgIDk2ICAgIDAg
ICAgMCAgICAxIDogIDI1MiAgMTI2DQp0Y3BfYmluZF9idWNrZXQgICAgICAg
MTEgICAgMjI2ICAgICAzMiAgICAyICAgIDIgICAgMSA6ICAyNTIgIDEyNg0K
dGNwX29wZW5fcmVxdWVzdCAgICAgICAwICAgICAgMCAgICAgNjQgICAgMCAg
ICAwICAgIDEgOiAgMjUyICAxMjYNCmluZXRfcGVlcl9jYWNoZSAgICAgICAg
MCAgICAgIDAgICAgIDY0ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQpp
cF9maWJfaGFzaCAgICAgICAgICAgMTEgICAgMjI2ICAgICAzMiAgICAyICAg
IDIgICAgMSA6ICAyNTIgIDEyNg0KaXBfZHN0X2NhY2hlICAgICAgICAgIDI3
ICAgICA3MiAgICAxNjAgICAgMyAgICAzICAgIDEgOiAgMjUyICAxMjYNCmFy
cF9jYWNoZSAgICAgICAgICAgICAxMCAgICAgNjAgICAgMTI4ICAgIDIgICAg
MiAgICAxIDogIDI1MiAgMTI2DQp1aGNpX3VyYl9wcml2ICAgICAgICAgIDAg
ICAgICAwICAgICAzMiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0KdWhj
aV9xaCAgICAgICAgICAgICAgICAwICAgICAgMCAgICAgMzIgICAgMCAgICAw
ICAgIDEgOiAgMjUyICAxMjYNCnVoY2lfdGQgICAgICAgICAgICAgICAgMCAg
ICAgIDAgICAgIDY0ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQpibGtk
ZXZfcmVxdWVzdHMgICAgNTI0MTYgIDUyNDQwICAgICA5NiAxMzExIDEzMTEg
ICAgMSA6ICAyNTIgIDEyNg0KZG5vdGlmeSBjYWNoZSAgICAgICAgICAwICAg
ICAgMCAgICAgMjAgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYNCmZpbGUg
bG9jayBjYWNoZSAgICAgICAgMyAgICAgODQgICAgIDkyICAgIDIgICAgMiAg
ICAxIDogIDI1MiAgMTI2DQpmYXN5bmMgY2FjaGUgICAgICAgICAgIDAgICAg
ICAwICAgICAxNiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0KdWlkX2Nh
Y2hlICAgICAgICAgICAgICAyICAgIDExMyAgICAgMzIgICAgMSAgICAxICAg
IDEgOiAgMjUyICAxMjYNCnNrYnVmZl9oZWFkX2NhY2hlICAgIDM2NiAgICA1
NTIgICAgMTYwICAgMjMgICAyMyAgICAxIDogIDI1MiAgMTI2DQpzb2NrICAg
ICAgICAgICAgICAgICAgNDAgICAgIDUwICAgIDgwMCAgIDEwICAgMTAgICAg
MSA6ICAxMjQgICA2Mg0KcGFnZV9idWZfdCAgICAgICAgICAgIDQ4ICAgICA0
OCAgICAxNjAgICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnBhZ2VfYnVm
X3JlZ190ICAgICAgICAgMSAgICAxMTMgICAgIDMyICAgIDEgICAgMSAgICAx
IDogIDI1MiAgMTI2DQphdmxfb2JqZWN0X3QgICAgICAgICAgIDIgICAgMTEz
ICAgICAzMiAgICAxICAgIDEgICAgMSA6ICAyNTIgIDEyNg0KYXZsX2VudHJ5
X3QgICAgICAgICAgMTMwICAgIDIyNiAgICAgMzIgICAgMiAgICAyICAgIDEg
OiAgMjUyICAxMjYNCmlub2RlX2NhY2hlICAgICAgICAgIDc3NiAgICA3NzYg
ICAgNDgwICAgOTcgICA5NyAgICAxIDogIDEyNCAgIDYyDQpiZGV2X2NhY2hl
ICAgICAgICAgICAgIDggICAgMTE4ICAgICA2NCAgICAyICAgIDIgICAgMSA6
ICAyNTIgIDEyNg0Kc2lncXVldWUgICAgICAgICAgICAgIDU4ICAgICA1OCAg
ICAxMzIgICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCmtpb2J1ZiAgICAg
ICAgICAgICAgICAgOSAgICAgNjAgICAgMTI4ICAgIDIgICAgMiAgICAxIDog
IDI1MiAgMTI2DQpkZW50cnlfY2FjaGUgICAgICAgIDExNzAgICAxMTcwICAg
IDEyOCAgIDM5ICAgMzkgICAgMSA6ICAyNTIgIDEyNg0KZmlscCAgICAgICAg
ICAgICAgICAgMzAzICAgIDM2MCAgICAgOTYgICAgOSAgICA5ICAgIDEgOiAg
MjUyICAxMjYNCm5hbWVzX2NhY2hlICAgICAgICAgICAgMiAgICAgIDIgICA0
MDk2ICAgIDIgICAgMiAgICAxIDogICA2MCAgIDMwDQpidWZmZXJfaGVhZCAg
ICAgICAzMjk3MDcgNDQ4MzYwICAgICA5NiAxMDM4MiAxMTIwOSAgICAxIDog
IDI1MiAgMTI2DQptbV9zdHJ1Y3QgICAgICAgICAgICAgNzIgICAgIDcyICAg
IDE2MCAgICAzICAgIDMgICAgMSA6ICAyNTIgIDEyNg0Kdm1fYXJlYV9zdHJ1
Y3QgICAgICAgNzYwICAgIDgyNiAgICAgNjQgICAxNCAgIDE0ICAgIDEgOiAg
MjUyICAxMjYNCmZzX2NhY2hlICAgICAgICAgICAgIDE3NyAgICAxNzcgICAg
IDY0ICAgIDMgICAgMyAgICAxIDogIDI1MiAgMTI2DQpmaWxlc19jYWNoZSAg
ICAgICAgICAxMDggICAgMTA4ICAgIDQxNiAgIDEyICAgMTIgICAgMSA6ICAx
MjQgICA2Mg0Kc2lnbmFsX2FjdCAgICAgICAgICAgMTExICAgIDExMSAgIDEz
MTIgICAzNyAgIDM3ICAgIDEgOiAgIDYwICAgMzANCnNpemUtMTMxMDcyKERN
QSkgICAgICAgMCAgICAgIDAgMTMxMDcyICAgIDAgICAgMCAgIDMyIDogICAg
MCAgICAwDQpzaXplLTEzMTA3MiAgICAgICAgICAgIDAgICAgICAwIDEzMTA3
MiAgICAwICAgIDAgICAzMiA6ICAgIDAgICAgMA0Kc2l6ZS02NTUzNihETUEp
ICAgICAgICAwICAgICAgMCAgNjU1MzYgICAgMCAgICAwICAgMTYgOiAgICAw
ICAgIDANCnNpemUtNjU1MzYgICAgICAgICAgICAgMyAgICAgIDMgIDY1NTM2
ICAgIDMgICAgMyAgIDE2IDogICAgMCAgICAwDQpzaXplLTMyNzY4KERNQSkg
ICAgICAgIDEgICAgICAxICAzMjc2OCAgICAxICAgIDEgICAgOCA6ICAgIDAg
ICAgMA0Kc2l6ZS0zMjc2OCAgICAgICAgICAgICAwICAgICAgMCAgMzI3Njgg
ICAgMCAgICAwICAgIDggOiAgICAwICAgIDANCnNpemUtMTYzODQoRE1BKSAg
ICAgICAgMCAgICAgIDAgIDE2Mzg0ICAgIDAgICAgMCAgICA0IDogICAgMCAg
ICAwDQpzaXplLTE2Mzg0ICAgICAgICAgICAgNjUgICAgIDY1ICAxNjM4NCAg
IDY1ICAgNjUgICAgNCA6ICAgIDAgICAgMA0Kc2l6ZS04MTkyKERNQSkgICAg
ICAgICAyICAgICAgMiAgIDgxOTIgICAgMiAgICAyICAgIDIgOiAgICAwICAg
IDANCnNpemUtODE5MiAgICAgICAgICAgICAxMyAgICAgMTMgICA4MTkyICAg
MTMgICAxMyAgICAyIDogICAgMCAgICAwDQpzaXplLTQwOTYoRE1BKSAgICAg
ICAgIDAgICAgICAwICAgNDA5NiAgICAwICAgIDAgICAgMSA6ICAgNjAgICAz
MA0Kc2l6ZS00MDk2ICAgICAgICAgICAgIDE0ICAgICAxNCAgIDQwOTYgICAx
NCAgIDE0ICAgIDEgOiAgIDYwICAgMzANCnNpemUtMjA0OChETUEpICAgICAg
ICAgMSAgICAgIDIgICAyMDQ4ICAgIDEgICAgMSAgICAxIDogICA2MCAgIDMw
DQpzaXplLTIwNDggICAgICAgICAgIDEyNjcgICAxMzI2ICAgMjA0OCAgNjYz
ICA2NjMgICAgMSA6ICAgNjAgICAzMA0Kc2l6ZS0xMDI0KERNQSkgICAgICAg
ICAxICAgICAgNCAgIDEwMjQgICAgMSAgICAxICAgIDEgOiAgMTI0ICAgNjIN
CnNpemUtMTAyNCAgICAgICAgICAgIDEyNSAgICAxMzIgICAxMDI0ICAgMzMg
ICAzMyAgICAxIDogIDEyNCAgIDYyDQpzaXplLTUxMihETUEpICAgICAgICAg
IDEgICAgICA4ICAgIDUxMiAgICAxICAgIDEgICAgMSA6ICAxMjQgICA2Mg0K
c2l6ZS01MTIgICAgICAgICAgICAgODY4ICAgIDg4MCAgICA1MTIgIDExMCAg
MTEwICAgIDEgOiAgMTI0ICAgNjINCnNpemUtMjU2KERNQSkgICAgICAgIDEy
OSAgICAxMzUgICAgMjU2ICAgIDkgICAgOSAgICAxIDogIDI1MiAgMTI2DQpz
aXplLTI1NiAgICAgICAgICAgICAxMjAgICAgMTIwICAgIDI1NiAgICA4ICAg
IDggICAgMSA6ICAyNTIgIDEyNg0Kc2l6ZS0xMjgoRE1BKSAgICAgICAgICA5
ICAgICA2MCAgICAxMjggICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnNp
emUtMTI4ICAgICAgICAgICAgIDY5MCAgICA2OTAgICAgMTI4ICAgMjMgICAy
MyAgICAxIDogIDI1MiAgMTI2DQpzaXplLTY0KERNQSkgICAgICAgICAgIDAg
ICAgICAwICAgICA2NCAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0Kc2l6
ZS02NCAgICAgICAgICAgICAgMjUxICAgIDM1NCAgICAgNjQgICAgNiAgICA2
ICAgIDEgOiAgMjUyICAxMjYNCnNpemUtMzIoRE1BKSAgICAgICAgICAgMSAg
ICAxMTMgICAgIDMyICAgIDEgICAgMSAgICAxIDogIDI1MiAgMTI2DQpzaXpl
LTMyICAgICAgICAgICAgIDE1ODIgICAxNTgyICAgICAzMiAgIDE0ICAgMTQg
ICAgMSA6ICAyNTIgIDEyNg0K
---1903347710-1179029972-990549610=:5964
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="slab.1"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105221140091.5964@osage.ncsa.uiuc.edu>
Content-Description: 
Content-Disposition: attachment; filename="slab.1"

c2xhYmluZm8gLSB2ZXJzaW9uOiAxLjEgKFNNUCkNCmttZW1fY2FjaGUgICAg
ICAgICAgICA4NSAgICAgODUgICAgMjMyICAgIDUgICAgNSAgICAxIDogIDI1
MiAgMTI2DQpuZnNfcmVhZF9kYXRhICAgICAgICAgIDAgICAgICAwICAgIDM4
NCAgICAwICAgIDAgICAgMSA6ICAxMjQgICA2Mg0KbmZzX3dyaXRlX2RhdGEg
ICAgICAgICAwICAgICAgMCAgICAzODQgICAgMCAgICAwICAgIDEgOiAgMTI0
ICAgNjINCm5mc19wYWdlICAgICAgICAgICAgICAgMCAgICAgIDAgICAgIDk2
ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQp4ZnNfY2hhc2hsaXN0ICAg
ICAgICAgIDEgICAgMjAyICAgICAxNiAgICAxICAgIDEgICAgMSA6ICAyNTIg
IDEyNg0KeGZzX2lsaSAgICAgICAgICAgICAgICAzICAgICA1NiAgICAxMzYg
ICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnhmc19pZm9yayAgICAgICAg
ICAgICAgMCAgICAgIDAgICAgIDU2ICAgIDAgICAgMCAgICAxIDogIDI1MiAg
MTI2DQp4ZnNfZWZpX2l0ZW0gICAgICAgICAgIDAgICAgICAwICAgIDI2MCAg
ICAwICAgIDAgICAgMSA6ICAxMjQgICA2Mg0KeGZzX2VmZF9pdGVtICAgICAg
ICAgICAwICAgICAgMCAgICAyNjAgICAgMCAgICAwICAgIDEgOiAgMTI0ICAg
NjINCnhmc19idWZfaXRlbSAgICAgICAgICAgMyAgICAgMjYgICAgMTQ4ICAg
IDEgICAgMSAgICAxIDogIDI1MiAgMTI2DQp4ZnNfZGFidWYgICAgICAgICAg
ICAgIDAgICAgICAwICAgICAxNiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEy
Ng0KeGZzX2RhX3N0YXRlICAgICAgICAgICAwICAgICAgMCAgICAzNDAgICAg
MCAgICAwICAgIDEgOiAgMTI0ICAgNjINCnhmc19nYXAgICAgICAgICAgICAg
ICAgMCAgICAgIDAgICAgIDE2ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2
DQp4ZnNfdHJhbnMgICAgICAgICAgICAgIDAgICAgICAwICAgIDMyMCAgICAw
ICAgIDAgICAgMSA6ICAxMjQgICA2Mg0KeGZzX2lub2RlICAgICAgICAgICAg
ICAzICAgICAgNyAgICA1MzYgICAgMSAgICAxICAgIDEgOiAgMTI0ICAgNjIN
Cnhmc19idHJlZV9jdXIgICAgICAgICAgMCAgICAgIDAgICAgMTQwICAgIDAg
ICAgMCAgICAxIDogIDI1MiAgMTI2DQp4ZnNfYm1hcF9mcmVlX2l0ZW0gICAg
ICAwICAgICAgMCAgICAgMTYgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYN
CnRjcF90d19idWNrZXQgICAgICAgICAgMCAgICAgIDAgICAgIDk2ICAgIDAg
ICAgMCAgICAxIDogIDI1MiAgMTI2DQp0Y3BfYmluZF9idWNrZXQgICAgICAg
MTEgICAgMjI2ICAgICAzMiAgICAyICAgIDIgICAgMSA6ICAyNTIgIDEyNg0K
dGNwX29wZW5fcmVxdWVzdCAgICAgICAwICAgICAgMCAgICAgNjQgICAgMCAg
ICAwICAgIDEgOiAgMjUyICAxMjYNCmluZXRfcGVlcl9jYWNoZSAgICAgICAg
MCAgICAgIDAgICAgIDY0ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQpp
cF9maWJfaGFzaCAgICAgICAgICAgMTEgICAgMjI2ICAgICAzMiAgICAyICAg
IDIgICAgMSA6ICAyNTIgIDEyNg0KaXBfZHN0X2NhY2hlICAgICAgICAgIDI3
ICAgICA3MiAgICAxNjAgICAgMyAgICAzICAgIDEgOiAgMjUyICAxMjYNCmFy
cF9jYWNoZSAgICAgICAgICAgICAxMCAgICAgNjAgICAgMTI4ICAgIDIgICAg
MiAgICAxIDogIDI1MiAgMTI2DQp1aGNpX3VyYl9wcml2ICAgICAgICAgIDAg
ICAgICAwICAgICAzMiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0KdWhj
aV9xaCAgICAgICAgICAgICAgICAwICAgICAgMCAgICAgMzIgICAgMCAgICAw
ICAgIDEgOiAgMjUyICAxMjYNCnVoY2lfdGQgICAgICAgICAgICAgICAgMCAg
ICAgIDAgICAgIDY0ICAgIDAgICAgMCAgICAxIDogIDI1MiAgMTI2DQpibGtk
ZXZfcmVxdWVzdHMgICAgNTI0MTYgIDUyNDQwICAgICA5NiAxMzExIDEzMTEg
ICAgMSA6ICAyNTIgIDEyNg0KZG5vdGlmeSBjYWNoZSAgICAgICAgICAwICAg
ICAgMCAgICAgMjAgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYNCmZpbGUg
bG9jayBjYWNoZSAgICAgICAgMyAgICAgODQgICAgIDkyICAgIDIgICAgMiAg
ICAxIDogIDI1MiAgMTI2DQpmYXN5bmMgY2FjaGUgICAgICAgICAgIDAgICAg
ICAwICAgICAxNiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0KdWlkX2Nh
Y2hlICAgICAgICAgICAgICAyICAgIDExMyAgICAgMzIgICAgMSAgICAxICAg
IDEgOiAgMjUyICAxMjYNCnNrYnVmZl9oZWFkX2NhY2hlICAgIDM2NiAgICA1
NTIgICAgMTYwICAgMjMgICAyMyAgICAxIDogIDI1MiAgMTI2DQpzb2NrICAg
ICAgICAgICAgICAgICAgNDAgICAgIDUwICAgIDgwMCAgIDEwICAgMTAgICAg
MSA6ICAxMjQgICA2Mg0KcGFnZV9idWZfdCAgICAgICAgICAgICA3ICAgICA0
OCAgICAxNjAgICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnBhZ2VfYnVm
X3JlZ190ICAgICAgICAgMSAgICAxMTMgICAgIDMyICAgIDEgICAgMSAgICAx
IDogIDI1MiAgMTI2DQphdmxfb2JqZWN0X3QgICAgICAgICAgIDIgICAgMTEz
ICAgICAzMiAgICAxICAgIDEgICAgMSA6ICAyNTIgIDEyNg0KYXZsX2VudHJ5
X3QgICAgICAgICAgICA0ICAgIDIyNiAgICAgMzIgICAgMiAgICAyICAgIDEg
OiAgMjUyICAxMjYNCmlub2RlX2NhY2hlICAgICAgICAgIDc3NiAgICA3NzYg
ICAgNDgwICAgOTcgICA5NyAgICAxIDogIDEyNCAgIDYyDQpiZGV2X2NhY2hl
ICAgICAgICAgICAgIDggICAgMTE4ICAgICA2NCAgICAyICAgIDIgICAgMSA6
ICAyNTIgIDEyNg0Kc2lncXVldWUgICAgICAgICAgICAgICAwICAgICAgMCAg
ICAxMzIgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYNCmtpb2J1ZiAgICAg
ICAgICAgICAgICAgNiAgICAgNjAgICAgMTI4ICAgIDIgICAgMiAgICAxIDog
IDI1MiAgMTI2DQpkZW50cnlfY2FjaGUgICAgICAgIDExNzAgICAxMTcwICAg
IDEyOCAgIDM5ICAgMzkgICAgMSA6ICAyNTIgIDEyNg0KZmlscCAgICAgICAg
ICAgICAgICAgMzAzICAgIDM2MCAgICAgOTYgICAgOSAgICA5ICAgIDEgOiAg
MjUyICAxMjYNCm5hbWVzX2NhY2hlICAgICAgICAgICAgMSAgICAgIDEgICA0
MDk2ICAgIDEgICAgMSAgICAxIDogICA2MCAgIDMwDQpidWZmZXJfaGVhZCAg
ICAgICAzMDM4OTQgNDc5MjQwICAgICA5NiAxMTQxNiAxMTk4MSAgICAxIDog
IDI1MiAgMTI2DQptbV9zdHJ1Y3QgICAgICAgICAgICAgNzIgICAgIDcyICAg
IDE2MCAgICAzICAgIDMgICAgMSA6ICAyNTIgIDEyNg0Kdm1fYXJlYV9zdHJ1
Y3QgICAgICAgNjU3ICAgIDgyNiAgICAgNjQgICAxNCAgIDE0ICAgIDEgOiAg
MjUyICAxMjYNCmZzX2NhY2hlICAgICAgICAgICAgIDE3NyAgICAxNzcgICAg
IDY0ICAgIDMgICAgMyAgICAxIDogIDI1MiAgMTI2DQpmaWxlc19jYWNoZSAg
ICAgICAgICAxMDggICAgMTA4ICAgIDQxNiAgIDEyICAgMTIgICAgMSA6ICAx
MjQgICA2Mg0Kc2lnbmFsX2FjdCAgICAgICAgICAgMTExICAgIDExMSAgIDEz
MTIgICAzNyAgIDM3ICAgIDEgOiAgIDYwICAgMzANCnNpemUtMTMxMDcyKERN
QSkgICAgICAgMCAgICAgIDAgMTMxMDcyICAgIDAgICAgMCAgIDMyIDogICAg
MCAgICAwDQpzaXplLTEzMTA3MiAgICAgICAgICAgIDAgICAgICAwIDEzMTA3
MiAgICAwICAgIDAgICAzMiA6ICAgIDAgICAgMA0Kc2l6ZS02NTUzNihETUEp
ICAgICAgICAwICAgICAgMCAgNjU1MzYgICAgMCAgICAwICAgMTYgOiAgICAw
ICAgIDANCnNpemUtNjU1MzYgICAgICAgICAgICAgMyAgICAgIDMgIDY1NTM2
ICAgIDMgICAgMyAgIDE2IDogICAgMCAgICAwDQpzaXplLTMyNzY4KERNQSkg
ICAgICAgIDEgICAgICAxICAzMjc2OCAgICAxICAgIDEgICAgOCA6ICAgIDAg
ICAgMA0Kc2l6ZS0zMjc2OCAgICAgICAgICAgICAwICAgICAgMCAgMzI3Njgg
ICAgMCAgICAwICAgIDggOiAgICAwICAgIDANCnNpemUtMTYzODQoRE1BKSAg
ICAgICAgMCAgICAgIDAgIDE2Mzg0ICAgIDAgICAgMCAgICA0IDogICAgMCAg
ICAwDQpzaXplLTE2Mzg0ICAgICAgICAgICAgNjUgICAgIDY1ICAxNjM4NCAg
IDY1ICAgNjUgICAgNCA6ICAgIDAgICAgMA0Kc2l6ZS04MTkyKERNQSkgICAg
ICAgICAyICAgICAgMiAgIDgxOTIgICAgMiAgICAyICAgIDIgOiAgICAwICAg
IDANCnNpemUtODE5MiAgICAgICAgICAgICAxMyAgICAgMTMgICA4MTkyICAg
MTMgICAxMyAgICAyIDogICAgMCAgICAwDQpzaXplLTQwOTYoRE1BKSAgICAg
ICAgIDAgICAgICAwICAgNDA5NiAgICAwICAgIDAgICAgMSA6ICAgNjAgICAz
MA0Kc2l6ZS00MDk2ICAgICAgICAgICAgIDE0ICAgICAxNCAgIDQwOTYgICAx
NCAgIDE0ICAgIDEgOiAgIDYwICAgMzANCnNpemUtMjA0OChETUEpICAgICAg
ICAgMSAgICAgIDIgICAyMDQ4ICAgIDEgICAgMSAgICAxIDogICA2MCAgIDMw
DQpzaXplLTIwNDggICAgICAgICAgIDEyNzEgICAxMzI4ICAgMjA0OCAgNjY0
ICA2NjQgICAgMSA6ICAgNjAgICAzMA0Kc2l6ZS0xMDI0KERNQSkgICAgICAg
ICAxICAgICAgNCAgIDEwMjQgICAgMSAgICAxICAgIDEgOiAgMTI0ICAgNjIN
CnNpemUtMTAyNCAgICAgICAgICAgIDEzMiAgICAxMzIgICAxMDI0ICAgMzMg
ICAzMyAgICAxIDogIDEyNCAgIDYyDQpzaXplLTUxMihETUEpICAgICAgICAg
IDEgICAgICA4ICAgIDUxMiAgICAxICAgIDEgICAgMSA6ICAxMjQgICA2Mg0K
c2l6ZS01MTIgICAgICAgICAgICAgODY4ICAgIDg4MCAgICA1MTIgIDExMCAg
MTEwICAgIDEgOiAgMTI0ICAgNjINCnNpemUtMjU2KERNQSkgICAgICAgIDEy
OSAgICAxMzUgICAgMjU2ICAgIDkgICAgOSAgICAxIDogIDI1MiAgMTI2DQpz
aXplLTI1NiAgICAgICAgICAgICAxMjAgICAgMTIwICAgIDI1NiAgICA4ICAg
IDggICAgMSA6ICAyNTIgIDEyNg0Kc2l6ZS0xMjgoRE1BKSAgICAgICAgICA5
ICAgICA2MCAgICAxMjggICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYNCnNp
emUtMTI4ICAgICAgICAgICAgIDY2MCAgICA2NjAgICAgMTI4ICAgMjIgICAy
MiAgICAxIDogIDI1MiAgMTI2DQpzaXplLTY0KERNQSkgICAgICAgICAgIDAg
ICAgICAwICAgICA2NCAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNg0Kc2l6
ZS02NCAgICAgICAgICAgICAgMjUxICAgIDM1NCAgICAgNjQgICAgNiAgICA2
ICAgIDEgOiAgMjUyICAxMjYNCnNpemUtMzIoRE1BKSAgICAgICAgICAgMSAg
ICAxMTMgICAgIDMyICAgIDEgICAgMSAgICAxIDogIDI1MiAgMTI2DQpzaXpl
LTMyICAgICAgICAgICAgIDE0NjYgICAxNTgyICAgICAzMiAgIDE0ICAgMTQg
ICAgMSA6ICAyNTIgIDEyNg0K
---1903347710-1179029972-990549610=:5964--

From owner-linux-xfs@oss.sgi.com Tue May 22 10:08:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MH8mE11411
	for linux-xfs-outgoing; Tue, 22 May 2001 10:08:48 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MH8kF11408
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:08:46 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MH8ib08399;
	Tue, 22 May 2001 12:08:44 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MH8hM08564;
	Tue, 22 May 2001 12:08:43 -0500 (CDT)
Date: Tue, 22 May 2001 12:08:43 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <sandeen@sgi.com>, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <200105221623.f4MGN5S10915@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221205010.5964-101000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903347710-1026672900-990551323=:5964"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1903347710-1026672900-990551323=:5964
Content-Type: TEXT/PLAIN; charset=US-ASCII

Steve,

I ran "iozone -s 4000m" again with a new kernel (your attached patch).
I'm getting the same errors and have attached a slab.out.gz file showing
slabinfo every 1s during the test.  The __alloc_pages: error shows up a
few seconds into the test.  buffer_head values seem to ramp up
quickly with iozone...

-Galen

 On Tue, 22 May 2001, Steve Lord wrote:

>
> Try the attached patch - it is against the 2.4.4 development tree, but it
> should work in the release tree as well. I am still benchmarking and
> scratching my head about this one, but it should help memory usage in
> xfs. Is it possible to send the output of cat /proc/slabcache whilst
> iozone is on its way to failing?
>
> Steve
>
>
> > Eric,
> >
> > I found your name and address on a thread about linux & xfs.  I'm also
> > seeing the "kernel: __alloc_pages: 0-order allocation
> > failed." error on a 2.4.2-XFS system I just setup.  We're comparing ext2,
> > reiserfs, and xfs with iozone.  The xfs performance was looking great (50%
> > better on writes than ext2 or reiserfs) until the box fell over scrolling
> > these errors.  It hangs the box and only a hard reset will suffice to
> > break out of it.
> >
> > I seem to be able to reproduce the error by running iozone this way:
> >
> > 	iozone -s 4000m
> >
> > That's a big iozone run, but the systems all have 2gig memory so I've got
> > to go big to get out of linux cache and see meaningful numbers.  Has there
> > been any progress with this bug?  If you'd like, I can get you a temporary
> > acct. on the system where I'm testing.
> >
> > -Galen
> >
> >  --
> > +
> > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > National Center for Supercomputing Applications           (217) 244-3473
> > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820

---1903347710-1026672900-990551323=:5964
Content-Type: APPLICATION/octet-stream; name="slab.out.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105221208430.5964@osage.ncsa.uiuc.edu>
Content-Description: 
Content-Disposition: attachment; filename="slab.out.gz"

H4sICDKNCjsAA3NsYWIub3V0AO3dT3PbOJrH8Xu/iuc4c5gtgP/Zt62da1dN
1fTdpdhyR5PEzvhPZntf/ZJ4QBIgKMeUiknkfFFdQGJZPwEgCJKfdpLfn/fy
2+5PyTKx9ldjuv/kf/7+u2TG2F8eP+7eHe5u7+Vv8mX/8Hi4v/tV7H9Z+cs/
f/vHX3/58Gn/6ep6d/1+L0FpyqDJ8qxvyrGy8mv31bL7qs2qX+5uH68e9rub
q5vd025MKEzQ5E3hfjNWLsFm/a+rzCX85+HwtI8jTND4BDNWacLn3R/RGLpX
TdBIW7mgsYpH8b9dwvX73eP7j4fHpynBvSczmf620vdN1Tzh8PEgccmaoLH5
1xNu7x8+xBHhPEhZLcxDlLC/PVx1c/kpmIgyaLLKLPRhnElNuDkz4d3z7SxB
Z9I3tmi+Ng83uy7jhXmwX52Hm93V49PuaX8kIS/MQkI0ij92n2VWVvbh6WF3
9xgF2Cxo8uyrM3m4u7+ZLesiaEpdUdlYLRyLp4f9/ur6+WFMiNdksdSHaBTv
Pu0+X932KcMxXXViPF1/vnr6T7cmrj/sx1NLGhM27dIwooRuD7uJMjLfB7+y
8uxrCfef93fdTvXv570/w61tgkaq4qWEw93+6erzfv8Q75bRgqiWNqkpoZvE
w7urfpOZjuaqUXQJN49P8+26zoLG6sl5bJvbPXxOd3upTNBYXRfH+vD8/vpw
9fzw7urzw+HLFBHNg47i2Dy4hH8Hc3BawtPNiwkvH4t3Hz/c7L8Mq8GdomVW
50W/wVbFuCZt3l9Si2F9hwk3d/dPh9s/ZTabUR+ypS1mTLg9fNzLx/vrD1GG
XuiGpn1xPdzuHv+8u553Yc0m9Xy4SdeDtXnQ+GNx7Ox+/NBt1LdX7/s7gDGp
MiZodE1m5VDNE/opSEpZBk3jgqwdqtk211/63TXnKUzQi4xv/HlxbCbHhIf9
H2PKqnnYffl4df/uX/vrp6AXqxP2d08Pf4bDWLc/9BeLZHvQpeSbwm24bTNU
s5l8158V8wWxap98PPzRnVPPs2tWXYSNjqIaqzjhw+E+ufav26NudBqjcVi9
0NnheucS8rFKz83k2i+531ur8JrVjtXstnj3af+YTmU+NYVxCe7XdtqrdYi5
+aU/r7rLTX9mhV0wU+P70JqhmvXh06fuFujh+To6LVZdL758utp1N/dxTF3V
QaPrYT6KaSbTSegXQh00fkUd60O/TyYh1jRBozu0u6myC7dB3Zq823282kUT
Yf1OortK7t6X10M1OxaPh//b/637JlNnf/n7b//9V58x7rT60vgl967MJfgv
hAnhTPgEO0+wRxKqsrvlC7sQ7PbutagP3bQsJ0RHIx+b8bXxWCwl5FldNVEf
7Ni418Yvuao5khD1waQJ5qUEW3WPhEfmwb0WzUP31LmcEHah0itOv6qH19yX
dJkvJDS2jVaD34u06V8cv+SrxYRoGob9oZgS9MwqjiT0m0jch+Dq73eY+dU/
XtXDN019qKZm2KPGaikhM0VzdB76F/V9U7WYEM2C+61v9MWqv3ZUdXEkwZos
Xg5STE3/4kIfgv3BJ8SHIpsa/2KeD9VSQmlny0GaoCmHnemFPvjvmd6vj0e+
ca9aa3y1mJCV8XKweRk0WfniNWtIiPqQeQVqggTbDtVSQndtjechN0Hjr91H
7yd9QtSHWtd/E1679X5y4dqtu9xsNax6OvAJURcka8ug8QnHUMzvcnEf1t1X
a0LUBVs22dT4BDc1tkgTfk9U0KKCqOA4DFQwTUAFUUFUUAsqKKjgVFDBE+YB
FRRUEBVMZxIVFFRwKSHqAyqo40cF3ZBRQX0jKugKKqgBZ6pghgqiguMwUME0
ARVEBVFBLaigoIJTQQVPmAdUUFBBVDCdSVRQUMGlhKgPqKCOHxV0Q0YF9Y2o
oCuooAacqYI5KogKjsNABdMEVBAVRAW1oIKCCk4FFTxhHlBBQQW3VsE8L/s9
xTe+D00/gGZpFKigoIKLCdHRQAVdQQV9H34AFXSAZHWn9SrYH4uqOTYKVBAV
RAW/ooIFKogKjsNABdMEVBAVRAW1oIKCCk4FFTxhHlBBQQW3VsHGuudi32gf
uofmTKukD6igoIKLCdHRQAVdQQV9H1BB7QQq6N6DCuo8XL4KlqggKjgOAxVM
E1BBVBAV1IIKCio4FVTwhHlABQUV3FgFbW66W/qh8X3Is+4ccVXSB1RQUMHF
hOhooIKuoIK+D6igdgIVdO9BBXUeLl8Fa1QQFRyH8QOoYJkFjVfBYzf1qODU
hy1U0G/7pRfaFx+XUUFUEBVEBVFBVBAV/N4q2Jr++PnG96Goq0yrpA+ooKCC
iwnR0UAFXUEFfR9QQe0EKujegwrqPFy+CjaoICo4DgMVTBNQQVQQFdSCCgoq
OBVU8IR5QAUFFdxYBbO87Dcn3/g+lE1rtUr6gAoKKriYEB0NVNAVVND3ARXU
TqCC7j2ooM7D5atgiwqiguMwUME0ARVEBVFBLaigoIJTQQVPmAdUUFDBrVWw
LvtTyje+D1XTGq2SPqCCggouJkRHAxV0BRX0fUAFtROooHsPKqjzcPEq2C0a
VBAVHIaBCqYJqCAqiApqQQUFFZwKKnjCPKCCggpurIK5bUx3/Hzj+1C33Ue6
KukDKiio4GJCdDRQQVdQQd8HVFA7gQq696CCOg+Xr4IWFUQFx2GggmkCKogK
ooJaUEFBBaeCCp4wD6igoIJbq2BZFN2Z4Bvfh6bp3uCqpA+ooKCCiwnR0UAF
XUEFfR9QQe0EKujegwrqPFy+CmaoICo4DgMVTBNQQVQQFdSCCgoqOBVU8IR5
QAUFFdxaBVvTf7hvfB/aumy1SvqACgoquJgQHQ1U0BVU0PcBFdROoILuPaig
zsPlq2COCqKC4zBQwTQBFUQFUUEtqKCgglNBBU+YB1RQUMGNVbDI8rw2XVOY
6WcFrSm7XcKa4WTDBXFBXBAXxAVxQe0+LqgFF+y+CRfEBYdh4IJpAi6IC+KC
WnBBwQWnggueMA+4oOCCW7ugafsb4bkLZk2NC+KCuODY4IKCC+KCfhS4oBZc
0Ja4IC44DgMXTBNwQVwQF9SCCwouOBVc8IR5wAUFF9zYBfO2LLPUBU13L4AL
4oK44NDggoIL4oJ+FLigFlywO4FxQVxwGAYumCbggrggLqgFFxRccCq44Anz
gAsKLri1CzbdXpTNXLCtywYWhAVhwbGBBQUWhAX9KGBBLbCgrWFBWHAcBiyY
JsCCsCAsqAUWFFhwKrDgCfMACwosuDULVnVVN3MWLLtfw4KwICw4NLCgwIKw
oB8FLKgFFuxu4GBBWHAYBiyYJsCCsCAsqAUWFFhwKrDgCfMACwosuDULtray
CQvWrYUFYUFYcGxgQYEFYUE/ClhQCyzYHTBYEBYchgELpgmwICwIC2qBBQUW
nAoseMI8wIICC27MgkVe9sfPN74P1jTuHx3p66QXuKDggosJ0dHABV3BBX0f
cEHtBC7o3oML6jxcvAt2DyS4IC44DAMXTBNwQVwQF9SCCwouOBVc8IR5wAUF
F9zaBesm67rvG98Ha9tyqJNe4IKCCy4mREcDF3QFF/R9wAW1E7igew8uqPNw
+S5ocUFccBwGLpgm4IK4IC6oBRcUXHAquOAJ84ALCi64sQvmpu2fj4o2b4J/
jNjWddt9ZF4snFu4oOCCiwnR0cAFXcEFfR9wQe0ELujegwvqPFy+C2bf2wXX
qt4GLjhbCIsb5Msu6A/XOS7oN8jv6oJRgle9lzwsdcG1CakLit7//fQu6G+g
znBBCW4cTnPBaBR2cR6+4oKrJmLZBdecnIsu6IXgDBdcp3rbuOCqUSy7oCac
44J+Sf3sLuieLcusCp65c1tqlSRs5YL+WHxPFxw+63QXzPXJuiyDNZnlQ/Uq
Fyz0wnmGC/rz4nQXHMZ7uguumslFF/SPFN/VBX0fznDB7l46aOzL87Dsgtaf
1q/Zo7ZyQaPb6hkuGPjJ+Mx+7Hl5wQVtWeatFLUJ/me3tXX3nNrV5cK5teyC
+YorxqILVrX7zjNc0M/eGS4o+nh2jgvqfb01peu5umA5VN/YBV+d8MZd0Mxd
0BxJ2NAFS5m5YHkkYUMXzGXmgvmRhC1cMPjRg8EFZ/bwNRe00zyc5IKZ21q6
U6IaE6pyqJbPzcQFfR9Od0H/fzHPcUHfh9NdUM+Ec1xwuOie7IK6QQ6Nf7Ue
q9e4oH7WGS5Y6VurMCGzQ/WNXLDQO5/TXXDVHeWyC9ZnuWCOC84ScEFcMFpR
uKB+OC6IC+KCuGBYcEEf8fp5+HFdUNeQb7wLtkP1jVxQn+Z8Y18exVYuWJup
GVywHapv5YKBGwyP47NRvOSCmam7h7O5C1Z1sc4F+XlBnxA87+KCuCAu6PuA
C+oxyKbmZ3bB6A9e+lebsfo2LqhXqSq8/mfZUP1ELnjezwsWuOAsARfEBaMV
hQvqh+OCuCAuiAuGBRf0Ea+fB1xwuJvFBbdzwaJsaim6p6Pw7xessrKvy4U1
hQsKLriYEB0NXNAVXND3ARfUY4ALaoIJGlzwgl2wxAVnCbggLhitKFxQPxwX
xAVxQVwwLLigj3j9POCCw90sLriVC2ZtlVd54oKZqXFBXNDggkODCwouiAv6
qcQFtax4PnirLljjgrMEXBAXjFYULqgfjgvigrggLhgWXNBHvH4ecMHhbhYX
3M4F6ypLXdAULS6ICxpccGhwQbl4F9Q9xX3k4IK1r5bPTf5+QVwwSMAFF1yw
xQVnCbggLhitKFxQPxwXxAVxQVwwLLigj3j9POCCw90sLridCzZ1mfw5YtO2
OS6ICxpccGhwQcEFcUE/ClxQy4rngx/XBc/6d0e6+ccFccGlBFwQFwxHgQvi
grig4IJhwQV9xOvnARcc7mZxwe1csO0f73BB9y244DwBF/QNLii4IC7oR4EL
alnxfPBWXdDigrMEXPD7uqBuNbggLrg0lbggLrgyARfEBXFBXPBncsGmsgs/
L1jbDBfEBQ0uODS4oOCCuKAfBS6oZcXzwVt1wQwXnCXggrhgtKJwQf1wXBAX
xAVxwbDggj7i9fOACw53s7ggLogLCi44VrggLphc93BBXHD5jhIX3MwFc1xw
loAL4oLRisIF9cNxQVwQF8QFw4IL+ojXzwMuONzN4oK4IC4ouOBY4YK4YHLd
wwVxweU7SlxwMxcscMFZAi6IC0YrChfUD8cFcUFcEBcMCy7oI14/D7jgcDeL
C+KCuKDggmOFC+KCyXUPF8QFl+8occHNXLDEBWcJuOB3dcEyCxpc8Lu6oN9y
/ZoslvqAC84TcEHBBXHBJOHHdUH/oHHZLmhzvRf96V3QY9xP7YK5sVWZ/rsj
tWlxQVzQ4IJDgwsKLogL+lHgglpWPB+8VRescMFZAi6IC0YrChfEBVdcKXBB
wQVxwSQBFxRcEBdMEjZxwaKoi4WfF8QFcUFcEBdM5gEXFFwQF/RlxfPBW3XB
BhecJeCCuGC0onBBXHDFlQIXFFwQF0wScEHBBXHBJGGTP0dc52Xy54ibprKw
ICxoYMGhgQUFFoQF/ShgQS0rHg/eKgu2sOAsARaEBaMVBQvCgiuuFLCgwIKw
YJIACwosCAsmCZv8uKDt7pxyWNB9Cyw4T4AFfQMLCiwIC/pRwIJaVjwevFEW
LCwsOEuABWHBaEXBgrDgiisFLCiwICyYJMCCAgvCgknCNn+K2JYtPy2oCbDg
PAEW9A0sKLAgLOhHAQtqWfF48FZZMIMFZwmwICwYrShYEBZccaWABQUWhAWT
BFhQYEFYMEnYhAXrJqvmPy3YFt2jMiwIC8KCQwMLCiwIC/pRwIJaVjwe/Lgs
2JzFgjksOEuABWHBaEXBgrDgiisFLCiwICyYJMCCAgvCgknCFizYbVBtkf5b
xEV39HBBXBAXHBpcUHBBXNCPAhfUsuL54K26YIELzhJwQVwwWlG4IC644kqB
CwouiAsmCbig4IK4YJKwiQuWtmwTF+we/AwuiAsaXHBocEHBBXFBPwpcUMuK
54O36oIlLjhLwAVxwWhF4YK44IorBS4ouCAumCTggoIL4oJJwiYu2NQ9CPrG
98Fmth7qpBe4oOCCiwnR0cAFXcEFfR9wQe0ELqgJJmhwwQt2wQoXnCXggrhg
tKJwQVxwxZUCFxRcEBdMEnBBwQVxwSRho79esOnWQ9HU/s5Bf16wyJ0LNgvn
Fi4ouOBiQnQ0cEFXcEHfB1xQO4ELaoIJGlzwgl2wxgVnCbggLhitKFwQF1xx
pcAFBRfEBZMEXFBwQVwwSdjGBbsb+tQF8+6cwAVxQVxwaHBBuXAXVBDEBXFB
Lbigvv1MF2xwwVkCLogLRisKF8QFV1wpcEHBBXHBJAEXFFwQF0wSNnHBsm0X
fl7Q1iUuiAsaXHBocEHBBXFBPwpcUMuK54O36oItLjhLwAVxwWhF4YK44Ior
BS4ouCAumCTggoIL4oJJwiYuWDR5d17MXdAYXBAXxAWnBFxQcEFc0I8CF9Sy
4vngjbpgaXDBWQIuiAtGKwoXxAVXXClwQcEFccEkYSsXVBDEBXFBLbhgf1q1
VbecZy5omgoXxAVxwSkBFxRcEBf0o8AFtax4PngbLvj/Bgzc+zGcAwA=
---1903347710-1026672900-990551323=:5964--

From owner-linux-xfs@oss.sgi.com Tue May 22 10:31:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MHVbi11930
	for linux-xfs-outgoing; Tue, 22 May 2001 10:31:37 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MHVaF11927
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:31:36 -0700
Received: (qmail 18621 invoked by uid 3995); 22 May 2001 17:31:34 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <200105221635.f4MGZv511029@jen.americas.sgi.com>
Date: 22 May 2001 13:31:34 -0400
In-Reply-To: Steve Lord's message of "Tue, 22 May 2001 11:35:57 -0500"
Message-ID: <wx0elthe1e1.fsf@sws5.ctd.ornl.gov>
Lines: 11
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord <lord@sgi.com> writes:

> > 	__alloc_pages: 0-order allocation failed.

I'm seeing these, too.
 
> p.s. I presume you are using a HIGHMEM kernel.

How would I know? I installed using the 1.0 installer.

-Dave

From owner-linux-xfs@oss.sgi.com Tue May 22 10:33:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MHXG111997
	for linux-xfs-outgoing; Tue, 22 May 2001 10:33:16 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MHXFF11994
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:33:15 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA04950
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:33:10 -0700 (PDT)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA64555 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 12:31:54 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f4MHUsG21641
	for linux-xfs@oss.sgi.com; Tue, 22 May 2001 13:30:54 -0400
Date: Tue, 22 May 2001 13:30:54 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105221730.f4MHUsG21641@gibble.americas.sgi.com>
Subject: TAKE - Remove unused outdated files.
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Tue May 22 10:28:26 PDT 2001
Workarea:  gibble.americas.sgi.com:/export/extra/x2.4-xfs-devel

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95693a
SCRIPTS/make-tarballs - 1.26
SCRIPTS/setvers.pl - 1.6
SOURCES/README.kernel-sources - 1.2
SOURCES/installkernel - 1.2
SOURCES/module-info - 1.2
SPECS/kernel-2.4.spec - 1.65
SOURCES/ksymoops-2.3.4-install.patch - 1.3
SOURCES/devfsd-v1.3.10.tar.gz - 1.2
SOURCES/kernel-2.4-BuildASM.sh - 1.2
SOURCES/kernel-2.4-string.patch - 1.2
SOURCES/pcmcia-cs-3.1.18-script.patch - 1.4
SOURCES/pcmcia-cs-3.1.18-config.patch - 1.4
SOURCES/pcmcia-cs-2.8.8-network.script - 1.2
SOURCES/linux-rhconfig.h - 1.5
SOURCES/linux-merge-modules.awk - 1.4
SOURCES/linux-merge-config.awk - 1.3
SOURCES/linux-2.4.0-ia64-agpgart.patch - 1.3
SOURCES/linux-2.4.0-changeloop.patch - 1.7
SOURCES/ksymoops-2.3.4.tar.gz - 1.2
SOURCES/linux-2.3.99-alpha.patch - 1.3
SOURCES/linux-2.3.99p3p6-sparc.patch - 1.2
SOURCES/linux-2.4.0-alpha.patch - 1.4
SOURCES/linux-2.4.0-test7-pre4-overflow.patch - 1.4
SOURCES/linux-2.4.0-test7-pre4-emu10k1.patch - 1.2
SOURCES/linux-2.4-pcmcia-cp.patch - 1.6
SOURCES/linux-2.2.16-useio.patch - 1.2
SOURCES/linux-2.4.0-nohighmemdebug.patch - 1.2
SOURCES/linux-2.4.0-intelethernet.patch - 1.5
SOURCES/linux-2.4.0-sym53-64bit.patch - 1.2
SOURCES/linux-2.4.0-netfilter-cpp.patch - 1.2
SOURCES/linux-2.4.0-starfire-ia64.patch - 1.2
SOURCES/linux-2.4.0-test9-ia64-shutup.patch - 1.2
SOURCES/linux-2.4.0-test11-kgcc.patch - 1.2
SOURCES/linux-2.4.0-ia64-getpagesize.patch - 1.2
SOURCES/linux-2.4.0-test11-ia64-unwind.patch - 1.2
SOURCES/linux-2.4.0-test11-vidfail.patch - 1.2
SOURCES/anaconda-7.1-xfs.patch - 1.2
SOURCES/anaconda_header.png - 1.3
SOURCES/first-375.png - 1.2
SOURCES/first.png - 1.2
SOURCES/mkinitrd-2.8-xfs.patch - 1.2
SOURCES/splash.png - 1.2
SPECS/anaconda-7.1-xfs.spec - 1.3
SPECS/mkinitrd-xfs.spec - 1.2
SOURCES/sgi.png - 1.2
SOURCES/linux-2.4.0-e820.patch - 1.2
SOURCES/linux-2.4.0-ia64-vhpt.patch - 1.2
SOURCES/tux2-release-2.4.0 - 1.4
SOURCES/linux-2.4.0-cipe-1.4.5.patch - 1.2
SOURCES/linux-2.4.0-ia64-free_dma.patch - 1.2
SOURCES/linux-2.4.0-ia64-copyu.patch - 1.2
SOURCES/linux-2.4.0-megaraid.patch - 1.4
SOURCES/linux-2.4.0-ia64-010109-2.diff - 1.4
SOURCES/linux-2.4.0-nonintconfig.patch - 1.2
SOURCES/linux-2.4.0-qla1280.patch - 1.2
SOURCES/linux-2.4.0-cs4281-fix.patch - 1.2
SOURCES/linux-2.4.0-raid5xor.patch - 1.2
SOURCES/linux-2.4.0-irda-assert.patch - 1.2
SOURCES/linux-2.4.0-sysctl.patch - 1.2
SOURCES/raid-autorun-2.4.0-A1 - 1.2
SOURCES/e1000-3.0.1.patch - 1.2
SOURCES/linux-2.4.1-pre10-xor.patch - 1.2
SOURCES/linux-2.4.1-pre10-fork.patch - 1.2
SOURCES/linux-2.4.1-pre10-dac960.patch - 1.2
SOURCES/linux-2.4.0-wvlan-cs.patch - 1.3
SOURCES/linux-2.4.0-wavelan-udelay.patch - 1.2
SOURCES/linux-2.4.0-tgafb-unregister-framebuffer.patch - 1.2
SOURCES/linux-2.4.0-test11-aacraid.patch - 1.2
SOURCES/linux-2.4.0-ipvs.patch - 1.2
SOURCES/linux-2.4.0-sard.patch - 1.2
SOURCES/linux-2.4.0-qla1280timer.patch - 1.2
SOURCES/linux-2.4.0-3x90x.patch - 1.2
SOURCES/linux-2.4.0-misc-warnings.patch - 1.3
SOURCES/linux-2.4.0-map_user_kiobuf-fix.patch - 1.2
SOURCES/linux-2.4.0-e100.patch - 1.2
SOURCES/linux-2.4.0-hpt366-vs-ibm.patch - 1.2
SOURCES/linux-2.4.0-lm_sensors.patch - 1.2
SOURCES/alsa-driver-0.5.10b.tar.bz2 - 1.2
SOURCES/linux-2.4.0-blocksched.patch - 1.2
SOURCES/patch-2.4.0-ac10.bz2 - 1.2
SOURCES/linux-2.4.1-zap_page_range_fix.patch - 1.2
SOURCES/linux-2.4.1-pre10-raid5.patch - 1.2
SOURCES/linux-2.4.1-pre10-io-apic.patch - 1.2
SOURCES/linux-2.4.1-matrox.patch - 1.2
SOURCES/linux-2.4.1-PIII-mxcsr.patch - 1.2
SOURCES/linux-2.4.0-xmm.patch - 1.2
SOURCES/linux-2.4.0-swapshm.patch - 1.2
SOURCES/linux-2.4.0-socket.patch - 1.2
SOURCES/linux-2.4.0-parport-cs.patch - 1.2
SOURCES/linux-2.4.0-maestro3.patch - 1.2
SOURCES/linux-2.4.0-ide-floppy.patch - 1.2
SOURCES/linux-2.4.0-ide-cs.patch - 1.2
SOURCES/linux-2.4.0-ia64-sys-wait4.patch - 1.2
SOURCES/linux-2.4.0-i82365.patch - 1.2
SOURCES/linux-2.4.0-gfp_mask.patch - 1.2
SOURCES/linux-2.4.0-3c575-3c59x.patch - 1.2
SOURCES/linux-2.4.0-eepro100.patch - 1.2
SOURCES/linux-2.4.0-aic7xxx-6.1.0.patch - 1.2
SOURCES/linux-2.4.0-cciss.patch - 1.2
SOURCES/linux-2.4.0-alpha-tux.patch - 1.2
SOURCES/linux-2.4.0-axboe-loop-fixes.patch - 1.2
SOURCES/linux-2.4.0-axboe-loop.patch - 1.2
SOURCES/kernel-2.4.2-alpha-BOOT.config - 1.2
SOURCES/kernel-2.4.2-alpha-jensen.config - 1.2
SOURCES/kernel-2.4.2-alpha-smp.config - 1.2
SOURCES/kernel-2.4.2-alpha.config - 1.2
SOURCES/kernel-2.4.2-athlon-smp.config - 1.2
SOURCES/kernel-2.4.2-athlon.config - 1.2
SOURCES/kernel-2.4.2-i386-BOOT.config - 1.2
SOURCES/kernel-2.4.2-i386-smp.config - 1.2
SOURCES/kernel-2.4.2-i386.config - 1.2
SOURCES/kernel-2.4.2-i586-smp.config - 1.2
SOURCES/kernel-2.4.2-i586.config - 1.2
SOURCES/kernel-2.4.2-i686-enterprise.config - 1.2
SOURCES/kernel-2.4.2-i686-smp.config - 1.2
SOURCES/kernel-2.4.2-i686.config - 1.2
SOURCES/kernel-2.4.2-ia64-smp.config - 1.2
SOURCES/kernel-2.4.2-ia64-snia.config - 1.2
SOURCES/kernel-2.4.2-ia64.config - 1.2
SOURCES/kernel-2.4.2-sparc-BOOT.config - 1.2
SOURCES/kernel-2.4.2-sparc-smp.config - 1.2
SOURCES/kernel-2.4.2-sparc.config - 1.2
SOURCES/kernel-2.4.2-sparc64-BOOT.config - 1.2
SOURCES/kernel-2.4.2-sparc64-smp.config - 1.2
SOURCES/kernel-2.4.2-sparc64.config - 1.2
SPECS/kernel-pcmcia-cs.spec - 1.2
SOURCES/pcmcia-cs-3.1.24-portrange.patch - 1.2
SOURCES/pcmcia-cs-3.1.23-updfstab.patch - 1.2
SOURCES/pcmcia-cs-3.1.23-yenta.patch - 1.2
SOURCES/pcmcia-cs-3.1.24-init.patch - 1.2
SOURCES/pcmcia-cs-3.1.24-modconfig.patch - 1.2
SOURCES/pcmcia-cs-3.1.24.tar.gz - 1.2
SOURCES/pcmcia-cs-3.1.24-rctrans.patch - 1.2
	- RPMS not created from this location anymore.



From owner-linux-xfs@oss.sgi.com Tue May 22 10:45:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MHjBI12239
	for linux-xfs-outgoing; Tue, 22 May 2001 10:45:11 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MHjAF12236
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:45:10 -0700
Received: from ledzep.americas.sgi.com (relay.sgi.com [137.38.226.97] (may be forged)) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA01399
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 10:45:09 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA45433; Tue, 22 May 2001 12:43:53 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4MHgrw21813;
	Tue, 22 May 2001 13:42:53 -0400
Message-ID: <3B0AA51B.476C3718@thebarn.com>
Date: Tue, 22 May 2001 13:42:51 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Venables, Michael" <Michael.Venables@compaq.com>
CC: "cooker@linux-mandrake.com" <cooker@linux-mandrake.com>,
   linux-xfs@oss.sgi.com
Subject: Re: Mandrake installer
References: <8C91B010B3B7994C88A266E1A72184D3C89014@cceexc19.americas.cpqcorp.net> <3B09B8DE.A751F34D@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell Cattelan wrote:

Ok all the iso's are now at
ftp://ftp.thebarn.com/SGI/Mandrake-XFS1.0/

I've updated disc 1 with a patched version of mkinitrd, initial ram disks should
be make correctly now.

> "Venables, Michael" wrote:
>
> > Russell -
> >
> > Some of this is aimed more at the MDK guys, but since you CCed them, they'll
> > pick up the thread.
> >
> > If it's not too much of a hassle, you might put discs 2 & 3 up. The copy of
> > disc 2 I have came from one of our internal ftp sites, and there seems to be
> > something wrong a bunch of the packages on it. I haven't seen disc 3 on any
> > of the sites I've visited.
>
> Ok will do, I'm remaking everything right now with a patched version of
> mkinitrd.
> Your best bet will be to use rysnc to "update" your disc1 iso, should  very
> little change
> from the original.
>
> >
> >
> > Have you given any thought to building against the 2.4.4 kernel? From what
> > I've been told by one of our kernel hackers, it holds up much better on the
> > sort of meatgrinder tests that we'd like to stress test XFS under.
>
> Ok like I said I don't have bunched time right now, so...
> I'll do one kernel, which one is more important right now?
> 2.4.3.whatever or the latest 2.4.4 in cooker.
>
> Note any 2.4.4 version will most likely be TOT from the development tree, as
> that is very close to what will be going into  XFS 1.0.1.
>
> >
> >
> > I've never had to do anything from the installer shell for Mandrake, and I
> > was sort of surprised that they use something other than bash. Didn't take
> > the time to look, but whatever it is, works hard against you doing any sort
> > of useful CLI work. Unlike RH, there's no mouse support or autofill.
> >
> > Additionally, I was completely unable to run mkinitrd. The permissions are
> > fine, but for some reason, it won't execute. If you've got any theories...
> >
> > More X config problems. Have a machine with a FireGL 4000. That card does
> > not appear in the list of supported video controllers. Also... is there no
> > option to function test an X configuration?
> >
> > -----Original Message-----
> > From: Russell Cattelan [mailto:cattelan@thebarn.com]
> > Sent: Monday, May 21, 2001 4:04 PM
> > To: Venables, Michael; lcooker@mandrake.com; linux-xfs@oss.sgi.com
> > Subject: Re: Mandrake installer
> >
> > "Venables, Michael" wrote:
> >
> > > I passed XFS Mandrake off to a couple of people here and happened to be
> > > around when they hit the same package install problems I did. The specific
> > > error was "bad package, unable to be installed" but I noticed that they
> > > begin on disk 2--so you're off the hook. Figured you'd want to know before
> > > you wasted any time.
> > >
> >
> > Ok quick caveat here, I have not spend a lot of time making sure everything
> > is perfectly polished
> > So I'm nor sure the iso build script did the right thing in regards to which
> > package is on which
> > CD. I think the original mandrake 8.0 disc 2 and 3 should work when
> > selecting
> > packages from
> > them, but I have not tested that so I'm not sure.
> > If need be I can put the disc 2 and 3 iso's that I generated on the ftp
> > site.
> >
> > I'm hoping the Mandrake folks will eventually help out with cleaning up
> > these
> > details,
> > but for the moment all I have to time to do is make sure the basic install
> > works.
> >
> > BTW yes the mkinitrd is failing... seems it is trying to be smart and
> > include
> > any
> > file systems that are not ext2 as a module.
> > Since xfs is compiled into the kernel mkinitrd can not find the module and
> > exits.
> > The Q&D fix is to go in and comment out the exit at line 100 in mkinitrd and
> > rerun the cmd by hand.
> >
> > >  michael
> >
> > --
> > Russell Cattelan
> > --
> > Digital Elves inc. -- Currently on loan to SGI
> > Linux XFS core developer.
>
> --
> Russell Cattelan
> --
> Digital Elves inc. -- Currently on loan to SGI
> Linux XFS core developer.

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May 22 11:04:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MI46312509
	for linux-xfs-outgoing; Tue, 22 May 2001 11:04:06 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MI45F12506
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:04:05 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4MI42e11860;
	Tue, 22 May 2001 13:04:02 -0500 (CDT)
Message-ID: <3B0AAAA9.8BB8D9E8@sgi.com>
Date: Tue, 22 May 2001 13:06:33 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sill <ds-linux-xfs@sws5.ctd.ornl.gov>
CC: linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <200105221635.f4MGZv511029@jen.americas.sgi.com> <wx0elthe1e1.fsf@sws5.ctd.ornl.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dave Sill wrote:
 
> > p.s. I presume you are using a HIGHMEM kernel.
> 
> How would I know? I installed using the 1.0 installer.

The "enterprise" kernel in our installer has HIGHMEM enabled, and it's
installed by default if you have 4GB or more, I believe.

If you do an "rpm -a | grep kernel" and see "enterprise" in any of the
packages, then it's installed, and I think "uname -a" will also tell you
if the enterprise kernel is currently running.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Tue May 22 11:05:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MI5aV12543
	for linux-xfs-outgoing; Tue, 22 May 2001 11:05:36 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MI5aF12540
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:05:36 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA05482
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:05:35 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1876758; Tue, 22 May 2001 13:04:18 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA94406; Tue, 22 May 2001 13:04:18 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MI7Kl13718; Tue, 22 May 2001 13:07:20 -0500
Message-Id: <200105221807.f4MI7Kl13718@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Tue, 22 May 2001 12:08:43 CDT." <Pine.LNX.4.33.0105221205010.5964-101000@osage.ncsa.uiuc.edu> 
Date: Tue, 22 May 2001 13:07:20 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
>   Send mail to mime@docserver.cac.washington.edu for more info.
> 
> ---1903347710-1026672900-990551323=:5964
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> Steve,
> 
> I ran "iozone -s 4000m" again with a new kernel (your attached patch).
> I'm getting the same errors and have attached a slab.out.gz file showing
> slabinfo every 1s during the test.  The __alloc_pages: error shows up a
> few seconds into the test.  buffer_head values seem to ramp up
> quickly with iozone...
> 
> -Galen
> 

Yep, looking at the first slabcache output, the patch will not help at all
in this scenario. Another one for the todo list....

Steve



From owner-linux-xfs@oss.sgi.com Tue May 22 11:09:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MI94g12602
	for linux-xfs-outgoing; Tue, 22 May 2001 11:09:04 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MI93F12599
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:09:03 -0700
Received: (qmail 19789 invoked by uid 3995); 22 May 2001 18:09:02 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <200105221635.f4MGZv511029@jen.americas.sgi.com>
	<wx0elthe1e1.fsf@sws5.ctd.ornl.gov> <3B0AAAA9.8BB8D9E8@sgi.com>
Date: 22 May 2001 14:09:01 -0400
In-Reply-To: Eric Sandeen's message of "Tue, 22 May 2001 13:06:33 -0500"
Message-ID: <wx0ae45dznm.fsf@sws5.ctd.ornl.gov>
Lines: 19
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen <sandeen@sgi.com> writes:

> Dave Sill wrote:
>  
> > > p.s. I presume you are using a HIGHMEM kernel.
> > 
> > How would I know? I installed using the 1.0 installer.
> 
> The "enterprise" kernel in our installer has HIGHMEM enabled, and it's
> installed by default if you have 4GB or more, I believe.
> 
> If you do an "rpm -a | grep kernel" and see "enterprise" in any of the
> packages, then it's installed, and I think "uname -a" will also tell you
> if the enterprise kernel is currently running.

OK, thanks. It's not. I've "only" got a 1GB. Should I switch to the
Enterprise kernel?

-Dave

From owner-linux-xfs@oss.sgi.com Tue May 22 11:37:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MIbC113416
	for linux-xfs-outgoing; Tue, 22 May 2001 11:37:12 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MIbAF13413
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:37:10 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id UAA15438;
	Tue, 22 May 2001 20:37:08 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id UAA19307;
	Tue, 22 May 2001 20:37:06 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 02B5357306; Tue, 22 May 2001 20:46:26 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 0D0B725835; Tue, 22 May 2001 20:47:25 +0200 (CEST)
Message-ID: <3B0AB2D4.73EA7924@ch.sauter-bc.com>
Date: Tue, 22 May 2001 20:41:24 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Keith Owens <kaos@melbourne.sgi.com>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: lilo -R
References: <9224.990531452@ocs3.ocs-net>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Owens schrieb:
> 
> On Tue, 22 May 2001 07:56:00 +0100 (BST),
> Keith Matthews <keith_m@sweeney.demon.co.uk> wrote:
> >On Mon, 21 May 2001 20:22:30 -0700 (PDT) John <John <jsh_45@yahoo.com>> wrote:
> >
> >> This is starting to get to me.  I "thought" that
> >> pulling the /dev/hdc drives cable and putting it on
> >> the first ide controller would be the easy thing to
> >> do, but that has been elusive.  I've tried almost
> >
> >More out of curiosity than anything, why did you want to do things this
> >way, as opposed to using LILO on the original configuration to boot from
> >hdc ?
> 
> He is building on hdc using an existing kernel then making hdc the boot
> disk, so it becomes hda in a new system.  lilo records device numbers
> and gets confused by this process.
> 
> The easiest method is to create the new system on hdc, do not run lilo,
> install the disk as hda, boot a kernel off an emergency floppy using
> root on the new hda then run lilo to install after the disk has been
> moved to hda.  The problem with that approach is fitting the kernel on
> a floppy, XFS is too big.  The only ways I can see of using an
> emergency floppy are by using an ext2 partition on hdc/hda or by
> building XFS as a module, but that requires fiddling with initrd,
> messy.

You can patch /sbin/mkbootdisk to write floppys with bigger size.

--- /sbin/mkbootdisk    Thu Feb  8 23:48:15 2001
+++ mkbootdisk  Wed May  9 11:34:16 2001
@@ -8,6 +8,7 @@
  unset kernel
  device=/dev/fd0
  unset verbose
+unset fdformat
  unset witheth
  unset mkinitrdargs
  unset compact
@@ -32,6 +33,7 @@
         --device)
             shift
             device=$1
+           fdformat=true
             ;;
         --mkinitrdargs)
             shift
@@ -141,12 +143,14 @@
  }

  [ -n "$verbose" ] && echo -n "Formatting $device... "
+[ -n "$fdformat" ] && fdformat $device
  mkdosfs -I $device > /dev/null || {
      echo "Failed to format $device" >&2
      exit 1
  }

-syslinux $device
+[ -n "$fdformat" ] && syslinux -s $device
+[ -z "$fdformat" ] && syslinux $device
  [ -n "$verbose" ] && echo "done."

  rm -rf $MOUNTDIR

Greetings
Simon



From owner-linux-xfs@oss.sgi.com Tue May 22 11:43:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MIhHG13525
	for linux-xfs-outgoing; Tue, 22 May 2001 11:43:17 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MIhFF13522
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:43:16 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4MIfEM15475
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:41:14 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 22 May 2001 13:41:13 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: Linux 2.4.4 xfs-dev from cvs (fwd)
Message-ID: <Pine.LNX.4.33.0105221341010.13960-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

With that kernel, I don't see anything in /proc/bus/usb. I know usb works,
cause I'm using a printer, a scanner, a digital camera, and a wireless
mouse and keyboard all with usb. I would really like to be able to see
/proc/bus/usb/devices though so I can use usbview.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com




From owner-linux-xfs@oss.sgi.com Tue May 22 11:46:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MIkBU13606
	for linux-xfs-outgoing; Tue, 22 May 2001 11:46:11 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MIk9F13599
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:46:09 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id UAA16878;
	Tue, 22 May 2001 20:46:08 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id UAA19942;
	Tue, 22 May 2001 20:46:07 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 5557457306; Tue, 22 May 2001 20:55:50 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id B0B4325835; Tue, 22 May 2001 20:56:49 +0200 (CEST)
Message-ID: <3B0AB508.BA846FD2@ch.sauter-bc.com>
Date: Tue, 22 May 2001 20:50:48 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Simon@mobile.sauter-bc.com, \@mobile.sauter-bc.com@lizard.webland.de,
   "Drake\" Danini <drake@jobpilot.it>"@mobile.sauter-bc.com
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: raid1 root with XFS
References: <002801c0e2c4$4b0b8f10$0401270a@milano.jobpilot>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Simon \"Drake\" Danini schrieb:
> 
> Hi all,
>     i'm trying to build up a linux system with 2 software raid1 xfs
> partitions (let's say hda1 hda2) ...
> i've tryed almost everything ...
> 
> patched mkinitrd (as suggested from this list)
> enabling and disabling devfs
> manually modifying initrd image (to arrange the /dev/md0 problem)
> trying to arrange the various /dev/md0 and/or /dev/md/0
> 
> but nothing seems to work
> the kernel used is the one of the 1.0 RedHat installer iso image
> downloaded from sgi
> 
> i always get the same error
> 
> raid1 personality registred
> Autodetecting RAID arrays ...
> autorun ...
> ... autorun DONE.
> Ext2fs: unable to read superblock
> ...
> XFS: SB read failed
> ... and then obviously the "kernel panic"
> 
> Can someone give me some hints ???
> 
> Thank a lot in advance and Ciao
> 
>                     Drake
> 
> 

Did you use this patch for mkinitrd. Previus patches from this list
don't
work as expected.

--- mkinitrd.orig       Thu May 10 18:16:05 2001
+++ mkinitrd    Thu May 10 18:16:05 2001
@@ -396,8 +396,9 @@
 fi
 
 if [ -n "$startraid" ]; then
-    cp -a /dev/md0 $MNTIMAGE/dev
+    mknod $MNTIMAGE/dev/md0 b 9 0
     echo "raidautorun /dev/md0" >> $RCFILE
+    echo "raidautorun /dev/md/0" >> $RCFILE
 fi
 
 chmod +x $RCFILE


Did you try to boot in rescue mode from the install cd? Is the lilo.conf
correct. I mean something like this:

boot=/dev/md0
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
message=/boot/message
linear
default=devfs

image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0
        label=orig
        initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img.orig
        read-only
        root=/dev/md0
        append="ramdisk_size=2500"

image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0
        label=devfs
        initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img
        read-only
        root=/dev/md0
        append="ramdisk_size=2500"

image=/boot/vmlinuz-2.4.2-SGI_XFS_1.0
        label=nodevfs
        initrd=/boot/initrd-2.4.2-SGI_XFS_1.0.img
        read-only
        root=/dev/md0
        append="ramdisk_size=2500 devfs=nomount"

Greetings
Simon (yes really :))



From owner-linux-xfs@oss.sgi.com Tue May 22 11:51:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MIpfU13782
	for linux-xfs-outgoing; Tue, 22 May 2001 11:51:41 -0700
Received: from mail15a.boca15-verio.com ([208.55.91.57])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MIpeF13778
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 11:51:40 -0700
Received: from www.sigmastorage.com (128.241.173.170)
	by mail15a.boca15-verio.com (RS ver 1.0.60s) with SMTP id 025843177
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:51:30 -0400 (EDT)
Message-ID: <3B0AB4BB.CF0E37C2@sigmastorage.com>
Date: Tue, 22 May 2001 11:49:31 -0700
From: Matt Ryan <matt@sigmastorage.com>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: lilo -R
References: <9224.990531452@ocs3.ocs-net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Loop-Detect: 1
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> He is building on hdc using an existing kernel then making hdc the boot
> disk, so it becomes hda in a new system.  lilo records device numbers
> and gets confused by this process.
> 
> The easiest method is to create the new system on hdc, do not run lilo,


actually, it's not too difficult to set lilo straight.  I have done
almost this exact same thing several times - that is, copy a linux
install over from hda to hdc, and run lilo on hdc so that it'll boot as
hda in a new box.

here's the lilo.conf file I used, and ran with a lilo -C ... the key
thing is the bios=0x80 line.  looking at the lilo.conf man page, this
might be sort of a hack, and machine/bios dependent, but it worked for
me.


boot=/dev/hdc
map=/mnt/boot/map
install=/mnt/boot/boot.b
prompt
timeout=50
message=/mnt/boot/message
linear
default=linux2.4.2
 
disk=/dev/hdc
        bios=0x80
 
image=/mnt/boot/vmlinuz-2.4.2-0.1.19
        label=linux2.4.2
        read-only
        root=/dev/hda5

From owner-linux-xfs@oss.sgi.com Tue May 22 12:29:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MJTTt14928
	for linux-xfs-outgoing; Tue, 22 May 2001 12:29:29 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MJTSF14925
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 12:29:28 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAB06426
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 12:29:23 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA421045 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:28:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA73553 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:28:06 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4MJV8b16553; Tue, 22 May 2001 14:31:08 -0500
Message-Id: <200105221931.f4MJV8b16553@jen.americas.sgi.com>
Date: Tue, 22 May 2001 14:31:08 -0500
Subject: TAKE - remove xfs debug options
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Too many people turned these on and suffered the consequences, making
them harder to get to to protect the innocent.


Date:  Tue May 22 12:27:03 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95719a
linux/fs/Config.in - 1.57
linux/Documentation/Configure.help - 1.79
	remove vnode tracing and xfs debug from config options


From owner-linux-xfs@oss.sgi.com Tue May 22 12:50:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MJob715443
	for linux-xfs-outgoing; Tue, 22 May 2001 12:50:37 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MJoaF15440
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 12:50:36 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA09505
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 12:49:09 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1899378; Tue, 22 May 2001 14:49:16 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA12220; Tue, 22 May 2001 14:49:16 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MJqIG19639; Tue, 22 May 2001 14:52:18 -0500
Message-Id: <200105221952.f4MJqIG19639@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Tue, 22 May 2001 12:08:43 CDT." <Pine.LNX.4.33.0105221205010.5964-101000@osage.ncsa.uiuc.edu> 
Date: Tue, 22 May 2001 14:52:17 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> Steve,
> 
> I ran "iozone -s 4000m" again with a new kernel (your attached patch).
> I'm getting the same errors and have attached a slab.out.gz file showing
> slabinfo every 1s during the test.  The __alloc_pages: error shows up a
> few seconds into the test.  buffer_head values seem to ramp up
> quickly with iozone...
> 
> -Galen
> 

One more question, are you running on top of md/lvm? I see you have a lot of
disk hardware connected to the box, just wondering if iozone is getting
to access lots of it, or just one device out of all the ones you have.

The fundamental issue appears to be dirtying memory way faster than it can
be cleaned, and not throttling the dirtying of memory correctly. You have
12000 pages worth of buffer heads allocated, which may be a bit excessive!

Steve


Steve



From owner-linux-xfs@oss.sgi.com Tue May 22 13:01:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MK19c15682
	for linux-xfs-outgoing; Tue, 22 May 2001 13:01:09 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MK17F15678
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:01:08 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MK16b20058;
	Tue, 22 May 2001 15:01:06 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MK16M24529;
	Tue, 22 May 2001 15:01:06 -0500 (CDT)
Date: Tue, 22 May 2001 15:01:06 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <sandeen@sgi.com>, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <200105221952.f4MJqIG19639@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve,

The disk under the hood is IBM raid array (sharks?).  We're seeing them
through a qlogic driver to the SAN.

If you've got any tuning params. or patches for me to try, let me know.
We like the performance of xfs (what we were able to measure), but need to
pick a filesystem soon.  This will be the filesystem behind our 512 host
linux cluster at NCSA.

I downloaded the development tree from your cvs server, but was not able
to "make bzImage" on linux 2.4.4:


gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
directory
make[5]: *** [aicasm] Error 1

So we're still on linux 2.4.2.  I down-graded the system for testing xfs
because your web site made it look like 2.4.2 was the development
platform.  If you've got a working 2.4.4 version I'd like to try it out
(that's what the rest of the cluster is running).

 -Galen

On Tue, 22 May 2001, Steve Lord wrote:

>
> >
> > Steve,
> >
> > I ran "iozone -s 4000m" again with a new kernel (your attached patch).
> > I'm getting the same errors and have attached a slab.out.gz file showing
> > slabinfo every 1s during the test.  The __alloc_pages: error shows up a
> > few seconds into the test.  buffer_head values seem to ramp up
> > quickly with iozone...
> >
> > -Galen
> >
>
> One more question, are you running on top of md/lvm? I see you have a lot of
> disk hardware connected to the box, just wondering if iozone is getting
> to access lots of it, or just one device out of all the ones you have.
>
> The fundamental issue appears to be dirtying memory way faster than it can
> be cleaned, and not throttling the dirtying of memory correctly. You have
> 12000 pages worth of buffer heads allocated, which may be a bit excessive!
>
> Steve
>
>
> Steve
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Tue May 22 13:06:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MK6YZ15835
	for linux-xfs-outgoing; Tue, 22 May 2001 13:06:34 -0700
Received: from le.org (adsl-216-101-234-35.dsl.snfc21.pacbell.net [216.101.234.35])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MK6YF15831
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:06:34 -0700
Received: from localhost (localhost [127.0.0.1])
	by le.org (Postfix) with ESMTP
	id 3CA5F6E00A; Tue, 22 May 2001 13:19:34 -0700 (PDT)
Date: Tue, 22 May 2001 13:19:34 -0700 (PDT)
From: Tin Le <tin@le.org>
X-X-Sender:  <tin@einstein.netimages.com>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
Cc: Steve Lord <lord@sgi.com>, <sandeen@sgi.com>,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.33.0105221317420.21584-100000@einstein.netimages.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001, Galen Arnold wrote:

> ....

> I downloaded the development tree from your cvs server, but was not able
> to "make bzImage" on linux 2.4.4:

> gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> directory
> make[5]: *** [aicasm] Error 1

There's a number of problems with compiling the Adaptec driver in 2.4.x.
See the online kernel discussion group for multiple reports and fixes.

However the error message above shows that you don't have Berkeley DB
v1.8x installed on your system.  Install that and you should get past the
above error.

Tin Le
----
http://tin.le.org
Tin Le - tin@le.org
Firewall and Security Consulting


From owner-linux-xfs@oss.sgi.com Tue May 22 13:10:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MKAAw15930
	for linux-xfs-outgoing; Tue, 22 May 2001 13:10:10 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MKA9F15927
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:10:09 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 22E0B1E19C; Tue, 22 May 2001 22:10:08 +0200 (MEST)
Date: Tue, 22 May 2001 22:09:11 +0200
From: Andi Kleen <ak@suse.de>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
Cc: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
Message-ID: <20010522220911.A6144@gruyere.muc.suse.de>
References: <200105221952.f4MJqIG19639@jen.americas.sgi.com> <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu>; from arnoldg@ncsa.uiuc.edu on Tue, May 22, 2001 at 03:01:06PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, May 22, 2001 at 03:01:06PM -0500, Galen Arnold wrote:
> gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> directory
> make[5]: *** [aicasm] Error 1

You can probably work around these problems by disabling 
CONFIG_SCSI_AIC7XXX and using CONFIG_SCSI_AIC7XXX_OLD instead (only 
visible when the first is off) 


-Andi

From owner-linux-xfs@oss.sgi.com Tue May 22 13:25:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MKPha16226
	for linux-xfs-outgoing; Tue, 22 May 2001 13:25:43 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MKPgF16223
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:25:42 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA14544
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:24:16 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1884968 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 15:24:25 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA63086 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 15:24:25 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4MKRQL19744; Tue, 22 May 2001 15:27:26 -0500
Message-Id: <200105222027.f4MKRQL19744@jen.americas.sgi.com>
Date: Tue, 22 May 2001 15:27:26 -0500
Subject: TAKE - a couple of allocator cleanups
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Tue May 22 13:23:15 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95727a
linux/fs/xfs_support/kmem.h - 1.5
	- Make the KM_ flags have real values

linux/fs/xfs_support/kmem.c - 1.6
	- Fix some oddities in the kmem_alloc interface (testing flags which are
	  zero), add a last ditch __vmalloc call to all cases.



From owner-linux-xfs@oss.sgi.com Tue May 22 13:27:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MKRTn16261
	for linux-xfs-outgoing; Tue, 22 May 2001 13:27:29 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MKRSF16257
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:27:28 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA14732
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:26:02 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA74044; Tue, 22 May 2001 15:26:12 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4MKPBw27811;
	Tue, 22 May 2001 16:25:11 -0400
Message-ID: <3B0ACB27.6E576737@thebarn.com>
Date: Tue, 22 May 2001 16:25:11 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: Galen Arnold <arnoldg@ncsa.uiuc.edu>, Steve Lord <lord@sgi.com>,
   sandeen@sgi.com, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <200105221952.f4MJqIG19639@jen.americas.sgi.com> <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu> <20010522220911.A6144@gruyere.muc.suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Andi Kleen wrote:

> On Tue, May 22, 2001 at 03:01:06PM -0500, Galen Arnold wrote:
> > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> > aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> > directory
> > make[5]: *** [aicasm] Error 1
>
> You can probably work around these problems by disabling
> CONFIG_SCSI_AIC7XXX and using CONFIG_SCSI_AIC7XXX_OLD instead (only
> visible when the first is off)

Or install the db1-devel rpm.


>
> -Andi

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May 22 13:33:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MKXXf16433
	for linux-xfs-outgoing; Tue, 22 May 2001 13:33:33 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MKXWF16430
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:33:32 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id NAA09601
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:44:33 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA80941; Tue, 22 May 2001 15:32:16 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4MKVFw27822;
	Tue, 22 May 2001 16:31:15 -0400
Message-ID: <3B0ACC92.2DFCA1E8@thebarn.com>
Date: Tue, 22 May 2001 16:31:14 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
CC: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Galen Arnold wrote:

> Steve,
>
> The disk under the hood is IBM raid array (sharks?).  We're seeing them
> through a qlogic driver to the SAN.
>
> If you've got any tuning params. or patches for me to try, let me know.
> We like the performance of xfs (what we were able to measure), but need to
> pick a filesystem soon.  This will be the filesystem behind our 512 host
> linux cluster at NCSA.
>
> I downloaded the development tree from your cvs server, but was not able
> to "make bzImage" on linux 2.4.4:
>
> gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> directory
> make[5]: *** [aicasm] Error 1
>
> So we're still on linux 2.4.2.  I down-graded the system for testing xfs
> because your web site made it look like 2.4.2 was the development
> platform.  If you've got a working 2.4.4 version I'd like to try it out
> (that's what the rest of the cluster is running).

The pending release of XFS 1.0.1 will be RH7.1 and 2.4.4 based, and will
be based primarily on what is in the development tree... once the list
or problems has been whittled down.


Note I'm running iozone locally on a 2gig system over a 2 disk md stripe,
so far no problems.... so we need to find the variable that is different.



>

>
> --
> +
> Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> National Center for Supercomputing Applications           (217) 244-3473
> 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Tue May 22 13:37:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MKbT416613
	for linux-xfs-outgoing; Tue, 22 May 2001 13:37:29 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MKbTF16610
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:37:29 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA16500
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 13:36:02 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1906404 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 15:36:12 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA36727 for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 15:36:11 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4MKdDc19843; Tue, 22 May 2001 15:39:13 -0500
Message-Id: <200105222039.f4MKdDc19843@jen.americas.sgi.com>
Date: Tue, 22 May 2001 15:39:13 -0500
Subject: TAKE - make xfs inodes go away quicker under low memory conditions
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This should help some people seeing allocation failures (only if you use
lots of inodes), problems during quotacheck, it may even be of benefit to
people seeing the ambiguous vns panic from nfs (but not a fix for it).

Date:  Tue May 22 13:28:23 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95728a
linux/fs/xfs/xfs_vnodeops.c - 1.503
	- When tearing down the linux inode, also teardown the xfs inode right away
	  if it is clean. This makes the prune_icache calls free up a lot more memory.



From owner-linux-xfs@oss.sgi.com Tue May 22 14:13:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLDiX17308
	for linux-xfs-outgoing; Tue, 22 May 2001 14:13:44 -0700
Received: from uwast.astro.wisc.edu (uwast.astro.wisc.edu [144.92.179.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLDhF17305
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:13:43 -0700
Received: from astro.wisc.edu (jansen@voodoo.astro.wisc.edu [144.92.179.132])
	by uwast.astro.wisc.edu (8.11.3/8.11.3) with ESMTP id f4MLDMT739781
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:13:22 -0500 (CDT)
Message-ID: <3B0AD672.870DD607@astro.wisc.edu>
Date: Tue, 22 May 2001 16:13:22 -0500
From: jansen <jansen@astro.wisc.edu>
X-Mailer: Mozilla 4.77C-SGI [en] (X11; U; IRIX 6.5 IP32)
X-Accept-Language: en
MIME-Version: 1.0
CC: linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS
References: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu> <3B0ACC92.2DFCA1E8@thebarn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Russell Cattelan wrote:

[stuff deleted]

> The pending release of XFS 1.0.1 will be RH7.1 and 2.4.4 based, and will
> be based primarily on what is in the development tree... once the list
> or problems has been whittled down.

[stuff deleted]

I realize that you all have a great many other things to do and fixing
non-XFS related kernel bugs is not your focus but having said that
I'd really like to see the patch for the IRIX -> Linux NFS directory bug 
(where files are missing when doing an "ls *" in a directory served via
NFS from an IRIX server) be included in the next XFS release.  I believe
this was mentioned on the list about three weeks ago.  There is a patch
that appears to fix this in the 1.0 release (with a little modification
since the patch is for stock 2.4.2).  I believe there was also a patch
for 2.4.4 but I haven't had the time to try it.

This bug initially stopped me from installing the 1.0 release on all
my Linux machines because we have a fair number of IRIX machines 
serving files via NFS and this bug caused a whole host of problems.

The patches for this bug can be found at:

http://www.fys.uio.no/~trondmy/src

-- 


------- Stephan

From owner-linux-xfs@oss.sgi.com Tue May 22 14:27:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLRjx17677
	for linux-xfs-outgoing; Tue, 22 May 2001 14:27:45 -0700
Received: from riker.skynet.be (riker.skynet.be [195.238.3.132])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLRhF17672
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:27:44 -0700
Received: from skynet.be (adsl-45200.turboline.skynet.be [217.136.48.144])
	by riker.skynet.be (8.11.2/8.11.2/Skynet-OUT-2.11) with ESMTP id f4MLRc127076
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 23:27:38 +0200 (MET DST)
	(envelope-from <kris.buggenhout@skynet.be>)
Message-ID: <3B0AD8A6.67AD18DE@skynet.be>
Date: Tue, 22 May 2001 23:22:46 +0200
From: kris buggenhout <kris.buggenhout@skynet.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS
References: <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu> <3B0ACC92.2DFCA1E8@thebarn.com> <3B0AD672.870DD607@astro.wisc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

jansen wrote:

> Russell Cattelan wrote:
>
> [stuff deleted]
>
> > The pending release of XFS 1.0.1 will be RH7.1 and 2.4.4 based, and will
> > be based primarily on what is in the development tree... once the list
> > or problems has been whittled down.
>
> [stuff deleted]
>
> I realize that you all have a great many other things to do and fixing
> non-XFS related kernel bugs is not your focus but having said that
> I'd really like to see the patch for the IRIX -> Linux NFS directory bug
> (where files are missing when doing an "ls *" in a directory served via
> NFS from an IRIX server) be included in the next XFS release.  I believe
> this was mentioned on the list about three weeks ago.  There is a patch
> that appears to fix this in the 1.0 release (with a little modification
> since the patch is for stock 2.4.2).  I believe there was also a patch
> for 2.4.4 but I haven't had the time to try it.
>
> This bug initially stopped me from installing the 1.0 release on all
> my Linux machines because we have a fair number of IRIX machines
> serving files via NFS and this bug caused a whole host of problems.
>
> The patches for this bug can be found at:
>
>

wasnt there a workaround ... by exporting the fs on the irix machine with -o
32bitclients option ?

I remember I had to do this to be able to mount irix nfs shares on linux'en
and Solaris 2.5 machines.
without strange problems like not seeing all files in an ls on the nfs
client.

I had to do this because our main file server was an Origin200 ... :)

could be a temp solution to not hold back on xfs ...   ;)



From owner-linux-xfs@oss.sgi.com Tue May 22 14:31:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLVdp17841
	for linux-xfs-outgoing; Tue, 22 May 2001 14:31:39 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLVdF17836
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:31:39 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA02560
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:42:40 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1907012; Tue, 22 May 2001 16:29:03 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA59280; Tue, 22 May 2001 16:29:03 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MLW4220011; Tue, 22 May 2001 16:32:04 -0500
Message-Id: <200105222132.f4MLW4220011@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, sandeen@sgi.com,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Tue, 22 May 2001 15:01:06 CDT." <Pine.LNX.4.33.0105221454130.8212-100000@osage.ncsa.uiuc.edu> 
Date: Tue, 22 May 2001 16:32:04 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Steve,
> 
> The disk under the hood is IBM raid array (sharks?).  We're seeing them
> through a qlogic driver to the SAN.
> 
> If you've got any tuning params. or patches for me to try, let me know.
> We like the performance of xfs (what we were able to measure), but need to
> pick a filesystem soon.  This will be the filesystem behind our 512 host
> linux cluster at NCSA.
> 
> I downloaded the development tree from your cvs server, but was not able
> to "make bzImage" on linux 2.4.4:
> 
> 
> gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> directory
> make[5]: *** [aicasm] Error 1
> 
> So we're still on linux 2.4.2.  I down-graded the system for testing xfs
> because your web site made it look like 2.4.2 was the development
> platform.  If you've got a working 2.4.4 version I'd like to try it out
> (that's what the rest of the cluster is running).
> 
>  -Galen
> 

I would really encourage you to get the 2.4.4 xfs kernel up and running, 
I am much happier with the code base we have there now, and we cannot yet
replicate the problem with the development tree. Hmm, maybe fiber is the
difference, the qlogic driver has a patchy history in linux.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 22 14:32:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLWLf17867
	for linux-xfs-outgoing; Tue, 22 May 2001 14:32:21 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLWKF17863
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:32:20 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MLWJb26785;
	Tue, 22 May 2001 16:32:19 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4MLWIM18296;
	Tue, 22 May 2001 16:32:18 -0500 (CDT)
Date: Tue, 22 May 2001 16:32:18 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <sandeen@sgi.com>, Mike Pflugmacher <mikep@ncsa.uiuc.edu>,
   Wayne Hoyenga <louis@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: <200105222132.f4MLW4220011@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105221631130.8212-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve,

I've done just that and am seeing a good iozone run as I leave the office
today.  I'll have some numbers tomorrow I think...

-Galen

On Tue, 22 May 2001, Steve Lord wrote:

> > Steve,
> >
> > The disk under the hood is IBM raid array (sharks?).  We're seeing them
> > through a qlogic driver to the SAN.
> >
> > If you've got any tuning params. or patches for me to try, let me know.
> > We like the performance of xfs (what we were able to measure), but need to
> > pick a filesystem soon.  This will be the filesystem behind our 512 host
> > linux cluster at NCSA.
> >
> > I downloaded the development tree from your cvs server, but was not able
> > to "make bzImage" on linux 2.4.4:
> >
> >
> > gcc -I/usr/include -ldb1 aicasm_gram.c aicasm_scan.c aicasm.c
> > aicasm_symbol.c -o aicasm aicasm_symbol.c:39: db1/db.h: No such file or
> > directory
> > make[5]: *** [aicasm] Error 1
> >
> > So we're still on linux 2.4.2.  I down-graded the system for testing xfs
> > because your web site made it look like 2.4.2 was the development
> > platform.  If you've got a working 2.4.4 version I'd like to try it out
> > (that's what the rest of the cluster is running).
> >
> >  -Galen
> >
>
> I would really encourage you to get the 2.4.4 xfs kernel up and running,
> I am much happier with the code base we have there now, and we cannot yet
> replicate the problem with the development tree. Hmm, maybe fiber is the
> difference, the qlogic driver has a patchy history in linux.
>
> Steve
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Tue May 22 14:33:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLXTP17909
	for linux-xfs-outgoing; Tue, 22 May 2001 14:33:29 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLXSF17906
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:33:28 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA02451
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:44:29 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1909705; Tue, 22 May 2001 16:32:10 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA99878; Tue, 22 May 2001 16:32:10 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4MLZAN20024; Tue, 22 May 2001 16:35:10 -0500
Message-Id: <200105222135.f4MLZAN20024@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: kris buggenhout <kris.buggenhout@skynet.be>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS 
In-Reply-To: Message from kris buggenhout <kris.buggenhout@skynet.be> 
   of "Tue, 22 May 2001 23:22:46 +0200." <3B0AD8A6.67AD18DE@skynet.be> 
Date: Tue, 22 May 2001 16:35:10 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> jansen wrote:
> 
> > Russell Cattelan wrote:
> >
> > [stuff deleted]
> >
> > > The pending release of XFS 1.0.1 will be RH7.1 and 2.4.4 based, and will
> > > be based primarily on what is in the development tree... once the list
> > > or problems has been whittled down.
> >
> > [stuff deleted]
> >
> > I realize that you all have a great many other things to do and fixing
> > non-XFS related kernel bugs is not your focus but having said that
> > I'd really like to see the patch for the IRIX -> Linux NFS directory bug
> > (where files are missing when doing an "ls *" in a directory served via
> > NFS from an IRIX server) be included in the next XFS release.  I believe
> > this was mentioned on the list about three weeks ago.  There is a patch
> > that appears to fix this in the 1.0 release (with a little modification
> > since the patch is for stock 2.4.2).  I believe there was also a patch
> > for 2.4.4 but I haven't had the time to try it.
> >
> > This bug initially stopped me from installing the 1.0 release on all
> > my Linux machines because we have a fair number of IRIX machines
> > serving files via NFS and this bug caused a whole host of problems.
> >
> > The patches for this bug can be found at:
> >
> >
> 
> wasnt there a workaround ... by exporting the fs on the irix machine with -o
> 32bitclients option ?
> 
> I remember I had to do this to be able to mount irix nfs shares on linux'en
> and Solaris 2.5 machines.
> without strange problems like not seeing all files in an ls on the nfs
> client.
> 
> I had to do this because our main file server was an Origin200 ... :)
> 
> could be a temp solution to not hold back on xfs ...   ;)

Well, 32 bits is not quite low enough, glibc only likes 31 bits in the
lseek offset, this is the problem. I talked to the glibc maintainer and
he will not budge on this one.  Yes we could package the patch if we do
a respin.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 22 14:58:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MLwrH18333
	for linux-xfs-outgoing; Tue, 22 May 2001 14:58:53 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MLwpF18330
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 14:58:52 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 152KAt-0005vL-00; Wed, 23 May 2001 09:58:43 +1200
Date: Wed, 23 May 2001 09:58:43 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Steve Lord <lord@sgi.com>
cc: "sandeen@sgi.com" <sandeen@sgi.com>,
   "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS
In-Reply-To: <200105222132.f4MLW4220011@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105230947190.18450-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001, Steve Lord wrote:

> I would really encourage you to get the 2.4.4 xfs kernel up and running,
> I am much happier with the code base we have there now, and we cannot yet
> replicate the problem with the development tree. Hmm, maybe fiber is the
> difference, the qlogic driver has a patchy history in linux.

I'd like to check out 2.4.4 as well -- installed 2.4.2 XFS 1.0 a couple of
days ago, and I'd like to say "good work, give yourself a collective pat
on the back" ;-)

Unfortunately, my system has a VIA Apollo Pro chip set, which isn't 100%
happy with 2.4.2 (none of the UDMA modes above 2 seem to work, e.g, and
you get fairly poor perfomance by the looks of it).
Gather 2.4.4 has some fixes for Via Crapollo... how would I go about
downloading 2.4.4 XFS?

I installed 2.4.2 XFS on a 20GB Seagate IDE disk (5,400 rpm, 512KB cache,
ATA-66) as well as a pair of IBM SCSI disks (7,200 rpm, 512KB cache, FW
SCSI 40MBps).

This is probably a Linux issue, but when I boot up from the IDE drive, and
do hdparm -tT, I see 78/15-16MBps results; however, if I boot up from the
SCSI drives, I see 88/9MBps for both the SCSI and the IDE drives. Can't
explain this, unless hdparm is giving some completely bogus results.


-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Tue May 22 15:42:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MMgRk19585
	for linux-xfs-outgoing; Tue, 22 May 2001 15:42:27 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MMgQF19582
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 15:42:26 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 152KrB-0005xu-00
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 10:42:25 +1200
Date: Wed, 23 May 2001 10:42:25 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: <linux-xfs@oss.sgi.com>
Subject: Size of CVS tree?
Message-ID: <Pine.LNX.4.33.0105231041520.18450-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

How big is it? Just so I don't bust my monthly data volume allocation
here... ;-)

-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Tue May 22 16:08:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MN8Ud20245
	for linux-xfs-outgoing; Tue, 22 May 2001 16:08:30 -0700
Received: from web12307.mail.yahoo.com (web12307.mail.yahoo.com [216.136.173.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MN8TF20242
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:08:29 -0700
Message-ID: <20010522230829.29124.qmail@web12307.mail.yahoo.com>
Received: from [192.208.44.100] by web12307.mail.yahoo.com; Tue, 22 May 2001 16:08:29 PDT
Date: Tue, 22 May 2001 16:08:29 -0700 (PDT)
From: Zuhra Leila <vic2000r@yahoo.com>
Subject: Installer Expert Text mode Question.
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello all.	

I have a problemm with SGI-XFS-RH7.1 installer.
When I go to the Expert text mode it does not allow
me to chose the drivers for network and SCSI cards.
After asking me for the language and Country and where

the installation packages are it waits a bit and after
that goes to anaconda without asking me for the
drivers
I want to chose for my network cards and SCSI
adapters.

SGI-XFS-RH7.0 installer in expert text mode works
fine.

Any help or Idea will help.

Thank you in advance.

Victor. 


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Tue May 22 16:21:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MNLaA20536
	for linux-xfs-outgoing; Tue, 22 May 2001 16:21:36 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MNLaF20533
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:21:36 -0700
Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4MNLX224911;
	Tue, 22 May 2001 18:21:33 -0500 (CDT)
Subject: Re: Installer Expert Text mode Question.
From: Eric Sandeen <sandeen@jump.net>
To: Zuhra Leila <vic2000r@yahoo.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010522230829.29124.qmail@web12307.mail.yahoo.com>
References: <20010522230829.29124.qmail@web12307.mail.yahoo.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 22 May 2001 18:24:07 -0500
Message-Id: <990573848.30565.10.camel@Porter>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 22 May 2001 16:08:29 -0700, Zuhra Leila wrote:
> Hello all.    
> 
> I have a problemm with SGI-XFS-RH7.1 installer.
> When I go to the Expert text mode it does not allow
> me to chose the drivers for network and SCSI cards.

Do you know if this behavior is different from the standard Red Hat
Linux 7.1 installer?

-Eric


From owner-linux-xfs@oss.sgi.com Tue May 22 16:32:53 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MNWrI20700
	for linux-xfs-outgoing; Tue, 22 May 2001 16:32:53 -0700
Received: from web12302.mail.yahoo.com (web12302.mail.yahoo.com [216.136.173.100])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4MNWqF20697
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:32:52 -0700
Message-ID: <20010522233252.88836.qmail@web12302.mail.yahoo.com>
Received: from [192.208.44.100] by web12302.mail.yahoo.com; Tue, 22 May 2001 16:32:52 PDT
Date: Tue, 22 May 2001 16:32:52 -0700 (PDT)
From: Zuhra Leila <vic2000r@yahoo.com>
Subject: Re: Installer Expert Text mode Question.E
To: Eric Sandeen <sandeen@jump.net>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <990573848.30565.10.camel@Porter>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just tryed this. It is exactly the same behavior
for RH7.1 Installer :-(


> > I have a problemm with SGI-XFS-RH7.1 installer.
> > When I go to the Expert text mode it does not
> allow
> > me to chose the drivers for network and SCSI
> cards.
> 
> Do you know if this behavior is different from the
> standard Red Hat
> Linux 7.1 installer?
> 
> -Eric
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Tue May 22 16:50:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4MNoGI21067
	for linux-xfs-outgoing; Tue, 22 May 2001 16:50:16 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4MNoFF21064
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 16:50:15 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 152Lun-000624-00; Wed, 23 May 2001 11:50:13 +1200
Date: Wed, 23 May 2001 11:50:13 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: <linux-xfs@oss.sgi.com>
cc: <sandeen@sgi.com>
Subject: Ramdisk size etc
Message-ID: <Pine.LNX.4.33.0105231146470.23119-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm going to rebuild the 2.4.2 kernel, and was wondering about the default
RAM disk size. In /etc/lilo.conf you have:

        append="ramdisk_size=2500"

for both the SMP and the UP kernel. Is that what the default value was set
to in the kernel .config file as well?

Also, for the SMP kernels, it might be an idea to take out APM support, as
it's supposedly not SMP safe.



-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Tue May 22 17:47:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N0l7722083
	for linux-xfs-outgoing; Tue, 22 May 2001 17:47:07 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N0l5F22080
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 17:47:05 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4N0l3l12554
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:47:03 +0800
Received: from mail ([203.167.26.164]) by sisa.i-manila.com.ph ; Wed, 23 May 2001 08:47:04 +0800 GMT
Received: from kalapati (kalapati.linux-server.tlc [192.168.0.201])
	by mail (Postfix) with ESMTP id 5DA1D3A59
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:46:49 +0800 (PHT)
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id D9E26461DCF
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:47:01 +0800 (PHT)
Date: Wed, 23 May 2001 08:47:01 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS
In-Reply-To: <Pine.LNX.4.33.0105230947190.18450-100000@vimfuego.saarinen.org>
Message-ID: <Pine.LNX.4.21.0105230837421.427-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 23 May 2001 at 09:58, Juha Saarinen wrote:

> Gather 2.4.4 has some fixes for Via Crapollo... how would I go about
> downloading 2.4.4 XFS?

Two ways you can go about it. First you download the vanilla 2.4.4 (or the
patch to bump up your kernel tree to 2.4.4 from 2.4.2), then grab the
latest XFS CVS patch:

<ftp://linux-xfs.sgi.com/projects/xfs/download/patches/linux-2.4.4-xfs-cvs-05152001.patch.gz>

To patch your kernel I've found a number of ways, but I personally use
this one:

 o Create a directory /usr/src/linux-2.4.4/
 o Extract your 2.4.4 kernel into /usr/src/linux-2.4.4/linux/
 o While in /usr/src/ do a
	cat linux-2.4.4-xfs-cvs-05152001.patch.gz | gunzip | patch -p0
 o ln -s linux-2.4.4/linux/ linux

Alternatively, you can get the entire development tree via CVS or CVSup.
This should give you the Linux kernel 2.4.4 with the required XFS stuff
updated to the last check-in by the developers. The benefit of this is
that you get the latest fixes and performance updates checked in. The
latest patch downloadable by the first method I gave was a snapshot done
on 15 May 2001.

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Tue May 22 17:50:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N0oVq22154
	for linux-xfs-outgoing; Tue, 22 May 2001 17:50:31 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N0oUF22151
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 17:50:30 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id CCFF5CAC50F
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 20:50:07 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 152Moh-0004ES-00
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 20:47:59 -0400
Date: Tue, 22 May 2001 20:47:59 -0400
To: linux-xfs@oss.sgi.com
Subject: XFS leaking memory
Message-ID: <20010522204759.A16254@chimesnet.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="EeQfGwPcQSOJBaQU"
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey everyone,

One of my idle boxes is running linux-2.4-xfs(cvs 17/5/2001).  The memory usage
is enormous.  A similar situation is resulting on other boxes.  Attached
is /proc/meminfo and /proc/slabinfo.

System
------
2x750Mhz
1GB ram

--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="meminfo.txt"

        total:    used:    free:  shared: buffers:  cached:
Mem:  1053982720 1026125824 27856896        0  6082560 865861632
Swap: 2147467264        0 2147467264
MemTotal:      1029280 kB
MemFree:         27204 kB
MemShared:           0 kB
Buffers:          5940 kB
Cached:         845568 kB
Active:          10188 kB
Inact_dirty:    815884 kB
Inact_clean:     25436 kB
Inact_target:       12 kB
HighTotal:      131072 kB
HighFree:        13556 kB
LowTotal:       898208 kB
LowFree:         13648 kB
SwapTotal:     2097136 kB
SwapFree:      2097136 kB

--EeQfGwPcQSOJBaQU
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="slabinfo.txt"

slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
nfs_read_data          0      0    384    0    0    1 :  124   62
nfs_write_data         0      0    384    0    0    1 :  124   62
nfs_page               0      0     96    0    0    1 :  252  126
fib6_nodes             5    226     32    2    2    1 :  252  126
ip6_dst_cache          5     40    192    2    2    1 :  252  126
ndisc_cache            1     30    128    1    1    1 :  252  126
xfs_chashlist       1944   2020     16   10   10    1 :  252  126
xfs_ili            40068  41580    136 1438 1485    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item         135    135    260    9    9    1 :  124   62
xfs_efd_item         135    135    260    9    9    1 :  124   62
xfs_buf_item         186    312    148   11   12    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state           0      0    340    0    0    1 :  124   62
xfs_trans            130    192    320   12   16    1 :  124   62
xfs_inode          45618  47168    468 5711 5896    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item    127    202     16    1    1    1 :  252  126
page_buf_t           274    400    192   16   20    1 :  252  126
page_buf_reg_t         1     40     96    1    1    1 :  252  126
avl_object_t           1    113     32    1    1    1 :  252  126
avl_entry_t          200    452     32    4    4    1 :  252  126
tcp_tw_bucket        150    150    128    5    5    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash            9    226     32    2    2    1 :  252  126
ip_dst_cache         168    168    160    7    7    1 :  252  126
arp_cache            120    120    128    4    4    1 :  252  126
blkdev_requests     2048   2080     96   52   52    1 :  252  126
dnotify cache        126    169     20    1    1    1 :  252  126
file lock cache      210    210     92    5    5    1 :  252  126
fasync cache         202    202     16    1    1    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    450    576    160   24   24    1 :  252  126
sock                 244    244    928   61   61    1 :  124   62
inode_cache       103396 105008    480 12946 13126    1 :  124   62
bdev_cache           780    885     64   15   15    1 :  252  126
sigqueue             261    261    132    9    9    1 :  252  126
dentry_cache      107130 114060    128 3658 3802    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 764    800     96   20   20    1 :  252  126
names_cache           28     28   4096   28   28    1 :   60   30
buffer_head       119140 136240     96 3353 3406    1 :  252  126
mm_struct            270    270    128    9    9    1 :  252  126
vm_area_struct      2292   2655     64   43   45    1 :  252  126
fs_cache             295    295     64    5    5    1 :  252  126
files_cache          171    171    416   19   19    1 :  124   62
signal_act           117    117   1312   39   39    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      0 131072    0    0   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             3      3  65536    3    3   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      2  32768    0    2    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              1      5   8192    1    5    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             50     50   4096   50   50    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            134    134   2048   67   67    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            176    176   1024   44   44    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             170    232    512   27   29    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             540    540    256   36   36    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128            1884   2010    128   67   67    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64             3237   3363     64   57   57    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            26464  27346     32  242  242    1 :  252  126

--EeQfGwPcQSOJBaQU--

From owner-linux-xfs@oss.sgi.com Tue May 22 17:51:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N0pfP22181
	for linux-xfs-outgoing; Tue, 22 May 2001 17:51:41 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N0peF22178
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 17:51:40 -0700
Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4N0paM14428;
	Tue, 22 May 2001 19:51:36 -0500 (CDT)
Subject: Re: Ramdisk size etc
From: Eric Sandeen <sandeen@sgi.com>
To: Juha Saarinen <juha@saarinen.org>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: 
	<Pine.LNX.4.33.0105231146470.23119-100000@vimfuego.saarinen.org>
References: <Pine.LNX.4.33.0105231146470.23119-100000@vimfuego.saarinen.org>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 22 May 2001 19:54:10 -0500
Message-Id: <990579250.30985.0.camel@Porter>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 23 May 2001 11:50:13 +1200, Juha Saarinen wrote:

> I'm going to rebuild the 2.4.2 kernel, and was wondering about the default
> RAM disk size. In /etc/lilo.conf you have:
> 
>         append="ramdisk_size=2500"
> 
> for both the SMP and the UP kernel. Is that what the default value was set
> to in the kernel .config file as well?

Here is how I understand this stuff:

The value in the kernel is just the default for what the ramdisk size
should be; passing a parameter to lilo overrides that.

Also, this option just sets an upper bound on the size of the ramdisk.
So I wouldn't worry TOO much about getting the size just right.

(But FWIW, the size is set to the default 4086 (4M) in the RPM kernel
configs)

> Also, for the SMP kernels, it might be an idea to take out APM support, as
> it's supposedly not SMP safe.

Configure.help says this:

  Note that the APM support is almost completely disabled for
  machines with more than one CPU.

At one point there was a discussion about allowing a tiny subset of AMP
functionality on SMP machines - basically, to allow soft power-off -
since so few machines are supported by ACPI under Linux at this point.

Since the configuration is _possible_, I assume (?) that it's safe, as
implemented.

-Eric

-----
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.



From owner-linux-xfs@oss.sgi.com Tue May 22 18:00:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N10WP22352
	for linux-xfs-outgoing; Tue, 22 May 2001 18:00:32 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N10VF22347
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:00:31 -0700
Received: from Porter (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4N10UM17773;
	Tue, 22 May 2001 20:00:30 -0500 (CDT)
Subject: Re: XFS leaking memory
From: Eric Sandeen <sandeen@sgi.com>
To: Tom Carroll <tcarroll@chimesnet.com>
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <20010522204759.A16254@chimesnet.com>
References: <20010522204759.A16254@chimesnet.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 22 May 2001 20:03:04 -0500
Message-Id: <990579785.31471.1.camel@Porter>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 22 May 2001 20:47:59 -0400, Tom Carroll wrote:
> Hey everyone,
> 
> One of my idle boxes is running linux-2.4-xfs(cvs 17/5/2001).  The memory usage
> is enormous.  A similar situation is resulting on other boxes.


Steve just checked in some changes related to this today, at least as
far as cleaning up inode memory - can you do an update and see if it
improves your situation?

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Tue May 22 18:05:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N15PO22488
	for linux-xfs-outgoing; Tue, 22 May 2001 18:05:25 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N15PF22485
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:05:25 -0700
Received: from madurai.engr.sgi.com ([163.154.5.75]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id SAA01107
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:05:24 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id RAA90657; Tue, 22 May 2001 17:59:25 -0700 (PDT)
Message-ID: <3B0B0BDD.8A0821F5@sgi.com>
Date: Tue, 22 May 2001 18:01:17 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Carroll <tcarroll@chimesnet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS leaking memory
References: <20010522204759.A16254@chimesnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Carroll wrote:
> 
> Hey everyone,
> 
> One of my idle boxes is running linux-2.4-xfs(cvs 17/5/2001).  The memory usage
> is enormous.  A similar situation is resulting on other boxes.  Attached
> is /proc/meminfo and /proc/slabinfo.
> 


There have been several recent fixes in this area;
can you please update to the latest cvs tree?

ananth.

--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Tue May 22 18:07:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N17WH22547
	for linux-xfs-outgoing; Tue, 22 May 2001 18:07:32 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N17WF22544
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:07:32 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id SAA00857
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:07:30 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA1896666; Tue, 22 May 2001 20:06:13 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA37179; Tue, 22 May 2001 20:06:13 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4N19DA20481; Tue, 22 May 2001 20:09:13 -0500
Message-Id: <200105230109.f4N19DA20481@jen.americas.sgi.com>
To: Tom Carroll <tcarroll@chimesnet.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS leaking memory 
References: <20010522204759.A16254@chimesnet.com>
Comments: In-reply-to Tom Carroll <tcarroll@chimesnet.com>
   message dated "Tue, 22 May 2001 20:47:59 -0400."
Date: Tue, 22 May 2001 20:09:12 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> --EeQfGwPcQSOJBaQU
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> Hey everyone,
> 
> One of my idle boxes is running linux-2.4-xfs(cvs 17/5/2001).  The memory usa
> ge
> is enormous.  A similar situation is resulting on other boxes.  Attached
> is /proc/meminfo and /proc/slabinfo.
> 
> System
> ------
> 2x750Mhz
> 1GB ram

This does not equate to a memory leak, there is no point in removing file
data from the cache unless there is another use for the memory, there is
always the possibility that it might be used again. All these numbers
mean is the memory has file data in it (it will be clean).

I also checked in a change today which will change memory usage when under
pressure - which this system is not.

Steve


From owner-linux-xfs@oss.sgi.com Tue May 22 18:16:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N1Go922723
	for linux-xfs-outgoing; Tue, 22 May 2001 18:16:50 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N1GmF22720
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:16:49 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 152NGX-00065z-00; Wed, 23 May 2001 13:16:45 +1200
Date: Wed, 23 May 2001 13:16:45 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Eric Sandeen <sandeen@sgi.com>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: Ramdisk size etc
In-Reply-To: <990579250.30985.0.camel@Porter>
Message-ID: <Pine.LNX.4.33.0105231254150.23119-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 22 May 2001, Eric Sandeen wrote:

> Here is how I understand this stuff:
>
> The value in the kernel is just the default for what the ramdisk size
> should be; passing a parameter to lilo overrides that.
>
> Also, this option just sets an upper bound on the size of the ramdisk.
> So I wouldn't worry TOO much about getting the size just right.
>
> (But FWIW, the size is set to the default 4086 (4M) in the RPM kernel
> configs)

Thanks, I wasn't sure what the upper limit should be. Set it to 4096.

> Configure.help says this:
>
>   Note that the APM support is almost completely disabled for
>   machines with more than one CPU.
>
> At one point there was a discussion about allowing a tiny subset of AMP
> functionality on SMP machines - basically, to allow soft power-off -
> since so few machines are supported by ACPI under Linux at this point.
>
> Since the configuration is _possible_, I assume (?) that it's safe, as
> implemented.

Well, I don't know, but:

# dmesg | grep apm
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14)
apm: disabled - APM is not SMP safe.


Incidentally, I had a chance to test the robustness of XFS just now. I
fat-fingered the compile of the kernel modules, and left out that critical
little number after the -j parameter for make. The OOM Killer stepped in
after a while, and started butchering processes, so I couldn't Ctrl-C or
even halt the system. I reset the box, and it came back up just fine, as
quickly as a normal boot.

SCSI device sdb: 8813870 512-byte hdwr sectors (4513 MB)
 /dev/scsi/host0/bus0/target2/lun0: p1 p2 < p5 p6 p7 >
Start mounting filesystem: sd(8,22)
XFS: WARNING: recovery required on readonly filesystem.

XFS: write access will be enabled during mount.

Starting XFS recovery on filesystem: sd(8,22) (dev: 8/22)
Ending XFS recovery on filesystem: sd(8,22) (dev: 8/22)


Start mounting filesystem: sd(8,23)
Starting XFS recovery on filesystem: sd(8,23) (dev: 8/23)
Ending XFS recovery on filesystem: sd(8,23) (dev: 8/23)
Start mounting filesystem: sd(8,5)
Starting XFS recovery on filesystem: sd(8,5) (dev: 8/5)
Ending XFS recovery on filesystem: sd(8,5) (dev: 8/5)
Start mounting filesystem: sd(8,7)
Ending clean XFS mount for filesystem: sd(8,7)
Start mounting filesystem: sd(8,6)
Starting XFS recovery on filesystem: sd(8,6) (dev: 8/6)
Ending XFS recovery on filesystem: sd(8,6) (dev: 8/6)
Start mounting filesystem: sd(8,17)
Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17)
Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17)

-- that was it. Very nice. :-)






-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544



From owner-linux-xfs@oss.sgi.com Tue May 22 18:30:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N1UUm22901
	for linux-xfs-outgoing; Tue, 22 May 2001 18:30:30 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N1UTF22898
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:30:29 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 152NTe-00066I-00; Wed, 23 May 2001 13:30:18 +1200
Date: Wed, 23 May 2001 13:30:18 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Federico Sevilla III <jijo@i-manila.com.ph>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS
In-Reply-To: <Pine.LNX.4.21.0105230837421.427-100000@kalapati.jijo.local>
Message-ID: <Pine.LNX.4.33.0105231329330.23119-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 23 May 2001, Federico Sevilla III wrote:

> On Wed, 23 May 2001 at 09:58, Juha Saarinen wrote:
>
> > Gather 2.4.4 has some fixes for Via Crapollo... how would I go about
> > downloading 2.4.4 XFS?
>
> Two ways you can go about it. First you download the vanilla 2.4.4 (or the
> patch to bump up your kernel tree to 2.4.4 from 2.4.2), then grab the
> latest XFS CVS patch:
>
> <ftp://linux-xfs.sgi.com/projects/xfs/download/patches/linux-2.4.4-xfs-cvs-05152001.patch.gz>
>
> To patch your kernel I've found a number of ways, but I personally use
> this one:
>
>  o Create a directory /usr/src/linux-2.4.4/
>  o Extract your 2.4.4 kernel into /usr/src/linux-2.4.4/linux/
>  o While in /usr/src/ do a
> 	cat linux-2.4.4-xfs-cvs-05152001.patch.gz | gunzip | patch -p0
>  o ln -s linux-2.4.4/linux/ linux
>
> Alternatively, you can get the entire development tree via CVS or CVSup.
> This should give you the Linux kernel 2.4.4 with the required XFS stuff
> updated to the last check-in by the developers. The benefit of this is
> that you get the latest fixes and performance updates checked in. The
> latest patch downloadable by the first method I gave was a snapshot done
> on 15 May 2001.

Thanks Federico. I'd like to do the CVS thing, but the tree looks very
big, so I'll need to think about it.

-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Tue May 22 18:46:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N1kab23145
	for linux-xfs-outgoing; Tue, 22 May 2001 18:46:36 -0700
Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N1kZF23142
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 18:46:35 -0700
Received: from UNIX47.ANDREW.CMU.EDU (UNIX47.ANDREW.CMU.EDU [128.2.11.247])
	by mail1.andrew.cmu.edu (8.11.1/8.11.1) with ESMTP id f4N1kC703041
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 21:46:12 -0400 (EDT)
Date: Tue, 22 May 2001 21:46:12 -0400 (EDT)
From: Hollis R Blanchard <hollis+@andrew.cmu.edu>
To: linux-xfs@oss.sgi.com
Subject: PPC success & wanted 0xfeedbabe
Message-ID: <Pine.LNX.4.21L.0105222134460.6636-100000@unix47.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey, just wanted to congratulate you all. I just got CVS XFS running on
PowerPC (slightly modified kernel 2.4.5pre3). Most of my problems came from
trying to apply a 2.4.4 patch to 2.4.5pre.

I was also very impressed with the state of the documentation and the
accompanying xfs utilities. I couldn't have asked for anything more; just
compile the package and install the rpm.

Did some quick banging on it and all looks well. One question though: I got
this output on my new xfs partition (after overfilling it, deleting
everything, and unmounting it):

$ /usr/sbin/xfs_logprint /dev/hda9
xfs_logprint:
    data device: 0x309
    log device: 0x309 daddr: 3072032 length: 9600

Header 0x2 wanted 0xfeedbabe
**********************************************************************
* ERROR: header cycle=2           block=2646                         *
**********************************************************************
Bad log record header

I have no idea what this means. xfs_check doesn't find any problems, and I
don't know this stuff well enough to investigate more (just experimenting).

-Hollis


From owner-linux-xfs@oss.sgi.com Tue May 22 19:03:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N23xb23385
	for linux-xfs-outgoing; Tue, 22 May 2001 19:03:59 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N23wF23382
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 19:03:58 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA09879
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 19:03:57 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id VAA1911769; Tue, 22 May 2001 21:02:40 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA14693; Tue, 22 May 2001 21:02:40 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4N25db20558; Tue, 22 May 2001 21:05:39 -0500
Message-Id: <200105230205.f4N25db20558@jen.americas.sgi.com>
To: Hollis R Blanchard <hollis+@andrew.cmu.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: PPC success & wanted 0xfeedbabe 
References: <Pine.LNX.4.21L.0105222134460.6636-100000@unix47.andrew.cmu.edu>
Comments: In-reply-to Hollis R Blanchard <hollis+@andrew.cmu.edu>
   message dated "Tue, 22 May 2001 21:46:12 -0400."
Date: Tue, 22 May 2001 21:05:39 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hey, just wanted to congratulate you all. I just got CVS XFS running on
> PowerPC (slightly modified kernel 2.4.5pre3). Most of my problems came from
> trying to apply a 2.4.4 patch to 2.4.5pre.
> 
> I was also very impressed with the state of the documentation and the
> accompanying xfs utilities. I couldn't have asked for anything more; just
> compile the package and install the rpm.
> 
> Did some quick banging on it and all looks well. One question though: I got
> this output on my new xfs partition (after overfilling it, deleting
> everything, and unmounting it):
> 
> $ /usr/sbin/xfs_logprint /dev/hda9
> xfs_logprint:
>     data device: 0x309
>     log device: 0x309 daddr: 3072032 length: 9600
> 
> Header 0x2 wanted 0xfeedbabe
> **********************************************************************
> * ERROR: header cycle=2           block=2646                         *
> **********************************************************************
> Bad log record header
> 
> I have no idea what this means. xfs_check doesn't find any problems, and I
> don't know this stuff well enough to investigate more (just experimenting).
> 
> -Hollis

Try running xfs_logprint -t on the filesystem, xfs_logprint on its own
is not quite smart enough to work out which parts of the log have been
written to as part of the last mount, and which have not. After a clean
unmount you should get this type of output:

[root@laptop lord]# xfs_logprint -t /dev/hda8
xfs_logprint:
    data device: 0x308
    log device: 0x308 daddr: 7654976 length: 12000

    log tail: 11364 head: 11364 state: <CLEAN>

Steve


From owner-linux-xfs@oss.sgi.com Tue May 22 19:42:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N2ggt24022
	for linux-xfs-outgoing; Tue, 22 May 2001 19:42:42 -0700
Received: from mail1.andrew.cmu.edu (MAIL1.ANDREW.CMU.EDU [128.2.10.131])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N2gfF24019
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 19:42:41 -0700
Received: from UNIX47.ANDREW.CMU.EDU (UNIX47.ANDREW.CMU.EDU [128.2.11.247])
	by mail1.andrew.cmu.edu (8.11.1/8.11.1) with ESMTP id f4N2gM718001;
	Tue, 22 May 2001 22:42:22 -0400 (EDT)
Date: Tue, 22 May 2001 22:42:22 -0400 (EDT)
From: Hollis R Blanchard <hollis+@andrew.cmu.edu>
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: PPC success & wanted 0xfeedbabe
In-Reply-To: <200105230205.f4N25db20558@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21L.0105222236500.6636-100000@unix47.andrew.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Tue, 22 May 2001, Steve Lord wrote:

> > Hey, just wanted to congratulate you all. I just got CVS XFS running on
> > PowerPC (slightly modified kernel 2.4.5pre3). Most of my problems came from
> > trying to apply a 2.4.4 patch to 2.4.5pre.

Oh, I did want to mention that I had some #ifdef MODULE difficulties.
avl_terminate and pagebuf_locking_terminate (iirc) were defined conditionally
but called unconditionally. I just deleted the ifdefs around the definition
and it worked fine. (As you might have guessed, I'm not using XFS as a
module.)

> > $ /usr/sbin/xfs_logprint /dev/hda9
> > xfs_logprint:
> >     data device: 0x309
> >     log device: 0x309 daddr: 3072032 length: 9600
> > 
> > Header 0x2 wanted 0xfeedbabe
> > **********************************************************************
> > * ERROR: header cycle=2           block=2646                         *
> > **********************************************************************
> > Bad log record header
> 
> Try running xfs_logprint -t on the filesystem, xfs_logprint on its own
> is not quite smart enough to work out which parts of the log have been
> written to as part of the last mount, and which have not. After a clean
> unmount you should get this type of output:
> 
> [root@laptop lord]# xfs_logprint -t /dev/hda8
> xfs_logprint:
>     data device: 0x308
>     log device: 0x308 daddr: 7654976 length: 12000
> 
>     log tail: 11364 head: 11364 state: <CLEAN>

Yes, I do get that, thank you. I didn't really follow your explanation (or the
man page's), but that's fine for me. :)

Thanks again!

-Hollis


From owner-linux-xfs@oss.sgi.com Tue May 22 22:08:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N58Xf26949
	for linux-xfs-outgoing; Tue, 22 May 2001 22:08:33 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N58UF26945
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 22:08:30 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 44CB7CAC50F
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 01:08:24 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 152Qqd-0004Jk-00
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 01:06:15 -0400
Date: Wed, 23 May 2001 01:06:15 -0400
To: linux-xfs@oss.sgi.com
Subject: Re: XFS leaking memory
Message-ID: <20010523010615.A16549@chimesnet.com>
References: <20010522204759.A16254@chimesnet.com> <200105230109.f4N19DA20481@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3"
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <200105230109.f4N19DA20481@jen.americas.sgi.com>; from lord@sgi.com on Tue, May 22, 2001 at 08:09:12PM -0500
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, May 22, 2001 at 08:09:12PM -0500, Steve Lord wrote:
> 
> This does not equate to a memory leak, there is no point in removing file
> data from the cache unless there is another use for the memory, there is
> always the possibility that it might be used again. All these numbers
> mean is the memory has file data in it (it will be clean).
> 
> I also checked in a change today which will change memory usage when under
> pressure - which this system is not.
> 
> Steve
> 
>

Hello all,
I compiled a new kernel (22/05/2001 22:30Z) and it 
corrected the idle memory usage.  

After rebooting, I recompiled the kernel.  After completion
of the compile, the box showed ~200MB memory consumption.  
cats of /proc/slabinfo and /proc/meminfo are attached.

Is there a way to decrease the aggressiveness of the caching
to lessen memory consumption?


I just want to congratulate everyone working on this project. 
Good job all.

Steve - I promise to choose my words more carefully in the future.

-Tom Carroll

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="meminfo.before"

        total:    used:    free:  shared: buffers:  cached:
Mem:  1053958144 68788224 985169920        0  3112960 41066496
Swap: 2147467264        0 2147467264
MemTotal:      1029256 kB
MemFree:        962080 kB
MemShared:           0 kB
Buffers:          3040 kB
Cached:          40104 kB
Active:          24812 kB
Inact_dirty:     18332 kB
Inact_clean:         0 kB
Inact_target:      384 kB
HighTotal:      131072 kB
HighFree:        79556 kB
LowTotal:       898184 kB
LowFree:        882524 kB
SwapTotal:     2097136 kB
SwapFree:      2097136 kB

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="slab.before"

slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           113    113     32    1    1    1 :  252  126
ip6_dst_cache         20     20    192    1    1    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        202    202     16    1    1    1 :  252  126
xfs_ili               56     56    136    2    2    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item          52     52    148    2    2    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state           0      0    340    0    0    1 :  124   62
xfs_trans             24     24    320    2    2    1 :  124   62
xfs_inode             88     88    468   11   11    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t            40     40    192    2    2    1 :  252  126
page_buf_reg_t        40     40     96    1    1    1 :  252  126
avl_object_t         113    113     32    1    1    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      40     40     96    1    1    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          226    226     32    2    2    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    216    216    160    9    9    1 :  252  126
sock                 112    112    928   28   28    1 :  124   62
inode_cache         3176   3176    480  397  397    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache        3420   3420    128  114  114    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 520    520     96   13   13    1 :  252  126
names_cache           11     11   4096   11   11    1 :   60   30
buffer_head        11320  11320     96  283  283    1 :  252  126
mm_struct             60     60    128    2    2    1 :  252  126
vm_area_struct      1416   1416     64   24   24    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           45     45    416    5    5    1 :  124   62
signal_act            45     45   1312   15   15    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             3      3  65536    3    3   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             39     39   4096   39   39    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            104    104   2048   52   52    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            128    128   1024   32   32    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             112    112    512   14   14    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             165    165    256   11   11    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             630    630    128   21   21    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32              678    678     32    6    6    1 :  252  126

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="meminfo.after"

        total:    used:    free:  shared: buffers:  cached:
Mem:  1053958144 246771712 807186432        0  3465216 199708672
Swap: 2147467264        0 2147467264
MemTotal:      1029256 kB
MemFree:        788268 kB
MemShared:           0 kB
Buffers:          3384 kB
Cached:         195028 kB
Active:          30496 kB
Inact_dirty:    167916 kB
Inact_clean:         0 kB
Inact_target:       44 kB
HighTotal:      131072 kB
HighFree:         3140 kB
LowTotal:       898184 kB
LowFree:        785128 kB
SwapTotal:     2097136 kB
SwapFree:      2097136 kB

--r5Pyd7+fXNt84Ff3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="slab.after"

slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           113    113     32    1    1    1 :  252  126
ip6_dst_cache         20     20    192    1    1    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        606    606     16    3    3    1 :  252  126
xfs_ili             1764   1764    136   63   63    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item         135    135    260    9    9    1 :  124   62
xfs_efd_item         135    135    260    9    9    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            144    144    320   12   12    1 :  124   62
xfs_inode           9208   9208    468 1151 1151    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item    202    202     16    1    1    1 :  252  126
page_buf_t           374    500    192   25   25    1 :  252  126
page_buf_reg_t        40     40     96    1    1    1 :  252  126
avl_object_t         113    113     32    1    1    1 :  252  126
avl_entry_t          426    678     32    6    6    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      40     40     96    1    1    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          226    226     32    2    2    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    504    504    160   21   21    1 :  252  126
sock                 156    156    928   39   39    1 :  124   62
inode_cache        12584  12584    480 1573 1573    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue             174    174    132    6    6    1 :  252  126
dentry_cache       17940  17940    128  598  598    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           11     11   4096   11   11    1 :   60   30
buffer_head        48826  49960     96 1230 1249    1 :  252  126
mm_struct            300    300    128   10   10    1 :  252  126
vm_area_struct      1821   1947     64   33   33    1 :  252  126
fs_cache             228    354     64    6    6    1 :  252  126
files_cache          171    171    416   19   19    1 :  124   62
signal_act           117    117   1312   39   39    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             3      3  65536    3    3   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             41     41   4096   41   41    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            182    244   1024   48   61    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             128    128    512   16   16    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             240    240    256   16   16    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             810    810    128   27   27    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              944    944     64   16   16    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32             1695   1695     32   15   15    1 :  252  126

--r5Pyd7+fXNt84Ff3--

From owner-linux-xfs@oss.sgi.com Tue May 22 22:35:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N5Z2f27368
	for linux-xfs-outgoing; Tue, 22 May 2001 22:35:02 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N5Z0F27365
	for <linux-xfs@oss.sgi.com>; Tue, 22 May 2001 22:35:00 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id HAA603175
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 07:34:56 +0200 (CEST)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA21783
	for linux-xfs@oss.sgi.com; Wed, 23 May 2001 15:33:37 +1000 (EST)
Date: Wed, 23 May 2001 15:33:37 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105230533.PAA21783@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - qa
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Tue May 22 22:32:22 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95761a
linux/fs/xfs/xfs_quota_priv.h - 1.19
linux/fs/xfs/xfs_dquot.h - 1.19
	- fix debug tests for quota mutex locks having been taken
	  (used in asserts).  this gets us through a debug qa run
	  on an smp machine with quota enabled.



From owner-linux-xfs@oss.sgi.com Wed May 23 02:17:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4N9HiH32604
	for linux-xfs-outgoing; Wed, 23 May 2001 02:17:44 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4N9HiF32601
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 02:17:44 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA02409
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 02:17:42 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id TAA11662
	for linux-xfs@oss.sgi.com; Wed, 23 May 2001 19:16:26 +1000 (EST)
Date: Wed, 23 May 2001 19:16:26 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105230916.TAA11662@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - libacl - get'ing empty ACL compatibility with ext2/BSD 
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This changes acl_get_file and acl_get_fd so that if an ACL has
never been explicitly set on a file/directory then in the
default compatibility mode, for access ACLs, a mininum 3-entry
ACL based on the std permissions is returned, and for default ACLs,
an empty (zero count) ACL is returned.
In IRIX compatibility mode (set by acl_set_compat(3)),
the IRIX semantics are preserved - which are, in both cases, an
ACL with a count of ACL_NOT_PRESENT (-1) is returned.

--Tim

Date:  Wed May 23 02:02:48 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95765a
cmd/xfstests/src/acl_get.c - 1.1
	- Gets an ACL on a file in various ways specified as different options.

cmd/xfstests/057 - 1.1
	- Test out compatibility modes attempting to retrieve an
	  ACL from a file when none has been explicitly set using chacl.

cmd/xfstests/057.out - 1.1
	- out for 57

cmd/acl/man/man3/acl_set_compat.3 - 1.1
	- Describe what acl_set_compat does.

cmd/xfstests/src/Makefile - 1.5
	- Add acl_get to get an acl on a file.

cmd/xfstests/group - 1.10
	- Add 057 for ACLs.

cmd/acl/man/man3/acl_get_file.3 - 1.3
	- Explain the effects of acl_set_compat.

cmd/acl/chacl/chacl.c - 1.4
	- With change to libacl, we now need to call acl_set_compat(ACL_COMPAT_IRIXGET)
	  to gain IRIX semantics.

cmd/acl/man/man3/acl_get_fd.3 - 1.3
	- Explain the effects of acl_set_compat.

cmd/acl/libacl/acl.c - 1.8
	- Add stuff for acl_set_compat() to turn on/off irix semantics.
	  Change acl_get_fd() and acl_get_file() to handle different compatibilities.

cmd/acl/include/acl.h - 1.4
	- Add stuff for acl_set_compat() to turn on/off irix semantics.

cmd/xfstests/include/builddefs.in - 1.4
	- Need to include the acl stuff.



From owner-linux-xfs@oss.sgi.com Wed May 23 04:45:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NBjOj04655
	for linux-xfs-outgoing; Wed, 23 May 2001 04:45:24 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NBjOF04652
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 04:45:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA19338
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 04:45:24 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1907333; Wed, 23 May 2001 06:44:06 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA54256; Wed, 23 May 2001 06:44:06 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4NBl0g21145; Wed, 23 May 2001 06:47:00 -0500
Message-Id: <200105231147.f4NBl0g21145@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Hollis R Blanchard <hollis+@andrew.cmu.edu>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: PPC success & wanted 0xfeedbabe 
In-Reply-To: Message from Hollis R Blanchard <hollis+@andrew.cmu.edu> 
   of "Tue, 22 May 2001 22:42:22 EDT." <Pine.LNX.4.21L.0105222236500.6636-100000@unix47.andrew.cmu.edu> 
Date: Wed, 23 May 2001 06:47:00 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Tue, 22 May 2001, Steve Lord wrote:
> 
> > > Hey, just wanted to congratulate you all. I just got CVS XFS running on
> > > PowerPC (slightly modified kernel 2.4.5pre3). Most of my problems came fr
> om
> > > trying to apply a 2.4.4 patch to 2.4.5pre.
> 
> Oh, I did want to mention that I had some #ifdef MODULE difficulties.
> avl_terminate and pagebuf_locking_terminate (iirc) were defined conditionally
> but called unconditionally. I just deleted the ifdefs around the definition
> and it worked fine. (As you might have guessed, I'm not using XFS as a
> module.)

Interesting, I also use built in xfs, looks like the _exit directive is
working differently between platforms. I can clean this up though.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 23 06:32:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NDW8x06914
	for linux-xfs-outgoing; Wed, 23 May 2001 06:32:08 -0700
Received: from marvin.linux-dude.com (c-d18a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.209])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NDW7F06910
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 06:32:07 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f4NDUpI02338;
	Wed, 23 May 2001 15:30:51 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jarek Luberek <jarek@swipnet.se>
To: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS leaking memory, cvs closed?
Date: Wed, 23 May 2001 15:30:50 +0200
X-Mailer: KMail [version 1.2]
References: <20010522204759.A16254@chimesnet.com> <200105230109.f4N19DA20481@jen.americas.sgi.com>
In-Reply-To: <200105230109.f4N19DA20481@jen.americas.sgi.com>
MIME-Version: 1.0
Message-Id: <01052315305000.02247@marvin>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wednesday 23 May 2001 03:09, you wrote:
...

> This does not equate to a memory leak, there is no point in removing file
> data from the cache unless there is another use for the memory, there is
> always the possibility that it might be used again. All these numbers
> mean is the memory has file data in it (it will be clean).

I booted my system this morning. During the day, it did not much
else than light mail trafic. At 3 pm I noticed from the unresponsivness
of the system that not everything was quite the same as in the
morning. Memory usage 200MB, free 56. Quite large numbers for 
xfs_inode and inode_cache in /proc/slabinfo. 

It runs a cvs copy from May 22 11.00 AM, EST (8 PM GMT). 
I would try a later copy if cvs server let me check it out but
cvs update -d does not work any longer as it used to.

> I also checked in a change today which will change memory usage when under
> pressure - which this system is not.


Greetings,
Jarek

From owner-linux-xfs@oss.sgi.com Wed May 23 08:05:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NF5Lo10354
	for linux-xfs-outgoing; Wed, 23 May 2001 08:05:21 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NF58F10348
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:05:09 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA656414
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 17:05:06 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1894311; Wed, 23 May 2001 10:03:48 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA06252; Wed, 23 May 2001 10:03:48 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4NF75V01709; Wed, 23 May 2001 10:07:05 -0500
Message-Id: <200105231507.f4NF75V01709@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Jarek Luberek <jarek@swipnet.se>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS leaking memory, cvs closed? 
In-Reply-To: Message from Jarek Luberek <jarek@swipnet.se> 
   of "Wed, 23 May 2001 15:30:50 +0200." <01052315305000.02247@marvin> 
Date: Wed, 23 May 2001 10:07:05 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Wednesday 23 May 2001 03:09, you wrote:
> ...
> 
> > This does not equate to a memory leak, there is no point in removing file
> > data from the cache unless there is another use for the memory, there is
> > always the possibility that it might be used again. All these numbers
> > mean is the memory has file data in it (it will be clean).
> 
> I booted my system this morning. During the day, it did not much
> else than light mail trafic. At 3 pm I noticed from the unresponsivness
> of the system that not everything was quite the same as in the
> morning. Memory usage 200MB, free 56. Quite large numbers for 
> xfs_inode and inode_cache in /proc/slabinfo. 

The inode pool sizes are what the latest fixes should help with.

> 
> It runs a cvs copy from May 22 11.00 AM, EST (8 PM GMT). 
> I would try a later copy if cvs server let me check it out but
> cvs update -d does not work any longer as it used to.

Hmm this appears to be working now - at least from here.

> 
> > I also checked in a change today which will change memory usage when under
> > pressure - which this system is not.
> 
> 
> Greetings,
> Jarek

Steve




From owner-linux-xfs@oss.sgi.com Wed May 23 08:14:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NFE4v11152
	for linux-xfs-outgoing; Wed, 23 May 2001 08:14:04 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NFE3F11149
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:14:03 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA01375
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:14:01 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1917298; Wed, 23 May 2001 10:12:46 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA92609; Wed, 23 May 2001 10:12:45 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4NFG2J01325; Wed, 23 May 2001 10:16:02 -0500
Message-Id: <200105231516.f4NFG2J01325@jen.americas.sgi.com>
Date: Wed, 23 May 2001 10:16:02 -0500
Subject: TAKE - nfs server over xfs fix
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

A recent change had a double lock trip in it - which causes hard hangs of
an nfs server sometimes (or the nmi oopser if you run with it). Problem
has only been out there a few days.

Date:  Wed May 23 08:11:18 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95782a
linux/fs/xfs/linux/xfs_vnode.c - 1.63
	- Fix a problem with cold cache NFS lookups coming in, recent changes led
	  to a double trip of a lock, making xfs drop its inode cache exposed this.



From owner-linux-xfs@oss.sgi.com Wed May 23 08:53:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NFrb812425
	for linux-xfs-outgoing; Wed, 23 May 2001 08:53:37 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4NFrZF12422
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 08:53:36 -0700
Received: (qmail 4675 invoked by uid 3995); 23 May 2001 15:53:33 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: 2.4.2 build problems
Date: 23 May 2001 11:53:33 -0400
Message-ID: <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov>
Lines: 68
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The latest chapter in my continuing saga to put together a Dell system
with two AMI MegaRAID's using XFS...

With the 1.0 (2.4.2) kernel, XFS works, but I get occasional:

   kernel: __alloc_pages: 2-order allocation failed.
   kernel: __alloc_pages: 0-order allocation failed.

And--the show stopper for me--the "mtx" tape library utility no longer
works under the 2.4 kernel, and the mtx maintainer has been laid off
and says 2.4 has a "busted SCSI subsystem".

Under RH 7.0 (2.2 kernel), mtx worked fine but XFS is not available.

I was hoping that building a custom 2.4.2 kernel with the options I
know I need might help, but now the kernel build is failing.

Here's what I've done:

  make xconfig, selected my options
  mv .config ..
  make mrproper
  mv ../.config .
  make oldconfig
  make CC=kgcc dep clean bzImage modules

It bombs out with:

  kgcc -E -C -P -I/usr/src/linux-2.4/include -imacros
  /usr/src/linux-2.4/include/asm-i386/page_offset.h -Ui386
  arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds 
  ld -m elf_i386 -T /usr/src/linux-2.4/arch/i386/vmlinux.lds -e stext
  arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
  init/version.o \ 
	--start-group \
	arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
	mm/mm.o fs/fs.o ipc/ipc.o \ 
	drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
	drivers/net/net.o drivers/media/media.o
	drivers/char/agp/agp.o drivers/char/drm/drm.o
	drivers/ide/idedriver.o drivers/scsi/scsidrv.o
	drivers/scsi/aic7xxx_new/aic7xxx_drv.o drivers/cdrom/driver.o
	drivers/sound/sounddrivers.o drivers/pci/driver.o
	drivers/pnp/pnp.o drivers/video/video.o \ 
	net/network.o \
	/usr/src/linux-2.4/arch/i386/lib/lib.a
	/usr/src/linux-2.4/lib/lib.a
	/usr/src/linux-2.4/arch/i386/lib/lib.a \ 
	--end-group \
	-o vmlinux
drivers/scsi/aic7xxx_new/aic7xxx_drv.o: In function `ahc_run_qoutfifo':
drivers/scsi/aic7xxx_new/aic7xxx_drv.o(.text+0x4fd8): multiple definition of `ahc_run_qoutfifo'
drivers/scsi/scsidrv.o(.text+0xefc8): first defined here
drivers/scsi/aic7xxx_new/aic7xxx_drv.o: In function `ahc_platform_freeze_devq':
drivers/scsi/aic7xxx_new/aic7xxx_drv.o(.text+0xbd8): multiple definition of `ahc_platform_freeze_devq'
drivers/scsi/scsidrv.o(.text+0xabc8): first defined here
...blah blah blah...

Questions:

 1) Why is the build failing?
 2) Does anyone have mtx working under 2.4?
 3) Is there another tape library controller beside mtx?
 4) Any other advice?

Thanks,

-Dave

From owner-linux-xfs@oss.sgi.com Wed May 23 09:10:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NGAuh13552
	for linux-xfs-outgoing; Wed, 23 May 2001 09:10:56 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NGAtF13549
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 09:10:55 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4NGApr07633;
	Wed, 23 May 2001 11:10:51 -0500 (CDT)
Message-ID: <3B0BE1AE.285C88D5@sgi.com>
Date: Wed, 23 May 2001 11:13:34 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sill <ds-linux-xfs@sws5.ctd.ornl.gov>
CC: linux-xfs@oss.sgi.com
Subject: Re: 2.4.2 build problems
References: <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dave Sill wrote:
 
>  1) Why is the build failing?

Sorry, the aic7xxx driver baffles me, hopefully someone else can help. 
:)

>  2) Does anyone have mtx working under 2.4?

Red Hat ships mtx with 7.1, which uses a 2.4 kernel.  Perhaps they have
some patches?  I am not at all familiar with mtx, but looking at what
Red Hat has done may help...

http://rpmfind.net/linux/RPM/redhat/7.1/i386/mtx-1.2.10-1.i386.html

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 23 09:15:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NGFYe13634
	for linux-xfs-outgoing; Wed, 23 May 2001 09:15:34 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NGFXF13631
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 09:15:33 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id SAA655583
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 18:15:30 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1914942; Wed, 23 May 2001 11:14:12 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA17515; Wed, 23 May 2001 11:14:11 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4NGHRH02235; Wed, 23 May 2001 11:17:27 -0500
Message-Id: <200105231617.f4NGHRH02235@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
cc: linux-xfs@oss.sgi.com
Subject: Re: 2.4.2 build problems 
In-Reply-To: Message from "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov> 
   of "23 May 2001 11:53:33 EDT." <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov> 
Date: Wed, 23 May 2001 11:17:27 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> Questions:
> 
>  1) Why is the build failing?
>  2) Does anyone have mtx working under 2.4?
>  3) Is there another tape library controller beside mtx?
>  4) Any other advice?
> 
> Thanks,
> 
> -Dave


I can do the easy part here - send questions 2 through 4 to linux kernel,
you are more likely to get an answer there. The aic build question might
also get an answer there.

It looks a little odd that drivers/scsi/scsidrv.o and
drivers/scsi/aic7xxx_new/aic7xxx_drv.o are going into the kernel link,
but sure enough that happens here too. It looks like something odd in
the config options for scsi. I do not have any ahc defines in my scsidrv.o
module. I would take a look at the scsi config options you have, if you
modified the Makefile in the scsi directory maybe the aic code is
going in both places.

Steve





From owner-linux-xfs@oss.sgi.com Wed May 23 09:17:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NGHsQ13760
	for linux-xfs-outgoing; Wed, 23 May 2001 09:17:54 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4NGHrF13757
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 09:17:53 -0700
Received: (qmail 5523 invoked by uid 3995); 23 May 2001 16:17:51 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Re: 2.4.2 build problems
References: <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov> <3B0BE1AE.285C88D5@sgi.com>
Date: 23 May 2001 12:17:51 -0400
In-Reply-To: Eric Sandeen's message of "Wed, 23 May 2001 11:13:34 -0500"
Message-ID: <wx0r8xgvy34.fsf@sws5.ctd.ornl.gov>
Lines: 10
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen <sandeen@sgi.com> writes:

> >  2) Does anyone have mtx working under 2.4?
> 
> Red Hat ships mtx with 7.1, which uses a 2.4 kernel.

Sorry, I wasn't very clear there. I'm running RH 7.1, so the question
is whether or not anyone's actually used it under 7.1+XFS.

-Dave

From owner-linux-xfs@oss.sgi.com Wed May 23 10:43:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NHh6a15905
	for linux-xfs-outgoing; Wed, 23 May 2001 10:43:06 -0700
Received: from epithumia.math.uh.edu (IDENT:root@epithumia.math.uh.edu [129.7.128.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NHh6F15902
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 10:43:06 -0700
Received: (from tibbs@localhost)
	by epithumia.math.uh.edu (8.11.0/8.11.1) id f4NHh2H17076;
	Wed, 23 May 2001 12:43:02 -0500
To: linux-xfs@oss.sgi.com
Subject: LVM Utilities?
From: Jason L Tibbitts III <tibbs@math.uh.edu>
Date: 23 May 2001 12:43:01 -0500
Message-ID: <ufan184yna2.fsf@epithumia.math.uh.edu>
Lines: 12
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I wanted to experiment with XFS and LVM so I installed the full set of RPMS
on an already running Red Hat 7.1. system.  Everything works fine, but I
can't seem to find the LVM utilities anywhere.

Can I just install any recent RPM of the utilities from sistina.com or do I
need one matched to the version included in the kernel?  (I'm somewhat
confused by the whole IOP compatibility thing right now.)  Anyone have a
source for RPMS known to work?

Thanks,

 - J<

From owner-linux-xfs@oss.sgi.com Wed May 23 12:06:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJ6tg19224
	for linux-xfs-outgoing; Wed, 23 May 2001 12:06:55 -0700
Received: from trillium-hollow.org (IDENT:root@trillium-hollow.org [209.180.166.89])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJ6sF19221
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:06:54 -0700
Received: from erich (helo=trillium)
	by trillium-hollow.org with local-esmtp (Exim 3.20 #1)
	id 152drt-0000Lp-00; Wed, 23 May 2001 12:00:25 -0700
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Problems with SMP version of XFS RH 7.1 installer 
In-Reply-To: Your message of "Sun, 20 May 2001 09:54:42 CDT."
             <200105201454.f4KEsgk19449@jen.americas.sgi.com> 
Date: Wed, 23 May 2001 12:00:25 -0700
From: erich@uruk.org
Message-Id: <E152drt-0000Lp-00@trillium-hollow.org>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Steve Lord <lord@sgi.com> wrote:

> > The overall result makes me think it's some kind of linux 2.4.2 SMP
> > stability problem, but I'm not sure what other kernel w/XFS to try...
...

> If you do try the development cvs tree, please let us know if it fixes
> you problem, also for general redhat 7.1 issues please look at this 
> page for issues redhat has found:
> 
> http://www.redhat.com/support/docs/gotchas/7.1/gotchas-71.html
> 
> However, since your problems show up copying large amounts of data,
> there is chance this is xfs chewing up all the memory on your machine
> and not letting go for some reason.

I think I found the problem, and it isn't XFS-related, though the
performance of the cvs tree I got on tuesday seems noticably better.
I still see some issues with large file transfers pushing everything
out of memory, but I imagine that's a 2.4 kernel VM tuning
issue.

The problem is that the RH 7.1 SMP kernel configuration defaults to having
a few bits of APM turned on, and on some SMP boxen, APM is seriously busted
once you activate the other processors and causes weird/buggy behavior/
occasional crashes unless you remove it from the kernel configuration.
I will do some more checking to see if it works with anything enabled at
all, but in any case I'm filing this in Bugzilla at RedHat and I'll wrangle
it out with them.

Hopefully I can get to XFS on GRUB now.  ;)

--
    Erich Stefan Boleyn     <erich@uruk.org>     http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"

From owner-linux-xfs@oss.sgi.com Wed May 23 12:08:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJ8AI19262
	for linux-xfs-outgoing; Wed, 23 May 2001 12:08:10 -0700
Received: from hermes.aoe.vt.edu (IDENT:root@hps.aoe.vt.edu [128.173.191.43])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJ8AF19256
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:08:10 -0700
Received: from localhost (jmd@localhost)
	by hermes.aoe.vt.edu (8.9.3/8.9.3) with ESMTP id PAA19458
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 15:08:09 -0400
Date: Wed, 23 May 2001 15:08:09 -0400 (EDT)
From: Josh Durham <jmd@aoe.vt.edu>
To: linux-xfs@oss.sgi.com
Subject: GrowFSing
Message-ID: <Pine.LNX.4.21.0105231504000.17257-100000@hermes.aoe.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

We're trying to migrate a large volume from ReiserFS to XFS.  We have a
350GB volume, with a 150GB reiserfs partition.  If I create an XFS
parition(it would be after the reiserfs one), copied the data from the
reiserfs partition to the xfs one, remove the reiserfs partition, would I
be able to growfs the xfs partition to use the entire volume?

Thanks alot,

  - Josh


From owner-linux-xfs@oss.sgi.com Wed May 23 12:23:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJNok19607
	for linux-xfs-outgoing; Wed, 23 May 2001 12:23:50 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJNnF19604
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:23:49 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08900
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:23:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1920227; Wed, 23 May 2001 14:22:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA44642; Wed, 23 May 2001 14:22:31 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4NJPkW06028; Wed, 23 May 2001 14:25:46 -0500
Message-Id: <200105231925.f4NJPkW06028@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Josh Durham <jmd@aoe.vt.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: GrowFSing 
In-Reply-To: Message from Josh Durham <jmd@aoe.vt.edu> 
   of "Wed, 23 May 2001 15:08:09 EDT." <Pine.LNX.4.21.0105231504000.17257-100000@hermes.aoe.vt.edu> 
Date: Wed, 23 May 2001 14:25:46 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> We're trying to migrate a large volume from ReiserFS to XFS.  We have a
> 350GB volume, with a 150GB reiserfs partition.  If I create an XFS
> parition(it would be after the reiserfs one), copied the data from the
> reiserfs partition to the xfs one, remove the reiserfs partition, would I
> be able to growfs the xfs partition to use the entire volume?
> 
> Thanks alot,
> 
>   - Josh


Unfortunately not, you can only grow at the end, not the beginning. Now,
if this is LVM or md, there may be tricks you can play to move things about,
but that would require boundaries to align correctly.

You could do this (CAREFULLY):

	o create a temporary partition at the end of the device,
	o copy the reiserfs data into this partition
	o remove the original partition which contained the reiserfs filesystem
	o make a larger partition containing all the space except that in
	  the new end of device partition, and put xfs on it.
	o copy the data from the temp partition into xfs
	o remove the temp partition and extend the xfs partition to the full
	  device
	o run growfs

I wish I had a simpler suggestion! I have done this type of thing, but not with
that much data. Moving the reiserfs filesystem might be faster at the block
level or the filesystem level (i.e. dd or cp -r) depending on how full it is.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 23 12:26:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJQoI19678
	for linux-xfs-outgoing; Wed, 23 May 2001 12:26:50 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJQnF19675
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:26:49 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA08780
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:26:49 -0700 (PDT)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA61695; Wed, 23 May 2001 14:25:33 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4NJOWw31361;
	Wed, 23 May 2001 15:24:33 -0400
Message-ID: <3B0C0E6C.53086F91@thebarn.com>
Date: Wed, 23 May 2001 15:24:30 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dave Sill <ds-linux-xfs@sws5.ctd.ornl.gov>
CC: linux-xfs@oss.sgi.com
Subject: Re: 2.4.2 build problems
References: <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dave Sill wrote:

> The latest chapter in my continuing saga to put together a Dell system
> with two AMI MegaRAID's using XFS...
>
> With the 1.0 (2.4.2) kernel, XFS works, but I get occasional:
>
>    kernel: __alloc_pages: 2-order allocation failed.
>    kernel: __alloc_pages: 0-order allocation failed.

We haven't been able to track this down precisely, but rumor has it
the devel tree which is at 2.4.4 is working better.



>
>
> And--the show stopper for me--the "mtx" tape library utility no longer
> works under the 2.4 kernel, and the mtx maintainer has been laid off
> and says 2.4 has a "busted SCSI subsystem".
>
> Under RH 7.0 (2.2 kernel), mtx worked fine but XFS is not available.
>
> I was hoping that building a custom 2.4.2 kernel with the options I
> know I need might help, but now the kernel build is failing.
>
> Here's what I've done:
>
>   make xconfig, selected my options
>   mv .config ..
>   make mrproper
>   mv ../.config .
>   make oldconfig
>   make CC=kgcc dep clean bzImage modules
>
> It bombs out with:
>
>   kgcc -E -C -P -I/usr/src/linux-2.4/include -imacros
>   /usr/src/linux-2.4/include/asm-i386/page_offset.h -Ui386
>   arch/i386/vmlinux.lds.S >arch/i386/vmlinux.lds
>   ld -m elf_i386 -T /usr/src/linux-2.4/arch/i386/vmlinux.lds -e stext
>   arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
>   init/version.o \
>         --start-group \
>         arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
>         mm/mm.o fs/fs.o ipc/ipc.o \
>         drivers/block/block.o drivers/char/char.o drivers/misc/misc.o
>         drivers/net/net.o drivers/media/media.o
>         drivers/char/agp/agp.o drivers/char/drm/drm.o
>         drivers/ide/idedriver.o drivers/scsi/scsidrv.o
>         drivers/scsi/aic7xxx_new/aic7xxx_drv.o drivers/cdrom/driver.o
>         drivers/sound/sounddrivers.o drivers/pci/driver.o
>         drivers/pnp/pnp.o drivers/video/video.o \
>         net/network.o \
>         /usr/src/linux-2.4/arch/i386/lib/lib.a
>         /usr/src/linux-2.4/lib/lib.a
>         /usr/src/linux-2.4/arch/i386/lib/lib.a \
>         --end-group \
>         -o vmlinux
> drivers/scsi/aic7xxx_new/aic7xxx_drv.o: In function `ahc_run_qoutfifo':
> drivers/scsi/aic7xxx_new/aic7xxx_drv.o(.text+0x4fd8): multiple definition of `ahc_run_qoutfifo'
> drivers/scsi/scsidrv.o(.text+0xefc8): first defined here
> drivers/scsi/aic7xxx_new/aic7xxx_drv.o: In function `ahc_platform_freeze_devq':
> drivers/scsi/aic7xxx_new/aic7xxx_drv.o(.text+0xbd8): multiple definition of `ahc_platform_freeze_devq'
> drivers/scsi/scsidrv.o(.text+0xabc8): first defined here
> ...blah blah blah...
>
> Questions:
>
>  1) Why is the build failing?
>  2) Does anyone have mtx working under 2.4?
>  3) Is there another tape library controller beside mtx?
>  4) Any other advice?
>
> Thanks,
>
> -Dave

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 23 12:36:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJaQm19936
	for linux-xfs-outgoing; Wed, 23 May 2001 12:36:26 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJaOF19933
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:36:24 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA648607
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:36:22 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1904328; Wed, 23 May 2001 14:35:04 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA95675; Wed, 23 May 2001 14:35:04 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4NJcI206089; Wed, 23 May 2001 14:38:18 -0500
Message-Id: <200105231938.f4NJcI206089@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: erich@uruk.org
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Problems with SMP version of XFS RH 7.1 installer 
In-Reply-To: Message from erich@uruk.org 
   of "Wed, 23 May 2001 12:00:25 PDT." <E152drt-0000Lp-00@trillium-hollow.org> 
Date: Wed, 23 May 2001 14:38:18 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> I think I found the problem, and it isn't XFS-related, though the
> performance of the cvs tree I got on tuesday seems noticably better.
> I still see some issues with large file transfers pushing everything
> out of memory, but I imagine that's a 2.4 kernel VM tuning
> issue.
> 
> The problem is that the RH 7.1 SMP kernel configuration defaults to having
> a few bits of APM turned on, and on some SMP boxen, APM is seriously busted
> once you activate the other processors and causes weird/buggy behavior/
> occasional crashes unless you remove it from the kernel configuration.
> I will do some more checking to see if it works with anything enabled at
> all, but in any case I'm filing this in Bugzilla at RedHat and I'll wrangle
> it out with them.

Interesting (Steve goes and turns off apm in in his own smp .config file)

> 
> Hopefully I can get to XFS on GRUB now.  ;)

Looks like there is plenty to do there ;-)

Steve




From owner-linux-xfs@oss.sgi.com Wed May 23 12:44:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NJiDE20087
	for linux-xfs-outgoing; Wed, 23 May 2001 12:44:13 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NJiCF20084
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 12:44:12 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id A5DCE1E2D7; Wed, 23 May 2001 21:44:11 +0200 (MEST)
Date: Wed, 23 May 2001 21:43:03 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: erich@uruk.org, linux-xfs@oss.sgi.com
Subject: Re: Problems with SMP version of XFS RH 7.1 installer
Message-ID: <20010523214303.A667@gruyere.muc.suse.de>
References: <E152drt-0000Lp-00@trillium-hollow.org> <200105231938.f4NJcI206089@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105231938.f4NJcI206089@jen.americas.sgi.com>; from lord@sgi.com on Wed, May 23, 2001 at 02:38:18PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 23, 2001 at 02:38:18PM -0500, Steve Lord wrote:
> > The problem is that the RH 7.1 SMP kernel configuration defaults to having
> > a few bits of APM turned on, and on some SMP boxen, APM is seriously busted
> > once you activate the other processors and causes weird/buggy behavior/
> > occasional crashes unless you remove it from the kernel configuration.
> > I will do some more checking to see if it works with anything enabled at
> > all, but in any case I'm filing this in Bugzilla at RedHat and I'll wrangle
> > it out with them.
> 
> Interesting (Steve goes and turns off apm in in his own smp .config file)

That should be a nop. apm.c does nothing on SMP kernels; except when you
enable apm=power-off and then it only does something on poweroff.


-Andi

From owner-linux-xfs@oss.sgi.com Wed May 23 13:35:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NKZIK22646
	for linux-xfs-outgoing; Wed, 23 May 2001 13:35:18 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NKZIF22643
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 13:35:18 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4NKZCb05619;
	Wed, 23 May 2001 15:35:13 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4NKZCM03862;
	Wed, 23 May 2001 15:35:12 -0500 (CDT)
Date: Wed, 23 May 2001 15:35:12 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Russell Cattelan <cattelan@thebarn.com>
cc: Andi Kleen <ak@suse.de>, Steve Lord <lord@sgi.com>, <sandeen@sgi.com>,
   Mike Pflugmacher <mikep@ncsa.uiuc.edu>, Wayne Hoyenga <louis@ncsa.uiuc.edu>,
   <linux-xfs@oss.sgi.com>
Subject: Re: linux 2.4.2-XFS
In-Reply-To: <3B0ACB27.6E576737@thebarn.com>
Message-ID: <Pine.LNX.4.33.0105231531460.25173-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Russell,

I was able to get a couple nice runs over xfs with the 2.4.4-xfs kernel
built from the development cvs tree.  I'm attaching a file with some
comparisons to reiserfs and ext2.  Thanks to all for the hints & tips.

I did get a few more
	__alloc_pages: 0-order allocation failed.

from xfs during the 3rd test, but it continued and completed ok.  The
kernel did not hang as before with 2.4.2.  Total test time for 3 runs of
"iozone -s 4000m" was about 5 hrs.

-Galen

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Wed May 23 13:46:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NKkD722864
	for linux-xfs-outgoing; Wed, 23 May 2001 13:46:13 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NKkCF22861
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 13:46:12 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4NKkBb06377
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 15:46:11 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
X-Envelope-To: <linux-xfs@oss.sgi.com>
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4NKkBM06315;
	Wed, 23 May 2001 15:46:11 -0500 (CDT)
Date: Wed, 23 May 2001 15:46:11 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: <linux-xfs@oss.sgi.com>
cc: <sgi-admin@ncsa.uiuc.edu>
Subject: the file I forgot...
Message-ID: <Pine.LNX.4.33.0105231541440.25173-200000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903347710-643906063-990650771=:25173"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---1903347710-643906063-990650771=:25173
Content-Type: TEXT/PLAIN; charset=US-ASCII


Here's the file.

And perhaps I spoke too soon.  My 2.4.4-xfs box just locked up solid on
its 4th attempt at iozone (I wanted to keep pounding it a bit longer to
see what happens).  It doesn't panic, it just stops responding (cannot
even answer a ping, console freezes).  I'm going to let it stay in that
state and see if it recovers in a while.
There are no additional 0-order allocation failed messages for the current
run of iozone on xfs--the box just went on holiday...

-Galen

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820

---1903347710-643906063-990650771=:25173
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=io
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105231546110.25173@osage.ncsa.uiuc.edu>
Content-Description: 
Content-Disposition: attachment; filename=io

UGVyZm9ybWFuY2UgZGF0YSBbIGdlbmVyYXRlZCB3aXRoOiBpb3pvbmUgLXMg
NDAwMG0gXQ0KZXh0MiAodHVuZWQgZG93biB0byA1MjAxMjggaW5vZGVzKQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICByYW5kb20gIHJhbmRvbSAgICBia3dkICByZWNvcmQg
IHN0cmlkZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog
ICAgICAgICAgICAgIEtCICByZWNsZW4gICB3cml0ZSByZXdyaXRlICAgIHJl
YWQgICAgcmVyZWFkICAgIHJlYWQgICB3cml0ZSAgICByZWFkIHJld3JpdGUg
ICAgcmVhZCAgIGZ3cml0ZSBmcmV3cml0ZSAgIGZyZWFkICBmcmVyZWFkDQog
ICAgICAgICA0MDk2MDAwICAgICAgIDQgICA2Mjg1OSAgIDYzOTEwICAgIDU2
Mjg1ICAgIDU2NTgyICAgIDEyOTQgICAxMzg0NSAgICAyODgxIDEwMjg0Mjkg
ICAxNTkzMyAgICA1MzQxMiAgICA0OTkxNCAgIDQ5NDU4ICAgIDU2NzU1DQog
ICAgICAgICA0MDk2MDAwICAgICAgIDQgICA0MzczOSAgIDQ4ODkzICAgIDU2
ODAyICAgIDU3NDU1ICAgIDEyOTUgICAxNDAyMSAgICAyODc3IDEwMzk0OTIg
ICAxNTY3MyAgICA0MTkxNSAgICA1NDUxMyAgIDQ4NjE3ICAgIDU3NTU1DQog
ICAgICAgICA0MDk2MDAwICAgICAgIDQgICA0MTIwMCAgIDUxODc1ICAgIDU3
MzE0ICAgIDU3NTI4ICAgIDEyOTMgICAxMzg1OCAgICAyODgxIDEwNDc0Mzkg
ICAxNTkzNiAgICA0NzExOCAgICA1MDExNyAgIDQ4NTk2ICAgIDU2NTQ2DQoN
CnJlaXNlcmZzDQogICAgICAgICA0MDk2MDAwICAgICAgIDQgICA1NjYxNCAg
IDU1NjQzICAgIDUxNzQ1ICAgIDUyMTM4ICAgIDEyNzYgICAxNDI0MCAgICAy
ODQzICA1MzY1MjMgICAxNTM0NiAgICA1NTM4OSAgICA1MzQ1MSAgIDQ5OTM1
ICAgIDUyMzg0DQogICAgICAgICA0MDk2MDAwICAgICAgIDQgICA1NDczNCAg
IDU1OTQwICAgIDUxMDk3ICAgIDUyMDcxICAgIDEyNDkgICAxMzg5NSAgICAy
ODM3ICA1MzU0ODYgICAxNTQxMyAgICA1NTc0MiAgICA1NzE4NSAgIDUwNzc5
ICAgIDUxNDQ4DQogICAgICAgICA0MDk2MDAwICAgICAgIDQgICA1NTI1OCAg
IDU3MTA4ICAgIDUxNzkwICAgIDUxNzU0ICAgIDEyNzUgICAxNDE3NyAgICAy
ODQyICA1MzM0MDAgICAxNTQ4MyAgICA1Njk0MCAgICA1NDE4OSAgIDUwODMy
ICAgIDUwODYwDQoNCnhmcw0KICAgICAgICAgNDA5NjAwMCAgICAgICA0ICAg
NjgzMDQgICA3NDM3NCAgICA1NTc5NCAgICA1NjUwMCAgICAxMjgxICAgMTQy
NzQgICAgMjg0MSAgOTM0NDQ3ICAgMTU1MzEgICAgNzM5NjMgICAgNzUzMjQg
ICA1NjA0MiAgICA1NjY1Nw0KICAgICAgICAgNDA5NjAwMCAgICAgICA0ICAg
NjM2MjcgICA3NzgyOSAgICA1NjcxMSAgICA1NjcyMCAgICAxMjcyICAgMTM4
MDEgICAgMjgzOCAgOTgxMDgzICAgMTU5MzkgICAgNzIxNTUgICAgNzUyMDgg
ICA1NTk1OCAgICA1NjM4MQ0KICAgICAgICAgNDA5NjAwMCAgICAgICA0ICAg
NjMzMzUgICA3NjA3OCAgICA1NTQzMyAgICA1NzA3MyAgICAxMjczICAgMTQx
MzQgICAgMjgzNSAgOTMwNTkxICAgMTUwNTggICAgNjYxODAgICAgNzU3MjAg
ICA1NTI1NSAgICA1NjUyNA0KDQoNClNwYWNlIGVmZmljaWVuY3kgY29tcGFy
aXNvbg0KDQpleHQyDQpGaWxlc3lzdGVtICAgICAgICAgICAxay1ibG9ja3Mg
ICAgICBVc2VkIEF2YWlsYWJsZSBVc2UlIE1vdW50ZWQgb24NCi9kZXYvc2Rk
MSAgICAgICAgICAgIDcxMDAyNTcwMCAgIDk0NDY0NTIgNjY1MDcyMzg4ICAg
MSUgL3N0b3JhZ2UNCg0KcmVpc2VyZnMNCi9kZXYvc2RjMSAgICAgICAgICAg
IDcxMDExNTU1MiAgICAgMzI4NDAgNzEwMDgyNzEyICAgMCUgL3N0b3JhZ2UN
Cg0KeGZzDQovZGV2L3NkZDEgICAgICAgICAgICA3MTAwNTA1NDQgICA0MTA2
OTQwIDcwNTk0MzYwNCAgIDElIC9zdG9yYWdlDQo=
---1903347710-643906063-990650771=:25173--

From owner-linux-xfs@oss.sgi.com Wed May 23 13:56:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NKulN23239
	for linux-xfs-outgoing; Wed, 23 May 2001 13:56:47 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NKujF23234
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 13:56:45 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152fdG-0006mg-00; Thu, 24 May 2001 08:53:26 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Jarek Luberek" <jarek@swipnet.se>, "Steve Lord" <lord@sgi.com>,
   <linux-xfs@oss.sgi.com>
Subject: RE: XFS leaking memory, cvs closed?
Date: Thu, 24 May 2001 08:52:53 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIOEAKCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01052315305000.02247@marvin>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: I booted my system this morning. During the day, it did not much
:: else than light mail trafic. At 3 pm I noticed from the unresponsivness
:: of the system that not everything was quite the same as in the
:: morning. Memory usage 200MB, free 56. Quite large numbers for
:: xfs_inode and inode_cache in /proc/slabinfo.

I don't know if this is related, but on a fresh install of XFS 1.0 (2.4.2),
I find that just after reboot, I get ~87-88MBps with hdparm buffer-cache
reads; after the system's been up and running (basically doing very little),
this drops to around 55MBps.

I see a similar drop in performance with Bonnie. The char/sec sequential
output figure drops from ~5,800KBps to 3,500KBps. If I reboot, performance
numbers go back to normal.

So... the question is, is it XFS, is it the Linux VM, the SCSI driver (it's
a Symbios sym53c8xx F/W SCSI), or a combination of all three?

# free
             total       used       free     shared    buffers     cached
Mem:        190288     186264       4024          0      65536      17140
-/+ buffers/cache:     103588      86700
Swap:       525656         32     525624


# cat /proc/slabinfo | grep xfs
xfs_chashlist       2613   2626     16   13   13    1 :  252  126
xfs_ili              108    168    136    6    6    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item          14     15    260    1    1    1 :  124   62
xfs_efd_item          14     30    260    1    2    1 :  124   62
xfs_buf_item          27     52    148    2    2    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          11     11    340    1    1    1 :  124   62
xfs_gap                0      0     16    0    0    1 :  252  126
xfs_trans              2     36    320    1    3    1 :  124   62
xfs_inode          66634  72667    536 9839 10381    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item    202    202     16    1    1    1 :  252  126



blkdev_requests     1536   1560     96   39   39    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache        2     42     92    1    1    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache              1    113     32    1    1    1 :  252  126
skbuff_head_cache    161    384    160   16   16    1 :  252  126
sock                  17     24    928    6    6    1 :  124   62
page_buf_t           240    240    160   10   10    1 :  252  126
page_buf_reg_t         6    113     32    1    1    1 :  252  126
avl_object_t           7    113     32    1    1    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
inode_cache        67504  69960    480 8745 8745    1 :  124   62
bdev_cache            44    118     64    2    2    1 :  252  126
sigqueue              29     29    132    1    1    1 :  252  126
kiobuf                47    180    128    6    6    1 :  252  126
dentry_cache       41994  59640    128 1988 1988    1 :  252  126
dquot                  0      0    128    0    0    1 :  252  126
filp                 268    280     96    7    7    1 :  252  126
names_cache            2      2   4096    2    2    1 :   60   30
buffer_head        66640  66640     96 1666 1666    1 :  252  126
mm_struct            120    120    160    5    5    1 :  252  126
vm_area_struct       755    826     64   14   14    1 :  252  126
fs_cache             177    177     64    3    3    1 :  252  126
files_cache           63     63    416    7    7    1 :  124   62
signal_act            45     45   1312   15   15    1 :   60   30



Will boot the system up with just an IDE drive to see if the symptoms
persist.


Cheers,

-- Juha


From owner-linux-xfs@oss.sgi.com Wed May 23 14:39:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NLdsv24640
	for linux-xfs-outgoing; Wed, 23 May 2001 14:39:54 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NLdrF24636
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 14:39:53 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA670762
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 23:39:50 +0200 (CEST)
	mail_from (cattelan@thebarn.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA63812; Wed, 23 May 2001 16:38:32 -0500 (CDT)
Received: from thebarn.com (localhost [127.0.0.1])
	by gibble.americas.sgi.com (8.11.3/8.11.2) with ESMTP id f4NLbVw01959;
	Wed, 23 May 2001 17:37:31 -0400
Message-ID: <3B0C2D99.A12BCD3B@thebarn.com>
Date: Wed, 23 May 2001 17:37:29 -0400
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
CC: linux-xfs@oss.sgi.com, sgi-admin@ncsa.uiuc.edu
Subject: Re: the file I forgot...
References: <Pine.LNX.4.33.0105231541440.25173-200000@osage.ncsa.uiuc.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Galen Arnold wrote:

> Here's the file.
>
> And perhaps I spoke too soon.  My 2.4.4-xfs box just locked up solid on
> its 4th attempt at iozone (I wanted to keep pounding it a bit longer to
> see what happens).  It doesn't panic, it just stops responding (cannot
> even answer a ping, console freezes).  I'm going to let it stay in that
> state and see if it recovers in a while.
> There are no additional 0-order allocation failed messages for the current
> run of iozone on xfs--the box just went on holiday...

don't suppose you compiled kdb into the kernel?

if so do you have access to the console?


>
>
> -Galen
>
> --
> +
> Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> National Center for Supercomputing Applications           (217) 244-3473
> 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
>
>   ------------------------------------------------------------------------
>          Name: io
>    io    Type: Plain Text (TEXT/PLAIN)
>      Encoding: BASE64

--
Russell Cattelan
--
Digital Elves inc. -- Currently on loan to SGI
Linux XFS core developer.




From owner-linux-xfs@oss.sgi.com Wed May 23 15:39:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4NMdt726245
	for linux-xfs-outgoing; Wed, 23 May 2001 15:39:55 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4NMdrF26242
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 15:39:53 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4NMbEP26684;
	Wed, 23 May 2001 17:37:14 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 23 May 2001 17:37:13 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Josh Durham <jmd@aoe.vt.edu>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: GrowFSing
In-Reply-To: <Pine.LNX.4.21.0105231504000.17257-100000@hermes.aoe.vt.edu>
Message-ID: <Pine.LNX.4.33.0105231736540.26113-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Do you have enough storage to do a test first on a smaller volume set?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Wed May 23 18:00:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O10Q029573
	for linux-xfs-outgoing; Wed, 23 May 2001 18:00:26 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O10PF29569
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 18:00:25 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4O10Ll31119
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 09:00:22 +0800
Received: from mail ([203.167.1.219]) by sisa.i-manila.com.ph ; Thu, 24 May 2001 09:00:23 +0800 GMT
Received: from kalapati (kalapati.linux-server.tlc [192.168.0.201])
	by mail (Postfix) with ESMTP id 7776E768D
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:55:10 +0800 (PHT)
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id EB44C463E36
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:55:11 +0800 (PHT)
Date: Thu, 24 May 2001 08:55:11 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: "Inheritance"
Message-ID: <Pine.LNX.4.21.0105240850110.637-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

I don't know if inheritance is the correct term to use for what I need and
would like to ask about.

This is my situation: I'd like to different group defaults and permission
defaults for files and directories in various directory trees. For
example, I could have files and directories /var/public/ default to be
owned by the user and his/her default group (normally the user, too), with
permissions u=rwX,g=rwX,o=rwX. Then I could have all files in /home/$USER/
to have the same ownership but only the permissions u=rwX,g=,o=.
Furthermore I'd like /var/public/ to be writeable by everyone, but they
shouldn't be able to delete the entire directory (although they can delete
the files within).

My problem now is that I can do either of these using umasks, but how can
I do both? I was wondering if EAs and ACLs were the solution for me. I
will be (already am) using XFS, of course.

Thanks in advance! :)

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Wed May 23 18:41:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O1fme30263
	for linux-xfs-outgoing; Wed, 23 May 2001 18:41:48 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O1fmF30258
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 18:41:48 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id SAA08808
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 18:41:46 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21526; Thu, 24 May 2001 11:40:26 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: linux-xfs@oss.sgi.com, sgi-admin@ncsa.uiuc.edu
Subject: Re: the file I forgot... 
In-reply-to: Your message of "Wed, 23 May 2001 15:46:11 EST."
             <Pine.LNX.4.33.0105231541440.25173-200000@osage.ncsa.uiuc.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 May 2001 11:40:25 +1000
Message-ID: <27017.990668425@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 23 May 2001 15:46:11 -0500 (CDT), 
Galen Arnold <arnoldg@ncsa.uiuc.edu> wrote:
>And perhaps I spoke too soon.  My 2.4.4-xfs box just locked up solid on
>its 4th attempt at iozone (I wanted to keep pounding it a bit longer to
>see what happens).  It doesn't panic, it just stops responding (cannot
>even answer a ping, console freezes).

Can you compile your kernel with kdb and serial console, run a null
modem to a second machine to capture the console output and boot with
kdb=on and nmi_watchdog=2 (SMP) or nmi_watchdog=1 (UP).  Instead of
freezing, the NMI watchdog should trip after 5 seconds and drop into
kdb.  Start with a backtrace (bt) of the current process, if it is
waiting for a lock then list the processes (ps) and do a backtrace of
processes that are running (btp <pid> for processes with '1' in the
'[*]' column).


From owner-linux-xfs@oss.sgi.com Wed May 23 18:51:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O1pEj31468
	for linux-xfs-outgoing; Wed, 23 May 2001 18:51:14 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O1pCF31465
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 18:51:12 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id DAA692074
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 03:51:09 +0200 (CEST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21609; Thu, 24 May 2001 11:49:50 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
cc: linux-xfs@oss.sgi.com
Subject: Re: 2.4.2 build problems 
In-reply-to: Your message of "23 May 2001 11:53:33 -0400."
             <wx0vgmsvz7m.fsf@sws5.ctd.ornl.gov> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 24 May 2001 11:49:50 +1000
Message-ID: <27089.990668990@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 23 May 2001 11:53:33 -0400, 
"Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov> wrote:
>drivers/scsi/aic7xxx_new/aic7xxx_drv.o: In function `ahc_run_qoutfifo':
>drivers/scsi/aic7xxx_new/aic7xxx_drv.o(.text+0x4fd8): multiple definition of `ahc_run_qoutfifo'
>drivers/scsi/scsidrv.o(.text+0xefc8): first defined here

At a guess, you have CONFIG_SCSI_AIC7XXX and CONFIG_SCSI_AIC7XXX_OLD
set, with both drivers built into the kernel.  You can only select both
drivers if both are modules.

Don't talk to me about aic7xxx, it is a shambles :(.


From owner-linux-xfs@oss.sgi.com Wed May 23 19:43:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O2hZJ02030
	for linux-xfs-outgoing; Wed, 23 May 2001 19:43:35 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O2hYF02027
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 19:43:34 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA08101
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 19:43:28 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA52728
	for linux-xfs@oss.sgi.com; Thu, 24 May 2001 12:41:58 +1000 (EST)
Date: Thu, 24 May 2001 12:41:58 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105240241.MAA52728@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - acl
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Forgot these in my previous TAKE (thanks Nathan for the reminder).

--Tim

Date:  Wed May 23 19:41:03 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95884a
cmd/acl/VERSION - 1.4
	- Update revision for libacl change to acl_get_file/acl_get_fd and
	  acl_set_compat.

cmd/acl/doc/CHANGES - 1.4
	- Describe libacl change to acl_get_file/acl_get_fd and
	  addition of acl_set_compat.



From owner-linux-xfs@oss.sgi.com Wed May 23 20:00:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O308C02276
	for linux-xfs-outgoing; Wed, 23 May 2001 20:00:08 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O306F02273
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:00:07 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152lM5-00078f-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:00:05 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: <linux-xfs@oss.sgi.com>
Subject: So far, so good.
Date: Thu, 24 May 2001 14:59:34 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIMECACAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Checked out the CVS earlier today, and built the kernel plus packages. Seems
to use less memory than 2.4.2, and it looks like the weird disk performance
slow-down has gone, but I can't say for sure yet...

Found this little buglet:

# rpm -Uvh xfsdump-1.0.9-0.i386.rpm
Preparing...                ###########################################
[100%]
   1:xfsdump                ###########################################
[100%]
error: cannot remove /usr/man/man8 - directory not empty

Shouldn't the man pages go into /usr/share/man instead?

-- Juha


From owner-linux-xfs@oss.sgi.com Wed May 23 20:33:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O3XtL02885
	for linux-xfs-outgoing; Wed, 23 May 2001 20:33:55 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O3XsF02882
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:33:55 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id UAA07271
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:33:53 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22500; Thu, 24 May 2001 13:32:36 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA18412;
	Thu, 24 May 2001 13:32:34 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105241332.ZM85697@wobbly.melbourne.sgi.com>
Date: Thu, 24 May 2001 13:32:33 -0500
In-Reply-To: "Juha Saarinen" <juha@saarinen.org>
        "So far, so good." (May 24,  2:59pm)
References: <LGECJLHBGAPMGAJFMAFIMECACAAA.juha@saarinen.org>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Juha Saarinen" <juha@saarinen.org>, <linux-xfs@oss.sgi.com>
Subject: Re: So far, so good.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

On May 24,  2:59pm, Juha Saarinen wrote:
> Subject: So far, so good.
> Checked out the CVS earlier today, and built the kernel plus packages. Seems
> to use less memory than 2.4.2, and it looks like the weird disk performance
> slow-down has gone, but I can't say for sure yet...
> 

Good to hear.

> Found this little buglet:
> 
> # rpm -Uvh xfsdump-1.0.9-0.i386.rpm
> Preparing...                ###########################################
> [100%]
>    1:xfsdump                ###########################################
> [100%]
> error: cannot remove /usr/man/man8 - directory not empty
> 
> Shouldn't the man pages go into /usr/share/man instead?
> 

The configure script makes a guess based on the man pages you
have installed already - see configure.in (pkg_man_dir), and
will fall back to using /usr/share/man.

Actually, what I would guess has happened is:
- you installed the xfsdump rpm from the xfs1.0 release
(this uses /usr/man/man8/...);
- you did a "make install" at some intermediate point;
- you installed the current xfsdump rpm, which you just
built yourself, probably via Makepkgs (this likely uses
/usr/share/man/man8/...)

am I right?  what are the contents of /usr/man/man8?  is
it the man pages _without_ the .gz extension?  (this would
have come from a "make install", which doesn't compress).

[rpm -q -l xfsdump will confirm whether the man pages you
now have installed are in /usr/share/man or not]

The error message comes from the rpm upgrade not being
able to remove (what rpm thinks should be) an "empty" subdir
- ie. the old /usr/man/man8, since we now install into
/usr/share/man by default.  This sequence has happened to
me a few times - its safe to delete the old /usr/man/man8
contents (from manual "make install"), as long as the new
rpm is using /usr/share/man.

cheers.

-- 
Nathan

From owner-linux-xfs@oss.sgi.com Wed May 23 20:40:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O3e4W02995
	for linux-xfs-outgoing; Wed, 23 May 2001 20:40:04 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O3e3F02992
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:40:03 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4O3bKK29431;
	Wed, 23 May 2001 22:37:20 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 23 May 2001 22:37:20 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Juha Saarinen <juha@saarinen.org>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: So far, so good.
In-Reply-To: <LGECJLHBGAPMGAJFMAFIMECACAAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.33.0105232237100.29374-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

By lsb standards I believe so.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 24 May 2001, Juha Saarinen wrote:

> Checked out the CVS earlier today, and built the kernel plus packages. Seems
> to use less memory than 2.4.2, and it looks like the weird disk performance
> slow-down has gone, but I can't say for sure yet...
>
> Found this little buglet:
>
> # rpm -Uvh xfsdump-1.0.9-0.i386.rpm
> Preparing...                ###########################################
> [100%]
>    1:xfsdump                ###########################################
> [100%]
> error: cannot remove /usr/man/man8 - directory not empty
>
> Shouldn't the man pages go into /usr/share/man instead?
>
> -- Juha
>


From owner-linux-xfs@oss.sgi.com Wed May 23 20:42:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O3gK303039
	for linux-xfs-outgoing; Wed, 23 May 2001 20:42:20 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O3gJF03036
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:42:19 -0700
Received: from snort.melbourne.sgi.com ([134.14.55.149]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id UAA00167
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:42:18 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA54536
	for linux-xfs@oss.sgi.com; Thu, 24 May 2001 13:41:01 +1000 (EST)
Date: Thu, 24 May 2001 13:41:01 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105240341.NAA54536@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This fixes a panic found by qa on "fuzzy" which uses xfs as a
module... we weren't properly cleaning up xqm.  If you see the
following backtrace (can only happen if you're using xfs+quota
as a module), the problem is now fixed in the dev tree.


kernel BUG at slab.c:804!

Entering kdb (current=0xc48cc000, pid 21592) on processor 0 Oops: invalid 
operand
due to oops @ 0xc0129101
eax = 0x0000001a ebx = 0xc3fc0378 ecx = 0x00000001 edx = 0x00000001 
esi = 0xc3fc036f edi = 0xc8915e14 esp = 0xc48cd9d0 eip = 0xc0129101 
ebp = 0xc48cda10 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc48cd99c
[0]kdb> b
    EBP       EIP         Function(args)
0xc48cda10 0xc0129101 kmem_cache_create+0x37d (0xc8915e09, 0x164, 0x20, 0x0, 
0x0)
                               kernel .text 0xc0100000 0xc0128d84 0xc0129150
0xc48cda30 0xc887f75c [xfs_support]kmem_zone_init+0x18 (0x164, 0xc8915e09)
                               xfs_support .text 0xc887f060 0xc887f744 
0xc887f760
0xc48cda50 0xc8895cd4 [xfs]xfs_qm_init+0x124
                               xfs .text 0xc888f060 0xc8895bb0 0xc8895d40
0xc48cda58 0xc8895e4a [xfs]xfs_qm_hold_quotafs_ref+0x1e (0xc4293000)
                               xfs .text 0xc888f060 0xc8895e2c 0xc8895e78
0xc48cda7c 0xc8897323 [xfs]xfs_qm_init_quotainfo+0x3b (0xc4293000)
                               xfs .text 0xc888f060 0xc88972e8 0xc8897504
0xc48cda94 0xc889627b [xfs]xfs_qm_mount_quotas+0x1af (0xc4293000)
                               xfs .text 0xc888f060 0xc88960cc 0xc889643c
0xc48cdb70 0xc88f21e1 [xfs]xfs_mountfs+0xe3d (0xc3a6fc60, 0xc4293000, 0x806, 
0x0)
                               xfs .text 0xc888f060 0xc88f13a4 0xc88f2288


Date:  Wed May 23 20:34:41 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95888a
linux/fs/xfs/xfsquotasstubs.c - 1.14
linux/fs/xfs/xfs_vfsops.c - 1.317
linux/fs/xfs/xfs_qm.c - 1.69
	- rework the way we initialize and tear down the quota-related
	  kmem zones.  this fixes a problem with (multiple) use of xfs
	  as a module, found by auto-qa.



From owner-linux-xfs@oss.sgi.com Wed May 23 20:46:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O3kSb03264
	for linux-xfs-outgoing; Wed, 23 May 2001 20:46:28 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O3kQF03258
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 20:46:26 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152m4s-0007BB-00; Thu, 24 May 2001 15:46:22 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>, <linux-xfs@oss.sgi.com>
Subject: RE: So far, so good.
Date: Thu, 24 May 2001 15:45:51 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIKECCCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <10105241332.ZM85697@wobbly.melbourne.sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Good to hear.

Bah... spoke to soon:

# hdparm -tT /dev/sda

/dev/sda:
 Timing buffer-cache reads:   128 MB in  2.37 seconds = 54.01 MB/sec
 Timing buffered disk reads:  64 MB in  6.87 seconds =  9.32 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  2.30 seconds = 55.65 MB/sec
 Timing buffered disk reads:  64 MB in 10.16 seconds =  6.30 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  2.28 seconds = 56.14 MB/sec
 Timing buffered disk reads:  64 MB in  6.88 seconds =  9.30 MB/sec

I don't understand this. I don't see it on any other 2.4.x-based box.

Will try it on an IDE drive shortly.

:: The configure script makes a guess based on the man pages you
:: have installed already - see configure.in (pkg_man_dir), and
:: will fall back to using /usr/share/man.
::
:: Actually, what I would guess has happened is:
:: - you installed the xfsdump rpm from the xfs1.0 release
:: (this uses /usr/man/man8/...);
:: - you did a "make install" at some intermediate point;
:: - you installed the current xfsdump rpm, which you just
:: built yourself, probably via Makepkgs (this likely uses
:: /usr/share/man/man8/...)
::
:: am I right?  what are the contents of /usr/man/man8?  is
:: it the man pages _without_ the .gz extension?  (this would
:: have come from a "make install", which doesn't compress).


The original install was from the XFS-2.4.2 CD installer -- didn't check
where it put the man pages. Never done a manual 'make install' though.

# ls -la /usr/man/man8
total 40
drwxr-xr-x    2 root     root         4096 May 24 14:54 .
drwxr-xr-x    7 root     root           61 May 21 05:51 ..
-r--r--r--    1 root     root          566 Apr 19 06:18 convertquota.8.gz
-r--r--r--    1 root     root         1172 Apr 19 06:18 edquota.8.gz
-r--r--r--    1 root     root          582 Apr 19 06:18 quot.8.gz
-r--r--r--    1 root     root         1281 Apr 19 06:18 quotacheck.8.gz
-r--r--r--    1 root     root         1443 Apr 19 06:18 quotaon.8.gz
-r--r--r--    1 root     root          671 Apr 19 06:18 repquota.8.gz
-r--r--r--    1 root     root          505 Apr 19 06:18 rquotad.8.gz
-r--r--r--    1 root     root          827 Apr 19 06:18 setquota.8.gz
-r--r--r--    1 root     root          471 Apr 19 06:18 warnquota.8.gz

# rpm -q --whatprovides /usr/man/man8/convertquota.8.gz
quota-3.01-SGI_5

That's the April 19 version. Is there a newer version available? Doesn't
seem to be in the CVS.

:: [rpm -q -l xfsdump will confirm whether the man pages you
:: now have installed are in /usr/share/man or not]

Yep, they're in the right directory.

Cheers,

-- Juha


From owner-linux-xfs@oss.sgi.com Wed May 23 21:01:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O419U03539
	for linux-xfs-outgoing; Wed, 23 May 2001 21:01:09 -0700
Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O417F03536
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:01:07 -0700
Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13])
	by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f4O412c03996
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:01:02 +1000 (EST)
Received: from spike (spike.csee.uq.edu.au [130.102.66.71])
	by nut.csee.uq.edu.au (8.11.3/8.11.3) with SMTP id f4O412o09492
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:01:02 +1000 (EST)
Message-ID: <002101c0e406$25ef4b70$47426682@csee.uq.edu.au>
From: "Chris Pascoe" <c.pascoe@csee.uq.edu.au>
To: <linux-xfs@oss.sgi.com>
Subject: Crashes in various ext2 functions while running xfstest/check
Date: Thu, 24 May 2001 14:01:02 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I'm running the XFS stress tests on a Dell Poweredge 4400 running.  The
kernel is the current CVS one (as at today) but the problem persists over
several weeks of compilations.  Local modifications to the kernel are the
addition of the module for the AACRAID Perc 3/Di RAID controller and the
e1000 driver from Intel for the ethernet card.  Highmem support is enabled
(the machine has 1GB of RAM).  The kernels are compiled with the kgcc
package from Redhat 7.0 (egcs
2.91.66) or the RH7.1 gcc (2.96-81) - it makes no difference.

hinv, dmesg, and backtraces from kdb at crash time are available at
http://www.csee.uq.edu.au/~chrisp/xfs/.  I don't know what other information
to gather.  Any pointers?

So far I have seen deaths (caused by NULL pointer exceptions) in (at least)
ext2_get_block, ext2_update_inode, ext2_alloc_branch, etc, while running
'check' from the xfstests directory.  I haven't been able to trigger any
crashes during any other activity on the system, using 2.2.19 and the
standard RH7.1 kernel (I can't run xfs test on those though, obviously).

I may be able to provide remote access + console access to the server if
it's of any use (it is a development/test box) if it is of any use.

Chris


From owner-linux-xfs@oss.sgi.com Wed May 23 21:01:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O41L303551
	for linux-xfs-outgoing; Wed, 23 May 2001 21:01:21 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O41JF03547
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:01:19 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id VAA10706
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:01:18 -0700 (PDT)
	mail_from (nathans@wobbly.melbourne.sgi.com)
Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22642; Thu, 24 May 2001 13:59:12 +1000
Received: (from nathans@localhost)
	by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA94870;
	Thu, 24 May 2001 13:59:11 +1000 (EST)
From: "Nathan Scott" <nathans@wobbly.melbourne.sgi.com>
Message-Id: <10105241359.ZM93573@wobbly.melbourne.sgi.com>
Date: Thu, 24 May 2001 13:59:10 -0500
In-Reply-To: "Juha Saarinen" <juha@saarinen.org>
        "RE: So far, so good." (May 24,  3:45pm)
References: <LGECJLHBGAPMGAJFMAFIKECCCAAA.juha@saarinen.org>
X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail)
To: "Juha Saarinen" <juha@saarinen.org>, <linux-xfs@oss.sgi.com>
Subject: Re: So far, so good.
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="PART-BOUNDARY=.110105241359.ZM93573.melbourne.sgi.com"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

--
--PART-BOUNDARY=.110105241359.ZM93573.melbourne.sgi.com
Content-Type: text/plain; charset=us-ascii

hi,

On May 24,  3:45pm, Juha Saarinen wrote:
> Subject: RE: So far, so good.
> 
> The original install was from the XFS-2.4.2 CD installer -- didn't check
> where it put the man pages. Never done a manual 'make install' though.
> 
> # ls -la /usr/man/man8
> total 40
> drwxr-xr-x    2 root     root         4096 May 24 14:54 .
> drwxr-xr-x    7 root     root           61 May 21 05:51 ..
> -r--r--r--    1 root     root          566 Apr 19 06:18 convertquota.8.gz
> -r--r--r--    1 root     root         1172 Apr 19 06:18 edquota.8.gz
> -r--r--r--    1 root     root          582 Apr 19 06:18 quot.8.gz
> -r--r--r--    1 root     root         1281 Apr 19 06:18 quotacheck.8.gz
> -r--r--r--    1 root     root         1443 Apr 19 06:18 quotaon.8.gz
> -r--r--r--    1 root     root          671 Apr 19 06:18 repquota.8.gz
> -r--r--r--    1 root     root          505 Apr 19 06:18 rquotad.8.gz
> -r--r--r--    1 root     root          827 Apr 19 06:18 setquota.8.gz
> -r--r--r--    1 root     root          471 Apr 19 06:18 warnquota.8.gz
> 
> # rpm -q --whatprovides /usr/man/man8/convertquota.8.gz
> quota-3.01-SGI_5
> 

thats strange - the spec file for this uses %{_mandir}.
oh, wait - its most probably because we build rpms on an
older redhat distribution (to ensure the rpms work for as
many people as possible).

> That's the April 19 version. Is there a newer version available? Doesn't
> seem to be in the CVS.
> 

there is a newer version, but I don't think this is pushed
out in the cvs tree anymore.  the code from sourceforge is
now at 3.01-pre6.  I've attached my current quota specfile
- you should be able to grab the -pre6 tarball, the run
`rpm -ba quota.spec' & to make yourself a new quota rpm...
it should always get the man path right, building locally.

cheers.

-- 
Nathan

--PART-BOUNDARY=.110105241359.ZM93573.melbourne.sgi.com
X-Zm-Content-Name: quota.spec
Content-Description: Text
Content-Type: text/plain ; name="quota.spec" ; charset=us-ascii

Name: quota
Summary: System administration tools for monitoring users' disk usage.
Version: 3.01
Release: 5SGI_7
Vendor: SGI
Source: http://sourceforge.net/projects/linuxquota/.../quota-3.01-pre6.tar.gz
Copyright: BSD
Group: System Environment/Base
BuildRoot: %{_tmppath}/%{name}-root

%description
The quota package contains system administration tools for monitoring
and limiting users' and or groups' disk usage, per filesystem.

Install quota if you want to monitor and/or limit user/group disk
usage.

%prep
%setup -q -n %{name}-tools

%build
autoconf
CFLAGS="$RPM_OPT_FLAGS"
./configure --prefix=%{buildroot}/usr --mandir=%{buildroot}%{_mandir}
make all

%install
rm -fr %{buildroot}

install -m 755 -d %{buildroot}/sbin %{buildroot}/usr/sbin %{buildroot}/usr/bin
install -m 755 -d %{buildroot}%{_mandir}/man1 %{buildroot}%{_mandir}/man2
install -m 755 -d %{buildroot}%{_mandir}/man3 %{buildroot}%{_mandir}/man8

install -m 555 quotacheck quotaon %{buildroot}/sbin
ln -sf quotaon %{buildroot}/sbin/quotaoff
install -m 555 edquota repquota warnquota setquota quot %{buildroot}/usr/sbin
install -m 555 quotastats xqmstats %{buildroot}/usr/sbin
install -m 555 quota %{buildroot}/usr/bin
# If not a distro using nfs-utils, uncomment this line
#install -m 555 rpc.rquotad /usr/sbin
install -m 444 *.1 %{buildroot}%{_mandir}/man1
install -m 444 *.2 %{buildroot}%{_mandir}/man2
install -m 444 *.3 %{buildroot}%{_mandir}/man3
# If not a distro using nfs-utils, comment out this line
rm rquotad.8
install -m 444 *.8 %{buildroot}%{_mandir}/man8

%clean
rm -rf %{buildroot}

%files
%defattr(-,root,root)
# You may want a warnquota.conf file, but works without one
#%config(noreplace) /etc/warnquota.conf
/sbin/quotacheck
/sbin/quotaon
/sbin/quotaoff
/usr/bin/quota
/usr/sbin/edquota
/usr/sbin/repquota
/usr/sbin/warnquota
/usr/sbin/quotastats
/usr/sbin/xqmstats
/usr/sbin/setquota
/usr/sbin/quot
# If not a distro using nfs-utils, uncomment this line
#/usr/sbin/rpc.rquotad
%{_mandir}/*/*

%changelog
* Thu May 17 2001 Nathan Scott <nathans@sgi.com>
- update to quota-3.01-pre6 code
- repquota patch incorporated now, so removed from spec file

* Mon May 07 2001 Nathan Scott <nathans@sgi.com>
- add patch to fix repquota infinite loop bug

* Thu May 03 2001 Nathan Scott <nathans@sgi.com>
- update to quota-3.01-pre5 code

* Thu Apr 12 2001 Nathan Scott <nathans@sgi.com>
- update to quota-3.01-pre4 code

* Fri Mar 30 2001 Nathan Scott <nathans@sgi.com>
- quota spec file for SGI overlay releases
- no rpc server as some distributions ship this in nfs-utils
- spec file based on the 3.00-3 version from Redhat rawhide

--PART-BOUNDARY=.110105241359.ZM93573.melbourne.sgi.com--


From owner-linux-xfs@oss.sgi.com Wed May 23 21:10:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O4Alk03723
	for linux-xfs-outgoing; Wed, 23 May 2001 21:10:47 -0700
Received: from dialup-63.208.119.30.Dial1.Weehawken1.Level3.net (dialup-63.208.119.30.Dial1.Weehawken1.Level3.net [63.208.119.30])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O4A7F03715
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:10:17 -0700
Received: from photino.sid.rice.edu (rjain@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f4O3UDtH025535;
	Wed, 23 May 2001 23:30:13 -0400
Received: (from rjain@localhost)
        by photino.sid.rice.edu (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) id f4O3U3Yd025533;
	Wed, 23 May 2001 23:30:03 -0400
Date: Wed, 23 May 2001 23:30:03 -0400
From: Rahul Jain <rahul@rice.edu>
To: Juha Saarinen <juha@saarinen.org>
Cc: linux-xfs@oss.sgi.com
Subject: Re: So far, so good.
Message-ID: <20010523233002.A25518@rice.edu>
Reply-To: Rahul Jain <rahul@rice.edu>
Mail-Followup-To: Juha Saarinen <juha@saarinen.org>, linux-xfs@oss.sgi.com
References: <LGECJLHBGAPMGAJFMAFIMECACAAA.juha@saarinen.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <LGECJLHBGAPMGAJFMAFIMECACAAA.juha@saarinen.org>; from juha@saarinen.org on Thu, May 24, 2001 at 02:59:34PM +1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, May 24, 2001 at 02:59:34PM +1200, Juha Saarinen wrote:
> # rpm -Uvh xfsdump-1.0.9-0.i386.rpm
> Preparing...                ###########################################
> [100%]
>    1:xfsdump                ###########################################
> [100%]
> error: cannot remove /usr/man/man8 - directory not empty
> 
> Shouldn't the man pages go into /usr/share/man instead?

That was changed recently. That warning was just rpm whining that there were
files in the dir when it tried to remove it (since the package no longer used
it).

-- 
-> -/-                       - Rahul Jain -                       -\- <-
-> -\- http://linux.rice.edu/~rahul -=- mailto:rahul-jain@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
   Version 11.423.999.220020101.23.50110101.042
   (c)1996-2000, All rights reserved. Disclaimer available upon request.

From owner-linux-xfs@oss.sgi.com Wed May 23 21:48:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O4mwe04987
	for linux-xfs-outgoing; Wed, 23 May 2001 21:48:58 -0700
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O4mvF04984
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 21:48:57 -0700
Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217])
	by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f4O4muM06660
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 00:48:56 -0400 (EDT)
Date: Thu, 24 May 2001 00:48:50 -0400 (EDT)
From: J Landman <landman@mediaone.net>
X-X-Sender:  <landman@dsl-squash.corp.sgi.com>
To: <linux-xfs@oss.sgi.com>
Subject: sanity check
Message-ID: <Pine.LNX.4.32.0105240033100.1730-100000@dsl-squash.corp.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Folks:

  Looked in the FAQ for this one, and I am pulling Russell's Mandrake 8.0
images just in case....

  So I want to take the patch, and apply it against the 2.4.3 kernel in
Mandrake 8.0.  I read through the instructions, and no where in there is a
mention of devfsd.  Now I know RH 7.1 with the installer uses devfsd, and
this has been a non-stop source of grief (xfs works great, VMware is
unhappy and needs reconfiging every time, and several other things are now
broken).

  What I want to do is, if devfsd is really required, then I do not want
to use it for the /dev directory.  The last few weeks of using it for
/dev on my laptop confirms that devfsd breaks things, specifically
VMWare, though it munges up the CD burner stuff, and quite a bit else as
well (that worked perfectly pre-devfsd).

  If I read the patch instructions correctly (assuming that they are not
ommitting anything) I do not need to set up devfsd.  Is this correct?  Is
devfsd a requirement to use xfs?  If it is required, then I presume there
is a way to limit what it can/cannot handle (via the /etc/devfsd.conf
file) so that it doesn't munge up non-xfs stuff.

  Thoughts/clues/advice welcome here.  I want to use xfs, I just do not
want to use devfsd anymore (unless there is some method available to make
it look, act, and generally feel *exactly* like the non-devfsd, so that my
apps don't break).

  Thanks!

-- 
 Joe Landman,
 landman@mediaone.net



From owner-linux-xfs@oss.sgi.com Wed May 23 22:08:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O58te05322
	for linux-xfs-outgoing; Wed, 23 May 2001 22:08:55 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O58sF05319
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:08:54 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4O58rY17809;
	Thu, 24 May 2001 00:08:53 -0500 (CDT)
Message-ID: <3B0C980B.7B89D131@sgi.com>
Date: Thu, 24 May 2001 00:11:39 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: J Landman <landman@mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: sanity check
References: <Pine.LNX.4.32.0105240033100.1730-100000@dsl-squash.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

J Landman wrote:

>   So I want to take the patch, and apply it against the 2.4.3 kernel in
> Mandrake 8.0.  I read through the instructions, and no where in there is a
> mention of devfsd.  Now I know RH 7.1 with the installer uses devfsd, and
> this has been a non-stop source of grief (xfs works great, VMware is
> unhappy and needs reconfiging every time, and several other things are now
> broken).

I'm assuming that you're using mdklinux-2.4.3-core-xfs-05072001.patch?

A few things.  Devfs is part of the standard 2.4 kernel, and turned on
and off via the kernel config.  The standard Mandrake 8.0 kernels DO
have devfs enabled.  There is also a userspace daemon, devfsd, which
helps manage /dev entries.  So, a standard Mandrake install does include
devfs configured & devfsd running, and our patch against their kernel
source tree won't change any of that.

However, devfs is NOT required for xfs in any way.  If you are running a
devfs-enabled kernel, you can always disable it by passing
"devfs=nomount" on the lilo command line, or add it to lilo.conf as an
"append" entry.  You'll have your old, standard, inode-hungry /dev just
the way you like it.  :)

Of course, if you recompile your kernel, you can just turn devfs off in
theconfig.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 23 22:32:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O5WVH05712
	for linux-xfs-outgoing; Wed, 23 May 2001 22:32:31 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O5WTF05709
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:32:29 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4O5WPl05012
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:32:25 +0800
Received: from mail ([203.167.2.164]) by sisa.i-manila.com.ph ; Thu, 24 May 2001 13:32:29 +0800 GMT
Received: from kalapati (kalapati.linux-server.tlc [192.168.0.201])
	by mail (Postfix) with ESMTP id AB69736D2
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:31:39 +0800 (PHT)
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 0A3B2463E36
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:31:39 +0800 (PHT)
Date: Thu, 24 May 2001 13:31:38 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: XFS performance drop after uptime (was: So far, so good)
In-Reply-To: <LGECJLHBGAPMGAJFMAFIKECCCAAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.21.0105241319300.637-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

Following Juha Saarinen's initiative, I decided to myself to some tests
with hdparm at various points in a boxe's "lifecycle". I did these tests
on a Pentium III 733MHz with 512MB RAM and 4 x 30.6GB UDMA/66 7200RPM IBM
hard drives on a RAID 5 array with a 3ware Escalade 6400 controller. I'm
running the latest (well, as of yesterday GMT+0800) CVS of XFS.

Command used for testing: 'hdparm -tT /dev/sda'

I. This was done after the box had been up for quite awhile (overnight)
doing all sorts of normal stuff (installation, basically, as I'm setting
this up as a server). I had about 250MB of my RAM used up, with 66MB in
buffers and 89MB in cache.

---[ results ]---
/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.48 seconds = 36.78 MB/sec
 Timing buffered disk reads:  64 MB in  3.80 seconds = 16.84 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.45 seconds = 37.10 MB/sec
 Timing buffered disk reads:  64 MB in  3.41 seconds = 18.77 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.

/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.15 seconds = 40.63 MB/sec
 Timing buffered disk reads:  64 MB in  3.21 seconds = 19.94 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.15 seconds = 40.63 MB/sec
 Timing buffered disk reads:  64 MB in  3.29 seconds = 19.45 MB/sec
---[ end of results ]---

Please take note of the comment that hdparm gave me on the second run.

II. I rebooted the machine, with all my services (squid, courier, et
al) disabled:

---[ results ]---
/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.97 seconds =131.96 MB/sec
 Timing buffered disk reads:  64 MB in  1.84 seconds = 34.78 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.96 seconds =133.33 MB/sec
 Timing buffered disk reads:  64 MB in  1.77 seconds = 36.16 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.97 seconds =131.96 MB/sec
 Timing buffered disk reads:  64 MB in  1.77 seconds = 36.16 MB/sec
---[ end of results ]---

Please take note of the humongous difference!

III. Righter after doing tests in (II), I loaded up a bunch of services
(apache, apache-ssl, courier, postgresql, slapd, samba) and then did the
tests again:

---[ results ]---
/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.88 seconds =145.45 MB/sec
 Timing buffered disk reads:  64 MB in  1.74 seconds = 36.78 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.85 seconds =150.59 MB/sec
 Timing buffered disk reads:  64 MB in  1.75 seconds = 36.57 MB/sec

/dev/sda:
 Timing buffer-cache reads:   128 MB in  0.85 seconds =150.59 MB/sec
 Timing buffered disk reads:  64 MB in  1.80 seconds = 35.56 MB/sec
---[ end of results ]---


Except for the results of the first pass, the buffered disk reads are
pretty consistent, with the buffer-cache reads going up (I presume because
the cache got populated with hdparm's test data).

Unfortunately I wasn't able to grab top, /proc/slabinfo, and /proc/meminfo
after I did the first (very slow) pass of tests. Next time I get into a
similar situation, I will make it a point to get this information and
share it with the list.

Results of 'free -m' after the tests in (III):

             total       used       free     shared    buffers     cached
Mem:           500        139        360          0         74         18
-/+ buffers/cache:         47        453
Swap:          972          0        972

BTW, for whatever it may be worth, I have quotas and ACLs disabled.

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Wed May 23 22:43:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O5hns05862
	for linux-xfs-outgoing; Wed, 23 May 2001 22:43:49 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O5hmF05859
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:43:48 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA19222
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:43:48 -0700 (PDT)
	mail_from (nathans@snort.melbourne.sgi.com)
Received: (from nathans@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA77402
	for linux-xfs@oss.sgi.com; Thu, 24 May 2001 15:42:30 +1000 (EST)
Date: Thu, 24 May 2001 15:42:30 +1000 (EST)
From: Nathan Scott <nathans@snort.melbourne.sgi.com>
Message-Id: <200105240542.PAA77402@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - qa/quota
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All tests should now pass with any combination of the quota
$MOUNT_OPTIONS, for all our local qa hosts (ie. with/without
a tape device, with/without smp, with/without modules, and
various libc/fileutils/compiler version combinations).

cheers.


Date:  Wed May 23 22:36:12 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/nathans/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95893a
cmd/xfstests/022.grpquota - 1.1
cmd/xfstests/022.noquota - 1.1
cmd/xfstests/036.ugquota - 1.1
cmd/xfstests/022.ugquota - 1.1
cmd/xfstests/022.usrquota - 1.1
cmd/xfstests/023.grpquota - 1.1
cmd/xfstests/023.noquota - 1.1
cmd/xfstests/036.usrquota - 1.1
cmd/xfstests/023.ugquota - 1.1
cmd/xfstests/023.usrquota - 1.1
cmd/xfstests/024.grpquota - 1.1
cmd/xfstests/024.noquota - 1.1
cmd/xfstests/055.usrquota - 1.1
cmd/xfstests/024.ugquota - 1.1
cmd/xfstests/024.usrquota - 1.1
cmd/xfstests/025.grpquota - 1.1
cmd/xfstests/025.noquota - 1.1
cmd/xfstests/055.ugquota - 1.1
cmd/xfstests/025.ugquota - 1.1
cmd/xfstests/025.usrquota - 1.1
cmd/xfstests/035.grpquota - 1.1
cmd/xfstests/035.noquota - 1.1
cmd/xfstests/055.noquota - 1.1
cmd/xfstests/035.ugquota - 1.1
cmd/xfstests/035.usrquota - 1.1
cmd/xfstests/036.grpquota - 1.1
cmd/xfstests/036.noquota - 1.1
cmd/xfstests/055.grpquota - 1.1
cmd/xfstests/043.usrquota - 1.1
cmd/xfstests/043.ugquota - 1.1
cmd/xfstests/037.grpquota - 1.1
cmd/xfstests/037.noquota - 1.1
cmd/xfstests/043.noquota - 1.1
cmd/xfstests/037.ugquota - 1.1
cmd/xfstests/037.usrquota - 1.1
cmd/xfstests/038.grpquota - 1.1
cmd/xfstests/038.noquota - 1.1
cmd/xfstests/043.grpquota - 1.1
cmd/xfstests/038.ugquota - 1.1
cmd/xfstests/038.usrquota - 1.1
cmd/xfstests/039.grpquota - 1.1
cmd/xfstests/039.noquota - 1.1
cmd/xfstests/039.usrquota - 1.1
cmd/xfstests/039.ugquota - 1.1
cmd/xfstests/common.dump - 1.11
	- updates for tests requiring a tape device to work with quota
	  mount options.

cmd/xfstests/043.out - 1.2
cmd/xfstests/039.out - 1.2
cmd/xfstests/038.out - 1.2
cmd/xfstests/037.out - 1.2
cmd/xfstests/036.out - 1.2
cmd/xfstests/035.out - 1.2
cmd/xfstests/025.out - 1.2
cmd/xfstests/024.out - 1.2
cmd/xfstests/023.out - 1.2
cmd/xfstests/022.out - 1.2
cmd/xfstests/055.out - 1.2
	- removed, no longer used - correct output is now conditional.



From owner-linux-xfs@oss.sgi.com Wed May 23 22:44:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O5isO05890
	for linux-xfs-outgoing; Wed, 23 May 2001 22:44:54 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O5irF05887
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:44:53 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4O5iiaJ084072;
	Thu, 24 May 2001 00:44:44 -0500 (CDT)
Message-ID: <3B0C91AB.9B2E4B2F@thebarn.com>
Date: Wed, 23 May 2001 23:44:27 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Sandeen <sandeen@sgi.com>
CC: J Landman <landman@mediaone.net>, linux-xfs@oss.sgi.com
Subject: Re: sanity check
References: <Pine.LNX.4.32.0105240033100.1730-100000@dsl-squash.corp.sgi.com> <3B0C980B.7B89D131@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Eric Sandeen wrote:

> J Landman wrote:
>
> >   So I want to take the patch, and apply it against the 2.4.3 kernel in
> > Mandrake 8.0.  I read through the instructions, and no where in there is a
> > mention of devfsd.  Now I know RH 7.1 with the installer uses devfsd, and
> > this has been a non-stop source of grief (xfs works great, VMware is
> > unhappy and needs reconfiging every time, and several other things are now
> > broken).
>
> I'm assuming that you're using mdklinux-2.4.3-core-xfs-05072001.patch?
>

Mandrake 8.0 does not have devfs turned on, neither does the
rpms XFS mandrake rpm's on oss.

Note it is important to work out the kinks in devfs due to the extreme
brokenness
of the current linux device naming convention, but yes many apps do not
correctly deal with devfs yet.

One option that may be considered it to enable devfs in 1.0.1 but
not to not have it mount devfs on /dev at mount time.


> A few things.  Devfs is part of the standard 2.4 kernel, and turned on
> and off via the kernel config.  The standard Mandrake 8.0 kernels DO
> have devfs enabled.  There is also a userspace daemon, devfsd, which
> helps manage /dev entries.  So, a standard Mandrake install does include
> devfs configured & devfsd running, and our patch against their kernel
> source tree won't change any of that.
>
> However, devfs is NOT required for xfs in any way.  If you are running a
> devfs-enabled kernel, you can always disable it by passing
> "devfs=nomount" on the lilo command line, or add it to lilo.conf as an
> "append" entry.  You'll have your old, standard, inode-hungry /dev just
> the way you like it.  :)
>
> Of course, if you recompile your kernel, you can just turn devfs off in
> theconfig.
>
> -Eric
>
> --
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.


From owner-linux-xfs@oss.sgi.com Wed May 23 22:47:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O5lgM05952
	for linux-xfs-outgoing; Wed, 23 May 2001 22:47:42 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O5leF05949
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 22:47:40 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4O5lbl07276
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:47:37 +0800
Received: from mail ([203.167.1.242]) by sisa.i-manila.com.ph ; Thu, 24 May 2001 13:47:40 +0800 GMT
Received: from kalapati (kalapati.linux-server.tlc [192.168.0.201])
	by mail (Postfix) with ESMTP id E39F7773D
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:44:16 +0800 (PHT)
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id 50979463E36
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:44:16 +0800 (PHT)
Date: Thu, 24 May 2001 13:44:16 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: XFS performance drop after uptime
In-Reply-To: <Pine.LNX.4.21.0105241319300.637-100000@kalapati.jijo.local>
Message-ID: <Pine.LNX.4.21.0105241337590.637-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi everyone,

It's me again. It looks like I spoke to soon with a pointing finger at XFS
in my last post. It's probably not uptime or activity that bring down my
performance, but lm_sensors.

I am using an ASUS CUV4X-E motherboard, that supposedly has a variant of
the w83781d sensor (according to the lm_sensors website it's probably an
ASUS AS99127F or some such variant which is misdetected as the w83781d).
Unfortunately ASUS refuses to release the datasheet to the lm_sensors
developers, so they've had to hack away the conversion factors for this
sensor. It's not working too well on my machine and upon loading the
module the thing goes on alarm because it (falsely) detects that the CPU
is running at 75C (it's actually running at 45C as the BIOS reports which
I presume is accurate).

Among the many things I disabled before I did a clean boot to give my
results detailed in (II), were the autoloading of the lm_sensor modules. I
tried and loading them and right after that I got the following as the
result of an 'hdparm -tT /dev/sda':

---[ result ]---
/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.40 seconds = 37.65 MB/sec
 Timing buffered disk reads:  64 MB in  3.36 seconds = 19.05 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.

/dev/sda:
 Timing buffer-cache reads:   128 MB in  3.40 seconds = 37.65 MB/sec
 Timing buffered disk reads:  64 MB in  3.31 seconds = 19.34 MB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.
---[ end of results ]---

Gotcha!

I still promised slabinfo and meminfo results (although I don't think
they're relevant), so here they are. I don't understand these two
pseudo-files, so if someone sees an actual discrepancy maybe he/she can
point it out. I hope everyone else will pardon the bandwidth used up in my
posting these:

---[ /proc/slabinfo ]---
slabinfo - version: 1.1
kmem_cache            69     78    100    2    2    1
ip_conntrack           1     22    352    1    2    1
tcp_tw_bucket          0      0     96    0    0    1
tcp_bind_bucket       13    113     32    1    1    1
tcp_open_request       0     59     64    0    1    1
inet_peer_cache        0      0     64    0    0    1
ip_fib_hash            9    113     32    1    1    1
ip_dst_cache          17     24    160    1    1    1
arp_cache              2     30    128    1    1    1
xfs_chashlist        151    202     16    1    1    1
xfs_ili               23     28    136    1    1    1
xfs_ifork              0      0     56    0    0    1
xfs_efi_item           0     15    260    0    1    1
xfs_efd_item           0     15    260    0    1    1
xfs_buf_item           3     26    148    1    1    1
xfs_dabuf              0    202     16    0    1    1
xfs_da_state           0      0    340    0    0    1
xfs_trans              0     24    320    0    2    1
xfs_inode            698    704    468   88   88    1
xfs_btree_cur          0     28    140    0    1    1
xfs_bmap_free_item      0    202     16    0    1    1
page_buf_t            21    120    192    4    6    1
page_buf_reg_t         4     40     96    1    1    1
avl_object_t           4    113     32    1    1    1
avl_entry_t            5    113     32    1    1    1
blkdev_requests     3072   4120     96   77  103    1
dnotify cache          0      0     20    0    0    1
file lock cache       17     42     92    1    1    1
fasync cache           0      0     16    0    0    1
uid_cache              6    113     32    1    1    1
skbuff_head_cache     59     72    160    3    3    1
sock                  45     54    832    5    6    2
inode_cache         5943   5944    480  743  743    1
bdev_cache            34     59     64    1    1    1
sigqueue               0     29    132    0    1    1
dentry_cache        6150   6180    128  205  206    1
filp                 558    560     96   14   14    1
names_cache            0      3   4096    0    3    1
buffer_head        72858  72920     96 1822 1823    1
mm_struct             66     90    128    3    3    1
vm_area_struct      1859   1947     64   32   33    1
fs_cache              65    118     64    2    2    1
files_cache           65     72    416    8    8    1
signal_act            69     72   1312   24   24    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072           17     18 131072   17   18   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536             9      9  65536    9    9   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             0      1  32768    0    1    8
size-16384(DMA)        2      2  16384    2    2    4
size-16384             2      3  16384    2    3    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192              2      2   8192    2    2    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096            106    107   4096  106  107    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048             39     42   2048   20   21    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             35     40   1024    9   10    1
size-512(DMA)          0      0    512    0    0    1
size-512             149    152    512   19   19    1
size-256(DMA)          0      0    256    0    0    1
size-256              31     45    256    3    3    1
size-128(DMA)          0      0    128    0    0    1
size-128            1634   1650    128   55   55    1
size-64(DMA)           0      0     64    0    0    1
size-64              212    708     64    4   12    1
size-32(DMA)           0      0     32    0    0    1
size-32              951   1017     32    9    9    1
---[ end of /proc/slabinfo ]---

---[ /proc/meminfo ]---
        total:    used:    free:  shared: buffers:  cached:
Mem:  525074432 145969152 379105280        0 77955072 19320832
Swap: 1019891712        0 1019891712
MemTotal:       512768 kB
MemFree:        370220 kB
MemShared:           0 kB
Buffers:         76128 kB
Cached:          18868 kB
Active:           6244 kB
Inact_dirty:     88752 kB
Inact_clean:         0 kB
Inact_target:        0 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       512768 kB
LowFree:        370220 kB
SwapTotal:      995988 kB
SwapFree:       995988 kB
---[ end of /proc/meminfo ]---

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Wed May 23 23:56:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O6ui707273
	for linux-xfs-outgoing; Wed, 23 May 2001 23:56:44 -0700
Received: from guardian.hermes.si (guardian.hermes.si [193.77.5.150])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O6uaF07267
	for <linux-xfs@oss.sgi.com>; Wed, 23 May 2001 23:56:37 -0700
Received: from hermes.si (primus.hermes.si [193.77.5.98])
	by guardian.hermes.si (8.9.3/8.9.3) with ESMTP id IAA22763
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:56:31 +0200 (METDST)
Received: (from uucp@localhost)
	by hermes.si (8.9.3/8.9.3) id IAA07932
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:56:28 +0200
Received: from oreh.hermes.si(10.65.207.12) by primus.hermes.si via smap (V2.1)
	id xma006792; Thu, 24 May 01 08:55:29 +0200
Received: by oreh.hermes.si with Internet Mail Service (5.5.2448.0)
	id <K34GLQDW>; Thu, 24 May 2001 08:55:31 +0200
Message-ID: <8DA212D53DEFD211A5E70060979801B41B86F9@oreh.hermes.si>
From: Andrej Jamsek <andrej.jamsek@hermes.si>
To: linux-xfs@oss.sgi.com
Subject: FW: LVM Utilities?
Date: Thu, 24 May 2001 08:54:29 +0200
Deferred-Delivery: Thu, 24 May 2001 08:55:00 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="windows-1252"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello.
I have RH7.1 installed and I build and installed LVM utilities from gziped
source tree from sistina page (www.sistina.com/lvm). I have installed LVM
utilities from lvm_0.9.1_beta7.tar.gz source tree and work fine.

Have a nice day
	Andrej

-----Original Message-----
From: Jason L Tibbitts III [mailto:tibbs@math.uh.edu]
Sent: 23. maj 2001 19:43
To: linux-xfs@oss.sgi.com
Subject: LVM Utilities?


I wanted to experiment with XFS and LVM so I installed the full set of RPMS
on an already running Red Hat 7.1. system.  Everything works fine, but I
can't seem to find the LVM utilities anywhere.

Can I just install any recent RPM of the utilities from sistina.com or do I
need one matched to the version included in the kernel?  (I'm somewhat
confused by the whole IOP compatibility thing right now.)  Anyone have a
source for RPMS known to work?

Thanks,

 - J<

From owner-linux-xfs@oss.sgi.com Thu May 24 00:16:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O7Gi307675
	for linux-xfs-outgoing; Thu, 24 May 2001 00:16:44 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O7GhF07672
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 00:16:43 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152pMK-0007NL-01; Thu, 24 May 2001 19:16:36 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Federico Sevilla III" <jijo@i-manila.com.ph>,
   "Linux XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: RE: XFS performance drop after uptime
Date: Thu, 24 May 2001 19:16:04 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIOECICAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.21.0105241337590.637-100000@kalapati.jijo.local>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: It's me again. It looks like I spoke to soon with a pointing
:: finger at XFS
:: in my last post. It's probably not uptime or activity that bring down my
:: performance, but lm_sensors.

I've got the i2c stuff compiled as modules, but these are not loaded.
Shouldn't matter...

-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 00:16:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O7Gla07685
	for linux-xfs-outgoing; Thu, 24 May 2001 00:16:47 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O7GkF07682
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 00:16:46 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152pMK-0007NL-00; Thu, 24 May 2001 19:16:36 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Federico Sevilla III" <jijo@i-manila.com.ph>,
   "Linux XFS Mailing List" <linux-xfs@oss.sgi.com>
Subject: RE: XFS performance drop after uptime (was: So far, so good)
Date: Thu, 24 May 2001 19:16:04 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIMECICAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.21.0105241319300.637-100000@kalapati.jijo.local>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

:: on a Pentium III 733MHz with 512MB RAM and 4 x 30.6GB UDMA/66 7200RPM IBM
:: hard drives on a RAID 5 array with a 3ware Escalade 6400 controller. I'm
:: running the latest (well, as of yesterday GMT+0800) CVS of XFS.

What's the chip set on that system? Intel or VIA?

It's a huge difference, and I wonder why. I don't see this kind of variation
on a single-CPU 440BX P2 system.

I've now tried with both SCSI and IDE drives -- same result. The hdparm
results drop in both cases after a certain amount of uptime (haven't been
able to figure out how much yet).

Also tried running in single mode, with the same result.

The kernel version doesn't seem to matter.



-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 01:53:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4O8r6h09425
	for linux-xfs-outgoing; Thu, 24 May 2001 01:53:06 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4O8r5F09422
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 01:53:05 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 152qrg-0007QQ-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 20:53:04 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: <linux-xfs@oss.sgi.com>
Subject: Errr... what's all this about then?
Date: Thu, 24 May 2001 20:52:32 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIIECKCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>From dmesg:

xfs_create looping, dir ino 0x40089, ino 0x4c240, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c241, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x14008d, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x14008e, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c243, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c244, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c247, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c248, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c249, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c24a, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x140094, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c254, ide0(3,7)


-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 04:03:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OB3cv12496
	for linux-xfs-outgoing; Thu, 24 May 2001 04:03:38 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OB3aF12488
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 04:03:36 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA06536
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 04:03:33 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1926984; Thu, 24 May 2001 06:01:11 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA77255; Thu, 24 May 2001 06:01:03 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OB49j09898; Thu, 24 May 2001 06:04:09 -0500
Message-Id: <200105241104.f4OB49j09898@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: linux-xfs@oss.sgi.com, sgi-admin@ncsa.uiuc.edu
Subject: Re: the file I forgot... 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Wed, 23 May 2001 15:46:11 CDT." <Pine.LNX.4.33.0105231541440.25173-200000@osage.ncsa.uiuc.edu> 
Date: Thu, 24 May 2001 06:04:09 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> Here's the file.
> 

Hmm, I see there were a couple of followups on the xfs hang during run 4,
I would really like to chase this one down if there is any chance of help
from your end in following Keith Owens' suggestions. The tricky part here
is determining if this is xfs itself, or xfs driving the linux vm system
up the wall. xfs itself did not change in the read/write path between 2.4.2
and 2.4.4, but the kernel does have relevent changes, and there are probably
more to make yet.

>
> -Galen
> 



>> Space efficiency comparison
>> ext2 Filesystem           1k-blocks      Used Available Use% Mounted
>> on /dev/sdd1            710025700   9446452 665072388   1% /storage
>>
>> reiserfs /dev/sdc1      710115552     32840 710082712   0% /storage
>>
>> xfs /dev/sdd1           710050544   4106940 705943604   1% /storage


These are a little bizzare - how much data did yoy have on the disk at
this point, and where did reiserfs put it! Did you also benchmark mkfs
times for the different filesystems (I see you got impatient with ext2
inode creation). Also I wonder if there is not something we can do with
xfs mkfs parameters to improve performance there, the latest mkfs.xfs
from cvs has a -d agsize=xxx option, you could specify 4Gbytes here, this
would allow xfs to allocate larger extents than the default of 1Gbyte,
not that we would read or write that much in one go on this hardware.
It might also be of some benefit to use the stripe alignment options of
mkfs (see the man page for swidth, sw, sunit and su options.

A couple of comments on the actual results, the XFS read path and the ext2
read path are esentially the same, the readahead logic is the same code,
the only difference is when the filesystem specific code is called to ask
where a block lives on disk. I think we can squeeze a bit more out of xfs,
but it takes mainline linux code changes.

What sized I/O does record rewrite do, looks like we have some work to
do there?

I also wonder if iozone could be made to do Direct I/O.

Thanks for doing all this benchmarking.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 24 04:15:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OBF4B13087
	for linux-xfs-outgoing; Thu, 24 May 2001 04:15:04 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OBF4F13082
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 04:15:04 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id EAA15129
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 04:15:04 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1925721; Thu, 24 May 2001 06:13:46 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA93120; Thu, 24 May 2001 06:13:46 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OBGqX09929; Thu, 24 May 2001 06:16:52 -0500
Message-Id: <200105241116.f4OBGqX09929@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Chris Pascoe" <c.pascoe@csee.uq.edu.au>
cc: linux-xfs@oss.sgi.com
Subject: Re: Crashes in various ext2 functions while running xfstest/check 
In-Reply-To: Message from "Chris Pascoe" <c.pascoe@csee.uq.edu.au> 
   of "Thu, 24 May 2001 14:01:02 +1000." <002101c0e406$25ef4b70$47426682@csee.uq.edu.au> 
Date: Thu, 24 May 2001 06:16:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


This is a little scary, the xfs and ext2 filesystems are on different devices,
otherwise I would question the raid driver, or are they? Your device numbers
are a little different, where are the partitions you used for the tests? 

I have not seen anything like this before, it smells a little of a buffer
head getting stamped on. Would it be possible to add disassemblies of the
ext2 functions you have hit corruption in? i.e. just run gdb on vmlinux
and disassemble them, otherwise it is hard to figure out which memory
reference was at fault.

Thanks

  Steve

> Hi,
> 
> I'm running the XFS stress tests on a Dell Poweredge 4400 running.  The
> kernel is the current CVS one (as at today) but the problem persists over
> several weeks of compilations.  Local modifications to the kernel are the
> addition of the module for the AACRAID Perc 3/Di RAID controller and the
> e1000 driver from Intel for the ethernet card.  Highmem support is enabled
> (the machine has 1GB of RAM).  The kernels are compiled with the kgcc
> package from Redhat 7.0 (egcs
> 2.91.66) or the RH7.1 gcc (2.96-81) - it makes no difference.
> 
> hinv, dmesg, and backtraces from kdb at crash time are available at
> http://www.csee.uq.edu.au/~chrisp/xfs/.  I don't know what other information
> to gather.  Any pointers?
> 
> So far I have seen deaths (caused by NULL pointer exceptions) in (at least)
> ext2_get_block, ext2_update_inode, ext2_alloc_branch, etc, while running
> 'check' from the xfstests directory.  I haven't been able to trigger any
> crashes during any other activity on the system, using 2.2.19 and the
> standard RH7.1 kernel (I can't run xfs test on those though, obviously).
> 
> I may be able to provide remote access + console access to the server if
> it's of any use (it is a development/test box) if it is of any use.
> 
> Chris



From owner-linux-xfs@oss.sgi.com Thu May 24 05:45:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OCjZ714714
	for linux-xfs-outgoing; Thu, 24 May 2001 05:45:35 -0700
Received: from gum.csee.uq.edu.au (gum.csee.uq.edu.au [130.102.66.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OCjWF14711
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 05:45:33 -0700
Received: from nut.csee.uq.edu.au (nut.csee.uq.edu.au [130.102.66.13])
	by gum.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f4OCjSc09266;
	Thu, 24 May 2001 22:45:29 +1000 (EST)
Received: from mango.csee.uq.edu.au (mango.csee.uq.edu.au [130.102.66.4])
	by nut.csee.uq.edu.au (8.11.3/8.11.3) with ESMTP id f4OCjSo29744;
	Thu, 24 May 2001 22:45:28 +1000 (EST)
Date: Thu, 24 May 2001 22:45:28 +1000 (EST)
From: Chris Pascoe <c.pascoe@csee.uq.edu.au>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Crashes in various ext2 functions while running xfstest/check 
In-Reply-To: <200105241116.f4OBGqX09929@jen.americas.sgi.com>
Message-ID: <Pine.GSO.4.33.0105242136050.21984-100000@mango.csee.uq.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Scanned-By: MIMEDefang 1.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> This is a little scary, the xfs and ext2 filesystems are on different devices,
> otherwise I would question the raid driver, or are they? Your device numbers
> are a little different, where are the partitions you used for the tests?

Both the sda and sdb devices are separate RAID volumes off the same
controller - sda is a RAID1 (dual 9GB drives) and sdb is a RAID5 (six 73GB
drives).

Start mounting filesystem: sd(8,17)
Ending clean XFS mount for filesystem: sd(8,17)
Start mounting filesystem: sd(8,18)
Ending clean XFS mount for filesystem: sd(8,18)

Those device numbers are strange?  Thye correlate to /dev/sdb1 and
/dev/sdb2.  I was using:
	TEST_DEV="/dev/sdb1"
        TEST_DIR="/tst1"
        SCRATCH_DEV="/dev/sdb2"
        SCRATCH_MNT="/tst2"

> I have not seen anything like this before, it smells a little of a buffer
> head getting stamped on. Would it be possible to add disassemblies of the
> ext2 functions you have hit corruption in? i.e. just run gdb on vmlinux
> and disassemble them, otherwise it is hard to figure out which memory
> reference was at fault.

Sure, I am rerunning and will put up dissassemblies as I catch them.
Unfortunately I 'cvs update'd and recompiled without saving the old
vmlinux.  I have two new bt's up now, combined with disassemble's of the
ext2 functions that were running when the oopses occured at
http://www.csee.uq.edu.au/~chrisp/xfs/disasm-20010523.  I hope I've done
the right thing!!

I'm compiling six new kernels on the machine at the moment, with a few
combinations of highmem on/highmem off, Pentium II vs Pentium III
selected, SMP vs Non-SMP, to see if changing any of these makes a
difference.  I think I can possibly disable the RAID controller too,
converting it back into a standard aic7xxx - will look into that hopefully
tomorrow too.

Chris


From owner-linux-xfs@oss.sgi.com Thu May 24 06:12:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ODCKC15271
	for linux-xfs-outgoing; Thu, 24 May 2001 06:12:20 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ODCIF15267
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 06:12:18 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4ODCCb18689;
	Thu, 24 May 2001 08:12:13 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4ODCCM04132;
	Thu, 24 May 2001 08:12:12 -0500 (CDT)
Date: Thu, 24 May 2001 08:12:12 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <cluster-admin@ncsa.uiuc.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: the file I forgot... 
In-Reply-To: <200105241104.f4OB49j09898@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105240809030.25173-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve,

I'll get another kernel built with kdb enabled and boot it with the NMI
settings suggested earlier.  In the meantime, I got lucky and had a crash
from the job I left running last night.  The output is at:

	http://www.ncsa.uiuc.edu/people/arnoldg/xfs/cr1

Right now I'm voting for b) below-- xfs driving the vm system up the wall.

-Galen

 On Thu, 24 May 2001, Steve Lord
wrote:

>
> >
> > Here's the file.
> >
>
> Hmm, I see there were a couple of followups on the xfs hang during run 4,
> I would really like to chase this one down if there is any chance of help
> from your end in following Keith Owens' suggestions. The tricky part here
> is determining if this is xfs itself, or xfs driving the linux vm system
> up the wall. xfs itself did not change in the read/write path between 2.4.2
> and 2.4.4, but the kernel does have relevent changes, and there are probably
> more to make yet.
>
> >
> > -Galen
> >
>
>
>
> >> Space efficiency comparison
> >> ext2 Filesystem           1k-blocks      Used Available Use% Mounted
> >> on /dev/sdd1            710025700   9446452 665072388   1% /storage
> >>
> >> reiserfs /dev/sdc1      710115552     32840 710082712   0% /storage
> >>
> >> xfs /dev/sdd1           710050544   4106940 705943604   1% /storage
>
>
> These are a little bizzare - how much data did yoy have on the disk at
> this point, and where did reiserfs put it! Did you also benchmark mkfs
> times for the different filesystems (I see you got impatient with ext2
> inode creation). Also I wonder if there is not something we can do with
> xfs mkfs parameters to improve performance there, the latest mkfs.xfs
> from cvs has a -d agsize=xxx option, you could specify 4Gbytes here, this
> would allow xfs to allocate larger extents than the default of 1Gbyte,
> not that we would read or write that much in one go on this hardware.
> It might also be of some benefit to use the stripe alignment options of
> mkfs (see the man page for swidth, sw, sunit and su options.
>
> A couple of comments on the actual results, the XFS read path and the ext2
> read path are esentially the same, the readahead logic is the same code,
> the only difference is when the filesystem specific code is called to ask
> where a block lives on disk. I think we can squeeze a bit more out of xfs,
> but it takes mainline linux code changes.
>
> What sized I/O does record rewrite do, looks like we have some work to
> do there?
>
> I also wonder if iozone could be made to do Direct I/O.
>
> Thanks for doing all this benchmarking.
>
> Steve
>
>

-- 
+
Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
National Center for Supercomputing Applications           (217) 244-3473
152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820


From owner-linux-xfs@oss.sgi.com Thu May 24 07:00:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OE0nF16655
	for linux-xfs-outgoing; Thu, 24 May 2001 07:00:49 -0700
Received: from psyduck.m6tech.gov (IDENT:root@[196.25.111.97])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OE0kF16652
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:00:47 -0700
Received: from localhost (nkukard@localhost)
	by psyduck.m6tech.gov (8.9.3/8.8.7) with ESMTP id QAA13334
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:00:47 +0200
X-Authentication-Warning: psyduck.m6tech.gov: nkukard owned process doing -bs
Date: Thu, 24 May 2001 16:00:47 +0200 (SAST)
From: Nigel Kukard <nkukard@yahoo.com>
X-Sender: nkukard@psyduck.m6tech.gov
To: linux-xfs@oss.sgi.com
Subject: LABEL=.... not working
Message-ID: <Pine.LNX.4.21.0105241553100.10753-100000@psyduck.m6tech.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I've got kernel 2.4.4, with the test xfs patch applied.
The problem is i cannot mount an XFS filesystem with a label. Here is what
i did to create the filessytem and set the label (no errors)....

	mkfs.xfs /dev/hdd1

	xfs_admin -L bootfs /dev/hdd1


now if i add the following to my  /etc/fstab  and try to mount the
filesystem it says its not found...

	LABEL=bootfs     /tmp/test    xfs    defaults    1 1


Here is the error....

	[root@fluffy /mnt]# mount /tmp/test
	mount: no such partition found


If i try the exact same lines but using ext2fs it works, any ideas?





Any feedback would be very much appreciated!
Nigel Kukard


From owner-linux-xfs@oss.sgi.com Thu May 24 07:11:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEBJm17078
	for linux-xfs-outgoing; Thu, 24 May 2001 07:11:19 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEBIF17073
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:11:18 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA702062
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:11:16 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1929153; Thu, 24 May 2001 09:09:58 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA32911; Thu, 24 May 2001 09:09:58 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OED2t14756; Thu, 24 May 2001 09:13:03 -0500
Message-Id: <200105241413.f4OED2t14756@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Nigel Kukard <nkukard@yahoo.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: Message from Nigel Kukard <nkukard@yahoo.com> 
   of "Thu, 24 May 2001 16:00:47 +0200." <Pine.LNX.4.21.0105241553100.10753-100000@psyduck.m6tech.gov> 
Date: Thu, 24 May 2001 09:13:02 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


You probably need a newer mount version, the xfs label support in the
mount command is recent. I am running mount-2.10m.

Steve

> Hi,
> 
> I've got kernel 2.4.4, with the test xfs patch applied.
> The problem is i cannot mount an XFS filesystem with a label. Here is what
> i did to create the filessytem and set the label (no errors)....
> 
> 	mkfs.xfs /dev/hdd1
> 
> 	xfs_admin -L bootfs /dev/hdd1
> 
> 
> now if i add the following to my  /etc/fstab  and try to mount the
> filesystem it says its not found...
> 
> 	LABEL=bootfs     /tmp/test    xfs    defaults    1 1
> 
> 
> Here is the error....
> 
> 	[root@fluffy /mnt]# mount /tmp/test
> 	mount: no such partition found
> 
> 
> If i try the exact same lines but using ext2fs it works, any ideas?
> 
> 
> 
> 
> 
> Any feedback would be very much appreciated!
> Nigel Kukard



From owner-linux-xfs@oss.sgi.com Thu May 24 07:20:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEKK117393
	for linux-xfs-outgoing; Thu, 24 May 2001 07:20:20 -0700
Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEKJF17389
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:20:19 -0700
Received: by chiara.elte.hu (Postfix, from userid 17000)
	id 1B3001FC7; Thu, 24 May 2001 16:20:06 +0200 (CEST)
Date: Thu, 24 May 2001 16:20:05 +0200
From: KELEMEN Peter <fuji@elte.hu>
To: linux-xfs@oss.sgi.com
Subject: Parallel read performance crawls
Message-ID: <20010524162005.A26407@chiara.elte.hu>
Reply-To: KELEMEN Peter <fuji@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary
X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20
X-GPG-Fingerprint: D402 4AF3 7488 165B CC34  4147 7F0C D922 EE4C 26E8
X-PGP-KeyID: 1024/45F83E45 1998/04/04
X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD  6D AA B5 8A D6 03 0F BF
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dear XFS developers,

While a single bonnie++ benchmarks shows excellent[1] performance
on my test machine, two parallel bonnie++s still excel in write
performance, but crawl[2] in read performance.  What is the effect
I'm seeing here?

Peter

[1]
Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xfs_1            3G 11236  99 63619  51 17625  18 10133  88 58129  28  94.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    16:15000:12/512   785  18 25534 101  1378  29  1582  37 24665  99  1575  29

[2]
Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xfs_2_1          2G 10851  98 42060  38  5277   5  4261  37  4040   1  47.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    16:15000:12/512   313  10 22666  98   763  24   403  15 23511  99   182   7

Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xfs_2_2          2G 10620  96 42498  39  5618   5  4296  37  3987   1  47.9   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
    16:15000:12/512   307   9 20354  99   804  22   428  14 23531 100   176   6

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \       /      fuji@elte.hu
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From owner-linux-xfs@oss.sgi.com Thu May 24 07:21:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OELHJ17428
	for linux-xfs-outgoing; Thu, 24 May 2001 07:21:17 -0700
Received: from psyduck.m6tech.gov (IDENT:root@[196.25.111.97])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OELEF17421
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:21:15 -0700
Received: from localhost (nkukard@localhost)
	by psyduck.m6tech.gov (8.9.3/8.8.7) with ESMTP id QAA13455
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:21:15 +0200
X-Authentication-Warning: psyduck.m6tech.gov: nkukard owned process doing -bs
Date: Thu, 24 May 2001 16:21:14 +0200 (SAST)
From: Nigel Kukard <nkukard@yahoo.com>
X-Sender: nkukard@psyduck.m6tech.gov
To: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: <200105241413.f4OED2t14756@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105241620020.10753-100000@psyduck.m6tech.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


[root@fluffy mnt]# mount -V
mount: mount-2.10m


Would devfs affect this at all?




Kind Regards
Nigel


From owner-linux-xfs@oss.sgi.com Thu May 24 07:25:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEPtO17550
	for linux-xfs-outgoing; Thu, 24 May 2001 07:25:55 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEPtF17547
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:25:55 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA06776
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:25:48 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1930600; Thu, 24 May 2001 09:24:31 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA30806; Thu, 24 May 2001 09:24:31 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OERZh14936; Thu, 24 May 2001 09:27:35 -0500
Message-Id: <200105241427.f4OERZh14936@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Nigel Kukard <nkukard@yahoo.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: Message from Nigel Kukard <nkukard@yahoo.com> 
   of "Thu, 24 May 2001 16:21:14 +0200." <Pine.LNX.4.21.0105241620020.10753-100000@psyduck.m6tech.gov> 
Date: Thu, 24 May 2001 09:27:35 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> [root@fluffy mnt]# mount -V
> mount: mount-2.10m
> 
> 
> Would devfs affect this at all?


Hmm, can you mount ext2 labeled filesystems whilst running devfs?
The quick test is to remove devfs by adding

	devfs=nomount

to the boot options.

Steve

> 
> 
> 
> 
> Kind Regards
> Nigel



From owner-linux-xfs@oss.sgi.com Thu May 24 07:32:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEWl417751
	for linux-xfs-outgoing; Thu, 24 May 2001 07:32:47 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEWkF17748
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:32:46 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03724
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:32:47 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1930455; Thu, 24 May 2001 09:31:02 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14590; Thu, 24 May 2001 09:31:01 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OEY6214966; Thu, 24 May 2001 09:34:06 -0500
Message-Id: <200105241434.f4OEY6214966@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Chris Pascoe <c.pascoe@csee.uq.edu.au>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Crashes in various ext2 functions while running xfstest/check 
In-Reply-To: Message from Chris Pascoe <c.pascoe@csee.uq.edu.au> 
   of "Thu, 24 May 2001 22:45:28 +1000." <Pine.GSO.4.33.0105242136050.21984-100000@mango.csee.uq.edu.au> 
Date: Thu, 24 May 2001 09:34:06 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hmm, thanks for the info, both the dumps come from lines where ext2 is
accessing the b_data field of buffers it just got back from cache for
the first time. It looks like the b_data field is NULL, this is a
legitimate state for b_data, but not for ext2 metadata buffers, so,
it may be a mix of ext2 and xfs running in parallel is part of the
problem here, but xfs does not mess with b_data directly, and does not
use the same buffer head based caching of metadata that ext2 does.

More to come on this one.

Steve

> 
> > This is a little scary, the xfs and ext2 filesystems are on different devic
> es,
> > otherwise I would question the raid driver, or are they? Your device number
> s
> > are a little different, where are the partitions you used for the tests?
> 
> Both the sda and sdb devices are separate RAID volumes off the same
> controller - sda is a RAID1 (dual 9GB drives) and sdb is a RAID5 (six 73GB
> drives).
> 
> Start mounting filesystem: sd(8,17)
> Ending clean XFS mount for filesystem: sd(8,17)
> Start mounting filesystem: sd(8,18)
> Ending clean XFS mount for filesystem: sd(8,18)
> 
> Those device numbers are strange?  Thye correlate to /dev/sdb1 and
> /dev/sdb2.  I was using:
> 	TEST_DEV="/dev/sdb1"
>         TEST_DIR="/tst1"
>         SCRATCH_DEV="/dev/sdb2"
>         SCRATCH_MNT="/tst2"
> 
> > I have not seen anything like this before, it smells a little of a buffer
> > head getting stamped on. Would it be possible to add disassemblies of the
> > ext2 functions you have hit corruption in? i.e. just run gdb on vmlinux
> > and disassemble them, otherwise it is hard to figure out which memory
> > reference was at fault.
> 
> Sure, I am rerunning and will put up dissassemblies as I catch them.
> Unfortunately I 'cvs update'd and recompiled without saving the old
> vmlinux.  I have two new bt's up now, combined with disassemble's of the
> ext2 functions that were running when the oopses occured at
> http://www.csee.uq.edu.au/~chrisp/xfs/disasm-20010523.  I hope I've done
> the right thing!!
> 
> I'm compiling six new kernels on the machine at the moment, with a few
> combinations of highmem on/highmem off, Pentium II vs Pentium III
> selected, SMP vs Non-SMP, to see if changing any of these makes a
> difference.  I think I can possibly disable the RAID controller too,
> converting it back into a standard aic7xxx - will look into that hopefully
> tomorrow too.
> 
> Chris



From owner-linux-xfs@oss.sgi.com Thu May 24 07:34:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEYdf17787
	for linux-xfs-outgoing; Thu, 24 May 2001 07:34:39 -0700
Received: from psyduck.m6tech.gov (IDENT:root@[196.25.111.97])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEYbF17780
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:34:37 -0700
Received: from localhost (nkukard@localhost)
	by psyduck.m6tech.gov (8.9.3/8.8.7) with ESMTP id QAA13569
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:34:38 +0200
X-Authentication-Warning: psyduck.m6tech.gov: nkukard owned process doing -bs
Date: Thu, 24 May 2001 16:34:37 +0200 (SAST)
From: Nigel Kukard <nkukard@yahoo.com>
X-Sender: nkukard@psyduck.m6tech.gov
To: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: <200105241427.f4OERZh14936@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105241627320.10753-100000@psyduck.m6tech.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Well, i now run on 100% pure devfs, no actual device files in my dev dir.

ext2fs works 100% fine with the exact same config.

I just did another test with ext2fs & xfs, i used the EXACT same line to
try mount namely....
   
   mount LABEL=testfs /tmp/test

with ext2fs it works fine, but when i reformat the partition to xfs, set
the label and try mount again it sez there is no such partition found.

i must be doing sumin wrong, what i have no clue  :-(




Kind regards
Nigel



From owner-linux-xfs@oss.sgi.com Thu May 24 07:46:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEkdu18379
	for linux-xfs-outgoing; Thu, 24 May 2001 07:46:39 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEkcF18374
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:46:38 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01591
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:46:24 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1930697; Thu, 24 May 2001 09:45:06 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA22208; Thu, 24 May 2001 09:45:06 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OEmAJ15020; Thu, 24 May 2001 09:48:10 -0500
Message-Id: <200105241448.f4OEmAJ15020@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Nigel Kukard <nkukard@yahoo.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: Message from Nigel Kukard <nkukard@yahoo.com> 
   of "Thu, 24 May 2001 16:34:37 +0200." <Pine.LNX.4.21.0105241627320.10753-100000@psyduck.m6tech.gov> 
Date: Thu, 24 May 2001 09:48:10 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> 
> Well, i now run on 100% pure devfs, no actual device files in my dev dir.
> 
> ext2fs works 100% fine with the exact same config.
> 
> I just did another test with ext2fs & xfs, i used the EXACT same line to
> try mount namely....
>    
>    mount LABEL=testfs /tmp/test
> 
> with ext2fs it works fine, but when i reformat the partition to xfs, set
> the label and try mount again it sez there is no such partition found.
> 
> i must be doing sumin wrong, what i have no clue  :-(


OK, you are not doing something wrong, I need to go find the mount
source code, this version of mount does not have the xfs code in it,
I just watched it run, and it does not look at the right place on the
disk to see an xfs label. Sorry, I should have tried rather than assumed
it was working here.


Steve



From owner-linux-xfs@oss.sgi.com Thu May 24 07:51:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEpU918592
	for linux-xfs-outgoing; Thu, 24 May 2001 07:51:30 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEpSF18589
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:51:28 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id QAA678957
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:51:26 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1891222; Thu, 24 May 2001 09:50:09 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA99755; Thu, 24 May 2001 09:50:08 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OErDi15051; Thu, 24 May 2001 09:53:13 -0500
Message-Id: <200105241453.f4OErDi15051@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Steve Lord <lord@sgi.com>
cc: Nigel Kukard <nkukard@yahoo.com>, linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: Message from Steve Lord <lord@sgi.com> 
   of "Thu, 24 May 2001 09:48:10 CDT." <200105241448.f4OEmAJ15020@jen.americas.sgi.com> 
Date: Thu, 24 May 2001 09:53:13 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> OK, you are not doing something wrong, I need to go find the mount
> source code, this version of mount does not have the xfs code in it,
> I just watched it run, and it does not look at the right place on the
> disk to see an xfs label. Sorry, I should have tried rather than assumed
> it was working here.


Looks like you need at least 2.10r for xfs support, and Util-linux is now
at 2.11d

It comes from here:

ftp://ftp.kernel.org/pub/linux/utils/util-linux/

I will see if I cannot get someone to provide an updated rpm which is
more xfs friendly.

Steve

> 
> 
> Steve
> 



From owner-linux-xfs@oss.sgi.com Thu May 24 07:54:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEsf318652
	for linux-xfs-outgoing; Thu, 24 May 2001 07:54:41 -0700
Received: from psyduck.m6tech.gov (IDENT:root@[196.25.111.97])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEscF18645
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:54:39 -0700
Received: from localhost (nkukard@localhost)
	by psyduck.m6tech.gov (8.9.3/8.8.7) with ESMTP id QAA13709;
	Thu, 24 May 2001 16:54:34 +0200
X-Authentication-Warning: psyduck.m6tech.gov: nkukard owned process doing -bs
Date: Thu, 24 May 2001 16:54:34 +0200 (SAST)
From: Nigel Kukard <nkukard@yahoo.com>
X-Sender: nkukard@psyduck.m6tech.gov
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: <200105241448.f4OEmAJ15020@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105241653340.10753-100000@psyduck.m6tech.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hey man, no prob at all, i really appreciate the quick response and
helpfull feedback.  :-)


Be sure to send me a patch when u done!
Nigel




On Thu, 24 May 2001, Steve Lord wrote:

> > 
> > 
> > Well, i now run on 100% pure devfs, no actual device files in my dev dir.
> > 
> > ext2fs works 100% fine with the exact same config.
> > 
> > I just did another test with ext2fs & xfs, i used the EXACT same line to
> > try mount namely....
> >    
> >    mount LABEL=testfs /tmp/test
> > 
> > with ext2fs it works fine, but when i reformat the partition to xfs, set
> > the label and try mount again it sez there is no such partition found.
> > 
> > i must be doing sumin wrong, what i have no clue  :-(
> 
> 
> OK, you are not doing something wrong, I need to go find the mount
> source code, this version of mount does not have the xfs code in it,
> I just watched it run, and it does not look at the right place on the
> disk to see an xfs label. Sorry, I should have tried rather than assumed
> it was working here.
> 
> 
> Steve
> 


From owner-linux-xfs@oss.sgi.com Thu May 24 07:58:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OEw0I18756
	for linux-xfs-outgoing; Thu, 24 May 2001 07:58:00 -0700
Received: from psyduck.m6tech.gov (IDENT:root@[196.25.111.97])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OEvvF18752
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 07:57:58 -0700
Received: from localhost (nkukard@localhost)
	by psyduck.m6tech.gov (8.9.3/8.8.7) with ESMTP id QAA13765;
	Thu, 24 May 2001 16:57:47 +0200
X-Authentication-Warning: psyduck.m6tech.gov: nkukard owned process doing -bs
Date: Thu, 24 May 2001 16:57:47 +0200 (SAST)
From: Nigel Kukard <nkukard@yahoo.com>
X-Sender: nkukard@psyduck.m6tech.gov
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: <200105241453.f4OErDi15051@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105241657350.10753-100000@psyduck.m6tech.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001, Steve Lord wrote:

> 
> > 
> > OK, you are not doing something wrong, I need to go find the mount
> > source code, this version of mount does not have the xfs code in it,
> > I just watched it run, and it does not look at the right place on the
> > disk to see an xfs label. Sorry, I should have tried rather than assumed
> > it was working here.
> 
> 
> Looks like you need at least 2.10r for xfs support, and Util-linux is now
> at 2.11d
> 
> It comes from here:
> 
> ftp://ftp.kernel.org/pub/linux/utils/util-linux/
> 
> I will see if I cannot get someone to provide an updated rpm which is
> more xfs friendly.

You mean a util-linux rpm?



> 
> Steve
> 
> > 
> > 
> > Steve
> > 
> 


From owner-linux-xfs@oss.sgi.com Thu May 24 08:06:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OF6p519073
	for linux-xfs-outgoing; Thu, 24 May 2001 08:06:51 -0700
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OF6oF19070
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:06:50 -0700
Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217])
	by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f4OF6lM08910;
	Thu, 24 May 2001 11:06:48 -0400 (EDT)
Date: Thu, 24 May 2001 11:06:37 -0400 (EDT)
From: J Landman <landman@mediaone.net>
X-X-Sender:  <landman@dsl-squash.corp.sgi.com>
To: Eric Sandeen <sandeen@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: sanity check
In-Reply-To: <3B0C980B.7B89D131@sgi.com>
Message-ID: <Pine.LNX.4.32.0105241105080.16968-100000@dsl-squash.corp.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Actually I checked my mandrake 8.0 machine, and no devfsd support is
included in the kernel by default.  I am glad to hear that I do not need
devfs.

Joe

On Thu, 24 May 2001, Eric Sandeen wrote:

> J Landman wrote:
>
> >   So I want to take the patch, and apply it against the 2.4.3 kernel in
> > Mandrake 8.0.  I read through the instructions, and no where in there is a
> > mention of devfsd.  Now I know RH 7.1 with the installer uses devfsd, and
> > this has been a non-stop source of grief (xfs works great, VMware is
> > unhappy and needs reconfiging every time, and several other things are now
> > broken).
>
> I'm assuming that you're using mdklinux-2.4.3-core-xfs-05072001.patch?
>
> A few things.  Devfs is part of the standard 2.4 kernel, and turned on
> and off via the kernel config.  The standard Mandrake 8.0 kernels DO
> have devfs enabled.  There is also a userspace daemon, devfsd, which
> helps manage /dev entries.  So, a standard Mandrake install does include
> devfs configured & devfsd running, and our patch against their kernel
> source tree won't change any of that.
>
> However, devfs is NOT required for xfs in any way.  If you are running a
> devfs-enabled kernel, you can always disable it by passing
> "devfs=nomount" on the lilo command line, or add it to lilo.conf as an
> "append" entry.  You'll have your old, standard, inode-hungry /dev just
> the way you like it.  :)
>
> Of course, if you recompile your kernel, you can just turn devfs off in
> theconfig.
>
> -Eric
>
>

-- 
 Joe Landman,
 landman@mediaone.net



From owner-linux-xfs@oss.sgi.com Thu May 24 08:14:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFE1919566
	for linux-xfs-outgoing; Thu, 24 May 2001 08:14:01 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFE0F19562
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:14:00 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4OFDvb08930;
	Thu, 24 May 2001 10:13:57 -0500 (CDT)
Message-ID: <3B0D25E0.C95B7815@sgi.com>
Date: Thu, 24 May 2001 10:16:48 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: J Landman <landman@mediaone.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: sanity check
References: <Pine.LNX.4.32.0105241105080.16968-100000@dsl-squash.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

J Landman wrote:
> 
> Actually I checked my mandrake 8.0 machine, and no devfsd support is
> included in the kernel by default.  I am glad to hear that I do not need
> devfs.

Sorry about the misinformation - I knew that Mandrake had done a lot of
work with devfs, and had included several patches to make it work
better, I mistakenly thought that it was enabled by default.

In any case, everything else I said about devfs, and it's independence
from XFS is correct, I believe.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 08:28:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFSp719952
	for linux-xfs-outgoing; Thu, 24 May 2001 08:28:51 -0700
Received: from epithumia.math.uh.edu (IDENT:root@epithumia.math.uh.edu [129.7.128.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFSoF19949
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:28:51 -0700
Received: (from tibbs@localhost)
	by epithumia.math.uh.edu (8.11.0/8.11.1) id f4OFSo506155;
	Thu, 24 May 2001 10:28:50 -0500
To: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working
References: <200105241453.f4OErDi15051@jen.americas.sgi.com>
From: Jason L Tibbitts III <tibbs@math.uh.edu>
Date: 24 May 2001 10:28:50 -0500
In-Reply-To: Steve Lord's message of "Thu, 24 May 2001 09:53:13 -0500"
Message-ID: <ufa3d9uix59.fsf@epithumia.math.uh.edu>
Lines: 9
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>>>>> "SL" == Steve Lord <lord@sgi.com> writes:

SL> I will see if I cannot get someone to provide an updated rpm which is
SL> more xfs friendly.

Red Hat shipped mount-2.11b as an erratum to 7.1.  It's on
updates.redhat.com.

 - J<

From owner-linux-xfs@oss.sgi.com Thu May 24 08:31:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFVEF20024
	for linux-xfs-outgoing; Thu, 24 May 2001 08:31:14 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFVDF20020
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:31:13 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OFVBk26969;
	Thu, 24 May 2001 10:31:11 -0500 (CDT)
Message-ID: <3B0D29E9.7AAF4638@sgi.com>
Date: Thu, 24 May 2001 10:34:01 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jason L Tibbitts III <tibbs@math.uh.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working
References: <200105241453.f4OErDi15051@jen.americas.sgi.com> <ufa3d9uix59.fsf@epithumia.math.uh.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Jason L Tibbitts III wrote:

> Red Hat shipped mount-2.11b as an erratum to 7.1.  It's on
> updates.redhat.com.

And Mandrake Cooker has 2.11c.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 08:34:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFY7A20109
	for linux-xfs-outgoing; Thu, 24 May 2001 08:34:07 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFY7F20106
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:34:07 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA12869
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:34:07 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1930732; Thu, 24 May 2001 10:32:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA89410; Thu, 24 May 2001 10:32:48 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OFZqL15113; Thu, 24 May 2001 10:35:52 -0500
Message-Id: <200105241535.f4OFZqL15113@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Jason L Tibbitts III <tibbs@math.uh.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: LABEL=.... not working 
In-Reply-To: Message from Jason L Tibbitts III <tibbs@math.uh.edu> 
   of "24 May 2001 10:28:50 CDT." <ufa3d9uix59.fsf@epithumia.math.uh.edu> 
Date: Thu, 24 May 2001 10:35:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> >>>>> "SL" == Steve Lord <lord@sgi.com> writes:
> 
> SL> I will see if I cannot get someone to provide an updated rpm which is
> SL> more xfs friendly.
> 
> Red Hat shipped mount-2.11b as an erratum to 7.1.  It's on
> updates.redhat.com.
> 
>  - J<

Thats good, the todo list is getting way too long!

Steve



From owner-linux-xfs@oss.sgi.com Thu May 24 08:43:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFhKT20270
	for linux-xfs-outgoing; Thu, 24 May 2001 08:43:20 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFh0F20265
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:43:01 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 98563CAC512
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:42:53 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 152xE7-0007pD-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:40:39 -0400
Date: Thu, 24 May 2001 11:40:39 -0400
To: linux-xfs@oss.sgi.com
Subject: Memory consumption
Message-ID: <20010524114039.A30044@chimesnet.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="XsQoSWH+UP9D9v3l"
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hey everyone,

Here's the scenario:

I was backing up an XFS fs to a tape.  I was not able to complete
the backup due to the high memory consumption of the xfs related caching.

It appears that every inode I touch is cached and once an inode is 
cache it never expires.

Attached is log of /proc/slabinfo during a untarring of an archive
onto a XFS fs.

--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=log

---------------------------------------
Snapshot 0 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        202    202     16    1    1    1 :  252  126
xfs_ili               28     28    136    1    1    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item          26     26    148    1    1    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state           0      0    340    0    0    1 :  124   62
xfs_trans             24     24    320    2    2    1 :  124   62
xfs_inode             48     48    468    6    6    1 :  124   62
xfs_btree_cur         28     28    140    1    1    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t            40     40    192    2    2    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache         2880   2880    480  360  360    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache        3210   3210    128  107  107    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache            9      9   4096    9    9    1 :   60   30
buffer_head        82280  82280     96 2057 2057    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32              452    452     32    4    4    1 :  252  126
---------------------------------------
Snapshot 10 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        328    404     16    2    2    1 :  252  126
xfs_ili             3192   3192    136  114  114    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            156    156    320   13   13    1 :  124   62
xfs_inode           3208   3208    468  401  401    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           160    160    192    8    8    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache         6032   6032    480  754  754    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache        6360   6360    128  212  212    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache            9      9   4096    9    9    1 :   60   30
buffer_head        89160  89160     96 2229 2229    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32             3729   3729     32   33   33    1 :  252  126
---------------------------------------
Snapshot 20 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        328    404     16    2    2    1 :  252  126
xfs_ili             6328   6328    136  226  226    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            156    156    320   13   13    1 :  124   62
xfs_inode           6336   6336    468  792  792    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           200    200    192   10   10    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache         9168   9168    480 1146 1146    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache        9510   9510    128  317  317    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache            9      9   4096    9    9    1 :   60   30
buffer_head        94582  94960     96 2371 2374    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32             6893   6893     32   61   61    1 :  252  126
---------------------------------------
Snapshot 30 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        404    404     16    2    2    1 :  252  126
xfs_ili             9604   9604    136  343  343    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans             94    156    320   12   13    1 :  124   62
xfs_inode           9632   9632    468 1204 1204    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           200    200    192   10   10    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        12456  12456    480 1557 1557    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       12810  12810    128  427  427    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache            9      9   4096    9    9    1 :   60   30
buffer_head       100320 100320     96 2508 2508    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            10057  10057     32   89   89    1 :  252  126
---------------------------------------
Snapshot 40 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        530    606     16    3    3    1 :  252  126
xfs_ili            11228  11228    136  401  401    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          11240  11240    468 1405 1405    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           200    200    192   10   10    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          226    226     32    2    2    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        14064  14064    480 1758 1758    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       14400  14400    128  480  480    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache            9      9   4096    9    9    1 :   60   30
buffer_head       103320 103320     96 2583 2583    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            11752  11752     32  104  104    1 :  252  126
---------------------------------------
Snapshot 50 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        530    606     16    3    3    1 :  252  126
xfs_ili            12684  12684    136  453  453    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          12704  12704    468 1588 1588    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           280    280    192   14   14    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        15536  15536    480 1942 1942    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       15900  15900    128  530  530    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       106180 107440     96 2657 2686    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            13221  13221     32  117  117    1 :  252  126
---------------------------------------
Snapshot 60 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        606    606     16    3    3    1 :  252  126
xfs_ili            14168  14168    136  506  506    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         182    182    148    7    7    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          14184  14184    468 1773 1773    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           280    280    192   14   14    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        17000  17000    480 2125 2125    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       17370  17370    128  579  579    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       109040 109040     96 2726 2726    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             42     42   4096   42   42    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            14577  14577     32  129  129    1 :  252  126
---------------------------------------
Snapshot 70 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        606    606     16    3    3    1 :  252  126
xfs_ili            16044  16044    136  573  573    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          16080  16080    468 2010 2010    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           320    320    192   16   16    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        18904  18904    480 2363 2363    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       19230  19230    128  641  641    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       112514 112640     96 2813 2816    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            16611  16611     32  147  147    1 :  252  126
---------------------------------------
Snapshot 80 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        606    606     16    3    3    1 :  252  126
xfs_ili            17948  17948    136  641  641    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          17976  17976    468 2247 2247    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           320    320    192   16   16    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        20800  20800    480 2600 2600    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       21150  21150    128  705  705    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       116400 116400     96 2910 2910    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            18532  18532     32  164  164    1 :  252  126
---------------------------------------
Snapshot 90 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        808    808     16    4    4    1 :  252  126
xfs_ili            20132  20132    136  719  719    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            130    192    320   16   16    1 :  124   62
xfs_inode          20160  20160    468 2520 2520    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        22976  22976    480 2872 2872    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       23340  23340    128  778  778    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       123800 123800     96 3095 3095    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20340  20340     32  180  180    1 :  252  126
---------------------------------------
Snapshot 100 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        808    808     16    4    4    1 :  252  126
xfs_ili            21560  21560    136  770  770    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   14   17    1 :  124   62
xfs_inode          21576  21576    468 2697 2697    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        24400  24400    480 3050 3050    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       24750  24750    128  825  825    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       135680 135680     96 3392 3392    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20327  20453     32  181  181    1 :  252  126
---------------------------------------
Snapshot 110 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        808    808     16    4    4    1 :  252  126
xfs_ili            22848  22848    136  816  816    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   16   17    1 :  124   62
xfs_inode          22864  22864    468 2858 2858    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        25688  25688    480 3211 3211    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       26010  26010    128  867  867    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       142786 143920     96 3579 3598    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20453  20453     32  181  181    1 :  252  126
---------------------------------------
Snapshot 120 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        934   1010     16    5    5    1 :  252  126
xfs_ili            24276  24276    136  867  867    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          24272  24272    468 3034 3034    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        27096  27096    480 3387 3387    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       27450  27450    128  915  915    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       148976 149480     96 3726 3737    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20453  20453     32  181  181    1 :  252  126
---------------------------------------
Snapshot 130 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        934   1010     16    5    5    1 :  252  126
xfs_ili            24360  24360    136  870  870    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   16   17    1 :  124   62
xfs_inode          24376  24376    468 3047 3047    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        27200  27200    480 3400 3400    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       27540  27540    128  918  918    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       149354 149480     96 3737 3737    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20453  20453     32  181  181    1 :  252  126
---------------------------------------
Snapshot 140 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        934   1010     16    5    5    1 :  252  126
xfs_ili            24472  24472    136  874  874    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          24480  24480    468 3060 3060    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           340    340    192   17   17    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          339    339     32    3    3    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        27296  27296    480 3412 3412    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       27630  27630    128  921  921    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       149814 151200     96 3746 3780    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 150 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist        934   1010     16    5    5    1 :  252  126
xfs_ili            25872  25872    136  924  924    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          25888  25888    468 3236 3236    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           400    400    192   20   20    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        28720  28720    480 3590 3590    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       29070  29070    128  969  969    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       156520 156520     96 3913 3913    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 160 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1010   1010     16    5    5    1 :  252  126
xfs_ili            28000  28000    136 1000 1000    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   12   17    1 :  124   62
xfs_inode          28024  28024    468 3503 3503    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           400    400    192   20   20    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        30848  30848    480 3856 3856    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       31200  31200    128 1040 1040    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       161640 161640     96 4041 4041    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 170 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1010   1010     16    5    5    1 :  252  126
xfs_ili            30688  30688    136 1096 1096    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         208    208    148    8    8    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   12   17    1 :  124   62
xfs_inode          30712  30712    468 3839 3839    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           400    400    192   20   20    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        33536  33536    480 4192 4192    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       33900  33900    128 1130 1130    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       170360 170360     96 4259 4259    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 180 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1010   1010     16    5    5    1 :  252  126
xfs_ili            31360  31360    136 1120 1120    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         234    234    148    9    9    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   17   17    1 :  124   62
xfs_inode          31384  31384    468 3923 3923    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           400    400    192   20   20    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        34208  34208    480 4276 4276    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       34560  34560    128 1152 1152    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       176400 176400     96 4410 4410    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 190 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            32620  32620    136 1165 1165    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         234    234    148    9    9    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          32616  32616    468 4077 4077    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           400    400    192   20   20    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        35432  35432    480 4429 4429    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       35790  35790    128 1193 1193    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       182354 182480     96 4559 4562    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 200 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            33740  33740    136 1205 1205    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         234    234    148    9    9    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   14   17    1 :  124   62
xfs_inode          33776  33776    468 4222 4222    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        36592  36592    480 4574 4574    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       36960  36960    128 1232 1232    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       190782 191160     96 4770 4779    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 210 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            34076  34076    136 1217 1217    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         234    234    148    9    9    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   17   17    1 :  124   62
xfs_inode          34112  34112    468 4264 4264    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        36936  36936    480 4617 4617    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       37290  37290    128 1243 1243    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       193120 193120     96 4828 4828    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 220 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            35056  35056    136 1252 1252    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   17   17    1 :  124   62
xfs_inode          35072  35072    468 4384 4384    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        37896  37896    480 4737 4737    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       38250  38250    128 1275 1275    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       200360 200360     96 5009 5009    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 230 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            36036  36036    136 1287 1287    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          36048  36048    468 4506 4506    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           480    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        38864  38864    480 4858 4858    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       39210  39210    128 1307 1307    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       208150 210040     96 5207 5251    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20566  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 240 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1212   1212     16    6    6    1 :  252  126
xfs_ili            37492  37492    136 1339 1339    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   12   17    1 :  124   62
xfs_inode          37488  37488    468 4686 4686    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           480    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        40304  40304    480 5038 5038    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       40650  40650    128 1355 1355    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       219040 219040     96 5476 5476    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 250 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1338   1414     16    7    7    1 :  252  126
xfs_ili            38052  38052    136 1359 1359    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   16   17    1 :  124   62
xfs_inode          38056  38056    468 4757 4757    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        40888  40888    480 5111 5111    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       41220  41220    128 1374 1374    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       223520 223520     96 5588 5588    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 260 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1338   1414     16    7    7    1 :  252  126
xfs_ili            38332  38332    136 1369 1369    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans             80    204    320   12   17    1 :  124   62
xfs_inode          38352  38352    468 4794 4794    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        41176  41176    480 5147 5147    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       41520  41520    128 1384 1384    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       225314 225440     96 5636 5636    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 270 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39284  39284    136 1403 1403    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   14   17    1 :  124   62
xfs_inode          39296  39296    468 4912 4912    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42120  42120    480 5265 5265    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42450  42450    128 1415 1415    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           10     10   4096   10   10    1 :   60   30
buffer_head       232760 232760     96 5819 5819    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1888   1888     64   32   32    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             43     43   4096   43   43    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20314  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 280 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   16   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       235450 236080     96 5889 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20566  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 290 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   14   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          452    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5869 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 300 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234694 236080     96 5873 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 310 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            142    204    320   14   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5868 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 320 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234694 236080     96 5868 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 330 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5871 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 340 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5871 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 350 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5871 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126
---------------------------------------
Snapshot 360 sec
---------------------------------------
slabinfo - version: 1.1 (SMP)
kmem_cache           102    102    232    6    6    1 :  252  126
fib6_nodes           226    226     32    2    2    1 :  252  126
ip6_dst_cache         40     40    192    2    2    1 :  252  126
ndisc_cache           30     30    128    1    1    1 :  252  126
xfs_chashlist       1414   1414     16    7    7    1 :  252  126
xfs_ili            39480  39480    136 1410 1410    1 :  252  126
xfs_ifork              0      0     56    0    0    1 :  252  126
xfs_efi_item           0      0    260    0    0    1 :  124   62
xfs_efd_item           0      0    260    0    0    1 :  124   62
xfs_buf_item         260    260    148   10   10    1 :  252  126
xfs_dabuf            202    202     16    1    1    1 :  252  126
xfs_da_state          22     22    340    2    2    1 :  124   62
xfs_trans            204    204    320   17   17    1 :  124   62
xfs_inode          39496  39496    468 4937 4937    1 :  124   62
xfs_btree_cur         56     56    140    2    2    1 :  252  126
xfs_bmap_free_item      0      0     16    0    0    1 :  252  126
page_buf_t           354    480    192   24   24    1 :  252  126
page_buf_reg_t        80     80     96    2    2    1 :  252  126
avl_object_t         226    226     32    2    2    1 :  252  126
avl_entry_t          326    452     32    4    4    1 :  252  126
tcp_tw_bucket         60     60    128    2    2    1 :  252  126
tcp_bind_bucket      226    226     32    2    2    1 :  252  126
tcp_open_request      80     80     96    2    2    1 :  252  126
inet_peer_cache        0      0     64    0    0    1 :  252  126
ip_fib_hash          113    113     32    1    1    1 :  252  126
ip_dst_cache          48     48    160    2    2    1 :  252  126
arp_cache             60     60    128    2    2    1 :  252  126
blkdev_requests     4120   4120     96  103  103    1 :  252  126
dnotify cache          0      0     20    0    0    1 :  252  126
file lock cache       84     84     92    2    2    1 :  252  126
fasync cache           0      0     16    0    0    1 :  252  126
uid_cache            226    226     32    2    2    1 :  252  126
skbuff_head_cache    360    360    160   15   15    1 :  252  126
sock                 152    152    928   38   38    1 :  124   62
inode_cache        42328  42328    480 5291 5291    1 :  124   62
bdev_cache           826    826     64   14   14    1 :  252  126
sigqueue              58     58    132    2    2    1 :  252  126
dentry_cache       42660  42660    128 1422 1422    1 :  252  126
dquot                  0      0     96    0    0    1 :  252  126
filp                 720    720     96   18   18    1 :  252  126
names_cache           12     12   4096   12   12    1 :   60   30
buffer_head       234568 236080     96 5871 5902    1 :  252  126
mm_struct             90     90    128    3    3    1 :  252  126
vm_area_struct      1947   1947     64   33   33    1 :  252  126
fs_cache             118    118     64    2    2    1 :  252  126
files_cache           54     54    416    6    6    1 :  124   62
signal_act            63     63   1312   21   21    1 :   60   30
size-131072(DMA)       0      0 131072    0    0   32 :    0    0
size-131072            0      1 131072    0    1   32 :    0    0
size-65536(DMA)        0      0  65536    0    0   16 :    0    0
size-65536             6      6  65536    6    6   16 :    0    0
size-32768(DMA)        0      0  32768    0    0    8 :    0    0
size-32768             0      1  32768    0    1    8 :    0    0
size-16384(DMA)        0      0  16384    0    0    4 :    0    0
size-16384             4      5  16384    4    5    4 :    0    0
size-8192(DMA)         0      0   8192    0    0    2 :    0    0
size-8192              0      1   8192    0    1    2 :    0    0
size-4096(DMA)         0      0   4096    0    0    1 :   60   30
size-4096             45     45   4096   45   45    1 :   60   30
size-2048(DMA)         0      0   2048    0    0    1 :   60   30
size-2048            122    122   2048   61   61    1 :   60   30
size-1024(DMA)         0      0   1024    0    0    1 :  124   62
size-1024            132    132   1024   33   33    1 :  124   62
size-512(DMA)          0      0    512    0    0    1 :  124   62
size-512             144    144    512   18   18    1 :  124   62
size-256(DMA)          0      0    256    0    0    1 :  252  126
size-256             390    390    256   26   26    1 :  252  126
size-128(DMA)          0      0    128    0    0    1 :  252  126
size-128             660    660    128   22   22    1 :  252  126
size-64(DMA)           0      0     64    0    0    1 :  252  126
size-64              236    236     64    4    4    1 :  252  126
size-32(DMA)           0      0     32    0    0    1 :  252  126
size-32            20440  20566     32  182  182    1 :  252  126

--XsQoSWH+UP9D9v3l--

From owner-linux-xfs@oss.sgi.com Thu May 24 08:48:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFmv420370
	for linux-xfs-outgoing; Thu, 24 May 2001 08:48:57 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFmuF20367
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:48:56 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA05987
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:48:57 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1932899; Thu, 24 May 2001 10:47:38 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA61047; Thu, 24 May 2001 10:47:38 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OFogK15845; Thu, 24 May 2001 10:50:42 -0500
Message-Id: <200105241550.f4OFogK15845@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Tom Carroll <tcarroll@chimesnet.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption 
In-Reply-To: Message from Tom Carroll <tcarroll@chimesnet.com> 
   of "Thu, 24 May 2001 11:40:39 EDT." <20010524114039.A30044@chimesnet.com> 
Date: Thu, 24 May 2001 10:50:42 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


> 
> Hey everyone,
> 
> Here's the scenario:
> 
> I was backing up an XFS fs to a tape.  I was not able to complete
> the backup due to the high memory consumption of the xfs related caching.
> 
> It appears that every inode I touch is cached and once an inode is 
> cache it never expires.
> 
> Attached is log of /proc/slabinfo during a untarring of an archive
> onto a XFS fs.
> 

This should be fixed in the cvs tree (within the last few days). How
old is your kernel.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 24 08:56:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OFus220550
	for linux-xfs-outgoing; Thu, 24 May 2001 08:56:54 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OFupF20547
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:56:51 -0700
Received: from madurai.engr.sgi.com ([163.154.5.75]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA04430
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 08:56:51 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA91513; Thu, 24 May 2001 08:50:44 -0700 (PDT)
Message-ID: <3B0D2EB0.CFF8F78B@sgi.com>
Date: Thu, 24 May 2001 08:54:24 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: KELEMEN Peter <fuji@elte.hu>
CC: linux-xfs@oss.sgi.com
Subject: Re: Parallel read performance crawls
References: <20010524162005.A26407@chiara.elte.hu>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

KELEMEN Peter wrote:
> 
> Dear XFS developers,
> 
> While a single bonnie++ benchmarks shows excellent[1] performance
> on my test machine, two parallel bonnie++s still excel in write
> performance, but crawl[2] in read performance.  What is the effect
> I'm seeing here?

FWIW, in the following, I see not only read performance drop with 2 bonnies,
but also re-write. Are you using the same disk as the target for
the 2 bonnies? If so, I would strongly suspect disk head contention.
Delayed allocation/writes in the block output case seem to have a positive
effect: clusters of writes are fairly large; there is no such clustering
at the higher level for reads (re-write is read+write iirc).

Can you target 2 different disks for the 2 bonnies?

ananth.

> 
> Peter
> 
> [1]
> Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> xfs_1            3G 11236  99 63619  51 17625  18 10133  88 58129  28  94.9   0
>                     ------Sequential Create------ --------Random Create--------
>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>     16:15000:12/512   785  18 25534 101  1378  29  1582  37 24665  99  1575  29
> 
> [2]
> Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> xfs_2_1          2G 10851  98 42060  38  5277   5  4261  37  4040   1  47.8   0
>                     ------Sequential Create------ --------Random Create--------
>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>     16:15000:12/512   313  10 22666  98   763  24   403  15 23511  99   182   7
> 
> Version 1.01b       ------Sequential Output------ --Sequential Input- --Random-
>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
> xfs_2_2          2G 10620  96 42498  39  5618   5  4296  37  3987   1  47.9   0
>                     ------Sequential Create------ --------Random Create--------
>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
> files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>     16:15000:12/512   307   9 20354  99   804  22   428  14 23531 100   176   6
> 
> --
>     .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
>  Kelemen Péter     /       \       /       \       /      fuji@elte.hu
> .+'         `+...+'         `+...+'         `+...+'         `+...+'

-- 
--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Thu May 24 09:01:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OG1as20648
	for linux-xfs-outgoing; Thu, 24 May 2001 09:01:36 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OG1ZF20645
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 09:01:35 -0700
Received: from madurai.engr.sgi.com ([163.154.5.75]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA05488
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 09:01:32 -0700 (PDT)
	mail_from (ananth@sgi.com)
Received: from sgi.com (sgigate.sgi.com [198.29.75.75]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA92243; Thu, 24 May 2001 08:54:56 -0700 (PDT)
Message-ID: <3B0D2FAC.18BF33AF@sgi.com>
Date: Thu, 24 May 2001 08:58:36 -0700
From: Rajagopal Ananthanarayanan <ananth@sgi.com>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10-1SGI_17 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Carroll <tcarroll@chimesnet.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption
References: <20010524114039.A30044@chimesnet.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Tom Carroll wrote:
> 
> Hey everyone,
> 
> Here's the scenario:
> 
> I was backing up an XFS fs to a tape.  I was not able to complete
> the backup due to the high memory consumption of the xfs related caching.
> 
> It appears that every inode I touch is cached and once an inode is
> cache it never expires.
> 
> Attached is log of /proc/slabinfo during a untarring of an archive
> onto a XFS fs.


Once again, recent changes in the development tree vastly
improve icache usage. What version of XFS are you using?

A general request: Can you please include the XFS version
(1.0+ISO?/RPM?/PATCH?, CVS+date-of-cvs-update, kernel version
if applicable) when reporting problems?

thanks!

ananth.

--------------------------------------------------------------------------
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--------------------------------------------------------------------------

From owner-linux-xfs@oss.sgi.com Thu May 24 09:36:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OGaDG21635
	for linux-xfs-outgoing; Thu, 24 May 2001 09:36:13 -0700
Received: from ex1.ncsa.uiuc.edu (ex1.ncsa.uiuc.edu [141.142.2.9])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OGaCF21632
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 09:36:12 -0700
Received: from mx1.ncsa.uiuc.edu (mx1.ncsa.uiuc.edu [141.142.2.8])
	by ex1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4OGaBb01184;
	Thu, 24 May 2001 11:36:11 -0500 (CDT)
X-Envelope-From: arnoldg@ncsa.uiuc.edu
Received: from osage.ncsa.uiuc.edu (osage.ncsa.uiuc.edu [141.142.2.56])
	by mx1.ncsa.uiuc.edu (8.11.0/8.11.0) with ESMTP id f4OGaBM20725;
	Thu, 24 May 2001 11:36:11 -0500 (CDT)
Date: Thu, 24 May 2001 11:36:10 -0500 (CDT)
From: Galen Arnold <arnoldg@ncsa.uiuc.edu>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: the file I forgot... 
In-Reply-To: <200105241104.f4OB49j09898@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105241113470.4337-100000@osage.ncsa.uiuc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve,

I've followed Keith's suggestions and added

	append="kdb=on,nmi_watchdog=2"

to lilo.conf and built a new kernel to go with it (kdb enabled).  I've run
tests this morning and get either : good iozone run, or lockup/hang
(3).  There were no more panics.  I'll try more tests after lunch, but
if nobody's got any more ideas, I'll throw in the towel and check back
in a couple weeks (maybe this bug will get fixed by then).

The xfs code is what I downloaded yesterday after lunch and my kernel is
2.4.4-xfs.

-Galen

> Hmm, I see there were a couple of followups on the xfs hang during run 4,
> I would really like to chase this one down if there is any chance of help
> from your end in following Keith Owens' suggestions. The tricky part here
> is determining if this is xfs itself, or xfs driving the linux vm system
> up the wall. xfs itself did not change in the read/write path between 2.4.2
> and 2.4.4, but the kernel does have relevent changes, and there are probably
> more to make yet.




From owner-linux-xfs@oss.sgi.com Thu May 24 09:59:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OGxxI22126
	for linux-xfs-outgoing; Thu, 24 May 2001 09:59:59 -0700
Received: from tacc.utexas.edu (IDENT:root@server.hpc.utexas.edu [129.116.206.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OGxwF22122
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 09:59:58 -0700
Received: from harrar.hpc.utexas.edu (harrar.hpc.utexas.edu [129.116.218.194])
	by tacc.utexas.edu (8.11.2/8.11.0) with ESMTP id f4OGxpk07123;
	Thu, 24 May 2001 11:59:51 -0500
Message-Id: <5.0.2.1.2.20010524114633.05cc31d0@127.0.0.1>
X-Sender: jones@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 24 May 2001 12:00:28 -0500
To: Tom Carroll <tcarroll@chimesnet.com>, linux-xfs@oss.sgi.com
From: "William L. Jones" <jones@hpc.utexas.edu>
Subject: Re: Memory consumption
In-Reply-To: <20010524114039.A30044@chimesnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

One modification that sgi could make  isto add a  dentry_operations struct to
delete the dentry at the first opportunity.   Their is an example
of this fs/pipe.c.   Some care would have to taken in openbyhandle since
you don't want to set the dentry_operations on a dentry that was made
by somebody else.

The d_delete function just returns 1 if the dentry should be celeted
on a  dput, assuming the references says you can.   The will causes
the dentry cash to remain small which fixes one memory problem.

The system will purge the dentry cach but it takes a while.

This will allow the system to purge the inode cache of unused inodes sooner
since there won't be a dentry referance to a inode.


At 11:40 AM 5/24/2001 -0400, Tom Carroll wrote:
>Hey everyone,
>
>Here's the scenario:
>
>I was backing up an XFS fs to a tape.  I was not able to complete
>the backup due to the high memory consumption of the xfs related caching.
>
>It appears that every inode I touch is cached and once an inode is
>cache it never expires.
>
>Attached is log of /proc/slabinfo during a untarring of an archive
>onto a XFS fs.


From owner-linux-xfs@oss.sgi.com Thu May 24 10:18:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OHIET22603
	for linux-xfs-outgoing; Thu, 24 May 2001 10:18:14 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OHIDF22600
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:18:13 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id B7624CAC512
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:18:07 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 152yiH-0007sU-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:15:53 -0400
Date: Thu, 24 May 2001 13:15:53 -0400
To: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption
Message-ID: <20010524131553.B30044@chimesnet.com>
References: <20010524114039.A30044@chimesnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <20010524114039.A30044@chimesnet.com>; from tcarroll@chimesnet.com on Thu, May 24, 2001 at 11:40:39AM -0400
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hey,

I just compiled linux-2.4-xfs 24/05/2001 16:30 GMT.

The large memory consumption issue still exists.  The previous
snapshot of /proc/slabinfo is accurate.

Any suggestions?
	Thanks in advance.

-Tom Carroll

From owner-linux-xfs@oss.sgi.com Thu May 24 10:40:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OHe8g23035
	for linux-xfs-outgoing; Thu, 24 May 2001 10:40:08 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OHe7F23032
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:40:07 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA04614
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:40:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1934923; Thu, 24 May 2001 12:38:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA96583; Thu, 24 May 2001 12:38:49 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OHfq617978; Thu, 24 May 2001 12:41:52 -0500
Message-Id: <200105241741.f4OHfq617978@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Tom Carroll <tcarroll@chimesnet.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption 
In-Reply-To: Message from Tom Carroll <tcarroll@chimesnet.com> 
   of "Thu, 24 May 2001 13:15:53 EDT." <20010524131553.B30044@chimesnet.com> 
Date: Thu, 24 May 2001 12:41:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hey,
> 
> I just compiled linux-2.4-xfs 24/05/2001 16:30 GMT.
> 
> The large memory consumption issue still exists.  The previous
> snapshot of /proc/slabinfo is accurate.
> 
> Any suggestions?
> 	Thanks in advance.
> 
> -Tom Carroll

OK, if the machine survives the failing dump process does the filesystem
unmount afterwards? I will go an run some quick tests, but it smells of
a reference count leak - dump uses a backdoor open function rather
than pathnames, this is probably where the problem is.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 24 10:51:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OHplv23218
	for linux-xfs-outgoing; Thu, 24 May 2001 10:51:47 -0700
Received: from webmail.chimesnet.com (postfix@mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OHplF23215
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:51:47 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 686F5CAC512
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:51:46 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 152zEp-0007ts-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:49:31 -0400
Date: Thu, 24 May 2001 13:49:31 -0400
To: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption
Message-ID: <20010524134931.C30044@chimesnet.com>
References: <tcarroll@chimesnet.com> <200105241741.f4OHfq617978@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <200105241741.f4OHfq617978@jen.americas.sgi.com>; from lord@sgi.com on Thu, May 24, 2001 at 12:41:52PM -0500
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It is not just a dump.  This behavior is evident within most 
operations that touch the filesystem.

Examples include compiling, untarring, samba, etc.

-Tom Carroll

On Thu, May 24, 2001 at 12:41:52PM -0500, Steve Lord wrote:
> > Hey,
> > 
> > I just compiled linux-2.4-xfs 24/05/2001 16:30 GMT.
> > 
> > The large memory consumption issue still exists.  The previous
> > snapshot of /proc/slabinfo is accurate.
> > 
> > Any suggestions?
> > 	Thanks in advance.
> > 
> > -Tom Carroll
> 
> OK, if the machine survives the failing dump process does the filesystem
> unmount afterwards? I will go an run some quick tests, but it smells of
> a reference count leak - dump uses a backdoor open function rather
> than pathnames, this is probably where the problem is.
> 
> Steve
> 
> 
> 

From owner-linux-xfs@oss.sgi.com Thu May 24 10:52:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OHqmi23252
	for linux-xfs-outgoing; Thu, 24 May 2001 10:52:48 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OHqkF23249
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:52:47 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA726430
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 19:52:44 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA1929629; Thu, 24 May 2001 12:51:27 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA09041; Thu, 24 May 2001 12:51:27 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OHsTC18313; Thu, 24 May 2001 12:54:29 -0500
Message-Id: <200105241754.f4OHsTC18313@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: the file I forgot... 
In-Reply-To: Message from Galen Arnold <arnoldg@ncsa.uiuc.edu> 
   of "Thu, 24 May 2001 11:36:10 CDT." <Pine.LNX.4.33.0105241113470.4337-100000@osage.ncsa.uiuc.edu> 
Date: Thu, 24 May 2001 12:54:29 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Steve,
> 
> I've followed Keith's suggestions and added
> 
> 	append="kdb=on,nmi_watchdog=2"
> 
> to lilo.conf and built a new kernel to go with it (kdb enabled).  I've run
> tests this morning and get either : good iozone run, or lockup/hang
> (3).  There were no more panics.  I'll try more tests after lunch, but
> if nobody's got any more ideas, I'll throw in the towel and check back
> in a couple weeks (maybe this bug will get fixed by then).
> 
> The xfs code is what I downloaded yesterday after lunch and my kernel is
> 2.4.4-xfs.

If you get the hang, can you get kdb to respond? If you are using a
serial console it is Ctrl-A if you are on a graphical console it is
the break key (do not run X, have the real console displayed, not the
virtual one X runs in).

If the nmi watchdog did not go off, then it is possible the cpus are just
spinning trying to free memory somewhere, looking for processes which are
on the cpu in the ps display (1 in the [*] column of that output). You can
use bt to get a stack of what is on the current cpu, and btp <pid> to
trace other processes. It you have a serial console and can capture the
output, the output of the bta command would be good to see.

Rik Van Reil who does a lot of the linux VM work just posted some changes
this morning which fix a couple of out of memory deadlocks, I may end up
asking you to try these.

Steve


> 
> -Galen
> 
> > Hmm, I see there were a couple of followups on the xfs hang during run 4,
> > I would really like to chase this one down if there is any chance of help
> > from your end in following Keith Owens' suggestions. The tricky part here
> > is determining if this is xfs itself, or xfs driving the linux vm system
> > up the wall. xfs itself did not change in the read/write path between 2.4.2
> > and 2.4.4, but the kernel does have relevent changes, and there are probabl
> y
> > more to make yet.
> 
> 



From owner-linux-xfs@oss.sgi.com Thu May 24 10:53:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OHrat23280
	for linux-xfs-outgoing; Thu, 24 May 2001 10:53:36 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OHrZF23277
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 10:53:36 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OHrWF07521;
	Thu, 24 May 2001 12:53:32 -0500 (CDT)
Message-ID: <3B0D4B47.34CD9E14@sgi.com>
Date: Thu, 24 May 2001 12:56:23 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Saarinen <juha@saarinen.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
References: <LGECJLHBGAPMGAJFMAFIIECKCAAA.juha@saarinen.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

What were you doing when this happened?

This comes from xfs_create() when xfs_dir_lookup() fails with ENOENT. 
I'll have to look more closely to see exactly what's going on...

-Eric


Juha Saarinen wrote:
> 
> >From dmesg:
> 
> xfs_create looping, dir ino 0x40089, ino 0x4c240, ide0(3,7)
 
> -- Juha

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 11:07:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OI7JC23518
	for linux-xfs-outgoing; Thu, 24 May 2001 11:07:19 -0700
Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OI7EF23515
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:07:14 -0700
Received: by chiara.elte.hu (Postfix, from userid 17000)
	id 6DE231FC7; Thu, 24 May 2001 20:07:11 +0200 (CEST)
Date: Thu, 24 May 2001 20:07:10 +0200
From: KELEMEN Peter <fuji@elte.hu>
To: Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Parallel read performance crawls
Message-ID: <20010524200710.A27566@chiara.elte.hu>
Reply-To: KELEMEN Peter <fuji@elte.hu>
References: <20010524162005.A26407@chiara.elte.hu> <3B0D2EB0.CFF8F78B@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: <3B0D2EB0.CFF8F78B@sgi.com>; from ananth@sgi.com on Thu, May 24, 2001 at 08:54:24AM -0700
Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary
X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20
X-GPG-Fingerprint: D402 4AF3 7488 165B CC34  4147 7F0C D922 EE4C 26E8
X-PGP-KeyID: 1024/45F83E45 1998/04/04
X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD  6D AA B5 8A D6 03 0F BF
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Rajagopal Ananthanarayanan (ananth@sgi.com) [20010524 08:54]:

> FWIW, in the following, I see not only read performance drop
> with 2 bonnies, but also re-write. Are you using the same disk
> as the target for the 2 bonnies? If so, I would strongly suspect
> disk head contention.  Delayed allocation/writes in the block
> output case seem to have a positive effect: clusters of writes
> are fairly large; there is no such clustering at the higher
> level for reads (re-write is read+write iirc).

I'm using a 80G LVM volume striped across two disks.  ReiserFS
shows 18M(write)/8M(read) performance when run in parallel.  I
will try to restructure my LVM setup.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \       /      fuji@elte.hu
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From owner-linux-xfs@oss.sgi.com Thu May 24 11:08:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OI8KI23598
	for linux-xfs-outgoing; Thu, 24 May 2001 11:08:20 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OI8JF23595
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:08:19 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64230 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S31634AbREXSIC>;
	Thu, 24 May 2001 20:08:02 +0200
Message-Id: <4.3.2.7.2.20010524200158.0390c988@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 20:08:07 +0200
To: "Chris Pascoe" <c.pascoe@csee.uq.edu.au>, <linux-xfs@oss.sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: Crashes in various ext2 functions while running
  xfstest/check
In-Reply-To: <002101c0e406$25ef4b70$47426682@csee.uq.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:01 24-5-2001 +1000, Chris Pascoe wrote:
>Hi,
>
>I'm running the XFS stress tests on a Dell Poweredge 4400 running.  The
>kernel is the current CVS one (as at today) but the problem persists over
>several weeks of compilations.  Local modifications to the kernel are the
>addition of the module for the AACRAID Perc 3/Di RAID controller and the
>e1000 driver from Intel for the ethernet card.  Highmem support is enabled
>(the machine has 1GB of RAM).  The kernels are compiled with the kgcc
>package from Redhat 7.0 (egcs
>2.91.66) or the RH7.1 gcc (2.96-81) - it makes no difference.

We have 2 Dell Poweredge 2450 machines that came with the Adaptec Raid 
controller and have replaced those controllers with AMI megaraid 
controllers instead.
Contact your local dell contact for a refund when purchasing the other 
controllers.

The driver for the Adaptec controllers is a port of the NT driver to 
solaris 8 to Linux.
IMNHO the adaptec controller is OK but drivers are _NOT_ and should thus be 
avoided.
The drivers worked OK on 2.2 kernels but the 2.4 port is still in it's infants.

I can't speak for the Intel e1000 drivers but I thought those were OK.

Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 11:28:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OISVT23934
	for linux-xfs-outgoing; Thu, 24 May 2001 11:28:31 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OISUF23931
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:28:30 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4OIQHP01977;
	Thu, 24 May 2001 13:26:17 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 24 May 2001 13:26:17 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Tom Carroll <tcarroll@chimesnet.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Memory consumption
In-Reply-To: <20010524134931.C30044@chimesnet.com>
Message-ID: <Pine.LNX.4.33.0105241323410.1903-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

A question to ask here is does type of hardware fit into this equation? As
in :

SMP vs Uni
SCSI vs IDE
# of volumes/drives etc.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 24 May 2001, Tom Carroll wrote:

> It is not just a dump.  This behavior is evident within most
> operations that touch the filesystem.
>
> Examples include compiling, untarring, samba, etc.
>
> -Tom Carroll
>
> On Thu, May 24, 2001 at 12:41:52PM -0500, Steve Lord wrote:
> > > Hey,
> > >
> > > I just compiled linux-2.4-xfs 24/05/2001 16:30 GMT.
> > >
> > > The large memory consumption issue still exists.  The previous
> > > snapshot of /proc/slabinfo is accurate.
> > >
> > > Any suggestions?
> > > 	Thanks in advance.
> > >
> > > -Tom Carroll
> >
> > OK, if the machine survives the failing dump process does the filesystem
> > unmount afterwards? I will go an run some quick tests, but it smells of
> > a reference count leak - dump uses a backdoor open function rather
> > than pathnames, this is probably where the problem is.
> >
> > Steve
> >
> >
> >
>


From owner-linux-xfs@oss.sgi.com Thu May 24 11:41:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OIfAD24167
	for linux-xfs-outgoing; Thu, 24 May 2001 11:41:10 -0700
Received: from webmail.chimesnet.com (mail001.level3.chc-chimes.com [63.211.16.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OIf9F24164
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:41:09 -0700
Received: from orbis (pixnat.chc-chimes.com [216.28.46.20])
	by webmail.chimesnet.com (Postfix) with ESMTP id 6490FCAC513
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:41:08 -0400 (EDT)
Received: from tcarroll by orbis with local (Exim 3.22 #1 (Debian))
	id 15300b-0007wq-00
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:38:53 -0400
Date: Thu, 24 May 2001 14:38:53 -0400
To: linux-xfs@oss.sgi.com
Subject: Re: Memory consumption
Message-ID: <20010524143853.A30513@chimesnet.com>
References: <20010524134931.C30044@chimesnet.com> <Pine.LNX.4.33.0105241323410.1903-100000@UberGeek.coremetrics.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
In-Reply-To: <Pine.LNX.4.33.0105241323410.1903-100000@UberGeek.coremetrics.com>; from austin@coremetrics.com on Thu, May 24, 2001 at 01:26:17PM -0500
From: Tom Carroll <tcarroll@chimesnet.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The system:
SMP
IDE

2x750 MHz IA32
1GB RAM

ServerWorks IDE (osb4)
IBM 60GB ATA100

One drive.  Here's my partition map

major minor  #blocks  name

   3     0   60051600 hda    
   3     1      56196 hda1 		ext2
   3     2    1052257 hda2		ext2
   3     3   58942485 hda3		LVM
  58     0    2097152 lvma		swap
  58     1   18874368 lvmb		xfs		
  58     2    4194304 lvmc		ext2
  58     3    2097152 lvmd		ext2
  58     4    4194304 lvme      xfs
  58     5   27484160 lvmf		xfs

On Thu, May 24, 2001 at 01:26:17PM -0500, Austin Gonyou wrote:
> A question to ask here is does type of hardware fit into this equation? As
> in :
> 
> SMP vs Uni
> SCSI vs IDE
> # of volumes/drives etc.
> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Thu, 24 May 2001, Tom Carroll wrote:
> 
> > It is not just a dump.  This behavior is evident within most
> > operations that touch the filesystem.
> >
> > Examples include compiling, untarring, samba, etc.
> >
> > -Tom Carroll
> >
> > On Thu, May 24, 2001 at 12:41:52PM -0500, Steve Lord wrote:
> > > > Hey,
> > > >
> > > > I just compiled linux-2.4-xfs 24/05/2001 16:30 GMT.
> > > >
> > > > The large memory consumption issue still exists.  The previous
> > > > snapshot of /proc/slabinfo is accurate.
> > > >
> > > > Any suggestions?
> > > > 	Thanks in advance.
> > > >
> > > > -Tom Carroll
> > >
> > > OK, if the machine survives the failing dump process does the filesystem
> > > unmount afterwards? I will go an run some quick tests, but it smells of
> > > a reference count leak - dump uses a backdoor open function rather
> > > than pathnames, this is probably where the problem is.
> > >
> > > Steve
> > >
> > >
> > >
> >
> 
> 

From owner-linux-xfs@oss.sgi.com Thu May 24 11:45:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OIjpP24313
	for linux-xfs-outgoing; Thu, 24 May 2001 11:45:51 -0700
Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OIjnF24307
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:45:50 -0700
Received: by chiara.elte.hu (Postfix, from userid 17000)
	id 383DC1FC8; Thu, 24 May 2001 20:45:48 +0200 (CEST)
Date: Thu, 24 May 2001 20:45:47 +0200
From: KELEMEN Peter <fuji@elte.hu>
To: Rajagopal Ananthanarayanan <ananth@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Parallel read performance crawls
Message-ID: <20010524204546.A27776@chiara.elte.hu>
Reply-To: KELEMEN Peter <fuji@elte.hu>
References: <20010524162005.A26407@chiara.elte.hu> <3B0D2EB0.CFF8F78B@sgi.com> <20010524200710.A27566@chiara.elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.3.17i
In-Reply-To: <20010524200710.A27566@chiara.elte.hu>; from fuji@elte.hu on Thu, May 24, 2001 at 08:07:10PM +0200
Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary
X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20
X-GPG-Fingerprint: D402 4AF3 7488 165B CC34  4147 7F0C D922 EE4C 26E8
X-PGP-KeyID: 1024/45F83E45 1998/04/04
X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD  6D AA B5 8A D6 03 0F BF
X-Comment: Personal opinion.  Paragraphs might have been reformatted.
X-Copyright: Forwarding or publishing without permission is prohibited.
X-Accept-Language: hu,en
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

* Kelemen Péter (fuji@elte.hu) [20010524 20:07]:

> I'm using a 80G LVM volume striped across two disks.

--- Distribution of logical volume on 2 physical volumes  ---
PV Name                                PE on PV     reads      writes
/dev/ide/host2/bus0/target0/lun0/part1 320          7182730    8829885
/dev/ide/host2/bus1/target1/lun0/part1 320          7182371    8826433

The reads/writes are evenly distributed between the two disks.

Peter

-- 
    .+'''+.         .+'''+.         .+'''+.         .+'''+.         .+''
 Kelemen Péter     /       \       /       \       /      fuji@elte.hu
.+'         `+...+'         `+...+'         `+...+'         `+...+'

From owner-linux-xfs@oss.sgi.com Thu May 24 11:52:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OIqs925618
	for linux-xfs-outgoing; Thu, 24 May 2001 11:52:54 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OIqrF25613
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:52:54 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64248 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S31993AbREXSwr>;
	Thu, 24 May 2001 20:52:47 +0200
Message-Id: <4.3.2.7.2.20010524204643.039126c0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 20:52:51 +0200
To: linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: 1.0 Installer
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The installer seems to barf when trying to Upgrade a installation of a 
system where the XFS filesystem is not clean.
I had to boot the machine another time to recover the filesystem to a clean 
state before I could try to upgrade it.

It first says that it will to upgrade the linux system on hda6 Anaconda 
then throws me a error that there is no linux system on hda6 (which is the 
root fs).

Although it may be hardware issues, the box is acting funny every now and 
then. It should not produce this error, but recover the fs on mount during 
install, would it?

Just checking if anyone else has seen this behaviour.
Does anyone know if this also happens when the ext2 fs is dirty or not?

Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 11:59:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OIxSZ25767
	for linux-xfs-outgoing; Thu, 24 May 2001 11:59:28 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OIxRF25764
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 11:59:27 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA717226
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 20:59:24 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1927642 for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:58:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA00849 for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:58:07 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4OJ1Ao18437; Thu, 24 May 2001 14:01:10 -0500
Message-Id: <200105241901.f4OJ1Ao18437@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: Backlog on the list....
Date: Thu, 24 May 2001 14:01:10 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,

If you are following the linux-xfs list you have probably noticed there are
lots of people asking questions, reporting problems etc. I always try to be
responsive, but at the moment, the incoming rate is a lot higher than we 
have the bandwidth to cope with. So I would be grateful if people out on
the list can help each other out when it comes to configuration questions and
the like so we can get our heads down in the problem fixing end of the 
business.

Thanks

   Steve





From owner-linux-xfs@oss.sgi.com Thu May 24 12:13:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OJD9p27263
	for linux-xfs-outgoing; Thu, 24 May 2001 12:13:09 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OJD8F27260
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 12:13:09 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OJD7B28642;
	Thu, 24 May 2001 14:13:07 -0500 (CDT)
Message-ID: <3B0D5DEE.54EC5532@sgi.com>
Date: Thu, 24 May 2001 14:15:58 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: 1.0 Installer
References: <4.3.2.7.2.20010524204643.039126c0@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:
> 
> The installer seems to barf when trying to Upgrade a installation of a
> system where the XFS filesystem is not clean.
> I had to boot the machine another time to recover the filesystem to a clean
> state before I could try to upgrade it.

Hm, we didn't anticipate this scenario.  :)  FWIW, the same thing
happens under ext2, if it detects that a filesystem was not cleanly
unmounted, the install won't continue.
 
> It first says that it will to upgrade the linux system on hda6 Anaconda
> then throws me a error that there is no linux system on hda6 (which is the
> root fs).
> 
> Although it may be hardware issues, the box is acting funny every now and
> then. It should not produce this error, but recover the fs on mount during
> install, would it?

I'm not sure if mount returns differently based on whether or not it
went through recovery... if so, anaconda may be interpreting this as a
problem.  I'd have to look into it... but for now, just run an upgrade
only on clean systems, I guess.
 
You say it's acting funny, do you mean _after_ the install?

> Just checking if anyone else has seen this behaviour.
> Does anyone know if this also happens when the ext2 fs is dirty or not?

Yep, the installer will ask you to reboot & fix the problem.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 12:43:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OJhdk27948
	for linux-xfs-outgoing; Thu, 24 May 2001 12:43:39 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OJhcF27945
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 12:43:38 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64308 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S32428AbREXTn1>;
	Thu, 24 May 2001 21:43:27 +0200
Message-Id: <4.3.2.7.2.20010524212751.037873b8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 21:43:17 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: 1.0 Installer
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B0D5DEE.54EC5532@sgi.com>
References: <4.3.2.7.2.20010524204643.039126c0@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:15 24-5-2001 -0500, Eric Sandeen wrote:
>Seth Mos wrote:
> >
> > The installer seems to barf when trying to Upgrade a installation of a
> > system where the XFS filesystem is not clean.
> > I had to boot the machine another time to recover the filesystem to a clean
> > state before I could try to upgrade it.
>
>Hm, we didn't anticipate this scenario.  :)  FWIW, the same thing
>happens under ext2, if it detects that a filesystem was not cleanly
>unmounted, the install won't continue.

Uhm, that shouldn't happen with a journaling fs :D

> > It first says that it will to upgrade the linux system on hda6 Anaconda
> > then throws me a error that there is no linux system on hda6 (which is the
> > root fs).
> >
> > Although it may be hardware issues, the box is acting funny every now and
> > then. It should not produce this error, but recover the fs on mount during
> > install, would it?
>
>I'm not sure if mount returns differently based on whether or not it
>went through recovery... if so, anaconda may be interpreting this as a
>problem.  I'd have to look into it... but for now, just run an upgrade
>only on clean systems, I guess.

I will, it's one for the archives.

>You say it's acting funny, do you mean _after_ the install?

Uhm no, before, during and after. Is that the right answer ;)
Seriously, I have seen the installer die with signal 11 when the cd drive 
was slave on the 2nd channel.
fsck.ext2 produced a signal 11 during boot when the /boot was clean.
It produced a signal 11 and a 4 during some other attempts after starting 
anaconda.

I will run memtest when it's upgraded.
The machine was a redhat 7.0 system that was installed at that time with 
the 2.4.0-test5 installer. And that one went fine :-)

The kernel that I had compiled on the machine does not misbehave that often.

It's weird though, I tried to make the machine fall over by compiling the 
kernel a 1000 times with make -j20 but it completed succesfully.
So for some reason the tide here seems to affect the stability of the machine.

> > Just checking if anyone else has seen this behaviour.
> > Does anyone know if this also happens when the ext2 fs is dirty or not?
>
>Yep, the installer will ask you to reboot & fix the problem.

It did not ask me to reboot and fix the problem, it just reported there was 
no linux installation on /dev/hda6 and decided that enough was enough.

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 13:06:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OK6iv28501
	for linux-xfs-outgoing; Thu, 24 May 2001 13:06:44 -0700
Received: from linux.compucomis.net (IDENT:postfix@[216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OK6iF28498
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:06:44 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id 60CA51397C; Thu, 24 May 2001 16:06:43 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by linux.compucomis.net (Postfix) with ESMTP
	id 5DCA31397B; Thu, 24 May 2001 16:06:43 -0400 (EDT)
Date: Thu, 24 May 2001 16:06:43 -0400 (EDT)
From: Mike Burger <mburger@compucomis.net>
To: Seth Mos <knuffie@xs4all.nl>
Cc: Eric Sandeen <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: Re: 1.0 Installer
In-Reply-To: <4.3.2.7.2.20010524212751.037873b8@pop.xs4all.nl>
Message-ID: <Pine.LNX.4.33.0105241605410.17475-100000@linux.compucomis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001, Seth Mos wrote:

> At 14:15 24-5-2001 -0500, Eric Sandeen wrote:
> >Seth Mos wrote:
> > >
> > > The installer seems to barf when trying to Upgrade a installation of a
> > > system where the XFS filesystem is not clean.
> > > I had to boot the machine another time to recover the filesystem to a clean
> > > state before I could try to upgrade it.
> >
> >Hm, we didn't anticipate this scenario.  :)  FWIW, the same thing
> >happens under ext2, if it detects that a filesystem was not cleanly
> >unmounted, the install won't continue.
>
> Uhm, that shouldn't happen with a journaling fs :D

Why not?  The installer doesn't invoke the cleanup routines...it just sees
a filesystem that was not cleanly unmounted.



From owner-linux-xfs@oss.sgi.com Thu May 24 13:19:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OKJmS28784
	for linux-xfs-outgoing; Thu, 24 May 2001 13:19:48 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OKJiF28781
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:19:44 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64668 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S33865AbREXUTd>;
	Thu, 24 May 2001 22:19:33 +0200
Message-Id: <4.3.2.7.2.20010524221224.03942780@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 22:19:39 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: 1.0 Installer
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B0D5DEE.54EC5532@sgi.com>
References: <4.3.2.7.2.20010524204643.039126c0@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 14:15 24-5-2001 -0500, Eric Sandeen wrote:
>Hm, we didn't anticipate this scenario.  :)  FWIW, the same thing
>happens under ext2, if it detects that a filesystem was not cleanly
>unmounted, the install won't continue.

Confirmed

 >> Just checking if anyone else has seen this behaviour.
> > Does anyone know if this also happens when the ext2 fs is dirty or not?
>
>Yep, the installer will ask you to reboot & fix the problem.

Indeed, it does ask you this.
First try got me a sig11 second try gave me the warning box that there is a 
unchecked fs (probably boot which is ext2) and asks me to fix it first.

I don't know what is wrong with the box or the CD. it keeps barfing with 
sig11 and oopses. I don't get it. If I boot the selfcompiled kernel (2.4.2 
based but then from CVS instead of the redhat kernel it doesn't fall over. 
Not even under serious load.

FYI it's a P1 233mmx with 64MB ram and a 20GB IDE disk.
I can send you the dmesg if you are interested.

Bye
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 13:40:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OKeii30306
	for linux-xfs-outgoing; Thu, 24 May 2001 13:40:44 -0700
Received: from hotmail.com (f94.law4.hotmail.com [216.33.149.94])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OKehF30303
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:40:43 -0700
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 24 May 2001 13:40:38 -0700
Received: from 216.191.43.227 by lw4fd.law4.hotmail.msn.com with HTTP;	Thu, 24 May 2001 20:40:38 GMT
X-Originating-IP: [216.191.43.227]
From: "Michael Sowka" <msowka@hotmail.com>
To: linux-xfs@oss.sgi.com
Subject: CVS Recompile ala RH 7.1 ...
Date: Thu, 24 May 2001 20:40:38 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F94gtZKpjE5aHaZVrDs00005376@hotmail.com>
X-OriginalArrivalTime: 24 May 2001 20:40:38.0381 (UTC) FILETIME=[CA6B89D0:01C0E491]
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Taking into consideration Steve's recent post I will make this short and 
sweet: ( hoping that makes a difference.. :) )...
I've succesfully loaded the RH7.1 XFS 1.0 and have been running since it's 
release... I LOVE IT! Now I want to recompile with imon (yet another great 
SGI piece of code... ) and I figured I'd get the latest XFS kernel from the 
CVS... now... being not tooo well hardware oriented I would like to know if 
there is a way I can applie the kernel CONFIGS from the RH 1.0 release such 
that I don't have to muddle through the 1000 questions during make config (I 
don't wanna play with make xconfig either) I just want to be able to apply 
the ?config? file from the RH7.1 XFS 1.0 release... (did that include the 
ide scsi emulation or is that detected during install and installed as 
module? )
Damn... this was far from short and sweet.... sorry.
Thanx for any comments and help in general in advance...
Mike
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


From owner-linux-xfs@oss.sgi.com Thu May 24 13:55:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OKt3P30679
	for linux-xfs-outgoing; Thu, 24 May 2001 13:55:03 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OKt2F30676
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:55:02 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64755 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S34220AbREXUyn>;
	Thu, 24 May 2001 22:54:43 +0200
Message-Id: <4.3.2.7.2.20010524222139.0394e2d0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 22:54:49 +0200
To: Mike Burger <mburger@compucomis.net>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: 1.0 Installer
Cc: Eric Sandeen <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
In-Reply-To: <Pine.LNX.4.33.0105241605410.17475-100000@linux.compucomis.
 net>
References: <4.3.2.7.2.20010524212751.037873b8@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 16:06 24-5-2001 -0400, Mike Burger wrote:
>On Thu, 24 May 2001, Seth Mos wrote:
>
> > At 14:15 24-5-2001 -0500, Eric Sandeen wrote:
> > >Seth Mos wrote:
> > > >
> > > > The installer seems to barf when trying to Upgrade a installation of a
> > > > system where the XFS filesystem is not clean.
> > > > I had to boot the machine another time to recover the filesystem to 
> a clean
> > > > state before I could try to upgrade it.
> > >
> > >Hm, we didn't anticipate this scenario.  :)  FWIW, the same thing
> > >happens under ext2, if it detects that a filesystem was not cleanly
> > >unmounted, the install won't continue.
> >
> > Uhm, that shouldn't happen with a journaling fs :D
>
>Why not?  The installer doesn't invoke the cleanup routines...it just sees
>a filesystem that was not cleanly unmounted.

How can one "see" a fs that is not cleanly unmounted? I mean what does 
anaconda do to check for that?
With ext2 you get a warning, journaling fs on the other hand know what to do.
It would be great if it could just recover the fs on mount and continue.

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 13:59:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OKxuM00564
	for linux-xfs-outgoing; Thu, 24 May 2001 13:59:56 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OKxtF00525
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 13:59:55 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:64756 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S34316AbREXU7s>;
	Thu, 24 May 2001 22:59:48 +0200
Message-Id: <4.3.2.7.2.20010524225455.0394ce30@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Thu, 24 May 2001 22:59:54 +0200
To: Eric Sandeen <sandeen@sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: 1.0 Installer
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <4.3.2.7.2.20010524221224.03942780@pop.xs4all.nl>
References: <3B0D5DEE.54EC5532@sgi.com>
 <4.3.2.7.2.20010524204643.039126c0@pop.xs4all.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 22:19 24-5-2001 +0200, Seth Mos wrote:
I don't know what is wrong with the box or the CD. it keeps barfing with 
sig11 and oopses. I don't get it. If I boot the selfcompiled kernel (2.4.2 
based but then from CVS instead of the redhat kernel it doesn't fall over. 
Not even under serious load.

>FYI it's a P1 233mmx with 64MB ram and a 20GB IDE disk.
>I can send you the dmesg if you are interested.

I ripped out one memory Dimm to see if it helps.
It looks like it is doing better now.

If so it is amazing that didn't crash before.
It had been running more then 2 weeks non stop without any errors or oopses.

It looks like I have just been lucky. The people that would originally get 
the system will probably be not amused by the fact that their hardware 
supplier ships them crap.

I'm really glad I am not supposed to pay for this system. I just have to 
configure it to make it suit their needs.

Bye
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Thu May 24 14:02:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OL24L04917
	for linux-xfs-outgoing; Thu, 24 May 2001 14:02:04 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OL21F04910
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:02:01 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id RAA25677;
	Thu, 24 May 2001 17:01:59 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Thu, 24 May 2001 17:01:59 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: Michael Sowka <msowka@hotmail.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: CVS Recompile ala RH 7.1 ...
In-Reply-To: <F94gtZKpjE5aHaZVrDs00005376@hotmail.com>
Message-ID: <Pine.LNX.4.30.0105241658340.1357-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001 at 8:40pm, Michael Sowka wrote

> CVS... now... being not tooo well hardware oriented I would like to know if
> there is a way I can applie the kernel CONFIGS from the RH 1.0 release such
> that I don't have to muddle through the 1000 questions during make config (I
> don't wanna play with make xconfig either) I just want to be able to apply
> the ?config? file from the RH7.1 XFS 1.0 release... (did that include the
> ide scsi emulation or is that detected during install and installed as
> module? )

The config files are in /usr/src/linux-2.4.2/configs (if you installed
the kernel-source RPM).  Download the new kernel source, and type (I
think) 'make oldconfig', and tell it which config file to use.
Alternatively, type 'make xconfig', click "Load config file", and point it
at your config file of choice.  Done.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


From owner-linux-xfs@oss.sgi.com Thu May 24 14:10:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OLAiS05236
	for linux-xfs-outgoing; Thu, 24 May 2001 14:10:44 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OLAhF05233
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:10:43 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1532N7-0007sy-00; Fri, 25 May 2001 09:10:17 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Eric Sandeen" <sandeen@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Fri, 25 May 2001 09:09:45 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIGECMCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B0D4B47.34CD9E14@sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: What were you doing when this happened?

I don't know, to be honest. Looks like it might have happened at boot-up, as
the entries are intertwined with the network card and parallel port ones:

parport0: assign_addrs: aa5500ff(38)
xfs_create looping, dir ino 0x40089, ino 0x4c240, ide0(3,7)

Linux Tulip driver version 0.9.14e (April 20, 2001)
tulip0:  EEPROM default media type Autosense.
tulip0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
00:12.0:  MII transceiver #1 config 3000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xec00, 00:C0:F0:4C:DD:DB, IRQ 18.
xfs_create looping, dir ino 0x40089, ino 0x4c241, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x14008d, ide0(3,7)

eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
xfs_create looping, dir ino 0x140081, ino 0x14008e, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c243, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c244, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c247, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c248, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c249, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c24a, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x140094, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c254, ide0(3,7)


-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 14:44:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OLiVf08264
	for linux-xfs-outgoing; Thu, 24 May 2001 14:44:31 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4OLiRF08260
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:44:28 -0700
Received: (qmail 22428 invoked from network); 24 May 2001 21:44:25 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 24 May 2001 21:44:25 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, cluster-admin@ncsa.uiuc.edu,
   linux-xfs@oss.sgi.com
Subject: Re: the file I forgot... 
In-reply-to: Your message of "Thu, 24 May 2001 08:12:12 EST."
             <Pine.LNX.4.33.0105240809030.25173-100000@osage.ncsa.uiuc.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 May 2001 07:44:24 +1000
Message-ID: <17356.990740664@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001 08:12:12 -0500 (CDT), 
Galen Arnold <arnoldg@ncsa.uiuc.edu> wrote:
>I'll get another kernel built with kdb enabled and boot it with the NMI
>settings suggested earlier.  In the meantime, I got lucky and had a crash
>from the job I left running last night.  The output is at:
>
>	http://www.ncsa.uiuc.edu/people/arnoldg/xfs/cr1

Ouch, the trace shows lots of repeated addresses, something is looping.
Please run the trace through ksymoops using the System.map for the
failing system so we can see where it is looping.


From owner-linux-xfs@oss.sgi.com Thu May 24 14:45:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OLjpB08302
	for linux-xfs-outgoing; Thu, 24 May 2001 14:45:51 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4OLjmF08299
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:45:49 -0700
Received: (qmail 22441 invoked from network); 24 May 2001 21:45:46 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 24 May 2001 21:45:46 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: the file I forgot... 
In-reply-to: Your message of "Thu, 24 May 2001 11:36:10 EST."
             <Pine.LNX.4.33.0105241113470.4337-100000@osage.ncsa.uiuc.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 May 2001 07:45:45 +1000
Message-ID: <17384.990740745@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001 11:36:10 -0500 (CDT), 
Galen Arnold <arnoldg@ncsa.uiuc.edu> wrote:
>I've followed Keith's suggestions and added
>
>	append="kdb=on,nmi_watchdog=2"

That needs to be append="kdb=on nmi_watchdog=2", space between boot
options, not comma.  I suspect that the comma had the effect of
disabling both kdb and nmi_watchdog.


From owner-linux-xfs@oss.sgi.com Thu May 24 14:59:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OLxGL08607
	for linux-xfs-outgoing; Thu, 24 May 2001 14:59:16 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OLxGF08604
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:59:16 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OLxDi17609;
	Thu, 24 May 2001 16:59:13 -0500 (CDT)
Message-ID: <3B0D84DD.2EC6933E@sgi.com>
Date: Thu, 24 May 2001 17:02:05 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: Mike Burger <mburger@compucomis.net>, linux-xfs@oss.sgi.com
Subject: Re: 1.0 Installer
References: <4.3.2.7.2.20010524212751.037873b8@pop.xs4all.nl> <4.3.2.7.2.20010524222139.0394e2d0@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:
 
> How can one "see" a fs that is not cleanly unmounted? I mean what does
> anaconda do to check for that?
> With ext2 you get a warning, journaling fs on the other hand know what to do.
> It would be great if it could just recover the fs on mount and continue.

I'd have to check, but anaconda may just say "if mount has _any_ output,
then assume it's a dirty filesystem, and bail out."  Since it was
originally designed to work only with ext2, this would be a decent
assumption.  We could make it smarter for the XFS installer, but that's
gonna be a ways down the priority list.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 14:59:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OLxVP08617
	for linux-xfs-outgoing; Thu, 24 May 2001 14:59:31 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OLxTF08614
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 14:59:30 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id XAA719630
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 23:59:28 +0200 (CEST)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA50848; Thu, 24 May 2001 15:03:11 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP
	id 5B16115A448; Thu, 24 May 2001 14:57:53 -0700 (PDT)
Subject: i440LX and DAC960 again
From: Florin Andrei <florin@sgi.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: mrlancealot@hotmail.com, Michael.Venables@compaq.com,
   linux-xfs@oss.sgi.com, seawolf-list@redhat.com
In-Reply-To: <3AFAD3AE.F51806B8@sgi.com>
References: <3AFAD3AE.F51806B8@sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 24 May 2001 14:57:53 -0700
Message-Id: <990741473.8059.6.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

(this discussion started after my unsuccessful attempts to install Red
Hat 7.1, with or without SGI XFS patches, on some systems based on Intel
440LX motherboards and DAC960 controllers)

On 10 May 2001 12:45:18 -0500, Eric Sandeen wrote:
> 
> 2) use the image at http://lager.dyndns.org/raid-dd-i686-0509-2.img to
> perform the install, then try booting the installer again with "linux
dd
> rescue" to get into rescue mode w/ a good driver, and move your raid
> module from kernel/drivers/scsi to kernel/drivers/block

Hi Eric,

I did exactly what you said:
Booted from RH7.1 SGI XFS CD with "text dd" and your drivers floppy,
installed everything, rebooted "linux dd rescue", moved the DAC960.o
file from scsi to block, rebooted the system... It doesn't work.

No matter if i move DAC960.o or not, during the boot process it tells me
that a DAC960 module is already loaded, and /sbin/insmod fails. Then it
gives some errors while trying to mount local filesystems.

Quotes:

##############################
Mounted devfs on /dev
Red Hat nash version 3.0.10 starting
Loading scsi_mod module
SCSI subsystem driver Revision: 1.00
Loading sd_mod module
Loading DAC960 module
##############################

Then i get a bunch of messages from the DAC960 driver. After that:

##############################
Partition check:
 rd/c0d0: p1 p2 p3 p4 < p5 p6 p7 >
Loading DAC960 module
insmod: a module named DAC960 already exists
ERROR: /bin/insmod exited abnormally!
Loading aic7xxx module
##############################

Then lots of messages from aic7xxx driver and a lot of other stuff.
It gets to the point where it remounts / and goes through the /etc/rc
hierarchy. But when mounting the other filesystems:

##############################
mount: special device /dev/rd/c0d0p1 does not exist
mount: special device /dev/rd/c0d0p7 ...
##############################

In the end, i get a system that has only / mounted.

Now, when i look to /dev/rd, of course there's no such file as c0d0p...

So, after that crippled boot, i modified /etc/fstab, putting things like
/dev/rd/disc0/part1, part2, part3, etc. instead of the default devices.
Now it works, it still tries to insmod DAC960 twice, but it appears to
be happy otherwise.

Comments?

Is there anyone from the Linux-XFS team in the Mountain View campus, so
i can lend you guys a DAC960 controller to play with?...

-- 
Florin Andrei

"All operating systems suck.
Linux just sucks less" - an MIT guy


From owner-linux-xfs@oss.sgi.com Thu May 24 15:05:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OM5nQ08801
	for linux-xfs-outgoing; Thu, 24 May 2001 15:05:49 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OM5mF08798
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:05:48 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OM5Fi19258;
	Thu, 24 May 2001 17:05:15 -0500 (CDT)
Message-ID: <3B0D8648.9FABD382@sgi.com>
Date: Thu, 24 May 2001 17:08:08 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Florin Andrei <florin@sgi.com>
CC: mrlancealot@hotmail.com, linux-xfs@oss.sgi.com
Subject: Re: i440LX and DAC960 again
References: <3AFAD3AE.F51806B8@sgi.com> <990741473.8059.6.camel@stantz.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Florin (trimmed the cc: list a bit) -

The driver disk doesn't work so well after all, it drops the updated
driver in drivers/scsi rather than drivers/block (this seems to be an
anaconda limitation).

You can use "linux rescue dd" to get up and running, then copy the new
driver from drivers/scsi (the wrong place) over the old one in
drivers/block (the right place).

-Eric

Florin Andrei wrote:
 
> Hi Eric,
> 
> I did exactly what you said:
> Booted from RH7.1 SGI XFS CD with "text dd" and your drivers floppy,
> installed everything, rebooted "linux dd rescue", moved the DAC960.o
> file from scsi to block, rebooted the system... It doesn't work.
> 
> No matter if i move DAC960.o or not, during the boot process it tells me
> that a DAC960 module is already loaded, and /sbin/insmod fails. Then it
> gives some errors while trying to mount local filesystems.

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 15:12:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OMCnV08996
	for linux-xfs-outgoing; Thu, 24 May 2001 15:12:49 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMCmF08993
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:12:48 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07670
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:12:50 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA93177; Thu, 24 May 2001 15:16:38 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP
	id 3076615A448; Thu, 24 May 2001 15:11:20 -0700 (PDT)
Subject: Re: i440LX and DAC960 again
From: Florin Andrei <florin@sgi.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: mrlancealot@hotmail.com, linux-xfs@oss.sgi.com
In-Reply-To: <3B0D8648.9FABD382@sgi.com>
References: <3AFAD3AE.F51806B8@sgi.com>
	<990741473.8059.6.camel@stantz.corp.sgi.com>  <3B0D8648.9FABD382@sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 24 May 2001 15:11:20 -0700
Message-Id: <990742280.8074.7.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 24 May 2001 17:08:08 -0500, Eric Sandeen wrote:
> Hi Florin (trimmed the cc: list a bit) -
> 
> The driver disk doesn't work so well after all, it drops the updated
> driver in drivers/scsi rather than drivers/block (this seems to be an
> anaconda limitation).
> 
> You can use "linux rescue dd" to get up and running, then copy the new
> driver from drivers/scsi (the wrong place) over the old one in
> drivers/block (the right place).

I don't think that's the problem. Like i told you, it does not matter if
i move the driver or not, i get the same error.
Somehow, /etc/fstab gets a wrong content. It has to see the partitions
as /dev/rd/disc0/part1 not as /dev/rd/c0d0p1
Or maybe /dev/rd/c0d0p... are missing?

-- 
Florin Andrei

"All operating systems suck.
Linux just sucks less" - an MIT guy


From owner-linux-xfs@oss.sgi.com Thu May 24 15:18:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OMIZJ09087
	for linux-xfs-outgoing; Thu, 24 May 2001 15:18:35 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMIZF09084
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:18:35 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4OMIYi22504;
	Thu, 24 May 2001 17:18:34 -0500 (CDT)
Message-ID: <3B0D8966.67D451CD@sgi.com>
Date: Thu, 24 May 2001 17:21:26 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Florin Andrei <florin@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: i440LX and DAC960 again
References: <3AFAD3AE.F51806B8@sgi.com>
		<990741473.8059.6.camel@stantz.corp.sgi.com>  <3B0D8648.9FABD382@sgi.com> <990742280.8074.7.camel@stantz.corp.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Florin Andrei wrote:

> I don't think that's the problem. Like i told you, it does not matter if
> i move the driver or not, i get the same error.

Oh, I'm sorry, skimming too fast...  you might do a find /lib/modules
-name dac960.o and see how many you have floating around.  If it's
complaining about being loaded twice, it seems like it might still be in
2 places.

> Somehow, /etc/fstab gets a wrong content. It has to see the partitions
> as /dev/rd/disc0/part1 not as /dev/rd/c0d0p1
> Or maybe /dev/rd/c0d0p... are missing?

I'm afraid I don't know for sure what to tell you on this.

/dev/rd/disc0/part1 looks like devfs naming, whereas /dev/rd/c0d0p1 is
the compatibility name.

Not sure where to go from here...

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 15:22:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OMM5n09169
	for linux-xfs-outgoing; Thu, 24 May 2001 15:22:05 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMM4F09166
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:22:04 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4OMJfX04720;
	Thu, 24 May 2001 17:19:41 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 24 May 2001 17:19:41 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Florin Andrei <florin@sgi.com>
cc: Eric Sandeen <sandeen@sgi.com>, <mrlancealot@hotmail.com>,
   <linux-xfs@oss.sgi.com>
Subject: Re: i440LX and DAC960 again
In-Reply-To: <990742280.8074.7.camel@stantz.corp.sgi.com>
Message-ID: <Pine.LNX.4.33.0105241719320.1903-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Perhaps DON't use devfs?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 24 May 2001, Florin Andrei wrote:

> On 24 May 2001 17:08:08 -0500, Eric Sandeen wrote:
> > Hi Florin (trimmed the cc: list a bit) -
> >
> > The driver disk doesn't work so well after all, it drops the updated
> > driver in drivers/scsi rather than drivers/block (this seems to be an
> > anaconda limitation).
> >
> > You can use "linux rescue dd" to get up and running, then copy the new
> > driver from drivers/scsi (the wrong place) over the old one in
> > drivers/block (the right place).
>
> I don't think that's the problem. Like i told you, it does not matter if
> i move the driver or not, i get the same error.
> Somehow, /etc/fstab gets a wrong content. It has to see the partitions
> as /dev/rd/disc0/part1 not as /dev/rd/c0d0p1
> Or maybe /dev/rd/c0d0p... are missing?
>
>


From owner-linux-xfs@oss.sgi.com Thu May 24 15:50:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OMoEa09724
	for linux-xfs-outgoing; Thu, 24 May 2001 15:50:14 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMoDF09721
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:50:13 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1533vm-0007x8-00; Fri, 25 May 2001 10:50:10 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Eric Sandeen" <sandeen@sgi.com>, "Florin Andrei" <florin@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: i440LX and DAC960 again
Date: Fri, 25 May 2001 10:49:37 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIGECPCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B0D8966.67D451CD@sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Oh, I'm sorry, skimming too fast...  you might do a find /lib/modules
:: -name dac960.o and see how many you have floating around.  If it's
:: complaining about being loaded twice, it seems like it might still be in
:: 2 places.

Also, you've probably already done this, but check modules.conf for
duplicate entries.

== Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 15:51:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4OMpsZ09870
	for linux-xfs-outgoing; Thu, 24 May 2001 15:51:54 -0700
Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4OMprF09866
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 15:51:53 -0700
Received: from dsl-squash.corp.sgi.com (nic-30-c48-217.mw.mediaone.net [24.30.48.217])
	by demai05.mw.mediaone.net (8.11.1/8.11.1) with ESMTP id f4OMpqM14467
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 18:51:52 -0400 (EDT)
Date: Thu, 24 May 2001 18:51:37 -0400 (EDT)
From: J Landman <landman@mediaone.net>
X-X-Sender:  <landman@dsl-squash.corp.sgi.com>
To: <linux-xfs@oss.sgi.com>
Subject: Success:  XFS 1.0 + Mandrake 8.0 on raid0
Message-ID: <Pine.LNX.4.32.0105241847180.21399-100000@dsl-squash.corp.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Folks:

  I have my Mandrake 8.0 happily running XFS with no problems (devfsd no
where in sight).  First off, thank you all!  It is nice to be able to do a

	dd if=/dev/zero of=big bs=10M count=820

and have it work (it does not on my Reiserfs partition).  I have an
operational raid0 (/dev/md0) set up to handle my files, and now I have
about 0.3 TB of 2 way striped XFS.

Awesome work folks!  Laptop reload is next.


-- 
 Joe Landman,
 landman@mediaone.net



From owner-linux-xfs@oss.sgi.com Thu May 24 16:20:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ONKAi10423
	for linux-xfs-outgoing; Thu, 24 May 2001 16:20:10 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ONK9F10420
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:20:09 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4ONK8B11206
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 18:20:08 -0500 (CDT)
Message-ID: <3B0D97D7.1526FBC8@sgi.com>
Date: Thu, 24 May 2001 18:23:03 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - minor irix merge
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May 24 16:17:45 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

Very tiny merge, just comment cleanup.  Doing my part to keep those
irix/linux diffs small...

Merge of irix6.5f:irix:95153b

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95970a
linux/fs/xfs/xfs_dmapi.c - 1.36
	- Merge of irix6.5f:irix:95153b
	  Update comments in xfs_dm_mapevent() and xfs_dm_testevent().  Fix for
	  bug 821346.


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 24 16:23:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ONNeU10482
	for linux-xfs-outgoing; Thu, 24 May 2001 16:23:40 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ONNaF10479
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:23:37 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1534Rr-0007zD-00; Fri, 25 May 2001 11:23:19 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Juha Saarinen" <juha@saarinen.org>, "Eric Sandeen" <sandeen@sgi.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Fri, 25 May 2001 11:22:46 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIGEDBCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <LGECJLHBGAPMGAJFMAFIGECMCAAA.juha@saarinen.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: :: What were you doing when this happened?
::
:: I don't know, to be honest.

OK, this is what I did, and it's repeatable:

service single start
service single stop

# rpm -q --whatprovides /sbin/service
initscripts-5.83-1


I emptied dmesg with the -c flag... but as soon as I go into single mode and
exit it, I get the:

xfs_create looping, dir ino 0x40089, ino 0x4c240, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c241, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x14008d, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x14008e, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c243, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c244, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c247, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c248, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c249, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c24a, ide0(3,7)

xfs_create looping, dir ino 0x140081, ino 0x140094, ide0(3,7)

xfs_create looping, dir ino 0x40089, ino 0x4c254, ide0(3,7)


entries. This is repeatable with "boot linux single" and "init 1" as well.

The system takes a long time to come up (presumably because of the
xfs_create errors?) and I get a few " Unknown Error 990" messages in the
process, as the system can't create files in /var/run for the processes...

-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 16:46:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ONkFT11289
	for linux-xfs-outgoing; Thu, 24 May 2001 16:46:15 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4ONkBF11268
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 16:46:13 -0700
Received: from vimfuego.saarinen.org ([192.168.1.1])
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 1534nj-000806-00; Fri, 25 May 2001 11:45:55 +1200
Date: Fri, 25 May 2001 11:45:55 +1200 (NZST)
From: Juha Saarinen <juha@saarinen.org>
To: Eric Sandeen <sandeen@sgi.com>
cc: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
In-Reply-To: <LGECJLHBGAPMGAJFMAFIGEDBCAAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.33.0105251145170.18450-100000@vimfuego.saarinen.org>
X-S: Always
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, 25 May 2001, Juha Saarinen wrote:

> :: :: What were you doing when this happened?
> ::
> :: I don't know, to be honest.
>
> OK, this is what I did, and it's repeatable:
>
> service single start
> service single stop

No, not 'service single stop'... 'exit' I meant. ;-)


-- 
Regards,


Juha

PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544


From owner-linux-xfs@oss.sgi.com Thu May 24 17:26:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P0QQG12126
	for linux-xfs-outgoing; Thu, 24 May 2001 17:26:26 -0700
Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P0QOF12123
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 17:26:25 -0700
Received: from [195.20.224.209] (helo=mrvdom02.schlund.de)
	by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #2)
	id 1535Qs-0000hx-00; Fri, 25 May 2001 02:26:22 +0200
Received: from pd901e265.dip.t-dialin.net ([217.1.226.101] helo=kernelpanix.aura.of.mankind)
	by mrvdom02.schlund.de with esmtp (Exim 2.12 #2)
	id 1535QM-0007y3-00; Fri, 25 May 2001 02:25:51 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4ONkCa04330;
	Fri, 25 May 2001 01:46:12 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to utz@s2y4n2c.de using -f
Date: Fri, 25 May 2001 01:46:12 +0200
From: utz@s2y4n2c.de
To: Juha Saarinen <juha@saarinen.org>
Cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
Message-ID: <20010525014612.A4196@s2y4n2c.de>
References: <LGECJLHBGAPMGAJFMAFIGECMCAAA.juha@saarinen.org> <LGECJLHBGAPMGAJFMAFIGEDBCAAA.juha@saarinen.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <LGECJLHBGAPMGAJFMAFIGEDBCAAA.juha@saarinen.org>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

Juha Saarinen [juha@saarinen.org] wrote:
> The system takes a long time to come up (presumably because of the
> xfs_create errors?) and I get a few " Unknown Error 990" messages in the
> process, as the system can't create files in /var/run for the processes...

I made today a fresh installation on one system (sgi XFS 1.0 install CD).

I just tried the gcc-2.96-81 for kernel again. I got an "Unknown Error 990"
and boot failed because /var/run was corrupted and umounting my nfs mounted
/home failed. I booted the install CD in rescue mode and run xfs_check and
xfs_repair. There were a lot of errors and about 20 files linkt to
lost+found. They are mostly PID files from /var/run/.

I installed the redhat 7.0 kgcc an recompiled the kernel (same source). No
problemes with it. The source is from cvs about 4 hours ago.

Maybe it is an compiler issue.


utz

From owner-linux-xfs@oss.sgi.com Thu May 24 20:32:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P3WHx15937
	for linux-xfs-outgoing; Thu, 24 May 2001 20:32:17 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P3WGF15933
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 20:32:16 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1538Jy-0008Ai-00; Fri, 25 May 2001 15:31:26 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: <utz@s2y4n2c.de>
Cc: "Eric Sandeen" <sandeen@sgi.com>, <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Fri, 25 May 2001 15:30:53 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIKEDGCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010525014612.A4196@s2y4n2c.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Maybe it is an compiler issue.

OK, installed compat-egcs (plus a host of other RPMs required), and tried
going into single mode and exiting it again.

No problems this time. It seems that if you go into single mode on a system
compiled with gcc 2.96-81, you'll end up with a corrupt /var (just like Utz,
I had to boot into rescue mode and run xfs_check and xfs_repair on /var.

So... here's a patch for the Makefile ;-):


--- Makefile    Fri May 25 15:24:36 2001
+++ Makefile.kgcc       Fri May 25 15:27:37 2001
@@ -26,8 +26,8 @@

 AS             = $(CROSS_COMPILE)as
 LD             = $(CROSS_COMPILE)ld
-CC             = $(CROSS_COMPILE)gcc
-#===== NOTE =====
+#CC            = $(CROSS_COMPILE)gcc
+#  ===== NOTE =====
 #  egcs-2.91.66 is the recommended compiler version for building XFS.
 #  Most of the XFS developers are using that particular version for
 #  development, testing, and performance analysis work, and it will
@@ -37,10 +37,13 @@
 #  On early versions of RedHat 7.x, kgcc is the recommended compiler
 #  for building the kernel (kgcc is the same as egcs-2.91.66) - if
 #  you use such a distribution and wish to use kgcc, uncomment this:
-#CC            = $(CROSS_COMPILE)kgcc
-#  The default gcc with RedHat 7.1 (gcc-2.96-81) also appears to
-#  generate good code, earlier versions of 2.96 are however an
-#  unknown quantity and not recommended.
+CC             = $(CROSS_COMPILE)kgcc
+#  Even though we though that the default gcc with RedHat 7.1
+#  (gcc-2.96-81) would generate good code, extensive testing by
+#  fearless volunteers has shown that building XFS with it will
+#  cause serious file system corruption in certain circumstances.
+#  Don't even think about using earlier versions of GCC 2.96.


Cheers,

- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 21:42:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P4gRt17327
	for linux-xfs-outgoing; Thu, 24 May 2001 21:42:27 -0700
Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4gPF17323
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 21:42:25 -0700
Received: from 1Cust180.tnt1.bay-minette.al.da.uu.net (1Cust180.tnt1.bay-minette.al.da.uu.net [63.29.15.180])
	by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id VAA08572;
	Thu, 24 May 2001 21:41:59 -0700 (PDT)
Date: Thu, 24 May 2001 23:40:08 -0500 (CDT)
From: Bruce Tenison <btenison@earthlink.net>
X-X-Sender:  <btenison@tenison.irstc.cc.al.us>
To: <utz@s2y4n2c.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Errr... what's all this about then?
In-Reply-To: <20010525014612.A4196@s2y4n2c.de>
Message-ID: <Pine.LNX.4.33.0105242335450.1582-300000@tenison.irstc.cc.al.us>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-180052713-990765608=:1582"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--8323329-180052713-990765608=:1582
Content-Type: TEXT/PLAIN; charset=US-ASCII

I've had similar problems here.  I have a Fujitsu 18Gig IDE drive that has
two partitions on it (both XFS, one mounted ro and the other is my root
partition)  Anyway, I just updated to the latest cvs copy of 2.4.4-xfs,
recompiled.  I booted the machine with the XFS root (clean, as reported
from xfs_check prior to booting with it being the root), after it
completed booting, immediately shutdown, and rebooted with another HD as
root, and ran xfs_check and xfs_repair on the, now corrupted XFS root.
The outputs of check and repair utils is included below, so you can see
what's happening.  Very similar problems, mostly in the pid files here
too!

Anything I can to to help diagnose the problem on my end here?
Bruce

> I made today a fresh installation on one system (sgi XFS 1.0 install CD).
>
> I just tried the gcc-2.96-81 for kernel again. I got an "Unknown Error 990"
> and boot failed because /var/run was corrupted and umounting my nfs mounted
> /home failed. I booted the install CD in rescue mode and run xfs_check and
> xfs_repair. There were a lot of errors and about 20 files linkt to
> lost+found. They are mostly PID files from /var/run/.
>
> I installed the redhat 7.0 kgcc an recompiled the kernel (same source). No
> problemes with it. The source is from cvs about 4 hours ago.
>
> Maybe it is an compiler issue.
>
>
> utz
>

-- 
Bruce Tenison
btenison@earthlink.net

Public Key available at: http://www.keyserver.net


--8323329-180052713-990765608=:1582
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=after_boot_repair
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105242340080.1582@tenison.irstc.cc.al.us>
Content-Description: 
Content-Disposition: attachment; filename=after_boot_repair

UGhhc2UgMSAtIGZpbmQgYW5kIHZlcmlmeSBzdXBlcmJsb2NrLi4uDQpQaGFz
ZSAyIC0gdXNpbmcgaW50ZXJuYWwgbG9nDQogICAgICAgIC0gemVybyBsb2cu
Li4NCiAgICAgICAgLSBzY2FuIGZpbGVzeXN0ZW0gZnJlZXNwYWNlIGFuZCBp
bm9kZSBtYXBzLi4uDQogICAgICAgIC0gZm91bmQgcm9vdCBpbm9kZSBjaHVu
aw0KUGhhc2UgMyAtIGZvciBlYWNoIEFHLi4uDQogICAgICAgIC0gc2NhbiBh
bmQgY2xlYXIgYWdpIHVubGlua2VkIGxpc3RzLi4uDQogICAgICAgIC0gcHJv
Y2VzcyBrbm93biBpbm9kZXMgYW5kIHBlcmZvcm0gaW5vZGUgZGlzY292ZXJ5
Li4uDQogICAgICAgIC0gYWdubyA9IDANCmltYXAgY2xhaW1zIGEgZnJlZSBp
bm9kZSAxNDQxOTUgaXMgaW4gdXNlLCBjb3JyZWN0aW5nIGltYXAgYW5kIGNs
ZWFyaW5nIGlub2RlDQppbWFwIGNsYWltcyBhIGZyZWUgaW5vZGUgMTQ0MTk2
IGlzIGluIHVzZSwgY29ycmVjdGluZyBpbWFwIGFuZCBjbGVhcmluZyBpbm9k
ZQ0KaW1hcCBjbGFpbXMgYSBmcmVlIGlub2RlIDE0NDE5NyBpcyBpbiB1c2Us
IGNvcnJlY3RpbmcgaW1hcCBhbmQgY2xlYXJpbmcgaW5vZGUNCmltYXAgY2xh
aW1zIGEgZnJlZSBpbm9kZSAxNDQxOTkgaXMgaW4gdXNlLCBjb3JyZWN0aW5n
IGltYXAgYW5kIGNsZWFyaW5nIGlub2RlDQpjbGVhcmVkIGlub2RlIDE0NDE5
OQ0KICAgICAgICAtIGFnbm8gPSAxDQppbWFwIGNsYWltcyBpbi11c2UgaW5v
ZGUgMjIzNTYxMSBpcyBmcmVlLCBjb3JyZWN0aW5nIGltYXANCiAgICAgICAg
LSBhZ25vID0gMg0KICAgICAgICAtIGFnbm8gPSAzDQogICAgICAgIC0gYWdu
byA9IDQNCmltYXAgY2xhaW1zIGEgZnJlZSBpbm9kZSA5MTEwMjUwIGlzIGlu
IHVzZSwgY29ycmVjdGluZyBpbWFwIGFuZCBjbGVhcmluZyBpbm9kZQ0KICAg
ICAgICAtIGFnbm8gPSA1DQogICAgICAgIC0gYWdubyA9IDYNCiAgICAgICAg
LSBhZ25vID0gNw0KICAgICAgICAtIHByb2Nlc3MgbmV3bHkgZGlzY292ZXJl
ZCBpbm9kZXMuLi4NClBoYXNlIDQgLSBjaGVjayBmb3IgZHVwbGljYXRlIGJs
b2Nrcy4uLg0KICAgICAgICAtIHNldHRpbmcgdXAgZHVwbGljYXRlIGV4dGVu
dCBsaXN0Li4uDQogICAgICAgIC0gY2xlYXIgbG9zdCtmb3VuZCAoaWYgaXQg
ZXhpc3RzKSAuLi4NCiAgICAgICAgLSBjbGVhcmluZyBleGlzdGluZyAibG9z
dCtmb3VuZCIgaW5vZGUNCiAgICAgICAgLSBtYXJraW5nIGVudHJ5ICJsb3N0
K2ZvdW5kIiB0byBiZSBkZWxldGVkDQogICAgICAgIC0gY2hlY2sgZm9yIGlu
b2RlcyBjbGFpbWluZyBkdXBsaWNhdGUgYmxvY2tzLi4uDQogICAgICAgIC0g
YWdubyA9IDANCmVudHJ5ICJzeXNsb2dkLnBpZCIgaW4gc2hvcnRmb3JtIGRp
cmVjdG9yeSAxNDQxOTIgcmVmZXJlbmNlcyBmcmVlIGlub2RlIDE0NDE5NQ0K
anVua2luZyBlbnRyeSAic3lzbG9nZC5waWQiIGluIGRpcmVjdG9yeSBpbm9k
ZSAxNDQxOTINCmVudHJ5ICJrbG9nZC5waWQiIGluIHNob3J0Zm9ybSBkaXJl
Y3RvcnkgMTQ0MTkyIHJlZmVyZW5jZXMgZnJlZSBpbm9kZSAxNDQxOTYNCmp1
bmtpbmcgZW50cnkgImtsb2dkLnBpZCIgaW4gZGlyZWN0b3J5IGlub2RlIDE0
NDE5Mg0KZW50cnkgImFwbWQucGlkIiBpbiBzaG9ydGZvcm0gZGlyZWN0b3J5
IDE0NDE5MiByZWZlcmVuY2VzIGZyZWUgaW5vZGUgMTQ0MTk3DQpqdW5raW5n
IGVudHJ5ICJhcG1kLnBpZCIgaW4gZGlyZWN0b3J5IGlub2RlIDE0NDE5Mg0K
ICAgICAgICAtIGFnbm8gPSAxDQogICAgICAgIC0gYWdubyA9IDINCiAgICAg
ICAgLSBhZ25vID0gMw0KICAgICAgICAtIGFnbm8gPSA0DQogICAgICAgIC0g
YWdubyA9IDUNCiAgICAgICAgLSBhZ25vID0gNg0KICAgICAgICAtIGFnbm8g
PSA3DQpQaGFzZSA1IC0gcmVidWlsZCBBRyBoZWFkZXJzIGFuZCB0cmVlcy4u
Lg0KICAgICAgICAtIHJlc2V0IHN1cGVyYmxvY2suLi4NClBoYXNlIDYgLSBj
aGVjayBpbm9kZSBjb25uZWN0aXZpdHkuLi4NCiAgICAgICAgLSByZXNldHRp
bmcgY29udGVudHMgb2YgcmVhbHRpbWUgYml0bWFwIGFuZCBzdW1tYXJ5IGlu
b2Rlcw0KICAgICAgICAtIGVuc3VyaW5nIGV4aXN0ZW5jZSBvZiBsb3N0K2Zv
dW5kIGRpcmVjdG9yeQ0KICAgICAgICAtIHRyYXZlcnNpbmcgZmlsZXN5c3Rl
bSBzdGFydGluZyBhdCAvIC4uLiANCnJlYnVpbGRpbmcgZGlyZWN0b3J5IGlu
b2RlIDEyOA0KICAgICAgICAtIHRyYXZlcnNhbCBmaW5pc2hlZCAuLi4gDQog
ICAgICAgIC0gdHJhdmVyc2luZyBhbGwgdW5hdHRhY2hlZCBzdWJ0cmVlcyAu
Li4gDQogICAgICAgIC0gdHJhdmVyc2FscyBmaW5pc2hlZCAuLi4gDQogICAg
ICAgIC0gbW92aW5nIGRpc2Nvbm5lY3RlZCBpbm9kZXMgdG8gbG9zdCtmb3Vu
ZCAuLi4gDQpkaXNjb25uZWN0ZWQgaW5vZGUgMTQ0MTk4LCBtb3ZpbmcgdG8g
bG9zdCtmb3VuZA0KZGlzY29ubmVjdGVkIGlub2RlIDE0NDIwMCwgbW92aW5n
IHRvIGxvc3QrZm91bmQNCmRpc2Nvbm5lY3RlZCBpbm9kZSAxNDQyMDEsIG1v
dmluZyB0byBsb3N0K2ZvdW5kDQpkaXNjb25uZWN0ZWQgaW5vZGUgMTQ0MjAy
LCBtb3ZpbmcgdG8gbG9zdCtmb3VuZA0KZGlzY29ubmVjdGVkIGlub2RlIDIy
MzU2MTEsIG1vdmluZyB0byBsb3N0K2ZvdW5kDQpQaGFzZSA3IC0gdmVyaWZ5
IGFuZCBjb3JyZWN0IGxpbmsgY291bnRzLi4uDQpkb25lDQo=
--8323329-180052713-990765608=:1582
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=after_boot_check
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.33.0105242340081.1582@tenison.irstc.cc.al.us>
Content-Description: 
Content-Disposition: attachment; filename=after_boot_check

YmFkIGZvcm1hdCAyIGZvciBpbm9kZSAxNDQxOTUgdHlwZSAwDQpiYWQgZm9y
bWF0IDIgZm9yIGlub2RlIDE0NDE5NiB0eXBlIDANCmJhZCBmb3JtYXQgMiBm
b3IgaW5vZGUgMTQ0MTk3IHR5cGUgMA0KYmFkIGZvcm1hdCAyIGZvciBpbm9k
ZSAxNDQxOTkgdHlwZSAwDQpiYWQgbmxpbmsgMSBmb3IgZnJlZSBpbm9kZSAy
MjM1NjExDQpiYWQgbW9kZSAwMTAwNjQ0IGZvciBmcmVlIGlub2RlIDIyMzU2
MTENCmJhZCBmb3JtYXQgMiBmb3IgaW5vZGUgOTExMDI1MCB0eXBlIDANCmJs
b2NrIDAvODUzNyB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAw
Lzg1MzggdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC84NTM5
IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvODU0MCB0eXBl
IHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzg1NDEgdHlwZSB1bmtu
b3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC84NTQyIHR5cGUgdW5rbm93biBu
b3QgZXhwZWN0ZWQNCmJsb2NrIDAvODU0MyB0eXBlIHVua25vd24gbm90IGV4
cGVjdGVkDQpibG9jayAwLzg1NDQgdHlwZSB1bmtub3duIG5vdCBleHBlY3Rl
ZA0KYmxvY2sgMC84NTQ1IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJs
b2NrIDAvODU0NiB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAw
Lzg1NDcgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC84NTQ4
IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvODU0OSB0eXBl
IHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzg1NTAgdHlwZSB1bmtu
b3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC84NTUxIHR5cGUgdW5rbm93biBu
b3QgZXhwZWN0ZWQNCmJsb2NrIDAvODU1MiB0eXBlIHVua25vd24gbm90IGV4
cGVjdGVkDQpibG9jayAwLzkyNDQgdHlwZSB1bmtub3duIG5vdCBleHBlY3Rl
ZA0KYmxvY2sgMC85MjQ1IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJs
b2NrIDAvOTI0NiB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAw
LzkyNDcgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85MjQ4
IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvOTI0OSB0eXBl
IHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzkyNTAgdHlwZSB1bmtu
b3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC85MjUxIHR5cGUgdW5rbm93biBu
b3QgZXhwZWN0ZWQNCmJsb2NrIDAvOTI1MiB0eXBlIHVua25vd24gbm90IGV4
cGVjdGVkDQpibG9jayAwLzkyNTMgdHlwZSB1bmtub3duIG5vdCBleHBlY3Rl
ZA0KYmxvY2sgMC81NjE4MSB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpi
bG9jayAwLzU2MTgyIHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2Nr
IDAvNTYxODYgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC81
OTk0MSB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzU5OTQy
IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvNjA0NDYgdHlw
ZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC82MDQ0NyB0eXBlIHVu
a25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzYwNDQ4IHR5cGUgdW5rbm93
biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvNjA0NDkgdHlwZSB1bmtub3duIG5v
dCBleHBlY3RlZA0KYmxvY2sgMC82MDQ1MCB0eXBlIHVua25vd24gbm90IGV4
cGVjdGVkDQpibG9jayAwLzYwNDUxIHR5cGUgdW5rbm93biBub3QgZXhwZWN0
ZWQNCmJsb2NrIDAvNjA0NTIgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0K
YmxvY2sgMC82MDQ1MyB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9j
ayAwLzYwNDU0IHR5cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAv
NjA0NTUgdHlwZSB1bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC82MDQ1
NiB0eXBlIHVua25vd24gbm90IGV4cGVjdGVkDQpibG9jayAwLzYwNDU3IHR5
cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmJsb2NrIDAvNjA0NTggdHlwZSB1
bmtub3duIG5vdCBleHBlY3RlZA0KYmxvY2sgMC82MDQ1OSB0eXBlIHVua25v
d24gbm90IGV4cGVjdGVkDQpibG9jayAwLzYwNDYwIHR5cGUgdW5rbm93biBu
b3QgZXhwZWN0ZWQNCmJsb2NrIDAvNjA0NjEgdHlwZSB1bmtub3duIG5vdCBl
eHBlY3RlZA0KYmxvY2sgMC82MDQ2MiB0eXBlIHVua25vd24gbm90IGV4cGVj
dGVkDQpsaW5rIGNvdW50IG1pc21hdGNoIGZvciBpbm9kZSAxNDQxOTUgKG5h
bWUgPyksIG5saW5rIDAsIGNvdW50ZWQgMQ0KbGluayBjb3VudCBtaXNtYXRj
aCBmb3IgaW5vZGUgMTQ0MTk2IChuYW1lID8pLCBubGluayAwLCBjb3VudGVk
IDENCmxpbmsgY291bnQgbWlzbWF0Y2ggZm9yIGlub2RlIDE0NDE5NyAobmFt
ZSA/KSwgbmxpbmsgMCwgY291bnRlZCAxDQpkaXNjb25uZWN0ZWQgaW5vZGUg
MTQ0MTk4LCBubGluayAxDQphbGxvY2F0ZWQgaW5vZGUgMTQ0MTk5IGhhcyAw
IGxpbmsgY291bnQNCmRpc2Nvbm5lY3RlZCBpbm9kZSAxNDQyMDAsIG5saW5r
IDENCmRpc2Nvbm5lY3RlZCBpbm9kZSAxNDQyMDEsIG5saW5rIDENCmRpc2Nv
bm5lY3RlZCBpbm9kZSAxNDQyMDIsIG5saW5rIDENCmJsb2NrIDEvNTIxIHR5
cGUgdW5rbm93biBub3QgZXhwZWN0ZWQNCmFsbG9jYXRlZCBpbm9kZSA5MTEw
MjUwIGhhcyAwIGxpbmsgY291bnQNCnNiX2lmcmVlIDE3NjY2LCBjb3VudGVk
IDE3NjQyDQpzYl9mZGJsb2NrcyAxODU3MDQsIGNvdW50ZWQgMTg1NjMwDQo=
--8323329-180052713-990765608=:1582--

From owner-linux-xfs@oss.sgi.com Thu May 24 21:43:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P4hPH17348
	for linux-xfs-outgoing; Thu, 24 May 2001 21:43:25 -0700
Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4hPF17345
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 21:43:25 -0700
Received: from 1Cust180.tnt1.bay-minette.al.da.uu.net (1Cust180.tnt1.bay-minette.al.da.uu.net [63.29.15.180])
	by snipe.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id VAA09384;
	Thu, 24 May 2001 21:43:21 -0700 (PDT)
Date: Thu, 24 May 2001 23:42:24 -0500 (CDT)
From: Bruce Tenison <btenison@earthlink.net>
X-X-Sender:  <btenison@tenison.irstc.cc.al.us>
To: <utz@s2y4n2c.de>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Errr... what's all this about then?
In-Reply-To: <20010525014612.A4196@s2y4n2c.de>
Message-ID: <Pine.LNX.4.33.0105242341550.1582-100000@tenison.irstc.cc.al.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

BTW, using RedHat 7.1 with kgcc here!  NOT gcc 2.96!

On Fri, 25 May 2001 utz@s2y4n2c.de wrote:

> Date: Fri, 25 May 2001 01:46:12 +0200
> From: utz@s2y4n2c.de
> To: Juha Saarinen <juha@saarinen.org>
> Cc: Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
> Subject: Re: Errr... what's all this about then?
>
> Hi
>
> Juha Saarinen [juha@saarinen.org] wrote:
> > The system takes a long time to come up (presumably because of the
> > xfs_create errors?) and I get a few " Unknown Error 990" messages in the
> > process, as the system can't create files in /var/run for the processes...
>
> I made today a fresh installation on one system (sgi XFS 1.0 install CD).
>
> I just tried the gcc-2.96-81 for kernel again. I got an "Unknown Error 990"
> and boot failed because /var/run was corrupted and umounting my nfs mounted
> /home failed. I booted the install CD in rescue mode and run xfs_check and
> xfs_repair. There were a lot of errors and about 20 files linkt to
> lost+found. They are mostly PID files from /var/run/.
>
> I installed the redhat 7.0 kgcc an recompiled the kernel (same source). No
> problemes with it. The source is from cvs about 4 hours ago.
>
> Maybe it is an compiler issue.
>
>
> utz
>

-- 
Bruce Tenison
btenison@earthlink.net

Public Key available at: http://www.keyserver.net



From owner-linux-xfs@oss.sgi.com Thu May 24 21:57:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P4vT817554
	for linux-xfs-outgoing; Thu, 24 May 2001 21:57:29 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P4vSF17550
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 21:57:28 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 1539f9-0008FT-00; Fri, 25 May 2001 16:57:23 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Bruce Tenison" <btenison@earthlink.net>, <utz@s2y4n2c.de>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Fri, 25 May 2001 16:56:50 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIIEDMCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.33.0105242341550.1582-100000@tenison.irstc.cc.al.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: BTW, using RedHat 7.1 with kgcc here!  NOT gcc 2.96!

I was just about to post "edit your Makefile to use kgcc instead of gcc"...
:-)

Recompiling the 2.4.4 XFS kernel with kgcc seems to have solved the fs
corruption issues for me.

-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 24 22:10:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P5AO517770
	for linux-xfs-outgoing; Thu, 24 May 2001 22:10:24 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P5AMF17767
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 22:10:23 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4P5ANi07782
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 00:10:23 -0500 (CDT)
Message-ID: <3B0DE9EE.4E14F346@sgi.com>
Date: Fri, 25 May 2001 00:13:18 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: TAKE - merge irix6.5f:irix:95964a
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May 24 22:08:09 PDT 2001
Workarea:  sshgate.corp.sgi.com:/home/sandeen/xfs/linux/workarea

Merge of mod irix6.5f:irix:95964a

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95977a
linux/fs/xfs/xfs_btree.c - 1.91
	- Replaced some missing parens for error handling.
(irix6.5f:irix:95964a)

From owner-linux-xfs@oss.sgi.com Thu May 24 23:03:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P63od19037
	for linux-xfs-outgoing; Thu, 24 May 2001 23:03:50 -0700
Received: from tigereye.hknet.com (tigereye.hknet.com [202.67.240.229])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P63mF19034
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 23:03:48 -0700
Received: from home (vp165253.hk.uac1.hknet.com [203.169.165.253])
	by tigereye.hknet.com (8.9.3/8.9.0) with SMTP id OAA12424
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:03:40 +0800 (HKT)
Message-ID: <01ce01c0e4e0$64eee940$0201000a@dailylomo.com>
From: "tin" <tin@tinwong.com>
To: <linux-xfs@oss.sgi.com>
Subject: harddisk LED won't stop
Date: Fri, 25 May 2001 14:03:15 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi :
after i using XFS don't know why, my harddisk 
always running,(never stop) i already check is not swapping
is it a bug or what?

thank you very much



tin@tinwong.com


From owner-linux-xfs@oss.sgi.com Thu May 24 23:12:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P6Cwg19184
	for linux-xfs-outgoing; Thu, 24 May 2001 23:12:58 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P6CvF19180
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 23:12:57 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 153AqE-0008JV-00; Fri, 25 May 2001 18:12:54 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "tin" <tin@tinwong.com>, <linux-xfs@oss.sgi.com>
Subject: RE: harddisk LED won't stop
Date: Fri, 25 May 2001 18:12:21 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIIEEACAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <01ce01c0e4e0$64eee940$0201000a@dailylomo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: hi :
:: after i using XFS don't know why, my harddisk 
:: always running,(never stop) i already check is not swapping
:: is it a bug or what?

Probably not. Check to see what processes you have running (ps -axw e.g.).

-- Juha

From owner-linux-xfs@oss.sgi.com Thu May 24 23:58:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P6wlZ20129
	for linux-xfs-outgoing; Thu, 24 May 2001 23:58:47 -0700
Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P6wlF20126
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 23:58:47 -0700
Received: from mind-flayer.almaden.ibm.com (mind-flayer.almaden.ibm.com [9.1.9.127])
	by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id XAA43626
	for <linux-xfs@oss.sgi.com>; Thu, 24 May 2001 23:58:03 -0700
Received: by mind-flayer.almaden.ibm.com (Postfix, from userid 500)
	id CAE5BE68BD; Thu, 24 May 2001 23:58:40 -0700 (PDT)
To: linux-xfs@oss.sgi.com
Subject: cannot compile modules with kernel-source-2.4.2-SGI_XFS_1.0
From: stephen farrell <sfarrell@almaden.ibm.com>
Date: 24 May 2001 23:58:40 -0700
Message-ID: <m3u229rk2n.fsf@mind-flayer.almaden.ibm.com>
Lines: 11
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I've re-installed (ie this is a new install) the kernel source
package, cd /usr/src/linux-2.4, cp configs/kernel-2.4.2-i686-config
.config and do make oldconfig; make dep; make bzImage and all is well.
Then I do make modules and it cannot handle module.h.  It says stuff
like like "nondigits in number and not hexadecimal" and "parse error
before '6b99f7d8'"... so I guess something crazy is going on with
modversions?... but what?

-- 
steve

From owner-linux-xfs@oss.sgi.com Fri May 25 00:14:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P7Exj20419
	for linux-xfs-outgoing; Fri, 25 May 2001 00:14:59 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P7EvF20416
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 00:14:57 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id AAA02551
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 00:13:30 -0700 (PDT)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA01981; Fri, 25 May 2001 17:12:11 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: stephen farrell <sfarrell@almaden.ibm.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: cannot compile modules with kernel-source-2.4.2-SGI_XFS_1.0 
In-reply-to: Your message of "24 May 2001 23:58:40 MST."
             <m3u229rk2n.fsf@mind-flayer.almaden.ibm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 25 May 2001 17:12:11 +1000
Message-ID: <25257.990774731@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 24 May 2001 23:58:40 -0700, 
stephen farrell <sfarrell@almaden.ibm.com> wrote:
>I've re-installed (ie this is a new install) the kernel source
>package, cd /usr/src/linux-2.4, cp configs/kernel-2.4.2-i686-config
>.config and do make oldconfig; make dep; make bzImage and all is well.
>Then I do make modules and it cannot handle module.h.  It says stuff
>like like "nondigits in number and not hexadecimal" and "parse error
>before '6b99f7d8'"... so I guess something crazy is going on with
>modversions?... but what?

>From Redhat?  They ship a seriously weird set of modversions data.
Blow it away and start from scratch.  See http://www.tux.org/lkml/#s8-8


From owner-linux-xfs@oss.sgi.com Fri May 25 01:04:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4P845n21422
	for linux-xfs-outgoing; Fri, 25 May 2001 01:04:05 -0700
Received: from ppi.co.jp (mail.ppi.co.jp [202.218.155.2])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4P843F21419
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 01:04:03 -0700
Received: from ppi.co.jp (tori.ppi.co.jp [10.1.11.12])
	by ppi.co.jp (8.11.2/8.11.2) with ESMTP id f4P83un06928
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:03:56 +0900 (JST)
Message-ID: <3B0E11EC.30F45CF7@ppi.co.jp>
Date: Fri, 25 May 2001 17:03:56 +0900
From: "T.Hattori" <tomo@ppi.co.jp>
X-Mailer: Mozilla 4.75 [ja] (WinNT; U)
X-Accept-Language: ja
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: mkfs.xfs option for RAID
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi.
For maximam performance and efficient performance, EXT2 file systems can
be built with "-b" & "-R stride= " options.
For instance, to match a normal RAID controller's 64KB default stripe
size, the command  'mke2fs -b 4096 -R stride=16 <device>' is
appropriate. ( 4KB * 16 = 64KB)

Can we tune XFS like this using -r option or others?


**********************************
T.Hattori
Japan
mail-to: tomo@ppi.co.jp




From owner-linux-xfs@oss.sgi.com Fri May 25 04:10:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PBAUs26829
	for linux-xfs-outgoing; Fri, 25 May 2001 04:10:30 -0700
Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PBAAF26817
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 04:10:11 -0700
Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1])
	by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id HAA01258;
	Fri, 25 May 2001 07:26:27 -0400
Message-ID: <3B0E4163.CB410F31@mindspring.com>
Date: Fri, 25 May 2001 07:26:27 -0400
From: Danny Cox <danscox@mindspring.com>
Reply-To: dcox@connex.com
Organization: Connex Inc
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "T.Hattori" <tomo@ppi.co.jp>
CC: linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs option for RAID
References: <3B0E11EC.30F45CF7@ppi.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"T.Hattori" wrote:
> 
> Hi.
> For maximam performance and efficient performance, EXT2 file systems can
> be built with "-b" & "-R stride= " options.
> For instance, to match a normal RAID controller's 64KB default stripe
> size, the command  'mke2fs -b 4096 -R stride=16 <device>' is
> appropriate. ( 4KB * 16 = 64KB)
> 
> Can we tune XFS like this using -r option or others?

	Yes!  In fact, mkfs.xfs "notices" if the block device is LVM or RAID,
and sets it's parameters automatically.  FYI, they are:

		sunit - stripe unit size in 512 byte blocks
		swidth - stripe width size in 512 byte blocks

-- 
"Men occasionally stumble over the truth, but most of them pick 
themselves up and hurry off as if nothing had happened." 
   -- Winston Churchill 

Danny

From owner-linux-xfs@oss.sgi.com Fri May 25 04:22:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PBM2827161
	for linux-xfs-outgoing; Fri, 25 May 2001 04:22:02 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PBM1F27156
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 04:22:01 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 7D7111E166; Fri, 25 May 2001 13:22:00 +0200 (MEST)
Date: Fri, 25 May 2001 13:20:58 +0200
From: Andi Kleen <ak@suse.de>
To: dcox@connex.com
Cc: "T.Hattori" <tomo@ppi.co.jp>, linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs option for RAID
Message-ID: <20010525132058.A29283@gruyere.muc.suse.de>
References: <3B0E11EC.30F45CF7@ppi.co.jp> <3B0E4163.CB410F31@mindspring.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B0E4163.CB410F31@mindspring.com>; from danscox@mindspring.com on Fri, May 25, 2001 at 07:26:27AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 25, 2001 at 07:26:27AM -0400, Danny Cox wrote:
> "T.Hattori" wrote:
> > 
> > Hi.
> > For maximam performance and efficient performance, EXT2 file systems can
> > be built with "-b" & "-R stride= " options.
> > For instance, to match a normal RAID controller's 64KB default stripe
> > size, the command  'mke2fs -b 4096 -R stride=16 <device>' is
> > appropriate. ( 4KB * 16 = 64KB)
> > 
> > Can we tune XFS like this using -r option or others?
> 
> 	Yes!  In fact, mkfs.xfs "notices" if the block device is LVM or RAID,
> and sets it's parameters automatically.  FYI, they are:

Are you sure it works for MD automatically too? When I'm reading the code
correctly only LVM_BLK_MAJOR is checked for.

-Andi

From owner-linux-xfs@oss.sgi.com Fri May 25 04:25:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PBPUT27276
	for linux-xfs-outgoing; Fri, 25 May 2001 04:25:30 -0700
Received: from wiley.ceo.com (66-2-81-26.customer.algx.net [66.2.81.26])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PBPTF27273
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 04:25:29 -0700
Received: from mindspring.com (IDENT:danny@localhost [127.0.0.1])
	by wiley.ceo.com (8.9.3/8.9.3) with ESMTP id HAA01476;
	Fri, 25 May 2001 07:41:47 -0400
Message-ID: <3B0E44FB.CC1BDF9B@mindspring.com>
Date: Fri, 25 May 2001 07:41:47 -0400
From: Danny Cox <danscox@mindspring.com>
Reply-To: dcox@connex.com
Organization: Connex Inc
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andi Kleen <ak@suse.de>
CC: dcox@connex.com, "T.Hattori" <tomo@ppi.co.jp>, linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs option for RAID
References: <3B0E11EC.30F45CF7@ppi.co.jp> <3B0E4163.CB410F31@mindspring.com> <20010525132058.A29283@gruyere.muc.suse.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Andi,

Andi Kleen wrote:
> 
> Are you sure it works for MD automatically too? When I'm reading the code
> correctly only LVM_BLK_MAJOR is checked for.

	No, I'm not sure.  It's worked for me correctly in the past, but I've
not updated from CVS lately.  Russell?

-- 
"Men occasionally stumble over the truth, but most of them pick 
themselves up and hurry off as if nothing had happened." 
   -- Winston Churchill 

Danny

From owner-linux-xfs@oss.sgi.com Fri May 25 05:52:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PCq1i29272
	for linux-xfs-outgoing; Fri, 25 May 2001 05:52:01 -0700
Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.121.50])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PCq0F29269
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 05:52:00 -0700
Received: from 1Cust191.tnt1.bay-minette.al.da.uu.net (1Cust191.tnt1.bay-minette.al.da.uu.net [63.29.15.191])
	by avocet.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id FAA24177;
	Fri, 25 May 2001 05:51:34 -0700 (PDT)
Date: Fri, 25 May 2001 07:48:46 -0500 (CDT)
From: Bruce Tenison <btenison@earthlink.net>
X-X-Sender:  <btenison@tenison.irstc.cc.al.us>
To: Juha Saarinen <juha@saarinen.org>
cc: <utz@s2y4n2c.de>, <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
In-Reply-To: <LGECJLHBGAPMGAJFMAFIIEDMCAAA.juha@saarinen.org>
Message-ID: <Pine.LNX.4.33.0105250746000.5021-100000@tenison.irstc.cc.al.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Strange...  Wish I could say the same here.  I've also tried a couple of
different Chipsets.  The main location that the drive will be housed is
using a Promise ATA66 PCI card controller, and I'm currently using it on a
VIA vt82c596b (rev 23) chipset, both showing the same style corruption
problems.  Something's amiss!

Bruce

> :: BTW, using RedHat 7.1 with kgcc here!  NOT gcc 2.96!
>
> I was just about to post "edit your Makefile to use kgcc instead of gcc"...
> :-)
>
> Recompiling the 2.4.4 XFS kernel with kgcc seems to have solved the fs
> corruption issues for me.
>
> -- Juha
>

-- 
Bruce Tenison
btenison@earthlink.net

Public Key available at: http://www.keyserver.net



From owner-linux-xfs@oss.sgi.com Fri May 25 06:45:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PDjVC30278
	for linux-xfs-outgoing; Fri, 25 May 2001 06:45:31 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PDjUF30275
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 06:45:30 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA01378
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 06:45:31 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1942407; Fri, 25 May 2001 08:44:11 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA69586; Fri, 25 May 2001 08:44:11 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4PDkx621397; Fri, 25 May 2001 08:46:59 -0500
Message-Id: <200105251346.f4PDkx621397@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: dcox@connex.com
cc: Andi Kleen <ak@suse.de>, "T.Hattori" <tomo@ppi.co.jp>,
   linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs option for RAID 
In-Reply-To: Message from Danny Cox <danscox@mindspring.com> 
   of "Fri, 25 May 2001 07:41:47 EDT." <3B0E44FB.CC1BDF9B@mindspring.com> 
Date: Fri, 25 May 2001 08:46:59 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Andi,
> 
> Andi Kleen wrote:
> > 
> > Are you sure it works for MD automatically too? When I'm reading the code
> > correctly only LVM_BLK_MAJOR is checked for.
> 
> 	No, I'm not sure.  It's worked for me correctly in the past, but I've
> not updated from CVS lately.  Russell?
> 


There is mkfs code in there for querying MD devices:

        /* MD volume */
        if (sb.st_rdev >> 8 == MD_MAJOR) {
                int fd;

                /* Open device */
                fd = open (dfile, O_RDONLY);
                if (fd == -1)
                        return;

                /* Is this thing on... */
                if (ioctl (fd, GET_ARRAY_INFO, &md)) {
                        fprintf (stderr, "Error getting array info from %s\n",
                                 dfile);
                        usage();
                }

                /* Check state */
                if (md.state) {
                        fprintf (stderr, "MD array %s not in clean state\n",
                                 dfile);
                        usage();
                }

                /* Deduct a disk from stripe width on RAID4/5 */
                if (md.level == 4 || md.level == 5)
                        md.nr_disks--;

                /* Update sizes */
                *sunit = md.chunk_size >> 9;
                *swidth = *sunit * md.nr_disks;

                return;
        }

Steve



From owner-linux-xfs@oss.sgi.com Fri May 25 06:54:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PDstF30540
	for linux-xfs-outgoing; Fri, 25 May 2001 06:54:55 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PDsrF30537
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 06:54:53 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id PAA776907
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 15:54:51 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1943923; Fri, 25 May 2001 08:53:33 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA93821; Fri, 25 May 2001 08:53:33 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4PDuMq21434; Fri, 25 May 2001 08:56:22 -0500
Message-Id: <200105251356.f4PDuMq21434@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Juha Saarinen" <juha@saarinen.org>
cc: utz@s2y4n2c.de, "Eric Sandeen" <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then? 
In-Reply-To: Message from "Juha Saarinen" <juha@saarinen.org> 
   of "Fri, 25 May 2001 15:30:53 +1200." <LGECJLHBGAPMGAJFMAFIKEDGCAAA.juha@saarinen.org> 
Date: Fri, 25 May 2001 08:56:22 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Thanks you guys for working through this one, that code you managed to
get into is for an old bug in xfs which was fixed years ago, you get into
the create a new file path, but when you go try insert the name into a
directory it says it exists, and you end up looping. Definitely looks like
there are still some compiler problems lurking. No doubt we could work through
and find the code which is getting misbuilt and rework it some, but right
now we have larger fish to fry.

Steve

> :: Maybe it is an compiler issue.
> 
> OK, installed compat-egcs (plus a host of other RPMs required), and tried
> going into single mode and exiting it again.
> 
> No problems this time. It seems that if you go into single mode on a system
> compiled with gcc 2.96-81, you'll end up with a corrupt /var (just like Utz,
> I had to boot into rescue mode and run xfs_check and xfs_repair on /var.
> 
> So... here's a patch for the Makefile ;-):
> 
> 
> --- Makefile    Fri May 25 15:24:36 2001
> +++ Makefile.kgcc       Fri May 25 15:27:37 2001
> @@ -26,8 +26,8 @@
> 
>  AS             = $(CROSS_COMPILE)as
>  LD             = $(CROSS_COMPILE)ld
> -CC             = $(CROSS_COMPILE)gcc
> -#===== NOTE =====
> +#CC            = $(CROSS_COMPILE)gcc
> +#  ===== NOTE =====
>  #  egcs-2.91.66 is the recommended compiler version for building XFS.
>  #  Most of the XFS developers are using that particular version for
>  #  development, testing, and performance analysis work, and it will
> @@ -37,10 +37,13 @@
>  #  On early versions of RedHat 7.x, kgcc is the recommended compiler
>  #  for building the kernel (kgcc is the same as egcs-2.91.66) - if
>  #  you use such a distribution and wish to use kgcc, uncomment this:
> -#CC            = $(CROSS_COMPILE)kgcc
> -#  The default gcc with RedHat 7.1 (gcc-2.96-81) also appears to
> -#  generate good code, earlier versions of 2.96 are however an
> -#  unknown quantity and not recommended.
> +CC             = $(CROSS_COMPILE)kgcc
> +#  Even though we though that the default gcc with RedHat 7.1
> +#  (gcc-2.96-81) would generate good code, extensive testing by
> +#  fearless volunteers has shown that building XFS with it will
> +#  cause serious file system corruption in certain circumstances.
> +#  Don't even think about using earlier versions of GCC 2.96.
> 
> 
> Cheers,
> 
> - Juha



From owner-linux-xfs@oss.sgi.com Fri May 25 07:16:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PEG9632233
	for linux-xfs-outgoing; Fri, 25 May 2001 07:16:09 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PEG8F32229
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 07:16:09 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 0D5EF1E1EA; Fri, 25 May 2001 16:16:08 +0200 (MEST)
Date: Fri, 25 May 2001 16:15:01 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: dcox@connex.com, Andi Kleen <ak@suse.de>, "T.Hattori" <tomo@ppi.co.jp>,
   linux-xfs@oss.sgi.com
Subject: Re: mkfs.xfs option for RAID
Message-ID: <20010525161501.A32512@gruyere.muc.suse.de>
References: <danscox@mindspring.com> <200105251346.f4PDkx621397@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105251346.f4PDkx621397@jen.americas.sgi.com>; from lord@sgi.com on Fri, May 25, 2001 at 08:46:59AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 25, 2001 at 08:46:59AM -0500, Steve Lord wrote:
> > Andi,
> > 
> > Andi Kleen wrote:
> > > 
> > > Are you sure it works for MD automatically too? When I'm reading the code
> > > correctly only LVM_BLK_MAJOR is checked for.
> > 
> > 	No, I'm not sure.  It's worked for me correctly in the past, but I've
> > not updated from CVS lately.  Russell?
> > 
> 
> 
> There is mkfs code in there for querying MD devices:

[...]
Looks like my cmd CVS checkout was hosed. After deleting and checking out
again the code is in there.

Thanks for clarifying,

-Andi

From owner-linux-xfs@oss.sgi.com Fri May 25 07:52:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PEqwH00662
	for linux-xfs-outgoing; Fri, 25 May 2001 07:52:58 -0700
Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PEqhF00655
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 07:52:44 -0700
Received: (from kszysiu@localhost)
	by main.braxis.co.uk (8.9.3/8.9.3) id QAA27549;
	Fri, 25 May 2001 16:51:25 +0200
Date: Fri, 25 May 2001 16:51:25 +0200
From: Krzysztof Rusocki <kszysiu@braxis.co.uk>
To: poldi <poldi@andreas-c.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS-Filesystem and MOSIX-Linux-Cluster
Message-ID: <20010525165125.A25312@main.braxis.co.uk>
References: <200105221201.f4MC14r07702@jen.americas.sgi.com> <Pine.LNX.4.33.0105221517190.229-100000@andreas-c>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.33.0105221517190.229-100000@andreas-c>; from poldi@andreas-c.de on Tue, May 22, 2001 at 03:18:33PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi Andreas,

I believe that (with God's help) i managed to marry xfs & mosix together.

If you have a machine for tests, check out files at:
    ftp://212.160.232.26/pub/linux/mosix/patches-2.4.4-xfs/

You'll find there xfs-changed patches.2.4.4 and kernel.new.2.4.4.tar files
(also gzipped). 'patches.2.4.4' applies to CVS linux-2.4-xfs dated 05/25/01
1400CEST, but i believe that will surely do with current CVS tree.
However I haven't checked yet if it works (i'll try to do it within not more
than 24hrs) - as far it passes ItCompilesForMe(TM) test ;)

I ain't a kernel developer but IMO (read it: as small as my knowledge is)
it should work ;> .

Cheers,
Krzysztof

On Tue, May 22, 2001 at 03:18:33PM +0200, poldi wrote:
> On Tue, 22 May 2001, Steve Lord wrote:
> 
> > >
> > > Hi Andreas,
> > >
> > > CVS Development snapshot is currently 2.4.4 based. So download CVS source
> > > tree and you'll have 2.4.4 <- that what you wanted. However I don't know how
> > > is it going to interact with Mosix patch, I think that  one of XFS
> > > developers should say something about potential problems (if any).
> >
> > Since I don't think any of us know anything about Mosix, I do not think
> > we can say anything one way or another. If someone can describe how Mosix
> > interacts with a filesystem we might be able to say something.
> >
> > Steve
> >
> > >
> > > Cheers,
> > > Krzysztof
> > >
> >
> >
> 
> See. www.mosix.org for more details on MOSIX and a Linux-Cluster.
> There is also a description how Mosix interacts with the Linux-Filesystem.
> 
> As I read some lines, I noticed out, that there is also an other
> filesystem, calles Mosix-Filesystem.
> May this helps you ?
> 
> Cheers
> 
> ------------------------------------------
> Andreas Cordes
> 
> Am Wiesenhof 145
> 26389 Wilhelmshaven
> 
>         Web : www.andreas-c.de
> Mail @ Home : info@andreas-c.de
>         UIN : 22895068
>        Cell : 0177/5776932
> ------------------------------------------
> 
> -=- If Linux doesn't have the solution -=-
> -=-     you have the wrong problem     -=-

From owner-linux-xfs@oss.sgi.com Fri May 25 09:54:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PGsnC03682
	for linux-xfs-outgoing; Fri, 25 May 2001 09:54:49 -0700
Received: from groupinfo.com (IDENT:root@groupinfo.com [35.12.129.253])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PGsmF03679
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 09:54:48 -0700
Received: from groupinfo.com ([35.12.129.200])
	by groupinfo.com (8.11.0/8.8.7) with ESMTP id f4PGsS518622
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:54:28 -0400
Message-ID: <3B0E8E5A.82EA5D59@groupinfo.com>
Date: Fri, 25 May 2001 12:54:50 -0400
From: Chris Szilagyi <chris@groupinfo.com>
Organization: Group InfoTech
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: XFS & RH 7.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

I recently installed Red Hat 7.1 using the SGI-XFS cd.  After
installation, I noticed that whenever I shutdown, the system gives an
error of "umount: /dev: device is busy" and complains it can't unmount
/dev.  From my experiences so far, this doesn't appear to happen if I
install with Red Hat's cd's, without using the SGI-XFS cd.

Everybody else I know that has installed Red Hat 7.1 with the SGI-XFS cd
has had the same problem, and we can't find an answer.  Are there any
issues that you know of about this or a fix for it?

Thanks,
--
Chris


From owner-linux-xfs@oss.sgi.com Fri May 25 10:12:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PHCsv04187
	for linux-xfs-outgoing; Fri, 25 May 2001 10:12:54 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PHCpF04184
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 10:12:52 -0700
Received: from lupo.thebarn.com (localhost [127.0.0.1])
	by lupo.thebarn.com (8.11.3/8.11.0) with ESMTP id f4PHCa820168;
	Fri, 25 May 2001 12:12:38 -0500 (CDT)
	(envelope-from cattelan@thebarn.com)
Date: Fri, 25 May 2001 12:12:36 -0500
Message-ID: <umevgmp1hff.wl@lupo.thebarn.com>
From: cattelan@thebarn.com
To: Chris Szilagyi <chris@groupinfo.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS & RH 7.1
In-Reply-To: <3B0E8E5A.82EA5D59@groupinfo.com>
References: <3B0E8E5A.82EA5D59@groupinfo.com>
User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)
MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At Fri, 25 May 2001 12:54:50 -0400,
Chris Szilagyi wrote:
> 
> Hello,
> 
> I recently installed Red Hat 7.1 using the SGI-XFS cd.  After
> installation, I noticed that whenever I shutdown, the system gives an
> error of "umount: /dev: device is busy" and complains it can't unmount
> /dev.  From my experiences so far, this doesn't appear to happen if I
> install with Red Hat's cd's, without using the SGI-XFS cd.
> 
> Everybody else I know that has installed Red Hat 7.1 with the SGI-XFS cd
> has had the same problem, and we can't find an answer.  Are there any
> issues that you know of about this or a fix for it?

This isn't a problem.
/dev is handled via devfs by default, and whatever reason does not
unmount at shutdown time, but since all devices are generated
internally by devfs nothing is lost by and unmount failure.

The easiest fix is to ignore the error. :-)
> 
> Thanks,
> --
> Chris

From owner-linux-xfs@oss.sgi.com Fri May 25 10:16:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PHGk204286
	for linux-xfs-outgoing; Fri, 25 May 2001 10:16:46 -0700
Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PHGVF04279
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 10:16:39 -0700
Received: (from kszysiu@localhost)
	by main.braxis.co.uk (8.9.3/8.9.3) id TAA14465;
	Fri, 25 May 2001 19:15:45 +0200
Date: Fri, 25 May 2001 19:15:44 +0200
From: Krzysztof Rusocki <kszysiu@braxis.co.uk>
To: Chris Szilagyi <chris@groupinfo.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS & RH 7.1
Message-ID: <20010525191544.A13407@main.braxis.co.uk>
References: <3B0E8E5A.82EA5D59@groupinfo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B0E8E5A.82EA5D59@groupinfo.com>; from chris@groupinfo.com on Fri, May 25, 2001 at 12:54:50PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi Chris,

Are you using devfs ?
Maybe you do have /dev on sepearate partition ?

I dunno if devfs is enabled by default in SGI-XFS,
if so, erasing line with /dev from /etc/fstab should solve
your problem (unless you have /dev on other partition)

It's only suggestion, i am not using RHS products since RHL7, neighter
SGI-XFS distribution.

Cheers,
Krzysztof

On Fri, May 25, 2001 at 12:54:50PM -0400, Chris Szilagyi wrote:
> Hello,
> 
> I recently installed Red Hat 7.1 using the SGI-XFS cd.  After
> installation, I noticed that whenever I shutdown, the system gives an
> error of "umount: /dev: device is busy" and complains it can't unmount
> /dev.  From my experiences so far, this doesn't appear to happen if I
> install with Red Hat's cd's, without using the SGI-XFS cd.
> 
> Everybody else I know that has installed Red Hat 7.1 with the SGI-XFS cd
> has had the same problem, and we can't find an answer.  Are there any
> issues that you know of about this or a fix for it?
> 
> Thanks,
> --
> Chris

From owner-linux-xfs@oss.sgi.com Fri May 25 10:26:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PHQx204825
	for linux-xfs-outgoing; Fri, 25 May 2001 10:26:59 -0700
Received: from linux.compucomis.net (IDENT:postfix@linux.CompuComIS.net [216.140.122.75])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PHQwF04821
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 10:26:58 -0700
Received: by linux.compucomis.net (Postfix, from userid 501)
	id BCE1913983; Fri, 25 May 2001 13:26:49 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
	by linux.compucomis.net (Postfix) with ESMTP
	id B473013982; Fri, 25 May 2001 13:26:49 -0400 (EDT)
Date: Fri, 25 May 2001 13:26:49 -0400 (EDT)
From: Mike Burger <mburger@compucomis.net>
To: Chris Szilagyi <chris@groupinfo.com>
Cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS & RH 7.1
In-Reply-To: <3B0E8E5A.82EA5D59@groupinfo.com>
Message-ID: <Pine.LNX.4.33.0105251326280.3555-100000@linux.compucomis.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

It's devfs.

It actually doesn't hurt anything.

On Fri, 25 May 2001, Chris Szilagyi wrote:

> Hello,
>
> I recently installed Red Hat 7.1 using the SGI-XFS cd.  After
> installation, I noticed that whenever I shutdown, the system gives an
> error of "umount: /dev: device is busy" and complains it can't unmount
> /dev.  From my experiences so far, this doesn't appear to happen if I
> install with Red Hat's cd's, without using the SGI-XFS cd.
>
> Everybody else I know that has installed Red Hat 7.1 with the SGI-XFS cd
> has had the same problem, and we can't find an answer.  Are there any
> issues that you know of about this or a fix for it?
>
> Thanks,
> --
> Chris
>
>


From owner-linux-xfs@oss.sgi.com Fri May 25 10:29:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PHTb204940
	for linux-xfs-outgoing; Fri, 25 May 2001 10:29:37 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4PHTaF04937
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 10:29:36 -0700
Received: (qmail 27897 invoked by uid 0); 25 May 2001 17:29:35 -0000
Received: from adsl-1-74.adsl.easynet.fr (HELO mail.gmx.de) (212.11.30.74)
  by mail.gmx.net (mail04) with SMTP; 25 May 2001 17:29:35 -0000
Message-ID: <200105251928090081.0181DC47@mail.gmx.de>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Fri, 25 May 2001 19:28:09 +0200
From: "linux" <dahouet@gmx.net>
To: linux-xfs@oss.sgi.com
Subject: cvs cmd pb compiling
Mime-Version: 1.0
Content-Type: text/plain; charset="WINDOWS-1250"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4PHTbF04938
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

i've updated my linux kernel with cvs today
i manage to compile the kernel succesfully 
but i can't compile the utils xfsdump in cmd directory

gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfsdump   arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stkchk.o stream.o util.o sproc.o attr.o inv_api.o inv_core.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o inomap.o var.o   -lhandle /usr/lib/libuuid.a ../librmt/librmt.a /usr/lib/libattr.a  
arch_xlate.o: In function `xlate_global_hdr':
/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64'
/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64'
arch_xlate.o: In function `xlate_content_inode_hdr':
/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64'
/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64'
/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: undefined reference to `__fswab64'
arch_xlate.o:/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: more undefined references to `__fswab64' follow
collect2: ld returned 1 exit status
make[1]: *** [xfsdump] Erreur 1
make: *** [default] Erreur 2


any idea ?
@++
nico


From owner-linux-xfs@oss.sgi.com Fri May 25 11:11:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PIB7U05933
	for linux-xfs-outgoing; Fri, 25 May 2001 11:11:07 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PIB6F05930
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 11:11:06 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4PI8rQ07288
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:08:54 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 25 May 2001 13:08:53 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS+chattr=no joy
Message-ID: <Pine.LNX.4.33.0105251305490.7272-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I get the following message when I try to chattr +i a file, anywhere, as
any user:

-----------Snip----------
[austin@UberGeek austin]$ touch test
[austin@UberGeek austin]$ chattr +ia test
chattr: Invalid argument while reading flags on test
-----------Snip----------
Any idea why that is?
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Fri May 25 11:49:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PInk207182
	for linux-xfs-outgoing; Fri, 25 May 2001 11:49:46 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PInjF07178
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 11:49:45 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4PIlSl01130
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:47:29 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 25 May 2001 13:47:28 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: USB+SGI cvs xfs kernel
Message-ID: <Pine.LNX.4.33.0105251346530.936-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I don't have a /proc/bus/usb/devices file. Has anyone else seen this?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Fri May 25 11:55:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PIts907791
	for linux-xfs-outgoing; Fri, 25 May 2001 11:55:54 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PItrF07788
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 11:55:53 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04654
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 11:55:55 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1950268; Fri, 25 May 2001 13:54:35 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA66725; Fri, 25 May 2001 13:54:35 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4PIvLG26811; Fri, 25 May 2001 13:57:22 -0500
Message-Id: <200105251857.f4PIvLG26811@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS+chattr=no joy 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Fri, 25 May 2001 13:08:53 CDT." <Pine.LNX.4.33.0105251305490.7272-100000@UberGeek.coremetrics.com> 
Date: Fri, 25 May 2001 13:57:21 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> I get the following message when I try to chattr +i a file, anywhere, as
> any user:
> 
> -----------Snip----------
> [austin@UberGeek austin]$ touch test
> [austin@UberGeek austin]$ chattr +ia test
> chattr: Invalid argument while reading flags on test
> -----------Snip----------
> Any idea why that is?


Well the short answer is:

CHATTR(1)                                               CHATTR(1)

NAME
       chattr - change file attributes on a Linux second extended
       file system

i.e. chattr is an ext2 specific command.

Steve



> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Fri May 25 12:11:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PJBEm08182
	for linux-xfs-outgoing; Fri, 25 May 2001 12:11:14 -0700
Received: from lupo.thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PJBBF08176
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:11:12 -0700
Received: (from cattelan@localhost)
	by lupo.thebarn.com (8.11.3/8.11.0) id f4PJB2Y20885;
	Fri, 25 May 2001 14:11:02 -0500 (CDT)
	(envelope-from cattelan)
From: Russell Cattelan <cattelan@thebarn.com>
MIME-Version: 1.0
Message-ID: <15118.44612.676944.703861@lupo.thebarn.com>
Date: Fri, 25 May 2001 14:11:00 -0500 (CDT)
To: linux-xfs@oss.sgi.com
Subject: No longer with SGI.
X-Mailer: VM 6.72 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
User-Agent: SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)
Content-Type: text/plain; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

As part of SGI's recent layoffs my contract with SGI has not
been renewed. 

Unfortunately this means I will not be working on XFS full time.
I do plan on staying active with  project as much as time permits, 
but given that I have not achieved "independently wealthy" :-) status 
I will have to find another contract.

I sure XFS will continue to grow and with all the recent community 
interest and support will become a valued part of the
Linux operating system.

-Russell Cattelan
DE inc.






From owner-linux-xfs@oss.sgi.com Fri May 25 12:19:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PJJXJ08465
	for linux-xfs-outgoing; Fri, 25 May 2001 12:19:33 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PJJWF08462
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:19:32 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4PJHH905515;
	Fri, 25 May 2001 14:17:17 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 25 May 2001 14:17:17 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: XFS+chattr=no joy 
In-Reply-To: <200105251857.f4PIvLG26811@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105251416520.936-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ahh..Sorry. Didn't realize that. I blew right by that when I looked at the
man page. DUH!. Thx

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Fri, 25 May 2001, Steve Lord wrote:

> > I get the following message when I try to chattr +i a file, anywhere, as
> > any user:
> >
> > -----------Snip----------
> > [austin@UberGeek austin]$ touch test
> > [austin@UberGeek austin]$ chattr +ia test
> > chattr: Invalid argument while reading flags on test
> > -----------Snip----------
> > Any idea why that is?
>
>
> Well the short answer is:
>
> CHATTR(1)                                               CHATTR(1)
>
> NAME
>        chattr - change file attributes on a Linux second extended
>        file system
>
> i.e. chattr is an ext2 specific command.
>
> Steve
>
>
>
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
>


From owner-linux-xfs@oss.sgi.com Fri May 25 12:31:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PJVGF08932
	for linux-xfs-outgoing; Fri, 25 May 2001 12:31:16 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PJVGF08925
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:31:16 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA27771
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:31:14 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA06827
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:31:13 -0700 (PDT)
Received: from [136.203.14.68] by blv-hub-01.boeing.com with ESMTP; Fri, 25 May 2001 12:31:04 -0700
Message-Id: <3B0EB2F7.1090404@pipcws.ca.boeing.com>
Date: Fri, 25 May 2001 12:31:03 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: No longer with SGI.
References: <15118.44612.676944.703861@lupo.thebarn.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Best of luck to you! You made many valuable contributions to XFS. I know 
that you'll be missed.

	Ric


Russell Cattelan wrote:

> As part of SGI's recent layoffs my contract with SGI has not
> been renewed. 
> 
> Unfortunately this means I will not be working on XFS full time.
> I do plan on staying active with  project as much as time permits, 
> but given that I have not achieved "independently wealthy" :-) status 
> I will have to find another contract.
> 
> I sure XFS will continue to grow and with all the recent community 
> interest and support will become a valued part of the
> Linux operating system.
> 
> -Russell Cattelan
> DE inc.
> 
> 
> 
> 
> 
> 




From owner-linux-xfs@oss.sgi.com Fri May 25 12:57:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PJvlq10024
	for linux-xfs-outgoing; Fri, 25 May 2001 12:57:47 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PJvkF10021
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:57:46 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA13219
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 12:57:46 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1950149 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:56:29 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA00137 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:56:29 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4PJxFF32582; Fri, 25 May 2001 14:59:15 -0500
Message-Id: <200105251959.f4PJxFF32582@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: Re: No longer with SGI. 
In-Reply-To: Message from Russell Cattelan <cattelan@thebarn.com> 
   of "Fri, 25 May 2001 14:11:00 CDT." <15118.44612.676944.703861@lupo.thebarn.com> 
Date: Fri, 25 May 2001 14:59:15 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,

I thought I should put something out on the list about this, I was waiting
for management approval to tell people, but maybe that was a little foolish.

So, yes, SGI had layoffs yesterday, and yes the XFS on linux project took
a hit because of this. However, we do intend to keep working on XFS linux,
and I do intend to work really hard to get it into the distributions and
Alan and Linus's kernels. It will take us a little while to regroup our
efforts and to work out our priorities on the project, hence my message
yesterday. We appear to be building momentum in the community right now,
and the last thing we need is less people to do the work, but financial
realities tend to take precedence in these situations.

I would like to thank Russell for all his contributions to the project, he
was one of the original two people working on the port (Jim Mostek was the
other) and did a lot of the early work of dragging the xfs code base out
of Irix. Russell also put in a lot of late night sessions working on the
code and dealing with questions from the list, and was instrumental in
the packaging of the 1.0 release. His full time contributions will be missed,
but hopefully he will have the time to make some contributions on his
own time.

I should also add that as part of the same budget cutting process SGI and
LinuxCare came to a mutual agreement to stop the contract for LinuxCare
helping out with the port. Martin Peterson also made many contributions,
and was and continues to be a valuble contact with the Linux community.
Martin (who I believe is travelling right now) has been doing Linux XFS
work on his own time for a few weeks now.

Steve (now officially swamped) Lord



> As part of SGI's recent layoffs my contract with SGI has not
> been renewed. 
> 
> Unfortunately this means I will not be working on XFS full time.
> I do plan on staying active with  project as much as time permits, 
> but given that I have not achieved "independently wealthy" :-) status 
> I will have to find another contract.
> 
> I sure XFS will continue to grow and with all the recent community 
> interest and support will become a valued part of the
> Linux operating system.
> 
> -Russell Cattelan
> DE inc.
> 
> 
> 
> 



From owner-linux-xfs@oss.sgi.com Fri May 25 13:31:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PKVis11409
	for linux-xfs-outgoing; Fri, 25 May 2001 13:31:44 -0700
Received: from vortex.xnote.com ([65.105.237.130])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PKVhF11406
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:31:43 -0700
Received: from mcpherve1 (slccheck01.firsthealth.com [209.180.88.28])
	by vortex.xnote.com (8.11.0/8.8.7) with SMTP id f4PJZqA14480
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:35:53 -0600
Reply-To: <vernon@xnote.com>
From: "Vernon McPherron" <vernon@xnote.com>
To: <linux-xfs@oss.sgi.com>
Subject: RE: No longer with SGI.
Date: Fri, 25 May 2001 14:32:36 -0600
Message-ID: <NFBBIABKBOFNBHMNALEPOEGECAAA.vernon@xnote.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <15118.44612.676944.703861@lupo.thebarn.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'd like to personally thank you for all the work you did.

I've followed XFS Linux development since it was first announced.  I'm
grateful to you and to all the SGI staff.  XFS for Linux is a wonderful gift
to us all.


-=/Vernon McPherron/=-

> -----Original Message-----
> From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On
> Behalf Of Russell Cattelan
> Sent: Friday, May 25, 2001 1:11 PM
> To: linux-xfs@oss.sgi.com
> Subject: No longer with SGI.
>
>
> As part of SGI's recent layoffs my contract with SGI has not
> been renewed.
>
> Unfortunately this means I will not be working on XFS full time.
> I do plan on staying active with  project as much as time permits,
> but given that I have not achieved "independently wealthy" :-) status
> I will have to find another contract.
>
> I sure XFS will continue to grow and with all the recent community
> interest and support will become a valued part of the
> Linux operating system.
>
> -Russell Cattelan
> DE inc.
>
>
>
>
>


From owner-linux-xfs@oss.sgi.com Fri May 25 13:32:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PKW4G11431
	for linux-xfs-outgoing; Fri, 25 May 2001 13:32:04 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PKW3F11428
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:32:03 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA18176
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:32:04 -0700 (PDT)
	mail_from (yili@sgi.com)
Received: from mtv-mven006e--n.engr.sgi.com (mtv-mven006e--n.engr.sgi.com [163.154.47.74])
	by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id NAA78591;
	Fri, 25 May 2001 13:30:37 -0700 (PDT)
Received: by mtv-mven006e--n.engr.sgi.com with Internet Mail Service (5.5.2653.19)
	id <KW4484XZ>; Fri, 25 May 2001 13:29:17 -0700
Message-ID: <DAC15315620ED51187140060943F47A927FDA0@mtv-mven006e--n.engr.sgi.com>
From: Yi Li <yili@sgi.com>
To: "'Steve Lord'" <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: RE: No longer with SGI. 
Date: Fri, 25 May 2001 13:29:09 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi all,

Just to add to Steve's comment, I am responsible for product managament on
XFS Linux, which is continuing as before.

We are really glad to see the growing interest and momentum on XFS Linux
within the community, and we appreciate very much the time and effort from
XFS users. 

SGI is committed to the XFS open source project, as in our other open source
projects. We will be maintaining XFS on IA32 as well as developing XFS for
IA64 as before.

Yi 

-------------------------------------------
Yi Li
Product Manager
File Systems and Networking, SGI
Phone: 650-933-6639
Fax: 650-933-0701
http://oss.sgi.com/projects/xfs/index.html


-----Original Message-----
From: Steve Lord [mailto:lord@sgi.com]
Sent: Friday, May 25, 2001 12:59 PM
To: linux-xfs@oss.sgi.com
Subject: Re: No longer with SGI. 



Hi,

I thought I should put something out on the list about this, I was waiting
for management approval to tell people, but maybe that was a little foolish.

So, yes, SGI had layoffs yesterday, and yes the XFS on linux project took
a hit because of this. However, we do intend to keep working on XFS linux,
and I do intend to work really hard to get it into the distributions and
Alan and Linus's kernels. It will take us a little while to regroup our
efforts and to work out our priorities on the project, hence my message
yesterday. We appear to be building momentum in the community right now,
and the last thing we need is less people to do the work, but financial
realities tend to take precedence in these situations.

I would like to thank Russell for all his contributions to the project, he
was one of the original two people working on the port (Jim Mostek was the
other) and did a lot of the early work of dragging the xfs code base out
of Irix. Russell also put in a lot of late night sessions working on the
code and dealing with questions from the list, and was instrumental in
the packaging of the 1.0 release. His full time contributions will be
missed,
but hopefully he will have the time to make some contributions on his
own time.

I should also add that as part of the same budget cutting process SGI and
LinuxCare came to a mutual agreement to stop the contract for LinuxCare
helping out with the port. Martin Peterson also made many contributions,
and was and continues to be a valuble contact with the Linux community.
Martin (who I believe is travelling right now) has been doing Linux XFS
work on his own time for a few weeks now.

Steve (now officially swamped) Lord

From owner-linux-xfs@oss.sgi.com Fri May 25 13:46:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PKkpR12097
	for linux-xfs-outgoing; Fri, 25 May 2001 13:46:51 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PKkoF12094
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:46:50 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA26887
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 13:46:51 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1953418 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 15:45:33 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA86040 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 15:39:15 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4PKg1M21204; Fri, 25 May 2001 15:42:01 -0500
Message-Id: <200105252042.f4PKg1M21204@jen.americas.sgi.com>
Date: Fri, 25 May 2001 15:42:01 -0500
Subject: TAKE - fix panic caused by mix of local and remote access to xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This problem was reported to the list a while ago as 

	"Errors using amanda/xfsdump" by Justin Tripp. 

It proved to be a nasty problem which has been in there since the original
implementation, it is a hang over from an Irix / Linux different in what
comes first, the fs specific data or the fs independent data.

This is a reworking of the implementation based on a suggestion by Al Viro
to the linux-fsdevel list last year, thanks to Chris Mason for pointing
me at it.

I have pounded on it here, and so far I do not have any regressions.
Since this places us more in line with the way other linux filesystems
do things, and removes some code, it is obviously correct ;-). However,
please let me know if odd things start to happen to your machine
after you start using this code.

Steve

Date:  Fri May 25 13:33:07 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95990a
linux/kernel/ksyms.c - 1.89
	- Export icreate4 unlock_new_inode to modules

linux/include/linux/fs.h - 1.93
	- Add new prototype for icreate4 and unlock_new_inode

linux/fs/inode.c - 1.40
	- Replace the xfs special ihold4 with icreate4 - this is a function
	  closer to iget, except it does not call read_inode but returns
	  a locked hashed inode for the caller to fill in. create_new_inode
	  was restructured some to allow for code reuse.

linux/fs/xfs/xfs_iget.c - 1.142
	- Restructure xfs / linux inode interface, we used to have a deadlock case
	  which we recognised with a panic. When xfs needs a new inode internally
	  it goes through icreate, and if this returns a new inode, it calls xfs_iget_core
	  to read the xfs inode off disk and fill it in. Various other cleanups as
	  a result of this.

linux/fs/xfs/xfs_inode.h - 1.149
	- prototype change

linux/fs/xfs/linux/xfs_vnode.c - 1.64
	- Restructure xfs / linux inode interface, we used to have a deadlock case
	  which we recognised with a panic. When xfs needs a new inode internally
	  it goes through icreate, and if this returns a new inode, it calls xfs_iget_core
	  to read the xfs inode off disk and fill it in. Various other cleanups as
	  a result of this.

linux/fs/xfs/linux/xfs_vnode.h - 1.20
	- Prototype changes and removals due to reworked interface



From owner-linux-xfs@oss.sgi.com Fri May 25 14:01:43 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PL1h112757
	for linux-xfs-outgoing; Fri, 25 May 2001 14:01:43 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PL1hF12754
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:01:43 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA01910
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:01:42 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA1951261 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 16:00:19 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA14901 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 16:00:18 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4PL34u26306; Fri, 25 May 2001 16:03:04 -0500
Message-Id: <200105252103.f4PL34u26306@jen.americas.sgi.com>
Date: Fri, 25 May 2001 16:03:04 -0500
Subject: TAKE - fix iget statistics
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

In watching things run I realized I was accounting for something twice,
this fixes the statistics and nothing else.

Date:  Fri May 25 13:59:15 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95992a
linux/fs/xfs/xfs_iget.c - 1.143
	- Fix statistics kept on inode lookup calls - we were double counting one case



From owner-linux-xfs@oss.sgi.com Fri May 25 14:47:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PLlld14292
	for linux-xfs-outgoing; Fri, 25 May 2001 14:47:47 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PLlkF14289
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:47:46 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 153PQr-0000TC-00; Sat, 26 May 2001 09:47:41 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Bruce Tenison" <btenison@earthlink.net>
Cc: <utz@s2y4n2c.de>, <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Sat, 26 May 2001 09:47:07 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIOEEGCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.LNX.4.33.0105250746000.5021-100000@tenison.irstc.cc.al.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: using it on a
:: VIA vt82c596b (rev 23) chipset, both showing the same style corruption
:: problems.  Something's amiss!

That's what we've got in common -- the VIA chip set. Nothing but trouble
with that, to be honest. Memory performance is slower than on 440BX chip
sets (trying to work out how to tweak the PCI registers with setpci so as to
enable memory interleaving) and the IDE interface works poorly.

Also discovered that there's an issue with the IO-APIC and Linux. If I
disable it (append="noapic" in lilo.conf or at the boot prompt), I don't see
the weird slowdown in disk performance.



-- Juha


From owner-linux-xfs@oss.sgi.com Fri May 25 14:56:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PLuCf14724
	for linux-xfs-outgoing; Fri, 25 May 2001 14:56:12 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PLuBF14721
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 14:56:12 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 153PZ1-0000TP-00; Sat, 26 May 2001 09:56:07 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Russell Cattelan" <cattelan@thebarn.com>, <linux-xfs@oss.sgi.com>
Subject: RE: No longer with SGI.
Date: Sat, 26 May 2001 09:55:33 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIIEEHCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <15118.44612.676944.703861@lupo.thebarn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: As part of SGI's recent layoffs my contract with SGI has not
:: been renewed. 
:: 
:: Unfortunately this means I will not be working on XFS full time.
:: I do plan on staying active with  project as much as time permits, 
:: but given that I have not achieved "independently wealthy" :-) status 
:: I will have to find another contract.
:: 
:: I sure XFS will continue to grow and with all the recent community 
:: interest and support will become a valued part of the
:: Linux operating system.

Good luck Russell, and thanks for all the support and work you've put in.

Cheers,

-- Juha

From owner-linux-xfs@oss.sgi.com Fri May 25 15:33:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PMX3p15837
	for linux-xfs-outgoing; Fri, 25 May 2001 15:33:03 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PMX1F15834
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 15:33:01 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA796582
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 00:32:58 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1945445 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:31:42 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA33344 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:31:42 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4PMYQC28777; Fri, 25 May 2001 17:34:27 -0500
Message-Id: <200105252234.f4PMYQC28777@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to xfs 
In-Reply-To: Message from Steve Lord <lord@sgi.com> 
   of "Fri, 25 May 2001 15:42:01 CDT." <200105252042.f4PKg1M21204@jen.americas.sgi.com> 
Date: Fri, 25 May 2001 17:34:26 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Sod's law says you find the hole right after you ship the code. There is a
bug in this code, I would not do a cvs update until I get a fix in, I know
roughly how to fix it, but it will take me a while to code and test it.

I would hold off on the cvs tree for a while until you see another message
from me on this thread - probably not today.

Steve

> This problem was reported to the list a while ago as 
> 
> 	"Errors using amanda/xfsdump" by Justin Tripp. 
> 
> It proved to be a nasty problem which has been in there since the original
> implementation, it is a hang over from an Irix / Linux different in what
> comes first, the fs specific data or the fs independent data.
> 
> This is a reworking of the implementation based on a suggestion by Al Viro
> to the linux-fsdevel list last year, thanks to Chris Mason for pointing
> me at it.
> 
> I have pounded on it here, and so far I do not have any regressions.
> Since this places us more in line with the way other linux filesystems
> do things, and removes some code, it is obviously correct ;-). However,
> please let me know if odd things start to happen to your machine
> after you start using this code.
> 
> Steve
> 
> Date:  Fri May 25 13:33:07 PDT 2001
> Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4
> 
> The following file(s) were checked into:
>   bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs
> 
> 
> Modid:  2.4.x-xfs:slinx:95990a
> linux/kernel/ksyms.c - 1.89
> 	- Export icreate4 unlock_new_inode to modules
> 
> linux/include/linux/fs.h - 1.93
> 	- Add new prototype for icreate4 and unlock_new_inode
> 
> linux/fs/inode.c - 1.40
> 	- Replace the xfs special ihold4 with icreate4 - this is a function
> 	  closer to iget, except it does not call read_inode but returns
> 	  a locked hashed inode for the caller to fill in. create_new_inode
> 	  was restructured some to allow for code reuse.
> 
> linux/fs/xfs/xfs_iget.c - 1.142
> 	- Restructure xfs / linux inode interface, we used to have a deadlock c
> ase
> 	  which we recognised with a panic. When xfs needs a new inode internal
> ly
> 	  it goes through icreate, and if this returns a new inode, it calls xf
> s_iget_core
> 	  to read the xfs inode off disk and fill it in. Various other cleanups
>  as
> 	  a result of this.
> 
> linux/fs/xfs/xfs_inode.h - 1.149
> 	- prototype change
> 
> linux/fs/xfs/linux/xfs_vnode.c - 1.64
> 	- Restructure xfs / linux inode interface, we used to have a deadlock c
> ase
> 	  which we recognised with a panic. When xfs needs a new inode internal
> ly
> 	  it goes through icreate, and if this returns a new inode, it calls xf
> s_iget_core
> 	  to read the xfs inode off disk and fill it in. Various other cleanups
>  as
> 	  a result of this.
> 
> linux/fs/xfs/linux/xfs_vnode.h - 1.20
> 	- Prototype changes and removals due to reworked interface
> 



From owner-linux-xfs@oss.sgi.com Fri May 25 15:35:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PMZ0S15898
	for linux-xfs-outgoing; Fri, 25 May 2001 15:35:00 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PMYxF15895
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 15:34:59 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id AAA801792
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 00:34:57 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA1953268 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:33:40 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA91267 for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:33:40 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4PMaPd28846; Fri, 25 May 2001 17:36:25 -0500
Message-Id: <200105252236.f4PMaPd28846@jen.americas.sgi.com>
Date: Fri, 25 May 2001 17:36:25 -0500
Subject: TAKE -  should fix ppc module build
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This changes pagebuf to use the __exit directive everywhere rather
than using #if MODULE in some places and __exit in others. This was
a problem on the ppc where I suspect __exit has no effect.

Date:  Fri May 25 15:32:42 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95993a
linux/fs/pagebuf/page_buf.c - 1.83
linux/fs/pagebuf/page_buf_locking.c - 1.12
linux/fs/pagebuf/avl.c - 1.4
	- Use __exit consistently in pagebuf code rather than #if MODULE



From owner-linux-xfs@oss.sgi.com Fri May 25 16:41:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4PNfmq17784
	for linux-xfs-outgoing; Fri, 25 May 2001 16:41:48 -0700
Received: from walt400.holman.net ([63.228.97.139])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4PNflF17781
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 16:41:47 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP
	id 119D640EFD6; Fri, 25 May 2001 16:50:44 -0700 (PDT)
Message-ID: <3B0EEFD4.4000005@uswest.net>
Date: Fri, 25 May 2001 16:50:44 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.9+) Gecko/20010523
X-Accept-Language: en
MIME-Version: 1.0
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: No longer with SGI.
References: <15118.44612.676944.703861@lupo.thebarn.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Take care Russell.  I've been mostly a lurker on the ml, but I wanted to 
mention that I really appreciate what you and others have done here. 
Thanks to SGI and everyone involved, we (the linux community) have a 
fantastic jfs which IMHO is the best available. Thanks again,

-Walt



Russell Cattelan wrote:

>As part of SGI's recent layoffs my contract with SGI has not
>been renewed. 
>
>Unfortunately this means I will not be working on XFS full time.
>I do plan on staying active with  project as much as time permits, 
>but given that I have not achieved "independently wealthy" :-) status 
>I will have to find another contract.
>
>I sure XFS will continue to grow and with all the recent community 
>interest and support will become a valued part of the
>Linux operating system.
>
>-Russell Cattelan
>DE inc.
>
>
>
>
>
>



From owner-linux-xfs@oss.sgi.com Fri May 25 17:38:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4Q0ccP19374
	for linux-xfs-outgoing; Fri, 25 May 2001 17:38:38 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4Q0cbF19371
	for <linux-xfs@oss.sgi.com>; Fri, 25 May 2001 17:38:37 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4Q0cEsd014533;
	Fri, 25 May 2001 17:38:14 -0700
Date: Fri, 25 May 2001 17:38:14 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Nathan Scott <nathans@wobbly.melbourne.sgi.com>
cc: linux-xfs@oss.sgi.com, lord@sgi.com
Subject: Re: XFS 1.0/Quota
In-Reply-To: <10105211503.ZM89802@wobbly.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0105251736200.276-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just tested out the latest CVS tree and quotacheck worked.  As far as I
can tell quota is working.  

Stats of machine:
256Mb Ram
350Gb xfs

Thank You.

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Mon, 21 May 2001, Nathan Scott wrote:

> hi Walter,
> 
> On May 19,  3:13pm, marchuk@ee.washington.edu wrote:
> > Subject: Re: XFS 1.0/Quota
> > Ok, I downloaded the latest CVS tree which contained the two files that
> > you put in a few days ago.  It still was getting stuck, after a few
> > minutes disk activity would stop and the whole machine would freeze.  Now
> > while it was doing the quotacheck and before it crashed i was doing
> > "free" to monitor the memory.  The memory was fluctuating, going back and
> > forth, which would mean that it was not eating up all the memory..it still
> > crashed.
> > 
> > So I mounted in a single user mode and saw the same error, process run out
> > of memory killing program.
> > 
> 
> Hmmm - ok, I'll try reproduce it here again - I've also
> found an anomoly in that /proc/slabinfo output you sent me
> which I'm discussing with Steve & Ananth (xfs/vm gurus),
> so hopefully something will come of that.
> 
> Thanks for your help so far - if you do manage to capture
> xqmstats output during a quotacheck on this fs, that would
> still be of great interest to me.
> 
> cheers.
> 
> -- 
> Nathan
> 


From owner-linux-xfs@oss.sgi.com Sat May 26 13:13:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QKDjF11627
	for linux-xfs-outgoing; Sat, 26 May 2001 13:13:45 -0700
Received: from basilio.i-manila.com.ph ([208.155.152.19])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QKDhd11624
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 13:13:44 -0700
Received: from sisa.i-manila.com.ph (sisa.i-manila.com.ph [208.155.152.18])
	by basilio.i-manila.com.ph (8.10.2/8.10.2) with SMTP id f4Q1eEl18463
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 09:40:14 +0800
Received: from mail ([203.167.1.193]) by sisa.i-manila.com.ph ; Sat, 26 May 2001 09:40:14 +0800 GMT
Received: from kalapati (kalapati.linux-server.tlc [192.168.0.201])
	by mail (Postfix) with ESMTP id BC05A4461
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 09:39:57 +0800 (PHT)
Received: from localhost (kalapati.jijo.local [127.0.0.1])
	by kalapati (Postfix) with ESMTP id D5AF0463E36
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 09:40:00 +0800 (PHT)
Date: Sat, 26 May 2001 09:40:00 +0800 (PHT)
From: Federico Sevilla III <jijo@i-manila.com.ph>
X-Sender: jijo@kalapati.jijo.local
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
Subject: Re: Backlog on the list....
In-Reply-To: <200105241901.f4OJ1Ao18437@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105260936150.434-100000@kalapati.jijo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 24 May 2001 at 14:01, Steve Lord wrote:
> If you are following the linux-xfs list you have probably noticed
> there are lots of people asking questions, reporting problems etc.

Just in case you wanted feedback, yes, I noticed this, too. ;>

> I always try to be responsive, but at the moment, the incoming rate is
> a lot higher than we have the bandwidth to cope with. So I would be
> grateful if people out on the list can help each other out when it
> comes to configuration questions and the like so we can get our heads
> down in the problem fixing end of the business.

I don't know how good a suggestion this is, but maybe you'd be interested
in creating a mailing list for developers to discuss the "real" issues.
Perhaps you can have <linux-xfs@oss.sgi.com> be for the users (of course
you'll still be there and will hopefully help out when you've got time)
and stuff like installation problems, et al.

Then you can have a <linux-xfs-devel@oss.sgi.com> mailing list for
primarily developer-related issues. This can probably be where you'll find
all those TAKE's, high-level performance discussions (?) and of course,
bugs and various people giving input on how to handle them.

There will of course be topics that should be in the developer's mailing
list that will first find their way to the main list. These can probably
be cc'd and the thread transferred when appropriate.

:)

 --> Jijo

--
Linux, MS-DOS, and Windows NT ...
... also known as the Good, the Bad, and the Ugly


From owner-linux-xfs@oss.sgi.com Sat May 26 13:57:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QKvB312393
	for linux-xfs-outgoing; Sat, 26 May 2001 13:57:11 -0700
Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QKvAd12390
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 13:57:10 -0700
Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192])
	by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id FAA30933;
	Sat, 26 May 2001 05:06:16 -0400
Message-ID: <3B0F762B.FBA0B3C0@ieee.org>
Date: Sat, 26 May 2001 05:23:55 -0400
From: "Bryan J. Smith" <b.j.smith@ieee.org>
Organization: SmithConcepts, Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Long time no post:  SourceForge, RedHat Avenue, kernel "jealousy"
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Long time no post:  SourceForge, RedHat Avenue

Two quick, non-technical issues ...

1.  I see there is now an official XFS project page at
SourceForge.NET.  I cannot seem to track down the individuals I need
to talk to to shut down my [accidental] "xfs4rh" project page.

2.  Has RedHat taken any interest in a beta program or other early
adopter attitude towards XFS?  If not, how about VA Linux?  Anyone
know of the status of the Ext3 port to kernel 2.4 (and if that is
what either are waiting on)?  I submitted some "Request For
Enhancement" Bugzilla tickets at the request of one of their
employees (mainly just package additions that they'll probably favor
for at least the Powertools CD), but I'm wondering if the RFE c/o
Bugzilla route might be a good way to poke them on XFS as well? **

3.  Did anyone read Hans Reiser's comments on non-ReiserFS
"jealousy" that it was adopted in kernel 2.4.1 (while others were
not)?  I'm sure he's got his reasons (I can think of one my own
posts where he saw such attitudes ;-), but I'm still curious as to
why XFS has not been considered for adoption into the stock kernel
yet myself (or at least considered, please tell me if this is no
longer true)?  Maybe that is what RedHat is ultimately waiting on?

Oh well, enough non-developer crap from me (not that I got any
developer crap anyway ;-).

-- TheBS

** Disclaimer:  I'm not here to incite any "JFS holy war" (God knows
I've had my share of "ReiserFS absolutists" on a couple of local
LUGs lately ;-).  I just figured RedHat/VALinux might be "waiting
on" Ext3 for 2.4 as they see it as a "more manageable, evolutionary"
(i.e. "safer" in their eyes, regardless of the merit of the argument
in reality) JFS for the final installment of the RedHat 7 series (or
not)?

-- 
Bryan J. Smith, President        mailto:b.j.smith@ieee.org
(407)366-7013 pager:(888)694-5793 chat:thebs413@AOL/MS/Yho
==========================================================
SmithConcepts, Inc.           http://www.SmithConcepts.com
        Consulting Engineers and IT Professionals

From owner-linux-xfs@oss.sgi.com Sat May 26 14:11:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QLBfY13091
	for linux-xfs-outgoing; Sat, 26 May 2001 14:11:41 -0700
Received: from ostrich.mail.pas.earthlink.net (ostrich.mail.pas.earthlink.net [207.217.120.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QLBfd13088
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 14:11:41 -0700
Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by ostrich.mail.pas.earthlink.net (8.9.3/8.9.3) with ESMTP id IAA02514
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 08:31:45 -0700 (PDT)
Received: from earthlink.net (1Cust161.tnt1.bay-minette.al.da.uu.net [63.29.15.161])
	by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id IAA23086;
	Sat, 26 May 2001 08:31:27 -0700 (PDT)
Message-ID: <3B0FCC24.50903@earthlink.net>
Date: Sat, 26 May 2001 10:30:44 -0500
From: Bruce Tenison <btenison@earthlink.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.9) Gecko/20010507
X-Accept-Language: en
MIME-Version: 1.0
To: Juha Saarinen <juha@saarinen.org>
CC: linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
References: <LGECJLHBGAPMGAJFMAFIOEEGCAAA.juha@saarinen.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Strange.  I'm experiencing the same problem on a Promise PDC20262 
controller card too!
Another thing, is that I've never, well...  mostly never ;) , 
experienced problems with other filesystems
on either chipset (I know there are issues with the VIA stuff, had 
problems with the USB stuff too,
makes me wonder why I bought the MB in the first place...)

Anyway, I'm gonna try and use a different drive and see if I experience 
the same problems.  Using a seperate
partition, mounted on my ext2 root, I haven't been able to make it 
fail.  Gonna install RH 71 on the XFS
partition and make it a root, and see if it'll fail there (as it does on 
my Fujitsu drive)

Juha Saarinen wrote:

>:: using it on a
>:: VIA vt82c596b (rev 23) chipset, both showing the same style corruption
>:: problems.  Something's amiss!
>
>That's what we've got in common -- the VIA chip set. Nothing but trouble
>with that, to be honest. Memory performance is slower than on 440BX chip
>sets (trying to work out how to tweak the PCI registers with setpci so as to
>enable memory interleaving) and the IDE interface works poorly.
>
>Also discovered that there's an issue with the IO-APIC and Linux. If I
>disable it (append="noapic" in lilo.conf or at the boot prompt), I don't see
>the weird slowdown in disk performance.
>
>
>
>-- Juha
>
>




From owner-linux-xfs@oss.sgi.com Sat May 26 14:32:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QLWK613715
	for linux-xfs-outgoing; Sat, 26 May 2001 14:32:20 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QLWJd13712
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 14:32:19 -0700
Received: from qn-212-58-163-195.quicknet.nl ([212.58.163.195]:64075 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S50963AbREZK61>;
	Sat, 26 May 2001 12:58:27 +0200
Message-Id: <4.3.2.7.2.20010526125350.030599d0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Sat, 26 May 2001 12:58:24 +0200
To: linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Kernel madness ensuing
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi,

With all the madness currently going on at SGI the last thing you need is 
that Linus releases 2.4.5.

Somebody should shoot murphy.

Steve, can you give a rough time schedule in which you think everything is 
regrouped over there for work to continue.
Would a week be a reasonable time? ;)

Bye
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Sat May 26 14:52:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QLqtY14317
	for linux-xfs-outgoing; Sat, 26 May 2001 14:52:55 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QLqsd14314
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 14:52:54 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4QLqpR08756;
	Sat, 26 May 2001 16:52:51 -0500 (CDT)
Message-ID: <3B102675.B6C6C741@sgi.com>
Date: Sat, 26 May 2001 16:56:05 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: Kernel madness ensuing
References: <4.3.2.7.2.20010526125350.030599d0@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:

> With all the madness currently going on at SGI the last thing you need is
> that Linus releases 2.4.5.
> 
> Somebody should shoot murphy.
> 
> Steve, can you give a rough time schedule in which you think everything is
> regrouped over there for work to continue.
> Would a week be a reasonable time? ;)

Hi Seth - 

I'm working on a 2.4.5 merge right now, but this is my first attempt to
become Russell-like, so it may take a bit more time than usual.  :) 
Once I have something the looks good, I can put up a "testing" patch.

Oh, but I'm also moving across the country in about 5 days, so I won't
be at peak efficiency for a while.  If it's not done before then,
perhaps I can convince Steve to pick it up.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sat May 26 15:01:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QM1XH14758
	for linux-xfs-outgoing; Sat, 26 May 2001 15:01:33 -0700
Received: from home.smithconcepts.com (ubr-35.28.151.oviedo.cfl.rr.com [65.35.28.151])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QM1Wd14755
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 15:01:32 -0700
Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192])
	by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id RAA07681;
	Sat, 26 May 2001 17:55:41 -0400
Message-ID: <3B102A81.362BBBC6@ieee.org>
Date: Sat, 26 May 2001 18:13:21 -0400
From: "Bryan J. Smith" <b.j.smith@ieee.org>
Organization: SmithConcepts, Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: My XFS /. post ...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

My XFS /. post ...

With the exception of a few typos, and use of XFS when I meant NFS a
couple of times, I have written a /. post that has gotten moderated
up to 5, and a large amount of direct E-mails (all positive --
unbelievable!).  My faith in /. has been restored admist an almost
absolute boycott by myself over the past 6 months.

The post directly asks RedHat and VALinux to start looking at
supporting XFS.  I'll let the rest of the detailed, 12 point post
speak for itself:

  http://slashdot.org/comments.pl?sid=01/05/26/0743254&cid=86

-- TheBS, a very satisifed SGI and XFS customer

-- 
Bryan J. Smith, President        mailto:b.j.smith@ieee.org
(407)366-7013 pager:(888)694-5793 chat:thebs413@AOL/MS/Yho
==========================================================
SmithConcepts, Inc.           http://www.SmithConcepts.com
        Consulting Engineers and IT Professionals

From owner-linux-xfs@oss.sgi.com Sat May 26 16:33:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QNXVM16665
	for linux-xfs-outgoing; Sat, 26 May 2001 16:33:31 -0700
Received: from walt400.holman.net ([63.226.230.146])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QNXTd16662
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 16:33:30 -0700
Received: from uswest.net (walt400.holman.net [10.0.0.2])
	by walt400.holman.net (Postfix) with ESMTP
	id 0D52140F035; Sat, 26 May 2001 16:42:20 -0700 (PDT)
Message-ID: <3B103F5B.2090207@uswest.net>
Date: Sat, 26 May 2001 16:42:19 -0700
From: Walt H <waltabbyh@uswest.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.9+) Gecko/20010525
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Tenison <btenison@earthlink.net>
Cc: Juha Saarinen <juha@saarinen.org>, linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
References: <LGECJLHBGAPMGAJFMAFIOEEGCAAA.juha@saarinen.org> <3B0FCC24.50903@earthlink.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

Just wanted to chime in with a FWIW post :)

I've also got a Promise PDC 20262 w/ an IBM Deskstar running in UDMA 
mode 4 w/ no problems whatsoever. Additionally a Maxtor Diamond Max 
connected to the stock BX MB w/ no problems. Early on (5-6 months ago) I 
did experience some minor corruption problems with the Maxtor connected 
directly to the mainboard, but never anything with the IBM on the 
Promise card. That thing's been solid. All fs's are XFS except boot 
which is reiserfs.

-Walt


Bruce Tenison wrote:

> Strange.  I'm experiencing the same problem on a Promise PDC20262 
> controller card too!
> Another thing, is that I've never, well...  mostly never ;) , 
> experienced problems with other filesystems
> on either chipset (I know there are issues with the VIA stuff, had 
> problems with the USB stuff too,
> makes me wonder why I bought the MB in the first place...)
>
> Anyway, I'm gonna try and use a different drive and see if I 
> experience the same problems.  Using a seperate
> partition, mounted on my ext2 root, I haven't been able to make it 
> fail.  Gonna install RH 71 on the XFS
> partition and make it a root, and see if it'll fail there (as it does 
> on my Fujitsu drive)
>
> Juha Saarinen wrote:
>
>> :: using it on a
>> :: VIA vt82c596b (rev 23) chipset, both showing the same style 
>> corruption
>> :: problems.  Something's amiss!
>>
>> That's what we've got in common -- the VIA chip set. Nothing but trouble
>> with that, to be honest. Memory performance is slower than on 440BX chip
>> sets (trying to work out how to tweak the PCI registers with setpci 
>> so as to
>> enable memory interleaving) and the IDE interface works poorly.
>>
>> Also discovered that there's an issue with the IO-APIC and Linux. If I
>> disable it (append="noapic" in lilo.conf or at the boot prompt), I 
>> don't see
>> the weird slowdown in disk performance.
>>
>>
>>
>> -- Juha
>>
>>
>
>
>
>



From owner-linux-xfs@oss.sgi.com Sat May 26 16:55:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4QNtdF17252
	for linux-xfs-outgoing; Sat, 26 May 2001 16:55:39 -0700
Received: from antares.cedar.buffalo.edu (antares.cedar.Buffalo.EDU [128.205.33.2])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4QNtcd17249
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 16:55:38 -0700
Received: (qmail 29193 invoked from network); 26 May 2001 14:55:32 -0000
Received: from zaurak.cedar.buffalo.edu (128.205.33.110)
  by antares.cedar.buffalo.edu with SMTP; 26 May 2001 14:55:32 -0000
Received: (from ajay@localhost)
	by zaurak.cedar.buffalo.edu (8.9.3+Sun/8.9.3) id KAA08099;
	Sat, 26 May 2001 10:55:31 -0400 (EDT)
Date: Sat, 26 May 2001 10:55:31 -0400
From: Ajay Shekhawat <ajay@cedar.Buffalo.EDU>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: No longer with SGI.
Message-ID: <20010526105531.A8095@zaurak.cedar.buffalo.edu>
References: <15118.44612.676944.703861@lupo.thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <15118.44612.676944.703861@lupo.thebarn.com>; from cattelan@thebarn.com on Fri, May 25, 2001 at 02:11:00PM -0500
Organization: Center for Document Analysis and Recognition
X-OfficePhone: +1 (716)-645-6164 ext. 101
X-Fax-Number: +1 (716)-645-6176
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Russell,
I would like to add my voice to the chorus of "Thank you"s, and wish
you all the best in your future endeavors.  You (and the XFS team)
have done a tremendous job bringing XFS to Linux.

Ajay


From owner-linux-xfs@oss.sgi.com Sat May 26 18:02:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R127b18336
	for linux-xfs-outgoing; Sat, 26 May 2001 18:02:07 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R126d18328
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:02:06 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 153ms9-0002lh-01; Sun, 27 May 2001 10:49:25 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Bruce Tenison" <btenison@earthlink.net>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Sun, 27 May 2001 10:48:56 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIKEFFCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B0FCC24.50903@earthlink.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Strange.  I'm experiencing the same problem on a Promise PDC20262
:: controller card too!
:: Another thing, is that I've never, well...  mostly never ;) ,
:: experienced problems with other filesystems
:: on either chipset (I know there are issues with the VIA stuff, had
:: problems with the USB stuff too,
:: makes me wonder why I bought the MB in the first place...)
::
:: Anyway, I'm gonna try and use a different drive and see if I experience
:: the same problems.  Using a seperate
:: partition, mounted on my ext2 root, I haven't been able to make it
:: fail.  Gonna install RH 71 on the XFS
:: partition and make it a root, and see if it'll fail there (as it does on
:: my Fujitsu drive)

Try booting with noapic on the command line, to see if the problems go away.

Never again VIA for me...

-- Juha


From owner-linux-xfs@oss.sgi.com Sat May 26 18:02:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R126G18329
	for linux-xfs-outgoing; Sat, 26 May 2001 18:02:06 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R125d18325
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:02:05 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with smtp (Exim 3.22 #1 (Red Hack))
	id 153nju-0002pC-01; Sun, 27 May 2001 11:44:58 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "Walt H" <waltabbyh@uswest.net>, "Bruce Tenison" <btenison@earthlink.net>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Sun, 27 May 2001 11:44:28 +1200
Message-ID: <LGECJLHBGAPMGAJFMAFIEEFJCAAA.juha@saarinen.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B103F5B.2090207@uswest.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: I've also got a Promise PDC 20262 w/ an IBM Deskstar running in UDMA
:: mode 4 w/ no problems whatsoever. Additionally a Maxtor Diamond Max
:: connected to the stock BX MB w/ no problems. Early on (5-6 months ago) I

Yep... you're using a BX440 motherboard. Bruce and I have VIA chip set ones.
I really, really, really regret buying that Tyan motherboard. :-(

-- Juha


From owner-linux-xfs@oss.sgi.com Sat May 26 18:55:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R1tvF19410
	for linux-xfs-outgoing; Sat, 26 May 2001 18:55:57 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R1tud19407
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:55:56 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA08872
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:55:59 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA1959452; Sat, 26 May 2001 20:54:39 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA14416; Sat, 26 May 2001 20:54:38 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4R1vAF31429; Sat, 26 May 2001 20:57:10 -0500
Message-Id: <200105270157.f4R1vAF31429@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Bryan J. Smith" <b.j.smith@ieee.org>
cc: linux-xfs@oss.sgi.com
Subject: Re: Long time no post: SourceForge, RedHat Avenue, kernel "jealousy" 
In-Reply-To: Message from "Bryan J. Smith" <b.j.smith@ieee.org> 
   of "Sat, 26 May 2001 05:23:55 EDT." <3B0F762B.FBA0B3C0@ieee.org> 
Date: Sat, 26 May 2001 20:57:10 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Long time no post:  SourceForge, RedHat Avenue
> 
> Two quick, non-technical issues ...
> 

> 2.  Has RedHat taken any interest in a beta program or other early
> adopter attitude towards XFS?  If not, how about VA Linux?  Anyone
> know of the status of the Ext3 port to kernel 2.4 (and if that is
> what either are waiting on)?  I submitted some "Request For
> Enhancement" Bugzilla tickets at the request of one of their
> employees (mainly just package additions that they'll probably favor
> for at least the Powertools CD), but I'm wondering if the RFE c/o
> Bugzilla route might be a good way to poke them on XFS as well? **

ext3 for 2.4 is being worked on, look on the linux-fsdevel list for
pointers, Stephen Tweedie has other people working on the port as
he is busy.

Things are happening slowly, we should start to appear in Debian, there
is a Mandrake installer patch, other things are happening, but I will
leave it to distributions to say things if they want to.

> 
> 3.  Did anyone read Hans Reiser's comments on non-ReiserFS
> "jealousy" that it was adopted in kernel 2.4.1 (while others were
> not)?  I'm sure he's got his reasons (I can think of one my own
> posts where he saw such attitudes ;-), but I'm still curious as to
> why XFS has not been considered for adoption into the stock kernel
> yet myself (or at least considered, please tell me if this is no
> longer true)?  Maybe that is what RedHat is ultimately waiting on?

Hmm, no jealousy here, I knew that was coming from about July last year
when Linus told me at Usenix that he would be putting reiserfs in 2.4.1.

It is not a matter of 'consideration' it is a matter of asking for inclusion,
apart from a badly timed submission to Alan Cox (in the middle of RedHat's
7.1 push) I have not asked anyone to include xfs in their kernel yet. We
are not feature complete yet, and while I do not think we will wait until
we are, I do have a list of bugs I need to shoot, and possibly one chunk
of code which will bounce off Linus very quickly.

Steve



From owner-linux-xfs@oss.sgi.com Sat May 26 18:58:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R1wuU19754
	for linux-xfs-outgoing; Sat, 26 May 2001 18:58:56 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R1wtd19748
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:58:55 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA04310
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 18:58:59 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA1971711; Sat, 26 May 2001 20:57:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA69875; Sat, 26 May 2001 20:57:32 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4R204P31451; Sat, 26 May 2001 21:00:04 -0500
Message-Id: <200105270200.f4R204P31451@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Seth Mos <knuffie@xs4all.nl>, linux-xfs@oss.sgi.com
Subject: Re: Kernel madness ensuing 
In-Reply-To: Message from Eric Sandeen <sandeen@sgi.com> 
   of "Sat, 26 May 2001 16:56:05 CDT." <3B102675.B6C6C741@sgi.com> 
Date: Sat, 26 May 2001 21:00:04 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Seth Mos wrote:
> 
> > With all the madness currently going on at SGI the last thing you need is
> > that Linus releases 2.4.5.
> > 
> > Somebody should shoot murphy.
> > 
> > Steve, can you give a rough time schedule in which you think everything is
> > regrouped over there for work to continue.
> > Would a week be a reasonable time? ;)
> 
> Hi Seth - 
> 
> I'm working on a 2.4.5 merge right now, but this is my first attempt to
> become Russell-like, so it may take a bit more time than usual.  :) 
> Once I have something the looks good, I can put up a "testing" patch.
> 
> Oh, but I'm also moving across the country in about 5 days, so I won't
> be at peak efficiency for a while.  If it's not done before then,
> perhaps I can convince Steve to pick it up.  :)
> 
> -Eric

Merging the code does not take that long, doing some regression tests on
various configurations does. The VM in 2.4 is still going through various
gyrations, and we do have some people experiencing problems because of it.
Things do appear to be improving - 2.4.4 was better than the 2.4.2 we
released at, but we have to hammer on things fairly hard to ensure we
got it right each time.

Steve



From owner-linux-xfs@oss.sgi.com Sat May 26 19:52:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R2qKW20730
	for linux-xfs-outgoing; Sat, 26 May 2001 19:52:20 -0700
Received: from bscwulf.bridgew.edu ([207.206.224.34])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R2qJd20727
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 19:52:19 -0700
Received: by bscwulf.bridgew.edu (Postfix, from userid 1000)
	id 660D63A9F3; Fri, 25 May 2001 19:45:31 -0500 (EST)
Date: Fri, 25 May 2001 19:45:31 -0500
From: glenn@bscwulf.bridgew.edu
To: linux-xfs@oss.sgi.com
Subject: XFS recovery
Message-ID: <20010525194531.C20904@bscwulf.bridgew.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Been running 2.4.2-XFS for a while.  Been telling myself
to upgrade that thing for a while--never did, and now I've
got a blown up filesystem to show for it.  Oops.

80 gig drive, filled to under 1.5 gigs free, about 5-10
active FTPs running at once.  Hard crash, kernel panic
("tried to kill init"), mount fails on reboot with "I/O
error" while doing the mount recovery, but nothing more
useful than that (it kernel panics immediately afterward,
having no root FS.)

After some effort (mostly due to not being able to find
a boot CD with XFS on it), I managed to get xfs_repair
running from a floppy.  Ran it; noticed far too many
errors, so stopped it.  Good thing I did--running it
again (this time with -n--which I should have done to
begin with) shows that, all told, it probably would have
wiped out anything that remains ("would have junked"
each of my root directories, after a massive number of
other directories.)  A quick check showed the boot CD
was a 2.2 kernel (XFS-less, for the sake of xfs_repairing);
I don't know if this would cause problems for what appears
to be a fully userspace program.  (In any event, it probably
made the situation worse.)

I've logged a full xfs_repair -n.  One thing missing from it
that the real (partial) run started out with was "error setting
block size: I/O error" (related to old kernel?)  The log
is at
ftp://bscwulf.bridgew.edu/out.txt.gz

It's listing a lot of files that havn't been touched in
days or weeks, not just files that were being written
at the crash.

I did a dry run with both XFS trees; they were visibly identical
(though I didn't bother to diff them.)

xfs_logprint shows one entry: "Unmount filesystem".

Any options short of "complete data loss"?  Oh, and if anyone
could point me to a reasonably stable CD image for XFS
recovery, I'd appreciate it.

--
Glenn Maynard

From owner-linux-xfs@oss.sgi.com Sat May 26 20:47:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R3lNk22020
	for linux-xfs-outgoing; Sat, 26 May 2001 20:47:23 -0700
Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R3lMd22017
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 20:47:22 -0700
Received: from idcomm.com (IDENT:stimits@k56-pip55.idcomm.com [209.60.72.182])
	by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id f4R1rkP11244
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 19:53:46 -0600
Message-ID: <3B105C76.1F73D2F0@idcomm.com>
Date: Sat, 26 May 2001 19:46:30 -0600
From: "D. Stimits" <stimits@idcomm.com>
Reply-To: stimits@idcomm.com
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Kernel patches
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

About a year ago I attended a Linux Expo where the XFS filesystem was
demonstrated (and it was impressive). At the time it was still being
"unencumbered", so I was unable to do anything with it. I'm now in the
process of trying to load a new machine, but find the patches haven't
kept up with newer kernel releases. I'm using SMP x86 which has had a
number of kernel changes which fix problems which were serious enough
that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
"linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
or 2nd). Normally I would be willing to test something like this out to
see if the failed chunks will cause failure, but with a filesystem, this
leaves me nervous.

My hopes are that XFS can make its way directly into the kernel source,
even if it is marked as "experimental". Until then, the next best thing
would be new patches becoming available very quickly after a new kernel
is announced. Can anyone give me an estimate on when a patch suitable
for 2.4.5 kernel will be available? Is there any kind of announcement or
devel email list I can join to track XFS development?

Thanks,
D. Stimits, stimits@idcomm.com

From owner-linux-xfs@oss.sgi.com Sat May 26 21:09:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R49LF22506
	for linux-xfs-outgoing; Sat, 26 May 2001 21:09:21 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R49Ld22503
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 21:09:21 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA01179
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 21:09:20 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id OAA27445;
	Sun, 27 May 2001 14:09:18 +1000
Date: Sun, 27 May 2001 14:09:18 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105270409.OAA27445@sherman.melbourne.sgi.com>
Subject: TAKE - Handle call *disp8(%reg) in kdb for ix86 backtrace
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Some code generates call *disp8(%reg) for calls via function pointers,
kdb needs to check for this construct when attempting an ix86
backtrace.  In particular the call from real_lookup to
[xfs]linvfs_lookup uses call *disp8(%reg).  This explains why some ix86
backtraces said <unknown>.

Date:  Sat May 26 21:02:58 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96002a
linux/arch/i386/kdb/kdbasupport.c - 1.15


From owner-linux-xfs@oss.sgi.com Sat May 26 23:41:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4R6fAJ25141
	for linux-xfs-outgoing; Sat, 26 May 2001 23:41:10 -0700
Received: from smtp9.xs4all.nl (smtp9.xs4all.nl [194.109.127.135])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4R6f8d25138
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 23:41:09 -0700
Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11])
	by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id RAA26406
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 17:21:49 +0200 (CEST)
Received: from ramoth.xs4all.nl (uucp@localhost)
	by asterix.xs4all.nl (8.9.1/8.9.1) with UUCP id RAA20755
	for oss.sgi.com!linux-xfs; Sat, 26 May 2001 17:21:49 +0200 (CEST)
Received: by ladystrange.bluehorizon.nl
	id m153fSM-0005qyC
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Sat, 26 May 2001 16:54:18 +0200 (CEST)
Date: Sat, 26 May 2001 16:54:17 +0200
From: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
To: linux-xfs@oss.sgi.com
Subject: XFS CVS server seems to be down
Message-ID: <20010526165417.A12668@ladystrange.bluehorizon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

I'm probably not the first one who notices it, but I'm unable tot reach the
CVS server. The server responds with a connection refused message.

Best regards,

	Pascal van Dam

From owner-linux-xfs@oss.sgi.com Sun May 27 12:33:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RJXC928916
	for linux-xfs-outgoing; Sun, 27 May 2001 12:33:12 -0700
Received: from bscwulf.bridgew.edu ([207.206.224.34])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RJWwd28911
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:33:02 -0700
Received: by bscwulf.bridgew.edu (Postfix, from userid 1000)
	id 909993AAC9; Sun, 27 May 2001 05:13:48 -0500 (EST)
Date: Sun, 27 May 2001 05:13:48 -0500
From: glenn@bscwulf.bridgew.edu
To: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
Message-ID: <20010527051348.A31767@bscwulf.bridgew.edu>
References: <20010525194531.C20904@bscwulf.bridgew.edu> <20010527113048.A25389@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010527113048.A25389@gruyere.muc.suse.de>; from ak@suse.de on Sun, May 27, 2001 at 11:30:48AM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 27, 2001 at 11:30:48AM +0200, Andi Kleen wrote:
> > Been running 2.4.2-XFS for a while.  Been telling myself
> > to upgrade that thing for a while--never did, and now I've
> > got a blown up filesystem to show for it.  Oops.
> > 
> > 80 gig drive, filled to under 1.5 gigs free, about 5-10
> > active FTPs running at once.  Hard crash, kernel panic
> 
> Is it possible that you ran out of memory (main memory+swap)
> when this happened? (the "tried to kill init" message points to it; 
> it used to be a bug in 2.4.2 that it did that on oom) 

I'm not sure, but I'd be inclined to say no--it's a 128M box with
relatively little running on it.  (Apache, standard small daemons, no X.)

I'm not sure what could have caused this level of damage so quickly,
either.  I *can* get reasonable looking output from xfs_ncheck--it seems
to sidestep the nuked files well enough; I have no idea if this output
is useful, though.  (I'd just run a full repair and see what came out,
but I don't have another drive large enough to dump this one to.)

Is it fairly safe to mount -o ro,norecovery?  (Of course, it may
fail to mount altogether, but it's worth a shot.)

--
Glenn Maynard

From owner-linux-xfs@oss.sgi.com Sun May 27 12:33:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RJXIn28924
	for linux-xfs-outgoing; Sun, 27 May 2001 12:33:18 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RJXFd28921
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:33:16 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id AF64B1E11E; Sun, 27 May 2001 11:31:56 +0200 (MEST)
Date: Sun, 27 May 2001 11:30:48 +0200
From: Andi Kleen <ak@suse.de>
To: glenn@bscwulf.bridgew.edu
Cc: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
Message-ID: <20010527113048.A25389@gruyere.muc.suse.de>
References: <20010525194531.C20904@bscwulf.bridgew.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010525194531.C20904@bscwulf.bridgew.edu>; from glenn@bscwulf.bridgew.edu on Fri, May 25, 2001 at 07:45:31PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Fri, May 25, 2001 at 07:45:31PM -0500, glenn@bscwulf.bridgew.edu wrote:
> Been running 2.4.2-XFS for a while.  Been telling myself
> to upgrade that thing for a while--never did, and now I've
> got a blown up filesystem to show for it.  Oops.
> 
> 80 gig drive, filled to under 1.5 gigs free, about 5-10
> active FTPs running at once.  Hard crash, kernel panic

Is it possible that you ran out of memory (main memory+swap)
when this happened? (the "tried to kill init" message points to it; 
it used to be a bug in 2.4.2 that it did that on oom) 

-Andi


From owner-linux-xfs@oss.sgi.com Sun May 27 12:57:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RJvxq31255
	for linux-xfs-outgoing; Sun, 27 May 2001 12:57:59 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RJvvd31243
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:57:57 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4RHeZaJ024409;
	Sun, 27 May 2001 12:40:36 -0500 (CDT)
Message-ID: <3B113C0E.3E4532D9@thebarn.com>
Date: Sun, 27 May 2001 12:40:30 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: stimits@idcomm.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Kernel patches
References: <3B105C76.1F73D2F0@idcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"D. Stimits" wrote:

Going to be a bit lazy here and not explain this again.
So plese read the documentation and understand what patches
are for what.

If you want the most current XFS  bitsgrab it from CVS.
currently at 244, Eric is working on the 245 merge which
probably will be done in a few days.



> About a year ago I attended a Linux Expo where the XFS filesystem was
> demonstrated (and it was impressive). At the time it was still being
> "unencumbered", so I was unable to do anything with it. I'm now in the
> process of trying to load a new machine, but find the patches haven't
> kept up with newer kernel releases. I'm using SMP x86 which has had a
> number of kernel changes which fix problems which were serious enough
> that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
> instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
> completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
> "linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
> source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
> or 2nd). Normally I would be willing to test something like this out to
> see if the failed chunks will cause failure, but with a filesystem, this
> leaves me nervous.
>
> My hopes are that XFS can make its way directly into the kernel source,
> even if it is marked as "experimental". Until then, the next best thing
> would be new patches becoming available very quickly after a new kernel
> is announced. Can anyone give me an estimate on when a patch suitable
> for 2.4.5 kernel will be available? Is there any kind of announcement or
> devel email list I can join to track XFS development?
>
> Thanks,
> D. Stimits, stimits@idcomm.com

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 27 12:58:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RJw0i31277
	for linux-xfs-outgoing; Sun, 27 May 2001 12:58:00 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RJvxd31254
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:57:59 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4RHaKaJ024376;
	Sun, 27 May 2001 12:36:21 -0500 (CDT)
Message-ID: <3B113B0F.DFE35D5@thebarn.com>
Date: Sun, 27 May 2001 12:36:15 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down
References: <20010526165417.A12668@ladystrange.bluehorizon.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"P.A.M. van Dam (Pascal)" wrote:

> Hi!
>
> I'm probably not the first one who notices it, but I'm unable tot reach the
> CVS server. The server responds with a connection refused message.
>
> Best regards,
>
>         Pascal van Dam

The connection to the ISP where oss lives seems to be down.

I'll page the admin and see what can be done.


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 27 12:58:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RJw0d31264
	for linux-xfs-outgoing; Sun, 27 May 2001 12:58:00 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RJvwd31249
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:57:58 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4RHlUaJ024446;
	Sun, 27 May 2001 12:47:30 -0500 (CDT)
Message-ID: <3B113DAC.213B33B1@thebarn.com>
Date: Sun, 27 May 2001 12:47:25 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: glenn@bscwulf.bridgew.edu
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
References: <20010525194531.C20904@bscwulf.bridgew.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

glenn@bscwulf.bridgew.edu wrote:

> Been running 2.4.2-XFS for a while.  Been telling myself
> to upgrade that thing for a while--never did, and now I've
> got a blown up filesystem to show for it.  Oops.
>
> 80 gig drive, filled to under 1.5 gigs free, about 5-10
> active FTPs running at once.  Hard crash, kernel panic
> ("tried to kill init"), mount fails on reboot with "I/O
> error" while doing the mount recovery, but nothing more
> useful than that (it kernel panics immediately afterward,
> having no root FS.)

First guess would be drive error, disk errors is the
log at recovery can be fatal and probably none recoverable.


>
>
> After some effort (mostly due to not being able to find
> a boot CD with XFS on it), I managed to get xfs_repair
> running from a floppy.  Ran it; noticed far too many
> errors, so stopped it.  Good thing I did--running it
> again (this time with -n--which I should have done to
> begin with) shows that, all told, it probably would have
> wiped out anything that remains ("would have junked"
> each of my root directories, after a massive number of
> other directories.)  A quick check showed the boot CD
> was a 2.2 kernel (XFS-less, for the sake of xfs_repairing);
> I don't know if this would cause problems for what appears
> to be a fully userspace program.  (In any event, it probably
> made the situation worse.)
>
> I've logged a full xfs_repair -n.  One thing missing from it
> that the real (partial) run started out with was "error setting
> block size: I/O error" (related to old kernel?)  The log
> is at

Yes that is the main problem with running any of the xfs utils
on a non xfs kernel.
Running xfs_repair with a non block set size  capable kernel
probably caused more damage to your file system
than originally had.

I would grab the boot.img from the 1.0 installer on the ftp site and
use that kernel + xfs_repair on a floppy.


> ftp://bscwulf.bridgew.edu/out.txt.gz
>
> It's listing a lot of files that havn't been touched in
> days or weeks, not just files that were being written
> at the crash.
>
> I did a dry run with both XFS trees; they were visibly identical
> (though I didn't bother to diff them.)
>
> xfs_logprint shows one entry: "Unmount filesystem".
>
> Any options short of "complete data loss"?  Oh, and if anyone
> could point me to a reasonably stable CD image for XFS
> recovery, I'd appreciate it.

The 1.0 installer iso can be used for repair as is has xfs_repair in
the second stage.


>
>
> --
> Glenn Maynard

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Sun May 27 13:07:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RK7xZ00966
	for linux-xfs-outgoing; Sun, 27 May 2001 13:07:59 -0700
Received: from bscwulf.bridgew.edu ([207.206.224.34])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RK7wd00962
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:07:58 -0700
Received: by bscwulf.bridgew.edu (Postfix, from userid 1000)
	id 9FCB43A9F3; Sun, 27 May 2001 15:07:56 -0500 (EST)
Date: Sun, 27 May 2001 15:07:55 -0500
From: glenn@bscwulf.bridgew.edu
To: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
Message-ID: <20010527150755.A2735@bscwulf.bridgew.edu>
References: <20010525194531.C20904@bscwulf.bridgew.edu> <3B113DAC.213B33B1@thebarn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3B113DAC.213B33B1@thebarn.com>; from cattelan@thebarn.com on Sun, May 27, 2001 at 12:47:25PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 27, 2001 at 12:47:25PM -0500, Russell Cattelan wrote:
 
> Yes that is the main problem with running any of the xfs utils
> on a non xfs kernel.
> Running xfs_repair with a non block set size  capable kernel
> probably caused more damage to your file system
> than originally had.

I'd suggest a few sanity checks, then--if the program's running
on a kernel that can't do so safely, warn loudly and require a --force,
since this isn't obvious.

> I would grab the boot.img from the 1.0 installer on the ftp site and
> use that kernel + xfs_repair on a floppy.

> The 1.0 installer iso can be used for repair as is has xfs_repair in
> the second stage.

I'll give them a try.  Thanks.

--
Glenn Maynard

From owner-linux-xfs@oss.sgi.com Sun May 27 13:27:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RKR7t01579
	for linux-xfs-outgoing; Sun, 27 May 2001 13:27:07 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKR6d01575
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:27:06 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4R6CfR19951;
	Sun, 27 May 2001 01:12:41 -0500 (CDT)
Message-ID: <3B109B9D.1B8F1BF8@sgi.com>
Date: Sun, 27 May 2001 01:15:57 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: stimits@idcomm.com
CC: linux-xfs@oss.sgi.com
Subject: Re: Kernel patches
References: <3B105C76.1F73D2F0@idcomm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"D. Stimits" wrote:
> 
> About a year ago I attended a Linux Expo where the XFS filesystem was
> demonstrated (and it was impressive). At the time it was still being
> "unencumbered", so I was unable to do anything with it. I'm now in the
> process of trying to load a new machine, but find the patches haven't
> kept up with newer kernel releases. I'm using SMP x86 which has had a
> number of kernel changes which fix problems which were serious enough
> that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
> instead use the 2.4.5 kernel. 

If you want to stay up to date with the latest kernels+XFS, a CVS
checkout is the way to go, with all the usual warnings about running CVS
code.  CVS is currently at 2.4.4.

> Of the available patches, 2.4.5 works
> completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
> "linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
> source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
> or 2nd).

Yep, that's to be expected, the first patch is independent filesystem
code, but the second has to mesh with the kernel, which is a moving
target.

> My hopes are that XFS can make its way directly into the kernel source,
> even if it is marked as "experimental". 

That is our hope as well.  :)

> Until then, the next best thing
> would be new patches becoming available very quickly after a new kernel
> is announced. Can anyone give me an estimate on when a patch suitable
> for 2.4.5 kernel will be available? 

I'm working on it now; bear in mind that 2.4.5 is less than a day old,
and we'd like to do some testing before we release it to the world.

> Is there any kind of announcement or
> devel email list I can join to track XFS development?

Sure, linux-xfs@oss.sgi.com is the all-purpose user/devel list, and
linux-xfs-announce@oss.sgi.com is for announcements only.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May 27 13:36:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RKaei01852
	for linux-xfs-outgoing; Sun, 27 May 2001 13:36:40 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKadd01849
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:36:39 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4RIv7622569;
	Sun, 27 May 2001 13:57:07 -0500 (CDT)
Message-ID: <3B114ECD.DC4FC3F5@sgi.com>
Date: Sun, 27 May 2001 14:00:29 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down
References: <20010526165417.A12668@ladystrange.bluehorizon.nl> <3B10A64B.E85EA958@sgi.com> <20010527164302.A5230@ladystrange.bluehorizon.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"P.A.M. van Dam (Pascal)" wrote:
 
> The IP I get resolved is indeed the old one, probably the propagation further
> downstream here doesn't work. But, using 216.32.174.27 also doesn't work.

Hm, oss seems to be down in general... this is bad timing, given
yesterday's Slashdot story and a long weekend here in the States...
hopefully this will get sorted out soon, sorry!

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May 27 13:44:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RKi1f02372
	for linux-xfs-outgoing; Sun, 27 May 2001 13:44:01 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKi1d02367
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:44:01 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4R6wD621827;
	Sun, 27 May 2001 01:58:13 -0500 (CDT)
Message-ID: <3B10A64B.E85EA958@sgi.com>
Date: Sun, 27 May 2001 02:01:31 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down
References: <20010526165417.A12668@ladystrange.bluehorizon.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"P.A.M. van Dam (Pascal)" wrote:
 
> I'm probably not the first one who notices it, but I'm unable tot reach the
> CVS server. The server responds with a connection refused message.

works for me here (outside SGI network)...

They rearranged some IPs earlier today, maybe you still have an old IP
cached?  oss.sgi.com is 216.32.174.27 for me.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Sun May 27 13:55:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RKteU03057
	for linux-xfs-outgoing; Sun, 27 May 2001 13:55:40 -0700
Received: from bscwulf.bridgew.edu ([207.206.224.34])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RKtdd03054
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:55:39 -0700
Received: by bscwulf.bridgew.edu (Postfix, from userid 1000)
	id 909993AAC9; Sun, 27 May 2001 05:13:48 -0500 (EST)
Date: Sun, 27 May 2001 05:13:48 -0500
From: glenn@bscwulf.bridgew.edu
To: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
Message-ID: <20010527051348.A31767@bscwulf.bridgew.edu>
References: <20010525194531.C20904@bscwulf.bridgew.edu> <20010527113048.A25389@gruyere.muc.suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010527113048.A25389@gruyere.muc.suse.de>; from ak@suse.de on Sun, May 27, 2001 at 11:30:48AM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 27, 2001 at 11:30:48AM +0200, Andi Kleen wrote:
> > Been running 2.4.2-XFS for a while.  Been telling myself
> > to upgrade that thing for a while--never did, and now I've
> > got a blown up filesystem to show for it.  Oops.
> > 
> > 80 gig drive, filled to under 1.5 gigs free, about 5-10
> > active FTPs running at once.  Hard crash, kernel panic
> 
> Is it possible that you ran out of memory (main memory+swap)
> when this happened? (the "tried to kill init" message points to it; 
> it used to be a bug in 2.4.2 that it did that on oom) 

I'm not sure, but I'd be inclined to say no--it's a 128M box with
relatively little running on it.  (Apache, standard small daemons, no X.)

I'm not sure what could have caused this level of damage so quickly,
either.  I *can* get reasonable looking output from xfs_ncheck--it seems
to sidestep the nuked files well enough; I have no idea if this output
is useful, though.  (I'd just run a full repair and see what came out,
but I don't have another drive large enough to dump this one to.)

Is it fairly safe to mount -o ro,norecovery?  (Of course, it may
fail to mount altogether, but it's worth a shot.)

--
Glenn Maynard

From owner-linux-xfs@oss.sgi.com Sun May 27 14:16:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RLGBa03370
	for linux-xfs-outgoing; Sun, 27 May 2001 14:16:11 -0700
Received: from bscwulf.bridgew.edu ([207.206.224.34])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RLGAd03367
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 14:16:10 -0700
Received: by bscwulf.bridgew.edu (Postfix, from userid 1000)
	id 8B26A3A9F3; Sun, 27 May 2001 16:16:09 -0500 (EST)
Date: Sun, 27 May 2001 16:16:09 -0500
From: glenn@bscwulf.bridgew.edu
To: linux-xfs@oss.sgi.com
Subject: Re: XFS recovery
Message-ID: <20010527161609.A2814@bscwulf.bridgew.edu>
References: <20010525194531.C20904@bscwulf.bridgew.edu> <3B113DAC.213B33B1@thebarn.com> <20010527150755.A2735@bscwulf.bridgew.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010527150755.A2735@bscwulf.bridgew.edu>; from glenn@bscwulf.bridgew.edu on Sun, May 27, 2001 at 03:07:55PM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 27, 2001 at 03:07:55PM -0500, glenn@bscwulf.bridgew.edu wrote:
> > Yes that is the main problem with running any of the xfs utils
> > on a non xfs kernel.
> > Running xfs_repair with a non block set size  capable kernel
> > probably caused more damage to your file system
> > than originally had.
> 
> I'd suggest a few sanity checks, then--if the program's running
> on a kernel that can't do so safely, warn loudly and require a --force,
> since this isn't obvious.
> 
> > I would grab the boot.img from the 1.0 installer on the ftp site and
> > use that kernel + xfs_repair on a floppy.
> 
> > The 1.0 installer iso can be used for repair as is has xfs_repair in
> > the second stage.
> 
> I'll give them a try.  Thanks.

That worked; only a few dozen files were nuked, none of which were
important.  Thanks.

*mutter* Past time to upgrade that kernel ...

--
Glenn Maynard

From owner-linux-xfs@oss.sgi.com Sun May 27 15:02:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4RM24H05351
	for linux-xfs-outgoing; Sun, 27 May 2001 15:02:04 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4RM23d05344
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 15:02:03 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 153rej-0002yf-00; Sun, 27 May 2001 15:55:53 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: <stimits@idcomm.com>, <linux-xfs@oss.sgi.com>
Subject: RE: Kernel patches
Date: Sun, 27 May 2001 15:55:25 +1200
Message-ID: <002101c0e660$dc190510$0a01a8c0@den2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <3B105C76.1F73D2F0@idcomm.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


:: is announced. Can anyone give me an estimate on when a patch suitable
:: for 2.4.5 kernel will be available? 

Steve Lord and Eric Sandeen are working on the 2.4.5 patch already, I
believe. RSN... ;-)

:: Is there any kind of 
:: announcement or
:: devel email list I can join to track XFS development?

linux-xfs-announce@oss.sgi.com?

-- Juha


From owner-linux-xfs@oss.sgi.com Sun May 27 17:15:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S0F8a07166
	for linux-xfs-outgoing; Sun, 27 May 2001 17:15:08 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S0F5d07161
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 17:15:05 -0700
Received: (qmail 5813 invoked from network); 27 May 2001 03:52:48 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 27 May 2001 03:52:48 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: stimits@idcomm.com
cc: linux-xfs@oss.sgi.com
Subject: Re: Kernel patches 
In-reply-to: Your message of "Sat, 26 May 2001 19:46:30 CST."
             <3B105C76.1F73D2F0@idcomm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 27 May 2001 13:52:47 +1000
Message-ID: <30549.990935567@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sat, 26 May 2001 19:46:30 -0600, 
"D. Stimits" <stimits@idcomm.com> wrote:
>Can anyone give me an estimate on when a patch suitable
>for 2.4.5 kernel will be available?

The CVS tree is already at kernel 2.4.4 and people are working on
upgrading to 2.4.5.

>Is there any kind of announcement or
>devel email list I can join to track XFS development?

This list for announcements, to keep up to date on the XFS development
tree see http://oss.sgi.com/projects/xfs/cvs_download.html.


From owner-linux-xfs@oss.sgi.com Sun May 27 17:15:09 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S0F9D07171
	for linux-xfs-outgoing; Sun, 27 May 2001 17:15:09 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S0F5d07160
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 17:15:05 -0700
Received: (qmail 7138 invoked from network); 27 May 2001 08:12:44 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 27 May 2001 08:12:44 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@ocs.com.au>
To: linux-xfs@oss.sgi.com
Subject: Oops in vn_revalidate with XFS 2.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Date: Sun, 27 May 2001 18:12:43 +1000
Message-ID: <6707.990951163@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

XFS 2.4.4 CVS as of Sun May 27 02:00 UTC.  SMP, compiled with gcc
version 2.96 20000731 (Red Hat Linux 7.1 2.96-81).  Redhat claim that
this version of gcc is OK to compile the kernel, there is no kgcc in
Redhat 7.1.  Running rsync from a second machine to this machine.

Reboot came up fine (and fast :).  Rerunning rsync worked the second
time but a later rsync failed at the same place.  Just before the
failure it said

  xfs_iget_core: ambiguous vns: vp/0xc2d9e508, invp/0xc73dbd08

[0]kdb> rd
eax = 0x00000000 ebx = 0xc73dbd08 ecx = 0xc7a6c800 edx = 0xc2d9d9c4
esi = 0xc73dbd08 edi = 0x00000084 esp = 0xc27f3d24 eip = 0xc88a5b0e
ebp = 0xc78db334 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0xc2d90018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc27f3cf0
[0]kdb> bt
    EBP       EIP         Function(args)
0xc78db334 0xc88a5b0e [xfs]vn_revalidate+0x1e (0xc73dbd08, 0x84, 0x0, 0xc12f70c0, 0xa007f5)
                               xfs .text 0xc8849060 0xc88a5af0 0xc88a5c00
           0xc887d4f1 [xfs]xfs_iget_core+0x611 (0xc73dbd08, 0xc7a6c800, 0x0, 0xa007f5, 0x0)
                               xfs .text 0xc8849060 0xc887cee0 0xc887d510
           0xc887d615 [xfs]xfs_iget+0x105 (0xc7a6c800, 0x0, 0xa007f5, 0x0, 0x0)
                               xfs .text 0xc8849060 0xc887d510 0xc887d650
           0xc88930f7 [xfs]xfs_dir_lookup_int+0x127 (0x0, 0xc2d9dbb0, 0x5, 0xc3faed20, 0xc27f3eec)
                               xfs .text 0xc8849060 0xc8892fd0 0xc8893290
           0xc8897a17 [xfs]xfs_lookup+0x97 (0xc2d9dbb0, 0xc3faed20, 0xc27f3ed8, 0xc27f3eec, 0x0)
                               xfs .text 0xc8849060 0xc8897980 0xc8897a90
           0xc88a05f8 [xfs]linvfs_lookup+0x68 (0xc2d9e5e0, 0xc3faecc0)
                               xfs .text 0xc8849060 0xc88a0590 0xc88a0650
           0xc013fc23 real_lookup+0x73 (0xc3657960, 0xc27f3f54, 0x0, 0x1, 0x8)
                               kernel .text 0xc0100000 0xc013fbb0 0xc013fcc0
           0xc01404f4 path_walk+0x6b4 (0xc6749000, 0xc27f3f9c)
                               kernel .text 0xc0100000 0xc013fe40 0xc0140790
           0xc0140c7a __user_walk+0x3a (0xbfff9878, 0x8, 0xc27f3f9c, 0xc3657960, 0xc13f0860)
                               kernel .text 0xc0100000 0xc0140c40 0xc0140ca0
           0xc013d623 sys_lstat64+0x13 (0xbfff9878, 0xbfffa888, 0x4014e9e4, 0xbfffa888, 0xbfff9878)
                               kernel .text 0xc0100000 0xc013d610 0xc013d680
           0xc0106e2b system_call+0x33
                               kernel .text 0xc0100000 0xc0106df8 0xc0106e30
[0]kdb> mds 0xc73dbd08
0xc73dbd08 00010000  ....  __u32 v_flag
0xc73dbd0c 00000002  ....  enum vtype v_type
0xc73dbd10 c7f42860  `(ôÇ  struct vfs *v_vfsp
0xc73dbd14 00026052  R`..  vnumber_t v_number
0xc73dbd18 00000000  ....
0xc73dbd1c 00000000  ....  bhv_head_t v_bh
0xc73dbd20 00000001  ....  spinlock_t v_lock
0xc73dbd24 c73dbc00  .¼=Ç  struct inode *v_inode

inode 0xc73dbc00
struct inode at  0xc73dbc00
 i_ino = 10487797 i_count = 1 i_dev = 0x814 i_size 0
 i_mode = 0x0  i_nlink = 1  i_rdev = 0x0
 i_hash.nxt = 0xc037a5e0 i_hash.prv = 0xc12f70c0
 i_list.nxt = 0xc2d9e5e8 i_list.prv = 0xc02c9288
 i_dentry.nxt = 0xc73dbc10 i_dentry.prv = 0xc73dbc10
 i_dirty_buffers.nxt = 0xc73dbc18 i_dirty_buffers.prv = 0xc73dbc18
 i_sb = 0xc78de800 i_op = 0xc03231e0 i_data = 0xc73dbca4 nrpages = 0
 i_mapping = 0xc73dbca4
 i_flags 0x0 i_state 0x48 [I_LOCK I_NEW]  fs specific info @ 0xc73dbd08

[0]kdb> id vn_revalidate
0xc88a5af0 vn_revalidate push   %edi
0xc88a5af1 vn_revalidate+0x1 push   %esi
0xc88a5af2 vn_revalidate+0x2 push   %ebx
0xc88a5af3 vn_revalidate+0x3 sub    $0x70,%esp
0xc88a5af6 vn_revalidate+0x6 mov    0x80(%esp,1),%ebx		struct vnode *vp
0xc88a5afd vn_revalidate+0xd movl   $0x14003fff,(%esp,1)
0xc88a5b04 vn_revalidate+0x14 mov    0x84(%esp,1),%edi
0xc88a5b0b vn_revalidate+0x1b mov    0x14(%ebx),%eax		vp->v_bh == NULL
0xc88a5b0e vn_revalidate+0x1e mov    0x8(%eax),%edx		vp->v_bh->bd_ops, oops
0xc88a5b11 vn_revalidate+0x21 push   $0x0
0xc88a5b13 vn_revalidate+0x23 mov    %edi,%eax
0xc88a5b15 vn_revalidate+0x25 and    $0x80,%eax
0xc88a5b1a vn_revalidate+0x2a push   %eax
0xc88a5b1b vn_revalidate+0x2b lea    0x8(%esp,1),%eax
0xc88a5b1f vn_revalidate+0x2f push   %eax
0xc88a5b20 vn_revalidate+0x30 mov    0x14(%ebx),%esi

Why is vp->v_bh NULL?

[0]kdb> mds c7f42860 (struct vfs)
0xc7f42860 00001020   ...
0xc7f42864 00000814  ....
0xc7f42868 00000001  ....
0xc7f4286c c7f4286c  l(ôÇ
0xc7f42870 c7f4286c  l(ôÇ
0xc7f42874 00000001  ....
0xc7f42878 00001000  ....
0xc7f4287c 00000000  ....
0xc7f42880 8b51c640  @ÆQ.
0xc7f42884 266bb554  Tµk&
0xc7f42888 c7a6ca18  .ʦÇ
0xc7f4288c c7a6c800  .ȦÇ
0xc7f42890 c78de800  .è.Ç
0xc7f42894 00000000  ....
0xc7f42898 00000000  ....
0xc7f4289c 00000000  ....
0xc7f428a0 00000002  ....
0xc7f428a4 00048000  ....
0xc7f428a8 6f616b30  0kao
0xc7f428ac 00000073  s...
0xc7f428b0 40000c83  ...@
0xc7f428b4 736f616b  kaos
0xc7f428b8 736e692d  -ins
0xc7f428bc 6c6c6174  tall
0xc7f428c0 8a000000  ....
0xc7f428c4 00000000  ....
0xc7f428c8 00000001  ....
0xc7f428cc 00000001  ....
0xc7f428d0 00000000  ....
0xc7f428d4 00000000  ....
0xc7f428d8 00000000  ....
0xc7f428dc 00000000  ....
0xc7f428e0 c7e93d20   =éÇ
0xc7f428e4 c7e93ea0   >éÇ
0xc7f428e8 00000000  ....
0xc7f428ec c78de000  .à.Ç
0xc7f428f0 00000008  ....
0xc7f428f4 ffffffff  ÿÿÿÿ
0xc7f428f8 00000001  ....
0xc7f428fc 00000002  ....


From owner-linux-xfs@oss.sgi.com Sun May 27 17:46:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S0kVL08204
	for linux-xfs-outgoing; Sun, 27 May 2001 17:46:31 -0700
Received: from diamondhead.hesbynett.no (diamondhead.hesbynett.no [212.33.144.138])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S0kUd08201
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 17:46:30 -0700
Received: (qmail 20518 invoked from network); 27 May 2001 06:00:45 -0000
Received: from unknown (HELO diamondhead.hesbynett.no) ([127.0.0.1]) (envelope-sender <zole@jblinux.net>)
          by localhost (qmail-ldap-1.03) with SMTP
          for <linux-xfs@oss.sgi.com>; 27 May 2001 06:00:45 -0000
Message-ID: <62026.213.142.74.216.990943245.squirrel@diamond.no>
Date: Sun, 27 May 2001 05:00:45 -0100 (GMT+1)
Subject: Another Linux distribution with XFS support :-)
From: "Ole Andre Vadla Ravnaas" <zole@jblinux.net>
To: linux-xfs@oss.sgi.com
Reply-To: zole@jblinux.net
X-Mailer: SquirrelMail (version 1.0.2)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

First off; thanks a lot for a great filesystem! :)

I chose to include support for XFS in my Linux distribution,
called JBLinux ( http://www.jblinux.net ), and it's been working like a
charm. Outstanding job folks!

I really hope that the mainstream distros will consider this and go for it,
a great filesystem like this deserves a stronger position in the Linux
community, and I'm pretty sure it'll get there. :-)

Keep up the good work!

Best regards,
Ole André Vadla Ravnås




From owner-linux-xfs@oss.sgi.com Sun May 27 18:03:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S138508704
	for linux-xfs-outgoing; Sun, 27 May 2001 18:03:08 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S136d08701
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 18:03:06 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id SAA01458
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 18:03:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id UAA1977570; Sun, 27 May 2001 20:01:45 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA70736; Sun, 27 May 2001 20:01:45 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4S143m07016; Sun, 27 May 2001 20:04:03 -0500
Message-Id: <200105280104.f4S143m07016@jen.americas.sgi.com>
To: Keith Owens <kaos@ocs.com.au>
cc: linux-xfs@oss.sgi.com
Subject: Re: Oops in vn_revalidate with XFS 2.4.4 
References: <6707.990951163@ocs3.ocs-net>
Comments: In-reply-to Keith Owens <kaos@ocs.com.au>
   message dated "Sun, 27 May 2001 18:12:43 +1000."
Date: Sun, 27 May 2001 20:04:03 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Keith, you got bitten by the bad revision of the code I checked in on
Friday, an icache_prune running in parallel with an xfs_iget would
have a chance of crashing the system. A fix went in later on Sunday.

Steve

> XFS 2.4.4 CVS as of Sun May 27 02:00 UTC.  SMP, compiled with gcc
> version 2.96 20000731 (Red Hat Linux 7.1 2.96-81).  Redhat claim that
> this version of gcc is OK to compile the kernel, there is no kgcc in
> Redhat 7.1.  Running rsync from a second machine to this machine.
> 
> Reboot came up fine (and fast :).  Rerunning rsync worked the second
> time but a later rsync failed at the same place.  Just before the
> failure it said
> 
>   xfs_iget_core: ambiguous vns: vp/0xc2d9e508, invp/0xc73dbd08
> 
> [0]kdb> rd
> eax = 0x00000000 ebx = 0xc73dbd08 ecx = 0xc7a6c800 edx = 0xc2d9d9c4
> esi = 0xc73dbd08 edi = 0x00000084 esp = 0xc27f3d24 eip = 0xc88a5b0e
> ebp = 0xc78db334 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
> xds = 0xc2d90018 xes = 0x00000018 origeax = 0xffffffff &regs = 0xc27f3cf0
> [0]kdb> bt
>     EBP       EIP         Function(args)
> 0xc78db334 0xc88a5b0e [xfs]vn_revalidate+0x1e (0xc73dbd08, 0x84, 0x0, 0xc12f7
> 0c0, 0xa007f5)
>                                xfs .text 0xc8849060 0xc88a5af0 0xc88a5c00
>            0xc887d4f1 [xfs]xfs_iget_core+0x611 (0xc73dbd08, 0xc7a6c800, 0x0, 
> 0xa007f5, 0x0)
>                                xfs .text 0xc8849060 0xc887cee0 0xc887d510
>            0xc887d615 [xfs]xfs_iget+0x105 (0xc7a6c800, 0x0, 0xa007f5, 0x0, 0x
> 0)
>                                xfs .text 0xc8849060 0xc887d510 0xc887d650
>            0xc88930f7 [xfs]xfs_dir_lookup_int+0x127 (0x0, 0xc2d9dbb0, 0x5, 0x
> c3faed20, 0xc27f3eec)
>                                xfs .text 0xc8849060 0xc8892fd0 0xc8893290
>            0xc8897a17 [xfs]xfs_lookup+0x97 (0xc2d9dbb0, 0xc3faed20, 0xc27f3ed
> 8, 0xc27f3eec, 0x0)
>                                xfs .text 0xc8849060 0xc8897980 0xc8897a90
>            0xc88a05f8 [xfs]linvfs_lookup+0x68 (0xc2d9e5e0, 0xc3faecc0)
>                                xfs .text 0xc8849060 0xc88a0590 0xc88a0650
>            0xc013fc23 real_lookup+0x73 (0xc3657960, 0xc27f3f54, 0x0, 0x1, 0x8
> )
>                                kernel .text 0xc0100000 0xc013fbb0 0xc013fcc0
>            0xc01404f4 path_walk+0x6b4 (0xc6749000, 0xc27f3f9c)
>                                kernel .text 0xc0100000 0xc013fe40 0xc0140790
>            0xc0140c7a __user_walk+0x3a (0xbfff9878, 0x8, 0xc27f3f9c, 0xc36579
> 60, 0xc13f0860)
>                                kernel .text 0xc0100000 0xc0140c40 0xc0140ca0
>            0xc013d623 sys_lstat64+0x13 (0xbfff9878, 0xbfffa888, 0x4014e9e4, 0
> xbfffa888, 0xbfff9878)
>                                kernel .text 0xc0100000 0xc013d610 0xc013d680
>            0xc0106e2b system_call+0x33
>                                kernel .text 0xc0100000 0xc0106df8 0xc0106e30
> [0]kdb> mds 0xc73dbd08
> 0xc73dbd08 00010000  ....  __u32 v_flag
> 0xc73dbd0c 00000002  ....  enum vtype v_type
> 0xc73dbd10 c7f42860  `(tG  struct vfs *v_vfsp
> 0xc73dbd14 00026052  R`..  vnumber_t v_number
> 0xc73dbd18 00000000  ....
> 0xc73dbd1c 00000000  ....  bhv_head_t v_bh
> 0xc73dbd20 00000001  ....  spinlock_t v_lock
> 0xc73dbd24 c73dbc00  .<=G  struct inode *v_inode
> 
> inode 0xc73dbc00
> struct inode at  0xc73dbc00
>  i_ino = 10487797 i_count = 1 i_dev = 0x814 i_size 0
>  i_mode = 0x0  i_nlink = 1  i_rdev = 0x0
>  i_hash.nxt = 0xc037a5e0 i_hash.prv = 0xc12f70c0
>  i_list.nxt = 0xc2d9e5e8 i_list.prv = 0xc02c9288
>  i_dentry.nxt = 0xc73dbc10 i_dentry.prv = 0xc73dbc10
>  i_dirty_buffers.nxt = 0xc73dbc18 i_dirty_buffers.prv = 0xc73dbc18
>  i_sb = 0xc78de800 i_op = 0xc03231e0 i_data = 0xc73dbca4 nrpages = 0
>  i_mapping = 0xc73dbca4
>  i_flags 0x0 i_state 0x48 [I_LOCK I_NEW]  fs specific info @ 0xc73dbd08
> 
> [0]kdb> id vn_revalidate
> 0xc88a5af0 vn_revalidate push   %edi
> 0xc88a5af1 vn_revalidate+0x1 push   %esi
> 0xc88a5af2 vn_revalidate+0x2 push   %ebx
> 0xc88a5af3 vn_revalidate+0x3 sub    $0x70,%esp
> 0xc88a5af6 vn_revalidate+0x6 mov    0x80(%esp,1),%ebx		struct vnode *v
> p
> 0xc88a5afd vn_revalidate+0xd movl   $0x14003fff,(%esp,1)
> 0xc88a5b04 vn_revalidate+0x14 mov    0x84(%esp,1),%edi
> 0xc88a5b0b vn_revalidate+0x1b mov    0x14(%ebx),%eax		vp->v_bh == NUL
> L
> 0xc88a5b0e vn_revalidate+0x1e mov    0x8(%eax),%edx		vp->v_bh->bd_op
> s, oops
> 0xc88a5b11 vn_revalidate+0x21 push   $0x0
> 0xc88a5b13 vn_revalidate+0x23 mov    %edi,%eax
> 0xc88a5b15 vn_revalidate+0x25 and    $0x80,%eax
> 0xc88a5b1a vn_revalidate+0x2a push   %eax
> 0xc88a5b1b vn_revalidate+0x2b lea    0x8(%esp,1),%eax
> 0xc88a5b1f vn_revalidate+0x2f push   %eax
> 0xc88a5b20 vn_revalidate+0x30 mov    0x14(%ebx),%esi
> 
> Why is vp->v_bh NULL?
> 
> [0]kdb> mds c7f42860 (struct vfs)
> 0xc7f42860 00001020   ...
> 0xc7f42864 00000814  ....
> 0xc7f42868 00000001  ....
> 0xc7f4286c c7f4286c  l(tG
> 0xc7f42870 c7f4286c  l(tG
> 0xc7f42874 00000001  ....
> 0xc7f42878 00001000  ....
> 0xc7f4287c 00000000  ....
> 0xc7f42880 8b51c640  @FQ.
> 0xc7f42884 266bb554  T5k&
> 0xc7f42888 c7a6ca18  .J&G
> 0xc7f4288c c7a6c800  .H&G
> 0xc7f42890 c78de800  .h.G
> 0xc7f42894 00000000  ....
> 0xc7f42898 00000000  ....
> 0xc7f4289c 00000000  ....
> 0xc7f428a0 00000002  ....
> 0xc7f428a4 00048000  ....
> 0xc7f428a8 6f616b30  0kao
> 0xc7f428ac 00000073  s...
> 0xc7f428b0 40000c83  ...@
> 0xc7f428b4 736f616b  kaos
> 0xc7f428b8 736e692d  -ins
> 0xc7f428bc 6c6c6174  tall
> 0xc7f428c0 8a000000  ....
> 0xc7f428c4 00000000  ....
> 0xc7f428c8 00000001  ....
> 0xc7f428cc 00000001  ....
> 0xc7f428d0 00000000  ....
> 0xc7f428d4 00000000  ....
> 0xc7f428d8 00000000  ....
> 0xc7f428dc 00000000  ....
> 0xc7f428e0 c7e93d20   =iG
> 0xc7f428e4 c7e93ea0   >iG
> 0xc7f428e8 00000000  ....
> 0xc7f428ec c78de000  .`.G
> 0xc7f428f0 00000008  ....
> 0xc7f428f4 ffffffff  
> 0xc7f428f8 00000001  ....
> 0xc7f428fc 00000002  ....

From owner-linux-xfs@oss.sgi.com Sun May 27 18:08:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S18ZH09056
	for linux-xfs-outgoing; Sun, 27 May 2001 18:08:35 -0700
Received: from studsv07.studserv.uni-stuttgart.de (studsv07.studserv.uni-stuttgart.de [129.69.21.37])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S18Yd09053
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 18:08:35 -0700
Received: from ysabell.wh.vaih [129.69.166.244] by studsv07.studserv.uni-stuttgart.de with ESMTP
  (SMTPD32-6.06) id A1C52502012A; Sun, 27 May 2001 12:07:01 +0200
Received: from marcelo by ysabell.wh.vaih with local (Exim 3.22 #1 (Debian))
	id 153xRt-0000x1-00
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 12:07:01 +0200
Date: Sun, 27 May 2001 12:07:00 +0200
From: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To: linux-xfs@oss.sgi.com
Subject: CVS Request: tag merges
Message-ID: <20010527120700.A3630@ysabell.wh.vaih>
Mail-Followup-To: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.18i
X-Operating-System: Linux ysabell 2.4.4-xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

 I have a small request: would it be possible for you guys to tag the
 sources after a merge with the mainstream kernel?  Something like
 linux-2-4-4-merge will do just fine.

 TIA,

-- 
Marcelo

From owner-linux-xfs@oss.sgi.com Sun May 27 19:15:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S2F3510421
	for linux-xfs-outgoing; Sun, 27 May 2001 19:15:03 -0700
Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S2F2d10417
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 19:15:02 -0700
Received: from earthlink.net (1Cust207.tnt1.bay-minette.al.da.uu.net [63.29.15.207])
	by albatross.prod.itd.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id TAA12795
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 19:14:35 -0700 (PDT)
Message-ID: <3B11B46D.9030009@earthlink.net>
Date: Sun, 27 May 2001 21:14:05 -0500
From: Bruce Tenison <btenison@earthlink.net>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.4-xfs i686; en-US; rv:0.9) Gecko/20010507
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
References: <LGECJLHBGAPMGAJFMAFIEEFJCAAA.juha@saarinen.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I've done a bit more work on this today, and now have a drive that 
doesn't seem to generate the errors I was having.
The solution for me seemed to be enabling devfs support.  I already had 
it compiled into the kernel, but not mounted.
To begin with I noticed that once I used the drive, and rebooted to a 
non-xfs partition (ext2) as root (with an xfs enabled
kernel) and issued an xfs_check on the xfs partition (that was 
previously root) it returned all kinds of errors.

I then, instinctively (I guess), issued an xfs_repair on the drive, and 
wound up with some entries in lost+found, mostly from
either log files or pid files in /var/run (and sometimes the directory 
itself)...  

Well, I noticed that a lot of times I was getting an xfs recovery after 
just issuing a reboot command.  So I started looking at
/etc/rc.d/init.d/halt to see how the filesystems were being umounted.   
It looks at /proc/mounts, so I looked there, and what did
I see?
/dev/ide/host0/bus0/target1/lun1/part3 / xfs rw 0 0

Hmmm.  Since I have devfs NOT mounted, just compiled in....  Well I 
rebooted, to the non-xfs, mounted the xfs partition, let it
recover, umounted it, then ran xfs_check.   No errors!!!!  Hmm, maybe I 
was overzealous on the xfs_repair earlier.  Shouldn't
xfs_repair check for this case?

Rebooted to the xfs partition with devfs=mount as an option.   
Everything seems to work after that....

Also, I noticed that, near the bottom of /etc/rc.d/init.d/halt there are 
the following lines (note the ext2):
# Remount read only anything that's left mounted.
#echo $"Remounting remaining filesystems (if any) readonly"
mount | awk '/ext2/ { print $3 }' | while read line; do
   mount -n -o ro,remount $line
done

So I guess this is looking for an ext2 partition as the root and maybe 
the only partition left to umount.  Since it's root, I guess
we can only remount it ro.  So I changed it to xfs, and placed a couple 
of mount commands to show me whether or not it worked.
It doesn't seem to remount the root xfs partition read-only (at least 
mount reports (rw) both before and after the remount).

But, at least I'm not seeing the errors anymore (I hope)

Hope this helps.

Bruce

Juha Saarinen wrote:

>:: I've also got a Promise PDC 20262 w/ an IBM Deskstar running in UDMA
>:: mode 4 w/ no problems whatsoever. Additionally a Maxtor Diamond Max
>:: connected to the stock BX MB w/ no problems. Early on (5-6 months ago) I
>
>Yep... you're using a BX440 motherboard. Bruce and I have VIA chip set ones.
>I really, really, really regret buying that Tyan motherboard. :-(
>
>-- Juha
>
>




From owner-linux-xfs@oss.sgi.com Sun May 27 21:39:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S4dDt12137
	for linux-xfs-outgoing; Sun, 27 May 2001 21:39:13 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S4dCd12134
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 21:39:12 -0700
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA00672
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 21:39:16 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA93824;
	Mon, 28 May 2001 14:37:53 +1000 (EST)
Date: Mon, 28 May 2001 14:37:53 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: linux <dahouet@gmx.net>
Cc: linux-xfs@oss.sgi.com
Subject: Re: cvs cmd pb compiling
Message-ID: <20010528143729.A97441@boing.melbourne.sgi.com>
References: <200105251928090081.0181DC47@mail.gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <200105251928090081.0181DC47@mail.gmx.de>; from dahouet@gmx.net on Fri, May 25, 2001 at 07:28:09PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Nico,

Did you do a 
    make
    make install install-dev
in the cmd/xfsprogs directory prior to your compile ?
The "make install-dev" from cmd/xfsprogs installs
a lot of the common xfs util header files such as
the endian conversion architecture files.

Alternatively, one could install the
xfsprogs-devel package to get the header files.

Let me know if this doesn't solve the problem.

Cheers,
--Tim

On Fri, May 25, 2001 at 07:28:09PM +0200, linux wrote:
> Hi,
> 
> i've updated my linux kernel with cvs today
> i manage to compile the kernel succesfully 
> but i can't compile the utils xfsdump in cmd directory
> 
> gcc -O1 -g -DDEBUG -funsigned-char -Wall -DDUMP -DRMT -DBASED -DDOSOCKS -DINVCONVFIX -DSIZEEST -DPIPEINVFIX -DEXTATTR -I/usr/include/xfs -I/usr/include/attr '-DVERSION="1.0.9"' -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DXFS_BIG_FILES=1 -DXFS_BIG_FILESYSTEMS=1 -o xfsdump   arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stkchk.o stream.o util.o sproc.o attr.o inv_api.o inv_core.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o inomap.o var.o   -lhandle /usr/lib/libuuid.a ../librmt/librmt.a /usr/lib/libattr.a  
> arch_xlate.o: In function `xlate_global_hdr':
> /usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64'
> /usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:67: undefined reference to `__fswab64'
> arch_xlate.o: In function `xlate_content_inode_hdr':
> /usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64'
> /usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:252: undefined reference to `__fswab64'
> /usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: undefined reference to `__fswab64'
> arch_xlate.o:/usr/src/linux-2.4-xfs/cmd/xfsdump/dump/arch_xlate.c:253: more undefined references to `__fswab64' follow
> collect2: ld returned 1 exit status
> make[1]: *** [xfsdump] Erreur 1
> make: *** [default] Erreur 2
> 
> 
> any idea ?
> @++
> nico
> 

From owner-linux-xfs@oss.sgi.com Mon May 28 00:18:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S7I2S14836
	for linux-xfs-outgoing; Mon, 28 May 2001 00:18:02 -0700
Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.127.131])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S7I0d14833
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 00:18:00 -0700
Received: from asterix.xs4all.nl (asterix.xs4all.nl [194.109.6.11])
	by smtp1.xs4all.nl (8.9.3/8.9.3) with ESMTP id SAA06874;
	Sun, 27 May 2001 18:25:58 +0200 (CEST)
Received: from ramoth.xs4all.nl (uucp@localhost)
	by asterix.xs4all.nl (8.9.1/8.9.1) with UUCP id SAA27303;
	Sun, 27 May 2001 18:25:58 +0200 (CEST)
Received: by ladystrange.bluehorizon.nl
	id m1541l0-0005t2C
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Sun, 27 May 2001 16:43:02 +0200 (CEST)
Date: Sun, 27 May 2001 16:43:02 +0200
From: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
To: Eric Sandeen <sandeen@sgi.com>
Cc: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>,
   linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down
Message-ID: <20010527164302.A5230@ladystrange.bluehorizon.nl>
References: <20010526165417.A12668@ladystrange.bluehorizon.nl> <3B10A64B.E85EA958@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.1i
In-Reply-To: <3B10A64B.E85EA958@sgi.com>; from Eric Sandeen on Sun, May 27, 2001 at 02:01:31AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, May 27, 2001 at 02:01:31AM -0500, Eric Sandeen wrote:
> "P.A.M. van Dam (Pascal)" wrote:
>  
> > I'm probably not the first one who notices it, but I'm unable tot reach the
> > CVS server. The server responds with a connection refused message.
> 
> works for me here (outside SGI network)...
> 
> They rearranged some IPs earlier today, maybe you still have an old IP
> cached?  oss.sgi.com is 216.32.174.27 for me.

Eric,

The IP I get resolved is indeed the old one, probably the propagation further
downstream here doesn't work. But, using 216.32.174.27 also doesn't work.

Best regards,

	Pascal

> 
> -Eric
> 
> -- 
> Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
> sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 02:22:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4S9MR317353
	for linux-xfs-outgoing; Mon, 28 May 2001 02:22:27 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4S9MPd17350
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 02:22:26 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id KAA03183;
	Mon, 28 May 2001 10:15:09 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id KAA10878;
	Mon, 28 May 2001 10:15:08 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id A240257306; Mon, 28 May 2001 10:24:14 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 39BD225835; Mon, 28 May 2001 10:25:08 +0200 (CEST)
Message-ID: <3B1209F9.9DF4C68D@ch.sauter-bc.com>
Date: Mon, 28 May 2001 10:19:05 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Jason L Tibbitts III <tibbs@math.uh.edu>
Cc: linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: LVM Utilities?
References: <ufan184yna2.fsf@epithumia.math.uh.edu>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

Just try this link. This one works with RH-7.1.
LVM with XFS works fine but snapshots don't work. There are patches
around but I didn't test them. Everything else works great.

http://rpmfind.net/linux/RPM/PLD//test/i386//lvm-0.9.1-0.beta7.i386.html

Oh yes, don't forget to change the /etc/rc.d/init.d/halt

--- halt.orig   Fri May 25 17:26:45 2001
+++ halt        Fri May 25 17:26:45 2001
@@ -161,6 +161,10 @@
        sig=-9
 done
 
+if [ -x /sbin/vgchange -a -f /etc/lvmtab ]; then
+    runcmd "Shutting down LVM:" /sbin/vgchange -a n
+fi
+
 [ -f /proc/bus/usb/devices ] && umount /proc/bus/usb
 
 # Remount read only anything that's left mounted.

Greetings
Simon

Jason L Tibbitts III schrieb:
> 
> I wanted to experiment with XFS and LVM so I installed the full set of RPMS
> on an already running Red Hat 7.1. system.  Everything works fine, but I
> can't seem to find the LVM utilities anywhere.
> 
> Can I just install any recent RPM of the utilities from sistina.com or do I
> need one matched to the version included in the kernel?  (I'm somewhat
> confused by the whole IOP compatibility thing right now.)  Anyone have a
> source for RPMS known to work?
> 
> Thanks,
> 
>  - J<



From owner-linux-xfs@oss.sgi.com Mon May 28 03:13:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SADRm18376
	for linux-xfs-outgoing; Mon, 28 May 2001 03:13:27 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SADPd18373
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 03:13:25 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id MAA27303;
	Mon, 28 May 2001 12:13:23 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id MAA21254;
	Mon, 28 May 2001 12:13:22 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 4C3EE57306; Mon, 28 May 2001 12:23:04 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 6D11225835; Mon, 28 May 2001 12:23:57 +0200 (CEST)
Message-ID: <3B1225D2.9C4BBFB1@ch.sauter-bc.com>
Date: Mon, 28 May 2001 12:17:54 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
Cc: Jason L Tibbitts III <tibbs@math.uh.edu>,
   linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: LVM Utilities?
References: <ufan184yna2.fsf@epithumia.math.uh.edu>
		<3B1209F9.9DF4C68D@ch.sauter-bc.com> <15122.7979.162461.242317@gilmour.mgm-net.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Yes, you're right, but it works very fine. And some things are missing
in beta6, don't remember... but... is it LVM on top of md (RAID5)?

Jochen Scharrlach schrieb:
> 
> Hi,
> 
> don't use the beta7-tools as XFS-1.0 comes with beta6-patches!
> 
> Bye,
> Jochen
> 
> --
> ----------------------------------------------------------------
> Nextra Baden-Wuerttemberg           | Jochen Scharrlach
> Communication Service Provider GmbH | Technik
> Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
> D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
> ----------------------------------------------------------------
> 
>   "An innovation a day keeps the monopolist away" -- Alan Cox

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Mon May 28 05:15:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SCFqN20777
	for linux-xfs-outgoing; Mon, 28 May 2001 05:15:52 -0700
Received: from ifi.informatik.uni-stuttgart.de (ifi.informatik.uni-stuttgart.de [129.69.211.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SCFod20774
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 05:15:50 -0700
Received: from bebop.informatik.uni-stuttgart.de (bebop [129.69.215.68]) by ifi.informatik.uni-stuttgart.de (8.9.3/2.2) with ESMTP id LAA25426; Mon, 28 May 2001 11:03:57 +0200 (MET DST)
Received: from techno.informatik.uni-stuttgart.de (magallon@techno.informatik.uni-stuttgart.de [129.69.218.24]) by bebop.informatik.uni-stuttgart.de (8.11.0/2.2) with SMTP id f4S948u24616; Mon, 28 May 2001 11:04:08 +0200
Received: by techno.informatik.uni-stuttgart.de (sSMTP sendmail emulation); Mon, 28 May 2001 11:04:08 +0200
Date: Mon, 28 May 2001 11:04:08 +0200
From: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: CVS Request: tag merges
Message-ID: <20010528110408.A10827@informatik.uni-stuttgart.de>
Mail-Followup-To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>,
	Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
References: <20010527120700.A3630@ysabell.wh.vaih> <3B11C367.7A7D0DD@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3B11C367.7A7D0DD@sgi.com>; from sandeen@sgi.com on Sun, May 27, 2001 at 10:17:59PM -0500
X-Operating-System: Linux techno 2.4.4-ac11
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>> Eric Sandeen <sandeen@sgi.com> writes:

 > I'm not sure what the advantage would be?  It's no more stable right
 > after a kernel merge, or anything like that.  But if you convince me
 > that it's useful, I could probably do it.  No promises though, I just
 > got a whole lot more(!) busy as of last week.

 I sympathize.  The point is to make it easier to compare the XFS tree
 with the kernel tree, that is, to be able to check out the version
 right after a given merge at any point in time.  I'm asking this
 because yesterday I was merging current XFS CVS with 2.4.5 and there
 were a couple of points where I was left wondering when and why a
 change was made, and I wished I could have the status of the CVS tree
 right after 2.4.4 was merged.  I ended up figuring out the dates for
 the merge, but using tags is easier...

-- 
Marcelo

From owner-linux-xfs@oss.sgi.com Mon May 28 05:47:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SClZI21547
	for linux-xfs-outgoing; Mon, 28 May 2001 05:47:35 -0700
Received: from mydomain.com (1Cust173.tnt2.cph3.da.uu.net [213.116.21.173])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SClWd21544
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 05:47:33 -0700
Message-Id: <200105281247.f4SClWd21544@oss.sgi.com>
Date: Mon, 28 May 2001 14:51:49 +0100
From: POWERWEB-TV <powerwebtv@wowmail.com>
To: POWERWEB-TV@oss.sgi.com
Subject: INCREDIBLE MEGA EXPERIENCE!
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ladies & Gentlemen,

Are you ready to the experience of a lifetime ?

As affiliates of the CIL group, we offer you to PLUGIN to the largest SEX-SERVER on the WEB, in order to get more than 3000 MegaBytes of the best and most sensational SEX on the entire Web! 

Why on earth do you think that thousands of people from 13 countries daily choose to visit 2 particular WebSites ?

Very EASY answer!

- The largest and most incredible content of LIVE SEX is offered!
- State-of-the-art LIVE SHOWS with the wildest and most horny amateurs and pornstars in the world!
- Hardcore LIVE SEX that hasn´t crossed your imagination!
- Incredible & amazing themes from soft sex to the most bizarre sex!
- Beautiful Girls & wild studs from almost every country, allowing you to watch, see & chat with awsome amateurs & pornstars who are blond, who are black, who are Scandinavian, who are Asian, who have BIG tits, who are shaved, who are pregnant who are .... you just name it !
- The best ever made SPY-CAMS, WATCH-CAMS, POOL-CAMS, SHOWER-CAMS, AMATEUR-CAMS ... etc!  
- Several high quality Interactive Cams & LIVE SEX Chat, where you are in controle !
- Much much more ... too much to mention !   

EVERYTHING is offered 100% ANONOMOUSLY & you don´t need to sign-up or have a creditcard ... How simple is that ? 

PLUGIN now to our MEGA SEX-SERVER through any of the 2 AwardWinning Sites listed below, and get instantly access to more than 3000 MegaBytes of State-of-the-art WebSex!

RIGHT HERE AT:

http://siam.to/affiliate93 


Or this one, if you just love true LESBIAN SEX, CHAT and MORE from Sunny Ibiza in Spain:

http://siam.to/affiliate69
  

Enjoy your trip to paradise!



Yours sincerely,
POWERWEB-TV 
World Affiliates of CIL Group

From owner-linux-xfs@oss.sgi.com Mon May 28 07:07:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SE7In23726
	for linux-xfs-outgoing; Mon, 28 May 2001 07:07:18 -0700
Received: from bastjon.mgm-net.de (bastjon.mgm-net.de [195.254.50.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SE7Hd23723
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 07:07:17 -0700
Received: from cepheus.mgm-net.de (IDENT:root@cepheus.mgm-net.de [192.168.1.2])
	by bastjon.mgm-net.de (8.9.3/8.9.3) with ESMTP id MAA21235;
	Mon, 28 May 2001 12:19:36 +0200 (CEST)
Received: from gilmour.mgm-net.de (IDENT:root@gilmour.mgm-net.de [192.168.1.37])
	by cepheus.mgm-net.de (8.9.3/8.9.3) with ESMTP id MAA16630;
	Mon, 28 May 2001 12:19:36 +0200
Received: (from js@localhost)
	by gilmour.mgm-net.de (8.11.0/8.11.0) id f4SAJaj08918;
	Mon, 28 May 2001 12:19:36 +0200
From: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15122.9784.230783.108657@gilmour.mgm-net.de>
Date: Mon, 28 May 2001 12:19:36 +0200 (CEST)
To: Simon Matter <simon.matter@ch.sauter-bc.com>
Cc: Jason L Tibbitts III <tibbs@math.uh.edu>,
   linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: LVM Utilities?
In-Reply-To: <3B1225D2.9C4BBFB1@ch.sauter-bc.com>
References: <ufan184yna2.fsf@epithumia.math.uh.edu>
	<3B1209F9.9DF4C68D@ch.sauter-bc.com>
	<15122.7979.162461.242317@gilmour.mgm-net.de>
	<3B1225D2.9C4BBFB1@ch.sauter-bc.com>
X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Simon Matter writes:
> Yes, you're right, but it works very fine. And some things are missing
> in beta6, don't remember... but... is it LVM on top of md (RAID5)?

There are known problems with beta7 and someone else had major trouble
with your combination (try to lvextend+xfs_growfs a volume twice). If
you _really_ need beta7 you should install the kernelpatch, too!

Bye,
Jochen

-- 
----------------------------------------------------------------
Nextra Baden-Wuerttemberg           | Jochen Scharrlach
Communication Service Provider GmbH | Technik
Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
----------------------------------------------------------------

  "An innovation a day keeps the monopolist away" -- Alan Cox

From owner-linux-xfs@oss.sgi.com Mon May 28 07:07:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SE7Jo23740
	for linux-xfs-outgoing; Mon, 28 May 2001 07:07:19 -0700
Received: from bastjon.mgm-net.de (bastjon.mgm-net.de [195.254.50.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SE7Id23727
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 07:07:19 -0700
Received: from cepheus.mgm-net.de (IDENT:root@cepheus.mgm-net.de [192.168.1.2])
	by bastjon.mgm-net.de (8.9.3/8.9.3) with ESMTP id LAA21152;
	Mon, 28 May 2001 11:49:36 +0200 (CEST)
Received: from gilmour.mgm-net.de (IDENT:root@gilmour.mgm-net.de [192.168.1.37])
	by cepheus.mgm-net.de (8.9.3/8.9.3) with ESMTP id LAA15814;
	Mon, 28 May 2001 11:49:32 +0200
Received: (from js@localhost)
	by gilmour.mgm-net.de (8.11.0/8.11.0) id f4S9nVR11087;
	Mon, 28 May 2001 11:49:31 +0200
From: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15122.7979.162461.242317@gilmour.mgm-net.de>
Date: Mon, 28 May 2001 11:49:31 +0200 (CEST)
To: Simon Matter <simon.matter@ch.sauter-bc.com>
Cc: Jason L Tibbitts III <tibbs@math.uh.edu>,
   linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: LVM Utilities?
In-Reply-To: <3B1209F9.9DF4C68D@ch.sauter-bc.com>
References: <ufan184yna2.fsf@epithumia.math.uh.edu>
	<3B1209F9.9DF4C68D@ch.sauter-bc.com>
X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

don't use the beta7-tools as XFS-1.0 comes with beta6-patches!

Bye,
Jochen

-- 
----------------------------------------------------------------
Nextra Baden-Wuerttemberg           | Jochen Scharrlach
Communication Service Provider GmbH | Technik
Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
----------------------------------------------------------------

  "An innovation a day keeps the monopolist away" -- Alan Cox

From owner-linux-xfs@oss.sgi.com Mon May 28 07:10:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SEAiK24602
	for linux-xfs-outgoing; Mon, 28 May 2001 07:10:44 -0700
Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.121.85])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SEAhd24598
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 07:10:43 -0700
Received: from tenisonhome (1Cust207.tnt1.bay-minette.al.da.uu.net [63.29.15.207])
	by gull.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with SMTP id HAA08506
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 07:10:30 -0700 (PDT)
From: "Bruce Tenison" <btenison@earthlink.net>
To: <linux-xfs@oss.sgi.com>
Subject: RE: Errr... what's all this about then?
Date: Mon, 28 May 2001 09:09:50 -0500
Message-ID: <GHEEILPOBMMLMKIOEOIKIENFCKAA.btenison@earthlink.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3B11BC2A.1C8A94C1@sgi.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Bruce Tenison wrote:
>
> <a lot>
Whoops ;)  Wanted to make sure I had all of the details *GRIN*
>
> Hm, not sure about the devfs thing, sure seems like it would not be
> related, but... I must admit that I have not yet really looked into this
> one.
I was just worrying about the umounts on shutdown or reboot.  Seems like the
scripts are getting their information from /proc/mounts and passing it on to
umount.  /proc/mounts is reporting the devfs version when devfs isn't
mounted
but compiled into the kernel.  Since the node doesn't exist, I'm wondering
if the fs doesn't get umounted (doesn't seem that way here...)

> Ack!  Nice catch, I guess we should fix that up, didn't think to look
> for ext2-specific things in the initscripts... one more for the eventual
> respin.  I might file this in Red Hat's Bugzilla, just for kicks.  :)
If you do, lemme know.  I'd like to track this one and see what the say 8-)
Glad to help in some way.  I'm going to give the root-fs stuff a real test
today  (having a Memorial Day party at the house, and the XFS stuff is
running
on a custom mp3 set-top box that drives the sound system ;) and see...

> I think that's because of the "-n" option, it doesn't write to mtab, so
> "mount" won't show you the (ro) even though it is.
Ahh!  Interesting.  Didn't think about that.

Thanks Eric!
Bruce


From owner-linux-xfs@oss.sgi.com Mon May 28 08:05:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SF5Jo26031
	for linux-xfs-outgoing; Mon, 28 May 2001 08:05:19 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SF5Id26026
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:05:18 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4S2oVk26768;
	Sun, 27 May 2001 21:50:31 -0500 (CDT)
Message-ID: <3B11BDC6.83EB0B4A@sgi.com>
Date: Sun, 27 May 2001 21:53:58 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: zole@jblinux.net
CC: linux-xfs@oss.sgi.com
Subject: Re: Another Linux distribution with XFS support :-)
References: <62026.213.142.74.216.990943245.squirrel@diamond.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ole Andre Vadla Ravnaas wrote:

> I chose to include support for XFS in my Linux distribution,
> called JBLinux ( http://www.jblinux.net ), and it's been working like a
> charm. Outstanding job folks!

Hi, yes, I saw this yesterday!  Glad to see that you've included it.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 08:07:08 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SF78q26336
	for linux-xfs-outgoing; Mon, 28 May 2001 08:07:08 -0700
Received: from porgy.srv.nld.sonera.net (mbox-01.soneraplaza.nl [195.66.15.137])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SF77d26333
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:07:07 -0700
Received: from qn-212-58-167-113.quicknet.nl ([212.58.167.113]:62754 "EHLO
        auto-nb1.xs4all.nl") by soneramail.nl with ESMTP id <S57639AbRE0UUK>;
	Sun, 27 May 2001 22:20:10 +0200
Message-Id: <4.3.2.7.2.20010527221528.0333c7b8@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Sun, 27 May 2001 22:20:09 +0200
To: stimits@idcomm.com, linux-xfs@oss.sgi.com
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: Kernel patches
In-Reply-To: <3B105C76.1F73D2F0@idcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Patches are made available on a regular basis on 
ftp://linux-xfs.sgi.com/projects/xfs/download

These patches are always regression tested before releasing them in the 
open. So it might just take some time before a 2.4.5 patch makes the ftp 
server or cvs that is regression tested.

I don't like patches that make my machine crash, but I hate the patches 
that eat my filesystem. So I can wait for now.

It looks like 2.4.5 will be available in a few days or so.

Cheers


At 19:46 26-5-2001 -0600, D. Stimits wrote:
>About a year ago I attended a Linux Expo where the XFS filesystem was
>demonstrated (and it was impressive). At the time it was still being
>"unencumbered", so I was unable to do anything with it. I'm now in the
>process of trying to load a new machine, but find the patches haven't
>kept up with newer kernel releases. I'm using SMP x86 which has had a
>number of kernel changes which fix problems which were serious enough
>that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
>instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
>completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
>"linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
>source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
>or 2nd). Normally I would be willing to test something like this out to
>see if the failed chunks will cause failure, but with a filesystem, this
>leaves me nervous.
>
>My hopes are that XFS can make its way directly into the kernel source,
>even if it is marked as "experimental". Until then, the next best thing
>would be new patches becoming available very quickly after a new kernel
>is announced. Can anyone give me an estimate on when a patch suitable
>for 2.4.5 kernel will be available? Is there any kind of announcement or
>devel email list I can join to track XFS development?
>
>Thanks,
>D. Stimits, stimits@idcomm.com

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Mon May 28 08:08:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SF8e226636
	for linux-xfs-outgoing; Mon, 28 May 2001 08:08:40 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SF8dd26632
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:08:39 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4S2nnY12847;
	Sun, 27 May 2001 21:49:49 -0500 (CDT)
Message-ID: <3B11BD9B.2FAD420C@sgi.com>
Date: Sun, 27 May 2001 21:53:15 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Owens <kaos@ocs.com.au>
CC: linux-xfs@oss.sgi.com
Subject: Re: Oops in vn_revalidate with XFS 2.4.4
References: <6707.990951163@ocs3.ocs-net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Owens wrote:
> 
> XFS 2.4.4 CVS as of Sun May 27 02:00 UTC.  SMP, compiled with gcc
> version 2.96 20000731 (Red Hat Linux 7.1 2.96-81).  Redhat claim that
> this version of gcc is OK to compile the kernel, there is no kgcc in
> Redhat 7.1.

Also, FWIW, kgcc IS available in 7.1, it's just in the RPM called
"compat-egcs" this time around.  I'm still skittish about the 7.1 gcc
compiler, at least for XFS, it looks like some people (Juha) ran into
some problems that may be compiler-related.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 08:08:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SF8fY26651
	for linux-xfs-outgoing; Mon, 28 May 2001 08:08:41 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SF8ed26635
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:08:40 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4S2heY11619;
	Sun, 27 May 2001 21:43:40 -0500 (CDT)
Message-ID: <3B11BC2A.1C8A94C1@sgi.com>
Date: Sun, 27 May 2001 21:47:06 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Tenison <btenison@earthlink.net>
CC: linux-xfs@oss.sgi.com
Subject: Re: Errr... what's all this about then?
References: <LGECJLHBGAPMGAJFMAFIEEFJCAAA.juha@saarinen.org> <3B11B46D.9030009@earthlink.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Bruce Tenison wrote:

<a lot>

Hm, not sure about the devfs thing, sure seems like it would not be
related, but... I must admit that I have not yet really looked into this
one.

> Also, I noticed that, near the bottom of /etc/rc.d/init.d/halt there are
> the following lines (note the ext2):
> # Remount read only anything that's left mounted.
> #echo $"Remounting remaining filesystems (if any) readonly"
> mount | awk '/ext2/ { print $3 }' | while read line; do
>    mount -n -o ro,remount $line
> done

Ack!  Nice catch, I guess we should fix that up, didn't think to look
for ext2-specific things in the initscripts... one more for the eventual
respin.  I might file this in Red Hat's Bugzilla, just for kicks.  :)

> So I guess this is looking for an ext2 partition as the root and maybe
> the only partition left to umount.  Since it's root, I guess
> we can only remount it ro.  So I changed it to xfs, and placed a couple
> of mount commands to show me whether or not it worked.
> It doesn't seem to remount the root xfs partition read-only (at least
> mount reports (rw) both before and after the remount).

I think that's because of the "-n" option, it doesn't write to mtab, so
"mount" won't show you the (ro) even though it is.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 08:10:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SFA3K27142
	for linux-xfs-outgoing; Mon, 28 May 2001 08:10:03 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SFA3d27135
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:10:03 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4S3EXY17170;
	Sun, 27 May 2001 22:14:33 -0500 (CDT)
Message-ID: <3B11C367.7A7D0DD@sgi.com>
Date: Sun, 27 May 2001 22:17:59 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: CVS Request: tag merges
References: <20010527120700.A3630@ysabell.wh.vaih>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Marcelo E. Magallon" wrote:

>  I have a small request: would it be possible for you guys to tag the
>  sources after a merge with the mainstream kernel?  Something like
>  linux-2-4-4-merge will do just fine.

Russell, our previous merge-master/cvs-guru is no longer contracting on
this project, so it looks like this stuff may fall to me.  This is
probably something I can do, but I'm not sure what the advantage would
be?  It's no more stable right after a kernel merge, or anything like
that.  But if you convince me that it's useful, I could probably do it. 
No promises though, I just got a whole lot more(!) busy as of last week.

-Eric


-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 08:11:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SFBcS27523
	for linux-xfs-outgoing; Mon, 28 May 2001 08:11:38 -0700
Received: from dkp.com ([204.191.16.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SFBbd27518
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:11:37 -0700
Received: (from ak@localhost)
	by dkp.com (8.9.3/8.9.3) id LAA04670
	for linux-xfs@oss.sgi.com; Mon, 28 May 2001 11:11:36 -0400
Date: Mon, 28 May 2001 11:11:35 -0400
From: Andrew Klaassen <ak@dkp.com>
To: linux-xfs@oss.sgi.com
Subject: Write caching, XFS log
Message-ID: <20010528111135.A3121@key.dkp.com>
Mail-Followup-To: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Question:  Would it make sense to put the XFS log on a device
with write caching turned off, and the main portion of the file
system on a device with write caching turned on?  From what I've
been reading, turning on write caching can give a major
performance boost in some cases, but can also seriously
jeopardize metadata integrity, defeating the purpose of having a
metadata-journalling FS in the first place.  Would turning off
write caching just for the log get around this problem?

Andrew Klaassen


From owner-linux-xfs@oss.sgi.com Mon May 28 08:28:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SFSCZ28298
	for linux-xfs-outgoing; Mon, 28 May 2001 08:28:12 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SFSAd28294
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:28:11 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id RAA933961
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 17:28:08 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1979165; Mon, 28 May 2001 10:26:51 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA82198; Mon, 28 May 2001 10:26:51 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4SFT3P21942; Mon, 28 May 2001 10:29:03 -0500
Message-Id: <200105281529.f4SFT3P21942@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Seth Mos <knuffie@xs4all.nl>
cc: stimits@idcomm.com, linux-xfs@oss.sgi.com
Subject: Re: Kernel patches 
In-Reply-To: Message from Seth Mos <knuffie@xs4all.nl> 
   of "Sun, 27 May 2001 22:20:09 +0200." <4.3.2.7.2.20010527221528.0333c7b8@pop.xs4all.nl> 
Date: Mon, 28 May 2001 10:29:03 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


If anyone is attempting their own 2.4.5 xfs merge, you will need to go
change the value of NR_GFPINDEX in include/linux/mmzone.h back to 0x100,
otherwise you will die very quickly running xfs. Look for a complete
patch/cvs update in a couple of days.

Steve

> Patches are made available on a regular basis on 
> ftp://linux-xfs.sgi.com/projects/xfs/download
> 
> These patches are always regression tested before releasing them in the 
> open. So it might just take some time before a 2.4.5 patch makes the ftp 
> server or cvs that is regression tested.
> 
> I don't like patches that make my machine crash, but I hate the patches 
> that eat my filesystem. So I can wait for now.
> 
> It looks like 2.4.5 will be available in a few days or so.
> 
> Cheers
> 
> 
> At 19:46 26-5-2001 -0600, D. Stimits wrote:
> >About a year ago I attended a Linux Expo where the XFS filesystem was
> >demonstrated (and it was impressive). At the time it was still being
> >"unencumbered", so I was unable to do anything with it. I'm now in the
> >process of trying to load a new machine, but find the patches haven't
> >kept up with newer kernel releases. I'm using SMP x86 which has had a
> >number of kernel changes which fix problems which were serious enough
> >that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
> >instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
> >completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
> >"linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
> >source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
> >or 2nd). Normally I would be willing to test something like this out to
> >see if the failed chunks will cause failure, but with a filesystem, this
> >leaves me nervous.
> >
> >My hopes are that XFS can make its way directly into the kernel source,
> >even if it is marked as "experimental". Until then, the next best thing
> >would be new patches becoming available very quickly after a new kernel
> >is announced. Can anyone give me an estimate on when a patch suitable
> >for 2.4.5 kernel will be available? Is there any kind of announcement or
> >devel email list I can join to track XFS development?
> >
> >Thanks,
> >D. Stimits, stimits@idcomm.com
> 
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.



From owner-linux-xfs@oss.sgi.com Mon May 28 08:48:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SFmfs28943
	for linux-xfs-outgoing; Mon, 28 May 2001 08:48:41 -0700
Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SFmdd28922
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:48:39 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f4S7ja819039;
	Mon, 28 May 2001 09:45:36 +0200
Message-Id: <4.3.2.7.2.20010528094149.03074660@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 28 May 2001 09:45:42 +0200
To: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>,
   Eric Sandeen <sandeen@sgi.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: Re: XFS CVS server seems to be down
Cc: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>,
   linux-xfs@oss.sgi.com
In-Reply-To: <20010527164302.A5230@ladystrange.bluehorizon.nl>
References: <3B10A64B.E85EA958@sgi.com>
 <20010526165417.A12668@ladystrange.bluehorizon.nl>
 <3B10A64B.E85EA958@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

At 16:43 27-5-2001 +0200, P.A.M. van Dam (Pascal) wrote:
>On Sun, May 27, 2001 at 02:01:31AM -0500, Eric Sandeen wrote:
> > "P.A.M. van Dam (Pascal)" wrote:
> >
> > > I'm probably not the first one who notices it, but I'm unable tot 
> reach the
> > > CVS server. The server responds with a connection refused message.
> >
> > works for me here (outside SGI network)...
> >
> > They rearranged some IPs earlier today, maybe you still have an old IP
> > cached?  oss.sgi.com is 216.32.174.27 for me.
>
>Eric,
>
>The IP I get resolved is indeed the old one, probably the propagation further
>downstream here doesn't work. But, using 216.32.174.27 also doesn't work.
>
>Best regards,
>
>         Pascal

When routing over the xs4all.nl network but using our company DNS server I 
get the following IP's.
Note that the linux-xfs.sgi.com machine times out.

[seth@lsautom seth]$ ping -c1 oss.sgi.com
PING oss.sgi.com (216.32.174.190) from 10.0.1.227 : 56(84) bytes of data.
64 bytes from oss.sgi.com (216.32.174.190): icmp_seq=0 ttl=241 time=171.692 
msec

--- oss.sgi.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/mdev = 171.692/171.692/171.692/0.000 ms
[seth@lsautom seth]$ ping -c1 linux-xfs.sgi.com
PING linux-xfs.sgi.com (216.32.174.30) from 10.0.1.227 : 56(84) bytes of data.

--- linux-xfs.sgi.com ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
[seth@lsautom seth]$

So the linux-xfs.sgi.com machine is now unreachable or was it part of a 
transplant?

Cheers

--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Mon May 28 08:48:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SFmdD28923
	for linux-xfs-outgoing; Mon, 28 May 2001 08:48:39 -0700
Received: from mail.coltex.nl (IDENT:root@edge.coltex.nl [194.151.97.115])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SFmcd28919
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:48:38 -0700
Received: from auto-nb1.xs4all.nl (auto-nb1.coltex.nl [10.0.1.171])
	by mail.coltex.nl (8.11.2/8.11.2) with ESMTP id f4S7rk819085;
	Mon, 28 May 2001 09:53:46 +0200
Message-Id: <4.3.2.7.2.20010528095120.03269eb0@pop.xs4all.nl>
X-Sender: knuffie@pop.xs4all.nl
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 28 May 2001 09:53:53 +0200
To: Eric Sandeen <sandeen@sgi.com>, Russell Cattelan <cattelan@thebarn.com>
From: Seth Mos <knuffie@xs4all.nl>
Subject: DNS servers sgi.com out of sync
Cc: linux-xfs@oss.sgi.com
In-Reply-To: <3B113B0F.DFE35D5@thebarn.com>
References: <20010526165417.A12668@ladystrange.bluehorizon.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Warning!

rs1.netsol.com which is the thirtary autoritive DNS server for sgi.com 
gives out the old address for oss.sgi.com.

Your DNS servers are out of sync!

[seth@lsautom seth]$ dig @ns2.sgi.com oss.sgi.com |grep oss.sgi.com
; <<>> DiG 9.1.0 <<>> @ns2.sgi.com oss.sgi.com
;oss.sgi.com.                   IN      A
oss.sgi.com.            7200    IN      A       216.32.174.27
[seth@lsautom seth]$ dig @beta.xerox.com oss.sgi.com |grep oss.sgi.com
; <<>> DiG 9.1.0 <<>> @beta.xerox.com oss.sgi.com
;oss.sgi.com.                   IN      A
oss.sgi.com.            7200    IN      A       216.32.174.27
[seth@lsautom seth]$ dig @rs1.netsol.com oss.sgi.com |grep oss.sgi.com
; <<>> DiG 9.1.0 <<>> @rs1.netsol.com oss.sgi.com
;oss.sgi.com.                   IN      A
oss.sgi.com.            7200    IN      A       216.32.174.190
[seth@lsautom seth]$


Cheers
--
Seth
Every program has two purposes one for which
it was written and another for which it wasn't
I use the last kind.


From owner-linux-xfs@oss.sgi.com Mon May 28 14:03:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SL3sG04145
	for linux-xfs-outgoing; Mon, 28 May 2001 14:03:54 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SL3rd04142
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 14:03:53 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id A8EFD1E3C3; Mon, 28 May 2001 23:03:47 +0200 (MEST)
Date: Mon, 28 May 2001 23:02:28 +0200
From: Andi Kleen <ak@suse.de>
To: Steve Lord <lord@sgi.com>
Cc: Seth Mos <knuffie@xs4all.nl>, stimits@idcomm.com, linux-xfs@oss.sgi.com
Subject: Re: Kernel patches
Message-ID: <20010528230228.A14491@gruyere.muc.suse.de>
References: <knuffie@xs4all.nl> <200105281529.f4SFT3P21942@jen.americas.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200105281529.f4SFT3P21942@jen.americas.sgi.com>; from lord@sgi.com on Mon, May 28, 2001 at 10:29:03AM -0500
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 28, 2001 at 10:29:03AM -0500, Steve Lord wrote:
> 
> If anyone is attempting their own 2.4.5 xfs merge, you will need to go
> change the value of NR_GFPINDEX in include/linux/mmzone.h back to 0x100,
> otherwise you will die very quickly running xfs. Look for a complete
> patch/cvs update in a couple of days.

Defining it to 0x40 is enough actually.

-Andi

From owner-linux-xfs@oss.sgi.com Mon May 28 14:06:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SL6i004405
	for linux-xfs-outgoing; Mon, 28 May 2001 14:06:44 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SL6hd04401
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 14:06:43 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id DC07B1E3EB; Mon, 28 May 2001 23:06:37 +0200 (MEST)
Date: Mon, 28 May 2001 23:05:23 +0200
From: Andi Kleen <ak@suse.de>
To: Andrew Klaassen <ak@dkp.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Write caching, XFS log
Message-ID: <20010528230523.B14491@gruyere.muc.suse.de>
References: <20010528111135.A3121@key.dkp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010528111135.A3121@key.dkp.com>; from ak@dkp.com on Mon, May 28, 2001 at 11:11:35AM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 28, 2001 at 11:11:35AM -0400, Andrew Klaassen wrote:
> Question:  Would it make sense to put the XFS log on a device
> with write caching turned off, and the main portion of the file
> system on a device with write caching turned on?  From what I've
> been reading, turning on write caching can give a major
> performance boost in some cases, but can also seriously
> jeopardize metadata integrity, defeating the purpose of having a
> metadata-journalling FS in the first place.  Would turning off
> write caching just for the log get around this problem?

It won't, because XFS needs to know on the whole volume when a write
has finished; otherwise it could remove transactions from the log too 
early. A transaction can only be removed from the log when it has 
been safely comitted, and that's hard to find out with write caching.

-Andi

From owner-linux-xfs@oss.sgi.com Mon May 28 14:12:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SLC3T04873
	for linux-xfs-outgoing; Mon, 28 May 2001 14:12:03 -0700
Received: from ente.berdmann.de (pD901186F.dip.t-dialin.net [217.1.24.111])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SLC1d04869
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 14:12:01 -0700
Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de)
	by ente.berdmann.de with esmtp (Exim 3.16 #2)
	id 154UIs-0001G5-00; Mon, 28 May 2001 23:11:54 +0200
Message-ID: <3B12BF19.FFB6AE85@berdmann.de>
Date: Mon, 28 May 2001 23:11:53 +0200
From: "Bernhard R. Erdmann" <be@berdmann.de>
Organization: Bernhard Erdmann Communication & Network Solutions
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4 i586)
X-Accept-Language: de, en, fr
MIME-Version: 1.0
To: Linux XFS Mailing List <linux-xfs@oss.sgi.com>
CC: "amanda-users@amanda.org" <amanda-users@amanda.org>
Subject: Bug: xfsrestore -t insists on CWD being on a XFS filesystem
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

xfsrestore for Linux in test mode (-t) stops at the beginning if CWD is
not on a XFS filesystem:

/usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda

I consider this being a bug: no actual restore is done, so CWD's
filesystem doesn't matter.

For Amanda throwing xfsrestore -t into the backup pipe this leds to an
empty index if /tmp/amanda is not on a XFS filesystem - not very useful
for restores.

# /usr/sbin/amrecover 
AMRECOVER Version 2.4.2p2. Contacting server on amandahost ...
220 ente AMANDA index server (2.4.2p2) ready.
200 Access OK
Setting restore date to today (2001-05-28)
200 Working date set to 2001-05-28.
200 Config set to be.
200 Dump host set to ente.
Can't determine disk and mount point from $CWD
amrecover> setdisk /var/spool/news 
Scanning /dumps/amanda...
200 Disk set to /var/spool/news.
amrecover> ls
2001-05-27 /
amrecover> 

The index dir looks like:

-rw-------   1 amanda   amanda    5931961 May 18 01:51 20010518_0.gz
-rw-------   1 amanda   amanda      45067 May 19 01:30 20010519_1.gz
-rw-------   1 amanda   amanda    5812498 May 20 04:58 20010520_0.gz
-rw-------   1 amanda   amanda          0 May 28 22:16 20010521_0
-rw-------   1 amanda   amanda         20 May 21 02:00 20010521_0.gz
-rw-------   1 amanda   amanda         88 May 22 01:46 20010522_1.gz
-rw-------   1 amanda   amanda         69 May 28 22:16 20010523_1
-rw-------   1 amanda   amanda         88 May 23 01:38 20010523_1.gz
-rw-------   1 amanda   amanda         88 May 24 01:54 20010524_2.gz
-rw-------   1 amanda   amanda         69 May 28 22:16 20010525_2
-rw-------   1 amanda   amanda         88 May 25 01:48 20010525_2.gz
-rw-------   1 amanda   amanda         88 May 26 01:37 20010526_3.gz
-rw-------   1 amanda   amanda         69 May 28 22:16 20010527_3
-rw-------   1 amanda   amanda         88 May 27 01:37 20010527_3.gz
# cat 20010523_1
//usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda

(20010521 was the day I introduced XFS on /var/spool/news.)


Here's a snippet from Amanda's sendbackup-dump.c:

        program->backup_name  = XFSDUMP;
        program->restore_name = XFSRESTORE;

        indexcmd = vstralloc(XFSRESTORE,
                             " -t",
                             " -v", " silent",
                             " -",
                             " 2>/dev/null",
                             " | sed",
                             " -e", " \'s/^/\\//\'",
                             NULL);
        write_tapeheader();

        start_index(createindex, dumpout, mesgf, indexf, indexcmd);


My quick & dirty solution is to mkfs.xfs the filesystem mounted to /tmp.


Regards,
Bernhard R. Erdmann

From owner-linux-xfs@oss.sgi.com Mon May 28 16:32:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4SNWqH07699
	for linux-xfs-outgoing; Mon, 28 May 2001 16:32:52 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4SNWod07696
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 16:32:50 -0700
Received: (qmail 22808 invoked from network); 28 May 2001 23:32:47 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 28 May 2001 23:32:47 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Oops in vn_revalidate with XFS 2.4.4 
In-reply-to: Your message of "Sun, 27 May 2001 20:04:03 EST."
             <200105280104.f4S143m07016@jen.americas.sgi.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 29 May 2001 09:32:45 +1000
Message-ID: <4134.991092765@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Sun, 27 May 2001 20:04:03 -0500, 
Steve Lord <lord@sgi.com> wrote:
>Keith, you got bitten by the bad revision of the code I checked in on
>Friday, an icache_prune running in parallel with an xfs_iget would
>have a chance of crashing the system. A fix went in later on Sunday.

Updated and ran a stress test overnight, it passed.


From owner-linux-xfs@oss.sgi.com Mon May 28 17:46:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T0kHH08764
	for linux-xfs-outgoing; Mon, 28 May 2001 17:46:17 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T0kFd08759
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 17:46:15 -0700
Received: (qmail 19667 invoked by uid 0); 28 May 2001 21:59:29 -0000
Received: from adsl-3-225.adsl.easynet.fr (HELO mail.gmx.de) (212.11.27.225)
  by mail.gmx.net (mail01) with SMTP; 28 May 2001 21:59:29 -0000
Message-ID: <200105282359220797.00DB1BAB@mail.gmx.de>
In-Reply-To: <20010528143729.A97441@boing.melbourne.sgi.com>
References: <200105251928090081.0181DC47@mail.gmx.de>
 <20010528143729.A97441@boing.melbourne.sgi.com>
X-Mailer: Calypso Version 3.20.01.01 (4)
Date: Mon, 28 May 2001 23:59:22 +0200
From: "linux" <dahouet@gmx.net>
To: "Timothy Shimmin" <tes@boing.melbourne.sgi.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: cvs cmd pb compiling
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4T0kGd08760
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

hi

i thought the problem was because i compile with the old devel
the make install-dev fixed everything.

But can i use the new cvs "cmd" with an early kernel ?
(2.4.4 patched with the 28/05 cvs cmd)

thanks

PS: Thanks Russel for your great job on XFS for linux developping

Le 28/05/2001 à 14:37 Timothy Shimmin a écrit :

>Hi Nico,
>
>Did you do a 
>    make
>    make install install-dev
>in the cmd/xfsprogs directory prior to your compile ?
>The "make install-dev" from cmd/xfsprogs installs
>a lot of the common xfs util header files such as
>the endian conversion architecture files.
>
>Alternatively, one could install the
>xfsprogs-devel package to get the header files.
>
>Let me know if this doesn't solve the problem.
>
>Cheers,
>--Tim




From owner-linux-xfs@oss.sgi.com Mon May 28 19:02:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T227K09929
	for linux-xfs-outgoing; Mon, 28 May 2001 19:02:07 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T225d09925
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:02:06 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 154U8M-0004LQ-02; Tue, 29 May 2001 09:01:02 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "'Eric Sandeen'" <sandeen@sgi.com>, "'Keith Owens'" <kaos@ocs.com.au>
Cc: <linux-xfs@oss.sgi.com>
Subject: RE: Oops in vn_revalidate with XFS 2.4.4
Date: Tue, 29 May 2001 09:00:33 +1200
Message-ID: <00be01c0e7b9$3cf85e90$0a01a8c0@den2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3B11BD9B.2FAD420C@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Eric,

:: Also, FWIW, kgcc IS available in 7.1, it's just in the RPM called
:: "compat-egcs" this time around.  I'm still skittish about the 7.1 gcc
:: compiler, at least for XFS, it looks like some people (Juha) ran into
:: some problems that may be compiler-related.

You need to install the compat-egcs rpm, plus the compat-glibc rpm as
well. 

Unfortunately, I haven't been able to suss out if the problem was
compiler or code related... Steve said something about it being a bug in
some ancient IRIX code (nasty old crud that ;-P). 

If I knew were to look, I'd try to isolate the problem.


Cheers,

-- Juha


From owner-linux-xfs@oss.sgi.com Mon May 28 19:11:39 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T2BdR10150
	for linux-xfs-outgoing; Mon, 28 May 2001 19:11:39 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T2Bcd10147
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:11:38 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA23120
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:11:37 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22839; Tue, 29 May 2001 12:10:20 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA41594;
	Tue, 29 May 2001 12:10:19 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Tue, 29 May 2001 12:10:19 +1000
To: <davidlm@nettaxi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: [Fwd: Feedback]
In-Reply-To: <3B126A4B.CB83B7FA@sgi.com>
Message-ID: <Pine.SGI.4.32.0105291057300.141812-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


The original questions were mailed to the Linux XFS project mail list but
were really about IRIX.  I'd suggest contacting SGI's customer support or
perhaps posting to comp.sys.sgi.admin in future, but I'll answer the
questions here as they are still relevant to both operating systems.

> Date: Mon, 28 May 2001 05:07:36 -0700
> From: davidlm@nettaxi.com (david martin)
>
>  I have too questions that I can't seem to figure out.
> 1\) Is it possible to use xfsdump and restore to creat and archive
> without the directory structure hard coded in.  i.e.
...
>   This is when I tried using xfsdump piped into xfsrestore to
>   copy a directory under a filesystem to another directory:
>
>   \(the 'restor_testing' is relative to /usr/people/cjones\)
>   samantha 1# cd /usr/people/cjones
>   samantha 8# xfsdump -s cjones/xlv_stuff - /usr/people \| xfsrestore -
> restore_testing
> .... and what I saw when it was done:
> samantha\[/usr/people/cjones/restor_testing/cjones/xlv_stuff\]ls -l
...
>   ***** now it didn't quite restore the data the way I wanted...  what I
>        wanted was this:
>
>   samantha\[/usr/people/cjones/restor_testing\]ll
...
> # This allowed me to create and restore but ZI wanted the data to be
> restored in a new location without creating the old directory structure
> in  the new directory.Is there a ways to do this\?

This is an interesting question, which provoked a lively discussion here.
The show answer is 'no', but if you want the medium length answer, read
on...

Basically the problem is that xfsdump is a _filesystem_ dump utility, not
a directory dump utility like tar.  It is not designed to do what you want
it to, and I would argue that it would be wrong to to give it this
feature.

What you ask seems simple and reasonable, but really it is neither.
First, is it the responsibility of xfsdump or xfsrestore?  xfsdump is
designed to create filesystem backups which means it has to maintain the
original directory structure - it does this by storing a map of the
directories in the dump.  To do what you want would mean that either
xfsdump would have to store a different directory structure in the dump,
or that xfsrestore would have to know how to compress the directory
structure the way you want.  xfsrestore would be unable to tell whether
the directory map in the dump matched the original filesystem or not - it
simply restores whatever is in the dump.  It would be unreasonable to ask
xfsrestore to somehow arbitrarily compress the directory structure as
there would be just too many variables, eg. name clashes, etc.

So, why can't xfsdump adjust the directory map when it writes the files?
First, you can specify several subdirectories with '-s', so it too would
have to deal with the possibility of name clashes.  Second, there's no way
for xfsrestore to tell whether xfsdump has adjusted the map in some way,
so unexpected things may happen if the dump is restored a year later, and
the operator doesn't know how the dump was performed.  Third, we can't
change the format of the dump to include exta information as we need to
remain forwards and backwards compatible with IRIX. Fourth, xfsdump
supports incremental dumps, and it's possible you could get into a real
mess if some parts of the series of dumps were restored to different
places in the filesystem.  Fifth, xfsdump was written in such a way as to
make implementation of this feature a real headache.  I'm sure there are
many other combinations and scenarios where horrible things could
happen...

What you want to use is cp, tar or cpio.  Or, if you really need to use
xfsdump/xfsrestore because you want to keep your extended attributes, then
just use the good ol' mv command after the restore.  But in the end,
xfsdump and xfsrestore are simply the wrong tools for the job.


> 2\)  I have been having trouble using xfsdump and restore on nfs mounted
> filesystems.  Is there a option that has to be issued, a way to work
> around this or does it just no work in this version\?  Thank you in
> advance....

xfsdump uses system calls that are specific to XFS to improve performance
and to support XFS specific features.  Unfortunately, NFS simply can't
handle these calls.  I take it your problem is that your tape drive is
attached to a host which is different from the host with the filesystem
you want dumped.  If this is the case, I'd suggest you try using xfsdump's
remote tape feature - ie. you can specify the hostname of the machine with
the attached tape drive as part of the tape device (hostname:/dev/tape).
See the xfsdump manpage for more details.

Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com







From owner-linux-xfs@oss.sgi.com Mon May 28 19:20:36 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T2Ka710368
	for linux-xfs-outgoing; Mon, 28 May 2001 19:20:36 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T2KZd10365
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:20:35 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA05497
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:20:39 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA22909; Tue, 29 May 2001 12:19:13 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA42264;
	Tue, 29 May 2001 12:19:12 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Tue, 29 May 2001 12:19:12 +1000
To: "Bernhard R. Erdmann" <be@berdmann.de>
cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>,
   "amanda-users@amanda.org" <amanda-users@amanda.org.com>
Subject: Re: Bug: xfsrestore -t insists on CWD being on a XFS filesystem
In-Reply-To: <3B12BF19.FFB6AE85@berdmann.de>
Message-ID: <Pine.SGI.4.32.0105291210450.141812-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, 28 May 2001, Bernhard R. Erdmann wrote:

> Hi,
>
> xfsrestore for Linux in test mode (-t) stops at the beginning if CWD is
> not on a XFS filesystem:

This is a known problem in xfsrestore which has been there since day 1 in
IRIX.  It has only been a minor inconvenience in IRIX, since few sites
would use XFS and EFS together on the same system, but obviously it's a
bigger issue in Linux.

I'll create an entry in SGI's internal bug database for this, and I'm sure
it'll get dealt with in due course.

Of course, the workaround for this would be to convert /tmp to XFS. :)

Ivan


>
> /usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda
>
> I consider this being a bug: no actual restore is done, so CWD's
> filesystem doesn't matter.
>
> For Amanda throwing xfsrestore -t into the backup pipe this leds to an
> empty index if /tmp/amanda is not on a XFS filesystem - not very useful
> for restores.
>
> # /usr/sbin/amrecover
> AMRECOVER Version 2.4.2p2. Contacting server on amandahost ...
> 220 ente AMANDA index server (2.4.2p2) ready.
> 200 Access OK
> Setting restore date to today (2001-05-28)
> 200 Working date set to 2001-05-28.
> 200 Config set to be.
> 200 Dump host set to ente.
> Can't determine disk and mount point from $CWD
> amrecover> setdisk /var/spool/news
> Scanning /dumps/amanda...
> 200 Disk set to /var/spool/news.
> amrecover> ls
> 2001-05-27 /
> amrecover>
>
> The index dir looks like:
>
> -rw-------   1 amanda   amanda    5931961 May 18 01:51 20010518_0.gz
> -rw-------   1 amanda   amanda      45067 May 19 01:30 20010519_1.gz
> -rw-------   1 amanda   amanda    5812498 May 20 04:58 20010520_0.gz
> -rw-------   1 amanda   amanda          0 May 28 22:16 20010521_0
> -rw-------   1 amanda   amanda         20 May 21 02:00 20010521_0.gz
> -rw-------   1 amanda   amanda         88 May 22 01:46 20010522_1.gz
> -rw-------   1 amanda   amanda         69 May 28 22:16 20010523_1
> -rw-------   1 amanda   amanda         88 May 23 01:38 20010523_1.gz
> -rw-------   1 amanda   amanda         88 May 24 01:54 20010524_2.gz
> -rw-------   1 amanda   amanda         69 May 28 22:16 20010525_2
> -rw-------   1 amanda   amanda         88 May 25 01:48 20010525_2.gz
> -rw-------   1 amanda   amanda         88 May 26 01:37 20010526_3.gz
> -rw-------   1 amanda   amanda         69 May 28 22:16 20010527_3
> -rw-------   1 amanda   amanda         88 May 27 01:37 20010527_3.gz
> # cat 20010523_1
> //usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda
>
> (20010521 was the day I introduced XFS on /var/spool/news.)
>
>
> Here's a snippet from Amanda's sendbackup-dump.c:
>
>         program->backup_name  = XFSDUMP;
>         program->restore_name = XFSRESTORE;
>
>         indexcmd = vstralloc(XFSRESTORE,
>                              " -t",
>                              " -v", " silent",
>                              " -",
>                              " 2>/dev/null",
>                              " | sed",
>                              " -e", " \'s/^/\\//\'",
>                              NULL);
>         write_tapeheader();
>
>         start_index(createindex, dumpout, mesgf, indexf, indexcmd);
>
>
> My quick & dirty solution is to mkfs.xfs the filesystem mounted to /tmp.
>
>
> Regards,
> Bernhard R. Erdmann
>

-- 
Ivan Rayner
ivanr@melbourne.sgi.com


From owner-linux-xfs@oss.sgi.com Mon May 28 19:54:01 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T2s1310924
	for linux-xfs-outgoing; Mon, 28 May 2001 19:54:01 -0700
Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T2s1d10921
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 19:54:01 -0700
Message-ID: <20010529025401.12651.qmail@web10001.mail.yahoo.com>
Received: from [24.19.151.88] by web10001.mail.yahoo.com; Mon, 28 May 2001 19:54:01 PDT
Date: Mon, 28 May 2001 19:54:01 -0700 (PDT)
From: Glow Nair <somanglow@yahoo.com>
Subject: Getting the iso file for Release 1.0
To: linux-xfs@oss.sgi.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi..

I was trying to download the iso file for XFS
using Internet explorer version 5.00.2614.3500
from the link 
ftp://oss.sgi.com/projects/xfs/download/Release-1.0/iso/

It keeps giving me an error.. saying.. "Make sure the
file is valid and you have permission to access the
location specified"

Any help would be greatly appreciated

Thanks

Glow


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

From owner-linux-xfs@oss.sgi.com Mon May 28 20:03:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T33Xv11172
	for linux-xfs-outgoing; Mon, 28 May 2001 20:03:33 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T33Wd11169
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 20:03:32 -0700
Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id FAA936295
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 05:03:29 +0200 (CEST)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA21789;
	Tue, 29 May 2001 13:02:11 +1000 (EST)
Date: Tue, 29 May 2001 13:02:10 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: linux <dahouet@gmx.net>
Cc: linux-xfs@oss.sgi.com
Subject: Re: cvs cmd pb compiling
Message-ID: <20010529130210.H97441@boing.melbourne.sgi.com>
References: <200105251928090081.0181DC47@mail.gmx.de> <20010528143729.A97441@boing.melbourne.sgi.com> <200105282359220797.00DB1BAB@mail.gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Mailer: Mutt 1.0us
In-Reply-To: <200105282359220797.00DB1BAB@mail.gmx.de>; from dahouet@gmx.net on Mon, May 28, 2001 at 11:59:22PM +0200
X-MIME-Autoconverted: from 8bit to quoted-printable by yog-sothoth.sgi.com id FAA936295
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4T33Xd11170
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Mon, May 28, 2001 at 11:59:22PM +0200, linux wrote:
> hi
Salut Nico,

> 
> i thought the problem was because i compile with the old devel
> the make install-dev fixed everything.
Good. 
(I presume you would have been using the headers from a previous install-dev).

> 
> But can i use the new cvs "cmd" with an early kernel ?
> (2.4.4 patched with the 28/05 cvs cmd)
I'm not sure I understand your question.
Are you asking if you can use the latest xfs commands from the 
cvs tree with a kernel which is not the latest ?
    If so...
    I would say generally, yes.
    I'm involved with EAs, ACLs and xfsdump/xfsrestore and they
    should work with earlier kernels - however, some bugs have
    been found in the kernel over time during development so it would 
    be better to have the latest kernel.

Ciao,
Tim.

> 
> thanks
> 
> PS: Thanks Russel for your great job on XFS for linux developping
> 
> Le 28/05/2001 à 14:37 Timothy Shimmin a écrit :
> 
> >Hi Nico,
> >
> >Did you do a 
> >    make
> >    make install install-dev
> >in the cmd/xfsprogs directory prior to your compile ?
> >The "make install-dev" from cmd/xfsprogs installs
> >a lot of the common xfs util header files such as
> >the endian conversion architecture files.
> >
> >Alternatively, one could install the
> >xfsprogs-devel package to get the header files.
> >
> >Let me know if this doesn't solve the problem.
> >
> >Cheers,
> >--Tim
> 
> 
> 

From owner-linux-xfs@oss.sgi.com Mon May 28 22:05:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T55gr14164
	for linux-xfs-outgoing; Mon, 28 May 2001 22:05:42 -0700
Received: from guarana.lsd.ic.unicamp.br (guarana.lsd.ic.unicamp.br [143.106.24.130])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T55dd14161
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 22:05:40 -0700
Received: (from aoliva@localhost)
	by guarana.lsd.ic.unicamp.br (8.11.2/8.11.2) id f4T2eQD14553;
	Mon, 28 May 2001 23:40:26 -0300
To: "Bernhard R. Erdmann" <be@berdmann.de>
Cc: Linux XFS Mailing List <linux-xfs@oss.sgi.com>,
   "amanda-users@amanda.org" <amanda-users@amanda.org>
Subject: Re: Bug: xfsrestore -t insists on CWD being on a XFS filesystem
References: <3B12BF19.FFB6AE85@berdmann.de>
From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
Date: 28 May 2001 23:40:26 -0300
In-Reply-To: <3B12BF19.FFB6AE85@berdmann.de> ("Bernhard R. Erdmann"'s message of "Mon, 28 May 2001 23:11:53 +0200")
Message-ID: <or8zjgj2sl.fsf@guarana.lsd.ic.unicamp.br>
Lines: 17
User-Agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On May 28, 2001, "Bernhard R. Erdmann" <be@berdmann.de> wrote:

> /usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda

> I consider this being a bug: no actual restore is done, so CWD's
> filesystem doesn't matter.

I'd go even further: xfsrestore should be capable of restoring onto
non-XFS filesystems.  What should matter is the format of the backup
image, not the underlying representation of data on the filesystem to
which files are being restored.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

From owner-linux-xfs@oss.sgi.com Mon May 28 22:19:40 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T5JeL14569
	for linux-xfs-outgoing; Mon, 28 May 2001 22:19:40 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T5Jdd14566
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 22:19:39 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id WAA09380
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 22:19:44 -0700 (PDT)
	mail_from (ivanr@melbourne.sgi.com)
Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA24035; Tue, 29 May 2001 15:18:17 +1000
From: ivanr@melbourne.sgi.com (Ivan Rayner)
Received: from localhost (ivanr@localhost)
	by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA42802;
	Tue, 29 May 2001 15:18:17 +1000 (EST)
X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs
Date: Tue, 29 May 2001 15:18:16 +1000
To: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
cc: "Bernhard R. Erdmann" <be@berdmann.de>,
   Linux XFS Mailing List <linux-xfs@oss.sgi.com>,
   "amanda-users@amanda.org" <amanda-users@amanda.org.com>
Subject: Re: Bug: xfsrestore -t insists on CWD being on a XFS filesystem
In-Reply-To: <or8zjgj2sl.fsf@guarana.lsd.ic.unicamp.br>
Message-ID: <Pine.SGI.4.32.0105291510400.141812-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 28 May 2001, Alexandre Oliva wrote:

> On May 28, 2001, "Bernhard R. Erdmann" <be@berdmann.de> wrote:
>
> > /usr/sbin/xfsrestore: ERROR: Current directory not XFS: /tmp/amanda
>
> > I consider this being a bug: no actual restore is done, so CWD's
> > filesystem doesn't matter.
>
> I'd go even further: xfsrestore should be capable of restoring onto
> non-XFS filesystems.  What should matter is the format of the backup
> image, not the underlying representation of data on the filesystem to
> which files are being restored.

xfsrestore _is capable_ of restoring onto non-XFS filesystems - it's just
that your cwd needs to be on an XFS filesystem.  The reason for this is
not clear, but there are comments in the code about wanting to create
temporary directories.  I guess it's possible that xfsrestore wants to
write extended attributes into the temporary directory, or do some other
XFS specific thing ... I don't know.  Whoever gets the chance to look into
will find out.

At the moment though, while xfsrestore may complain that it can't
preallocate space, it will continue to restore files into ext2.  Of
course, extended attributes wont get restored.

But your point is taken - xfsrestore should behave nicely on non-xfs
filesystems in general.

Ivan

-- 
Ivan Rayner
ivanr@melbourne.sgi.com


From owner-linux-xfs@oss.sgi.com Mon May 28 22:56:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T5ugv15311
	for linux-xfs-outgoing; Mon, 28 May 2001 22:56:42 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T5ufd15308
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 22:56:41 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4T3lVg02723;
	Mon, 28 May 2001 22:47:31 -0500 (CDT)
Message-ID: <3B131CAC.73E79A5E@sgi.com>
Date: Mon, 28 May 2001 22:51:08 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Glow Nair <somanglow@yahoo.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Getting the iso file for Release 1.0
References: <20010529025401.12651.qmail@web10001.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Glow Nair wrote:
> 
> Hi..
> 
> I was trying to download the iso file for XFS
> using Internet explorer version 5.00.2614.3500
> from the link
> ftp://oss.sgi.com/projects/xfs/download/Release-1.0/iso/
> 
> It keeps giving me an error.. saying.. "Make sure the
> file is valid and you have permission to access the
> location specified"

Hm, our network guys still have some surprises in store for us, it
seems... you might try grabbing the ISO from one of the mirrors listed
at 

http://216.32.174.27/projects/xfs/download.html
       ^^^^^^^^^^^^^
        oss.sgi.com

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Mon May 28 23:06:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T66A815673
	for linux-xfs-outgoing; Mon, 28 May 2001 23:06:10 -0700
Received: from relay.xlink.net (relay.xlink.net [193.141.40.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T669d15668
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 23:06:09 -0700
Received: from lizard.webland.de (lizard.webland.de [194.122.76.201])
	by relay.xlink.net (8.9.3/8.8.7) with ESMTP id IAA23707;
	Tue, 29 May 2001 08:06:07 +0200 (MET DST)
Received: (from uucp@localhost)
	by lizard.webland.de (8.8.8/8.8.7) id IAA02793;
	Tue, 29 May 2001 08:06:06 +0200 (MET DST)
>Received: from mobile.sauter-bc.com (unknown [10.1.6.21])
	by basel1.sauter-bc.com (Postfix) with ESMTP
	id 55C9A57306; Tue, 29 May 2001 08:15:35 +0200 (CEST)
Received: from ch.sauter-bc.com (support.cad.sba [10.1.200.117])
	by mobile.sauter-bc.com (Postfix) with ESMTP
	id 59A3225835; Tue, 29 May 2001 08:16:28 +0200 (CEST)
Message-ID: <3B133D51.708EEF74@ch.sauter-bc.com>
Date: Tue, 29 May 2001 08:10:25 +0200
From: Simon Matter <simon.matter@ch.sauter-bc.com>
Organization: Sauter AG, Basel
X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.1 i686)
X-Accept-Language: de-CH, en
MIME-Version: 1.0
To: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
Cc: Jason L Tibbitts III <tibbs@math.uh.edu>,
   linux-xfs <linux-xfs@oss.sgi.com>
Subject: Re: LVM Utilities?
References: <ufan184yna2.fsf@epithumia.math.uh.edu>
		<3B1209F9.9DF4C68D@ch.sauter-bc.com>
		<15122.7979.162461.242317@gilmour.mgm-net.de>
		<3B1225D2.9C4BBFB1@ch.sauter-bc.com> <15122.9784.230783.108657@gilmour.mgm-net.de>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I tried to find any problems but I couldn't. My setup is stock RH7.1/XFS
Kernel with devfs enabled. Soft RAID 5 and LVM on top of it, containing
several partitions with xfs,reiserfs and ext2. I extended and reduced
the ext2 partition several times and I growed the xfs partition 10 times
with absolutely no problem. I think it is not a beta6/beta7 problem but
something else inside XFS?
> 
> Simon Matter writes:
> > Yes, you're right, but it works very fine. And some things are missing
> > in beta6, don't remember... but... is it LVM on top of md (RAID5)?
> 
> There are known problems with beta7 and someone else had major trouble
> with your combination (try to lvextend+xfs_growfs a volume twice). If
> you _really_ need beta7 you should install the kernelpatch, too!
> 
> Bye,
> Jochen
> 
> --
> ----------------------------------------------------------------
> Nextra Baden-Wuerttemberg           | Jochen Scharrlach
> Communication Service Provider GmbH | Technik
> Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
> D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
> ----------------------------------------------------------------
> 
>   "An innovation a day keeps the monopolist away" -- Alan Cox

-- 
Simon Matter              Tel:  +41 61 695 57 35
Fr.Sauter AG / CIT        Fax:  +41 61 695 53 30
Im Surinam 55
CH-4016 Basel             [mailto:simon.matter@ch.sauter-bc.com]



From owner-linux-xfs@oss.sgi.com Tue May 29 02:50:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4T9oS019914
	for linux-xfs-outgoing; Tue, 29 May 2001 02:50:28 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4T9o9d19911
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 02:50:10 -0700
Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA07958
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 00:13:32 -0700 (PDT)
	mail_from (tes@snort.melbourne.sgi.com)
Received: (from tes@localhost)
	by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA57035
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 17:12:09 +1000 (EST)
Date: Tue, 29 May 2001 17:12:09 +1000 (EST)
From: Timothy Shimmin <tes@snort.melbourne.sgi.com>
Message-Id: <200105290712.RAA57035@snort.melbourne.sgi.com>
To: linux-xfs@oss.sgi.com
Subject: TAKE - libacl
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

This change is only in userspace and should _not_ affect the only 
xfs ACL command, chacl.

It corrects problems with 
  acl_get_file, acl_get_fd, acl_create_entry, acl_get_entry
most of which were pointed out by Juergen Hasch.
(Juergen, want to be added to the credits ?)

--Tim

Date:  Tue May 29 00:08:24 PDT 2001
Workarea:  snort.melbourne.sgi.com:/diskb/build4/tes/slinx-xfs-acl

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96007a
cmd/xfstests/058 - 1.1
	- Test out the changes for acl_create_entry, acl_get_entry

cmd/xfstests/src/acl_test.c - 1.1
	- Program to do libacl tests.
	  Started it off with testing of acl_create_entry and acl_get_entry.
	  Check to see it follows standard as much as possible.

cmd/xfstests/058.out - 1.1
	- output from src/acl_test called by 058.

cmd/xfstests/src/Makefile - 1.6
	- Add src/acl_test.

cmd/xfstests/group - 1.11
	- Add 058 and a description about acl group.

linux/include/linux/acl.h - 1.5
	- sync up with cmd/acl/include/acl.h

cmd/acl/VERSION - 1.5
	- Bump version for acl_get_file,acl_get_fd,acl_create_entry,acl_get_entry changes.

cmd/acl/libacl/acl.c - 1.9
	- Fix up acl_get_file,acl_get_fd,acl_create_entry,acl_get_entry.

cmd/acl/doc/CHANGES - 1.5
	- Add text about acl_get_file,acl_get_fd,acl_create_entry,acl_get_entry changes.

cmd/acl/include/acl.h - 1.5
	- Add ACL_UNDEFINED_TAG & ACL_PERM_NONE for acl_create_entry.
	  Add acl_get_perm() proto.

cmd/xfstests/057 - 1.2
	- Fix up 057 to test the prior bug in acl_get_fd, acl_get_file.

cmd/xfstests/057.out - 1.2
	- sync up with 057



From owner-linux-xfs@oss.sgi.com Tue May 29 04:50:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TBomV21803
	for linux-xfs-outgoing; Tue, 29 May 2001 04:50:48 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TBojd21800
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 04:50:45 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id EAA03143
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 04:50:50 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id GAA1990286; Tue, 29 May 2001 06:49:27 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA68782; Tue, 29 May 2001 06:49:27 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4TBpUD25262; Tue, 29 May 2001 06:51:30 -0500
Message-Id: <200105291151.f4TBpUD25262@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Andi Kleen <ak@suse.de>
cc: Andrew Klaassen <ak@dkp.com>, linux-xfs@oss.sgi.com
Subject: Re: Write caching, XFS log 
In-Reply-To: Message from Andi Kleen <ak@suse.de> 
   of "Mon, 28 May 2001 23:05:23 +0200." <20010528230523.B14491@gruyere.muc.suse.de> 
Date: Tue, 29 May 2001 06:51:30 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Mon, May 28, 2001 at 11:11:35AM -0400, Andrew Klaassen wrote:
> > Question:  Would it make sense to put the XFS log on a device
> > with write caching turned off, and the main portion of the file
> > system on a device with write caching turned on?  From what I've
> > been reading, turning on write caching can give a major
> > performance boost in some cases, but can also seriously
> > jeopardize metadata integrity, defeating the purpose of having a
> > metadata-journalling FS in the first place.  Would turning off
> > write caching just for the log get around this problem?
> 
> It won't, because XFS needs to know on the whole volume when a write
> has finished; otherwise it could remove transactions from the log too 
> early. A transaction can only be removed from the log when it has 
> been safely comitted, and that's hard to find out with write caching.
> 
> -Andi

Andi is correct here, XFS relies on the I/O completion of metadata writes
to determine when it is safe to reuse log space.

Under Irix there is device qualification for running XFS on a disk, basically
running stress tests, power cycling, and checking the filesystem after
recovery (note that checking an unrecovered filesystem does not do you
much good, since the log replay is what makes the filesystem consistent
again). Now there may be well designed write caching disks out there which
do things like push the cache out to a powerdown track using power held
in a capacitor, or taken from the energy of the spindle rotation, but 
there are also disks designed for Windows and the 'Your filesystem was
not unmounted cleanly, please shutdown your system before powercycling'
message.

Given a drive which is capable of responding write commands which indicate
if caching is allowed, it would be possible to do something like cache file
data, but not metadata and log I/O. Again, getting very hardware specific.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 29 06:28:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TDS5826300
	for linux-xfs-outgoing; Tue, 29 May 2001 06:28:05 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TDRxd26292
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 06:27:59 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4T0KNaJ036390;
	Mon, 28 May 2001 19:20:24 -0500 (CDT)
Message-ID: <3B12EB42.61C7F4A9@thebarn.com>
Date: Mon, 28 May 2001 19:20:18 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Seth Mos <knuffie@xs4all.nl>
CC: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>,
   Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down
References: <3B10A64B.E85EA958@sgi.com>
	 <20010526165417.A12668@ladystrange.bluehorizon.nl>
	 <3B10A64B.E85EA958@sgi.com> <4.3.2.7.2.20010528094149.03074660@pop.xs4all.nl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Seth Mos wrote:

Seems the firewall at the ISP is not passing all the ports to linux-xfs that need
to be.

I'll talk with the admin on tuesday and see if we can get things straightened
out.

Note linux-xfs will be decommissioned at some point between now and the
end of June. The machine was always intended to be temporary as test
XFS installation in a production environment.

The current plan is to upgrade oss to XFS 1.0.<whatever> at which point
the purpose of linux-xfs will have ended.



>
> When routing over the xs4all.nl network but using our company DNS server I
> get the following IP's.
> Note that the linux-xfs.sgi.com machine times out.
>
> [seth@lsautom seth]$ ping -c1 oss.sgi.com
> PING oss.sgi.com (216.32.174.190) from 10.0.1.227 : 56(84) bytes of data.
> 64 bytes from oss.sgi.com (216.32.174.190): icmp_seq=0 ttl=241 time=171.692
> msec
>
> --- oss.sgi.com ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max/mdev = 171.692/171.692/171.692/0.000 ms
> [seth@lsautom seth]$ ping -c1 linux-xfs.sgi.com
> PING linux-xfs.sgi.com (216.32.174.30) from 10.0.1.227 : 56(84) bytes of data.
>
> --- linux-xfs.sgi.com ping statistics ---
> 1 packets transmitted, 0 packets received, 100% packet loss
> [seth@lsautom seth]$
>
> So the linux-xfs.sgi.com machine is now unreachable or was it part of a
> transplant?
>
> Cheers
>
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May 29 06:28:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TDS5u26302
	for linux-xfs-outgoing; Tue, 29 May 2001 06:28:05 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TDS1d26294
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 06:28:01 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4SFhsaJ032651;
	Mon, 28 May 2001 10:43:54 -0500 (CDT)
Message-ID: <3B127235.F820229B@thebarn.com>
Date: Mon, 28 May 2001 10:43:49 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: CVS Request: tag merges
References: <20010527120700.A3630@ysabell.wh.vaih>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

"Marcelo E. Magallon" wrote:

> Hi,
>
>  I have a small request: would it be possible for you guys to tag the
>  sources after a merge with the mainstream kernel?  Something like
>  linux-2-4-4-merge will do just fine.

Well I think what your asking for is a straight 2.4.x checking which
is then tagged as such?

Then a simple cvs diff -r linux.X would be able to generate an XFS
patch.
Problem with implementing this is that ptools does not support
branching, rather
it uses a concept of LOD "line of development" which is actually a
complete copy of a
repository. While ptools lod's will give diffs the same way cvs branches
will, translating
this cvs would be very difficult.


I could tag the tree just after the merge checkins, this wouldn't be as
useful as
a pure linux branch but it would give symbolic points in time.

Let me go find exactly when the 244 merge went in and I'll tag the tree
at that time.


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May 29 07:08:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TE8Gv28774
	for linux-xfs-outgoing; Tue, 29 May 2001 07:08:16 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TE8Dd28768
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 07:08:13 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA08239
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 07:08:18 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1992914 for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 09:06:56 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA09801; Tue, 29 May 2001 09:06:56 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4TE8w506689; Tue, 29 May 2001 09:08:58 -0500
Message-Id: <200105291408.f4TE8w506689@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Steve Lord <lord@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to xfs 
In-Reply-To: Message from Steve Lord <lord@sgi.com> 
   of "Fri, 25 May 2001 17:34:26 CDT." <200105252234.f4PMYQC28777@jen.americas.sgi.com> 
Date: Tue, 29 May 2001 09:08:58 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> Sod's law says you find the hole right after you ship the code. There is a
> bug in this code, I would not do a cvs update until I get a fix in, I know
> roughly how to fix it, but it will take me a while to code and test it.
> 
> I would hold off on the cvs tree for a while until you see another message
> from me on this thread - probably not today.
> 
> Steve
> 

This was fixed over the weekend by the way.

Steve



From owner-linux-xfs@oss.sgi.com Tue May 29 09:17:11 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TGHBn06483
	for linux-xfs-outgoing; Tue, 29 May 2001 09:17:11 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TGH7d06480
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 09:17:07 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA02879
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 09:17:06 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1987921; Tue, 29 May 2001 11:15:49 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA53278; Tue, 29 May 2001 11:15:49 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4TGHov28672; Tue, 29 May 2001 11:17:50 -0500
Message-Id: <200105291617.f4TGHov28672@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to xfs 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Tue, 29 May 2001 11:11:29 CDT." <Pine.LNX.4.33.0105291110550.8330-100000@UberGeek.coremetrics.com> 
Date: Tue, 29 May 2001 11:17:50 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> The tree has been updated for everyone with all newest changes since
> friday, so this fix can be checked out?


Yep, everything should be back in sync after all the little ups and downs
of the weekend.

Steve

> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 



From owner-linux-xfs@oss.sgi.com Tue May 29 09:55:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TGtIM07499
	for linux-xfs-outgoing; Tue, 29 May 2001 09:55:18 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TGtEd07496
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 09:55:15 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id HAA03030;
	Mon, 28 May 2001 07:30:40 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Mon, 28 May 2001 07:30:40 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: Russell Cattelan <cattelan@thebarn.com>
cc: Linux xfs mailing list <linux-xfs@oss.sgi.com>
Subject: Re: No longer with SGI.
In-Reply-To: <15118.44612.676944.703861@lupo.thebarn.com>
Message-ID: <Pine.LNX.4.30.0105280729430.1357-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

To add another voice to the chorus, thank you for all your hard work
Russell, and good luck in all your future endeavors.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


From owner-linux-xfs@oss.sgi.com Tue May 29 11:18:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TIIAK09357
	for linux-xfs-outgoing; Tue, 29 May 2001 11:18:10 -0700
Received: from marvin.linux-dude.com (c-e48a70d5.032-6-73746f3.cust.bredbandsbolaget.se [213.112.138.228])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4TII1d09353
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 11:18:01 -0700
Received: from marvin (localhost [127.0.0.1])
	by marvin.linux-dude.com (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with SMTP id f4TIHrT03644
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 20:17:53 +0200
Content-Type: Multipart/Mixed;
  charset="iso-8859-1";
  boundary="------------Boundary-00=_T504J4WBJ6LN5N4PIAGY"
From: Jarek Luberek <jarek@swipnet.se>
To: linux-xfs@oss.sgi.com
Subject: Inode cache again, is this linux or xfs specific
Date: Tue, 29 May 2001 20:17:53 +0200
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01052920175300.03589@marvin>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


--------------Boundary-00=_T504J4WBJ6LN5N4PIAGY
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

I've been following the cvs tree daily and still, after 8 hours of 
running the system becomes unresponsive.

$ grep inode /proc/slabinfo
xfs_inode          91876 131432    468 12539 16429    1 :  124   62
inode_cache        92075 100504    480 12563 12563    1 :  124   62

free still shows 190M used 60M free.

I'm testing the wrong branch or is the common behaviour of the
main branch?

Greetings,
Jarek

--------------Boundary-00=_T504J4WBJ6LN5N4PIAGY
Content-Type: text/plain;
  charset="iso-8859-1";
  name="slabinfo"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="slabinfo"

c2xhYmluZm8gLSB2ZXJzaW9uOiAxLjEgKFNNUCkKa21lbV9jYWNoZSAgICAgICAgICAgMTAyICAg
IDEwMiAgICAyMzIgICAgNiAgICA2ICAgIDEgOiAgMjUyICAxMjYKdXJiX3ByaXYgICAgICAgICAg
ICAgMTEzICAgIDExMyAgICAgMzIgICAgMSAgICAxICAgIDEgOiAgMjUyICAxMjYKdWhjaV9kZXNj
ICAgICAgICAgICAxMTIxICAgMTEyMSAgICAgNjQgICAxOSAgIDE5ICAgIDEgOiAgMjUyICAxMjYK
ZmliNl9ub2RlcyAgICAgICAgICAgICA1ICAgIDIyNiAgICAgMzIgICAgMiAgICAyICAgIDEgOiAg
MjUyICAxMjYKaXA2X2RzdF9jYWNoZSAgICAgICAgICA1ICAgICA0MCAgICAxOTIgICAgMiAgICAy
ICAgIDEgOiAgMjUyICAxMjYKbmRpc2NfY2FjaGUgICAgICAgICAgICAxICAgICAzMCAgICAxMjgg
ICAgMSAgICAxICAgIDEgOiAgMjUyICAxMjYKaXBfbXJ0X2NhY2hlICAgICAgICAgICAwICAgICAg
MCAgICAgOTYgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYKdGNwX3R3X2J1Y2tldCAgICAgICAg
IDYwICAgICA2MCAgICAxMjggICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYKdGNwX2JpbmRfYnVj
a2V0ICAgICAgMjI2ICAgIDIyNiAgICAgMzIgICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYKdGNw
X29wZW5fcmVxdWVzdCAgICAgIDQwICAgICA0MCAgICAgOTYgICAgMSAgICAxICAgIDEgOiAgMjUy
ICAxMjYKaW5ldF9wZWVyX2NhY2hlICAgICAgICAwICAgICAgMCAgICAgNjQgICAgMCAgICAwICAg
IDEgOiAgMjUyICAxMjYKaXBfZmliX2hhc2ggICAgICAgICAgICA5ICAgIDIyNiAgICAgMzIgICAg
MiAgICAyICAgIDEgOiAgMjUyICAxMjYKaXBfZHN0X2NhY2hlICAgICAgICAgMTkyICAgIDE5MiAg
ICAxNjAgICAgOCAgICA4ICAgIDEgOiAgMjUyICAxMjYKYXJwX2NhY2hlICAgICAgICAgICAgIDYw
ICAgICA2MCAgICAxMjggICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYKeGZzX2NoYXNobGlzdCAg
ICAgICA1NjA2ICAgNTg1OCAgICAgMTYgICAyOSAgIDI5ICAgIDEgOiAgMjUyICAxMjYKeGZzX2ls
aSAgICAgICAgICAgICAgNzA3ICAgIDcyOCAgICAxMzYgICAyNiAgIDI2ICAgIDEgOiAgMjUyICAx
MjYKeGZzX2lmb3JrICAgICAgICAgICAgICAwICAgICAgMCAgICAgNTYgICAgMCAgICAwICAgIDEg
OiAgMjUyICAxMjYKeGZzX2VmaV9pdGVtICAgICAgICAgIDMwICAgICAzMCAgICAyNjAgICAgMiAg
ICAyICAgIDEgOiAgMTI0ICAgNjIKeGZzX2VmZF9pdGVtICAgICAgICAgIDMwICAgICAzMCAgICAy
NjAgICAgMiAgICAyICAgIDEgOiAgMTI0ICAgNjIKeGZzX2J1Zl9pdGVtICAgICAgICAgIDc4ICAg
ICA3OCAgICAxNDggICAgMyAgICAzICAgIDEgOiAgMjUyICAxMjYKeGZzX2RhYnVmICAgICAgICAg
ICAgMjAyICAgIDIwMiAgICAgMTYgICAgMSAgICAxICAgIDEgOiAgMjUyICAxMjYKeGZzX2RhX3N0
YXRlICAgICAgICAgIDIyICAgICAyMiAgICAzNDAgICAgMiAgICAyICAgIDEgOiAgMTI0ICAgNjIK
eGZzX3RyYW5zICAgICAgICAgICAgMTMwICAgIDE5MiAgICAzMjAgICAxMyAgIDE2ICAgIDEgOiAg
MTI0ICAgNjIKeGZzX2lub2RlICAgICAgICAgIDkxODc2IDEzMTQzMiAgICA0NjggMTI1MzkgMTY0
MjkgICAgMSA6ICAxMjQgICA2Mgp4ZnNfYnRyZWVfY3VyICAgICAgICAgNTYgICAgIDU2ICAgIDE0
MCAgICAyICAgIDIgICAgMSA6ICAyNTIgIDEyNgp4ZnNfYm1hcF9mcmVlX2l0ZW0gICAgMjAyICAg
IDIwMiAgICAgMTYgICAgMSAgICAxICAgIDEgOiAgMjUyICAxMjYKcGFnZV9idWZfdCAgICAgICAg
ICAgMjYyICAgIDY0MCAgICAxOTIgICAzMSAgIDMyICAgIDEgOiAgMjUyICAxMjYKcGFnZV9idWZf
cmVnX3QgICAgICAgICAxICAgICA0MCAgICAgOTYgICAgMSAgICAxICAgIDEgOiAgMjUyICAxMjYK
YXZsX29iamVjdF90ICAgICAgICAgICAxICAgIDExMyAgICAgMzIgICAgMSAgICAxICAgIDEgOiAg
MjUyICAxMjYKYXZsX2VudHJ5X3QgICAgICAgICAgMzEzICAgIDY3OCAgICAgMzIgICAgNiAgICA2
ICAgIDEgOiAgMjUyICAxMjYKbmZzX3JlYWRfZGF0YSAgICAgICAgICAwICAgICAgMCAgICAzODQg
ICAgMCAgICAwICAgIDEgOiAgMTI0ICAgNjIKbmZzX3dyaXRlX2RhdGEgICAgICAgICAwICAgICAg
MCAgICAzODQgICAgMCAgICAwICAgIDEgOiAgMTI0ICAgNjIKbmZzX3BhZ2UgICAgICAgICAgICAg
ICAwICAgICAgMCAgICAgOTYgICAgMCAgICAwICAgIDEgOiAgMjUyICAxMjYKYmxrZGV2X3JlcXVl
c3RzICAgICAyMDQ4ICAgMjA4MCAgICAgOTYgICA1MiAgIDUyICAgIDEgOiAgMjUyICAxMjYKZG5v
dGlmeSBjYWNoZSAgICAgICAgICAwICAgICAgMCAgICAgMjAgICAgMCAgICAwICAgIDEgOiAgMjUy
ICAxMjYKZmlsZSBsb2NrIGNhY2hlICAgICAgMTI2ICAgIDEyNiAgICAgOTIgICAgMyAgICAzICAg
IDEgOiAgMjUyICAxMjYKZmFzeW5jIGNhY2hlICAgICAgICAgICAyICAgIDIwMiAgICAgMTYgICAg
MSAgICAxICAgIDEgOiAgMjUyICAxMjYKdWlkX2NhY2hlICAgICAgICAgICAgMTI2ICAgIDIyNiAg
ICAgMzIgICAgMiAgICAyICAgIDEgOiAgMjUyICAxMjYKc2tidWZmX2hlYWRfY2FjaGUgICAgOTAw
ICAgIDkwMCAgICAxOTIgICA0NSAgIDQ1ICAgIDEgOiAgMjUyICAxMjYKc29jayAgICAgICAgICAg
ICAgICAgMTgwICAgIDE4MCAgICA5MjggICA0NSAgIDQ1ICAgIDEgOiAgMTI0ICAgNjIKaW5vZGVf
Y2FjaGUgICAgICAgIDkyMDc1IDEwMDUwNCAgICA0ODAgMTI1NjMgMTI1NjMgICAgMSA6ICAxMjQg
ICA2MgpiZGV2X2NhY2hlICAgICAgICAgICAzODAgICAgNDcyICAgICA2NCAgICA4ICAgIDggICAg
MSA6ICAyNTIgIDEyNgpzaWdxdWV1ZSAgICAgICAgICAgICAyNjEgICAgMjYxICAgIDEzMiAgICA5
ICAgIDkgICAgMSA6ICAyNTIgIDEyNgpkZW50cnlfY2FjaGUgICAgICAgNDU2NjIgIDgxMDAwICAg
IDEyOCAyNzAwIDI3MDAgICAgMSA6ICAyNTIgIDEyNgpmaWxwICAgICAgICAgICAgICAgIDExNjAg
ICAxMTYwICAgICA5NiAgIDI5ICAgMjkgICAgMSA6ICAyNTIgIDEyNgpuYW1lc19jYWNoZSAgICAg
ICAgICAgIDkgICAgICA5ICAgNDA5NiAgICA5ICAgIDkgICAgMSA6ICAgNjAgICAzMApidWZmZXJf
aGVhZCAgICAgICAgIDkwNjEgIDEzMjAwICAgICA5NiAgMzI1ICAzMzAgICAgMSA6ICAyNTIgIDEy
NgptbV9zdHJ1Y3QgICAgICAgICAgICAxODAgICAgMTgwICAgIDEyOCAgICA2ICAgIDYgICAgMSA6
ICAyNTIgIDEyNgp2bV9hcmVhX3N0cnVjdCAgICAgIDM0MjIgICAzNDIyICAgICA2NCAgIDU4ICAg
NTggICAgMSA6ICAyNTIgIDEyNgpmc19jYWNoZSAgICAgICAgICAgICAyMzYgICAgMjM2ICAgICA2
NCAgICA0ICAgIDQgICAgMSA6ICAyNTIgIDEyNgpmaWxlc19jYWNoZSAgICAgICAgICAxMjYgICAg
MTI2ICAgIDQxNiAgIDE0ICAgMTQgICAgMSA6ICAxMjQgICA2MgpzaWduYWxfYWN0ICAgICAgICAg
ICAxMDUgICAgMTA1ICAgMTMxMiAgIDM1ICAgMzUgICAgMSA6ICAgNjAgICAzMApzaXplLTEzMTA3
MihETUEpICAgICAgIDAgICAgICAwIDEzMTA3MiAgICAwICAgIDAgICAzMiA6ICAgIDAgICAgMApz
aXplLTEzMTA3MiAgICAgICAgICAgIDAgICAgICAwIDEzMTA3MiAgICAwICAgIDAgICAzMiA6ICAg
IDAgICAgMApzaXplLTY1NTM2KERNQSkgICAgICAgIDAgICAgICAwICA2NTUzNiAgICAwICAgIDAg
ICAxNiA6ICAgIDAgICAgMApzaXplLTY1NTM2ICAgICAgICAgICAgIDMgICAgICAzICA2NTUzNiAg
ICAzICAgIDMgICAxNiA6ICAgIDAgICAgMApzaXplLTMyNzY4KERNQSkgICAgICAgIDAgICAgICAw
ICAzMjc2OCAgICAwICAgIDAgICAgOCA6ICAgIDAgICAgMApzaXplLTMyNzY4ICAgICAgICAgICAg
IDEgICAgICA0ICAzMjc2OCAgICAxICAgIDQgICAgOCA6ICAgIDAgICAgMApzaXplLTE2Mzg0KERN
QSkgICAgICAgIDAgICAgICAwICAxNjM4NCAgICAwICAgIDAgICAgNCA6ICAgIDAgICAgMApzaXpl
LTE2Mzg0ICAgICAgICAgICAgIDAgICAgICAyICAxNjM4NCAgICAwICAgIDIgICAgNCA6ICAgIDAg
ICAgMApzaXplLTgxOTIoRE1BKSAgICAgICAgIDAgICAgICAwICAgODE5MiAgICAwICAgIDAgICAg
MiA6ICAgIDAgICAgMApzaXplLTgxOTIgICAgICAgICAgICAgIDEgICAgICA1ICAgODE5MiAgICAx
ICAgIDUgICAgMiA6ICAgIDAgICAgMApzaXplLTQwOTYoRE1BKSAgICAgICAgIDAgICAgICAwICAg
NDA5NiAgICAwICAgIDAgICAgMSA6ICAgNjAgICAzMApzaXplLTQwOTYgICAgICAgICAgICAgNzkg
ICAgMTEwICAgNDA5NiAgIDc5ICAxMTAgICAgMSA6ICAgNjAgICAzMApzaXplLTIwNDgoRE1BKSAg
ICAgICAgIDAgICAgICAwICAgMjA0OCAgICAwICAgIDAgICAgMSA6ICAgNjAgICAzMApzaXplLTIw
NDggICAgICAgICAgICAgOTggICAgMTI4ICAgMjA0OCAgIDU1ICAgNjQgICAgMSA6ICAgNjAgICAz
MApzaXplLTEwMjQoRE1BKSAgICAgICAgIDAgICAgICAwICAgMTAyNCAgICAwICAgIDAgICAgMSA6
ICAxMjQgICA2MgpzaXplLTEwMjQgICAgICAgICAgICAyNTYgICAgMjU2ICAgMTAyNCAgIDY0ICAg
NjQgICAgMSA6ICAxMjQgICA2MgpzaXplLTUxMihETUEpICAgICAgICAgIDAgICAgICAwICAgIDUx
MiAgICAwICAgIDAgICAgMSA6ICAxMjQgICA2MgpzaXplLTUxMiAgICAgICAgICAgICAyMjQgICAg
MjI0ICAgIDUxMiAgIDI4ICAgMjggICAgMSA6ICAxMjQgICA2MgpzaXplLTI1NihETUEpICAgICAg
ICAgIDAgICAgICAwICAgIDI1NiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNgpzaXplLTI1NiAg
ICAgICAgICAgIDEyMTUgICAxMjE1ICAgIDI1NiAgIDgxICAgODEgICAgMSA6ICAyNTIgIDEyNgpz
aXplLTEyOChETUEpICAgICAgICAgIDAgICAgICAwICAgIDEyOCAgICAwICAgIDAgICAgMSA6ICAy
NTIgIDEyNgpzaXplLTEyOCAgICAgICAgICAgIDMzODQgICAzNTEwICAgIDEyOCAgMTE3ICAxMTcg
ICAgMSA6ICAyNTIgIDEyNgpzaXplLTY0KERNQSkgICAgICAgICAgIDAgICAgICAwICAgICA2NCAg
ICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNgpzaXplLTY0ICAgICAgICAgICAgIDcyMzMgICA3NjEx
ICAgICA2NCAgMTI4ICAxMjkgICAgMSA6ICAyNTIgIDEyNgpzaXplLTMyKERNQSkgICAgICAgICAg
IDAgICAgICAwICAgICAzMiAgICAwICAgIDAgICAgMSA6ICAyNTIgIDEyNgpzaXplLTMyICAgICAg
ICAgICAgMTAzNjAgIDIwNTY2ICAgICAzMiAgMTQ4ICAxODIgICAgMSA6ICAyNTIgIDEyNgo=

--------------Boundary-00=_T504J4WBJ6LN5N4PIAGY--

From owner-linux-xfs@oss.sgi.com Tue May 29 16:43:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TNhcA15254
	for linux-xfs-outgoing; Tue, 29 May 2001 16:43:38 -0700
Received: (from root@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4TNhZE15252
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 16:43:35 -0700
Date: Tue, 29 May 2001 16:43:35 -0700
From: root <root@oss.sgi.com>
Message-Id: <200105292343.f4TNhZE15252@oss.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

List test please ignore

From owner-linux-xfs@oss.sgi.com Tue May 29 17:01:26 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U01Qe15659
	for linux-xfs-outgoing; Tue, 29 May 2001 17:01:26 -0700
Received: from linux-xfs.sgi.com (IDENT:root@linux-xfs.sgi.com [216.32.174.30])
	by oss.sgi.com (8.11.3/8.11.3) with ESMTP id f4U01Nh15656
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 17:01:23 -0700
Received: (from cattelan@localhost)
	by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f4U01Nx4010535
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 17:01:23 -0700
Date: Tue, 29 May 2001 17:01:23 -0700
From: cattelan@linux-xfs.sgi.com
Message-Id: <200105300001.f4U01Nx4010535@linux-xfs.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

List test please ignore

From owner-linux-xfs@oss.sgi.com Tue May 29 17:03:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U03Vn15731
	for linux-xfs-outgoing; Tue, 29 May 2001 17:03:31 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U03Nh15725
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 17:03:28 -0700
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [137.38.226.97]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id CAA1032659
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 02:03:17 +0200 (CEST)
	mail_from (cattelan@gibble.americas.sgi.com)
Received: from gibble.americas.sgi.com (gibble.americas.sgi.com [128.162.195.80]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA99373 for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 19:02:01 -0500 (CDT)
Received: (from cattelan@localhost)
	by gibble.americas.sgi.com (8.11.3/8.11.2) id f4U011R30638
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 20:01:01 -0400
Date: Tue, 29 May 2001 20:01:01 -0400
From: Russell Cattelan <cattelan@sgi.com>
Message-Id: <200105300001.f4U011R30638@gibble.americas.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

List test please ignore

From owner-linux-xfs@oss.sgi.com Tue May 29 17:58:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U0wJE17208
	for linux-xfs-outgoing; Tue, 29 May 2001 17:58:19 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U0wHh17199
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 17:58:17 -0700
Received: (from cattelan@localhost)
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) id f4TNbrbb047335
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 18:37:53 -0500 (CDT)
Date: Tue, 29 May 2001 18:37:53 -0500 (CDT)
From: Russell Cattelan <cattelan@thebarn.com>
Message-Id: <200105292337.f4TNbrbb047335@lips.borg.umn.edu>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

List test please ignore

From owner-linux-xfs@oss.sgi.com Tue May 29 21:26:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U4Qiv20579
	for linux-xfs-outgoing; Tue, 29 May 2001 21:26:44 -0700
Received: from wolfbert.skynet.be (wolfbert.skynet.be [195.238.3.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U4Qeh20576
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 21:26:41 -0700
Received: from riker.skynet.be (riker.skynet.be [195.238.3.132])
	by wolfbert.skynet.be (8.11.2/8.11.2/Skynet-OUT-FALLBACK-2.12) with ESMTP id f4TJQ5c10676
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 21:26:05 +0200 (MET DST)
	(envelope-from <kris.buggenhout@skynet.be>)
Received: from skynet.be (adsl-45538.turboline.skynet.be [217.136.49.226])
	by riker.skynet.be (8.11.2/8.11.2/Skynet-OUT-2.11) with ESMTP id f4TJOGs03490
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 21:24:16 +0200 (MET DST)
	(envelope-from <kris.buggenhout@skynet.be>)
Message-ID: <3B13F63C.8C5F3EB3@skynet.be>
Date: Tue, 29 May 2001 21:19:24 +0200
From: kris buggenhout <kris.buggenhout@skynet.be>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: whats wrong with the cvs repository ( cvsup )
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

for 2 days in a row i cannot make contact with the cvs repository for
xfs .. ( with cvsup to linux-xfs.sgi.com)

any hope on restoring that service ?



From owner-linux-xfs@oss.sgi.com Tue May 29 22:47:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U5lKs21211
	for linux-xfs-outgoing; Tue, 29 May 2001 22:47:20 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U5lHh21208
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 22:47:17 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4U5lCaJ049930;
	Wed, 30 May 2001 00:47:13 -0500 (CDT)
Message-ID: <3B14895B.AB22EEC7@thebarn.com>
Date: Wed, 30 May 2001 00:47:07 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: kris buggenhout <kris.buggenhout@skynet.be>
CC: linux-xfs@thebarn.com
Subject: Re: whats wrong with the cvs repository ( cvsup )
References: <3B13F63C.8C5F3EB3@skynet.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kris buggenhout wrote:

> for 2 days in a row i cannot make contact with the cvs repository for
> xfs .. ( with cvsup to linux-xfs.sgi.com)
>
> any hope on restoring that service ?

I apologize for interruption of service.

oss and linux-xfs were moved inside of a firewall this past Friday,
which
also involved a change of ip address for both machines.

Due to some poor planing the DNS  configuration were not correctly
updated, and certain ports (namely cvsup) were also not correctly
configured.

I have contacted the admin and he is trying to contact the appropriate
people
in control of the DNS and firewall configurations..

short answer: hopefully soon.



--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Tue May 29 23:02:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U625Q21392
	for linux-xfs-outgoing; Tue, 29 May 2001 23:02:05 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U621h21388
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 23:02:01 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4TFU9E08367;
	Tue, 29 May 2001 10:30:09 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 29 May 2001 10:30:09 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: TAKE - fix panic caused by mix of local and remote access to
 xfs 
In-Reply-To: <200105291408.f4TE8w506689@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105291029560.8330-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

That means it's been tagged?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 29 May 2001, Steve Lord wrote:

> >
> > Sod's law says you find the hole right after you ship the code. There is a
> > bug in this code, I would not do a cvs update until I get a fix in, I know
> > roughly how to fix it, but it will take me a while to code and test it.
> >
> > I would hold off on the cvs tree for a while until you see another message
> > from me on this thread - probably not today.
> >
> > Steve
> >
>
> This was fixed over the weekend by the way.
>
> Steve
>


From owner-linux-xfs@oss.sgi.com Tue May 29 23:02:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U625W21393
	for linux-xfs-outgoing; Tue, 29 May 2001 23:02:05 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U620h21386
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 23:02:00 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4TGBTi08661;
	Tue, 29 May 2001 11:11:29 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Tue, 29 May 2001 11:11:29 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: TAKE - fix panic caused by mix of local and remote access to
 xfs 
In-Reply-To: <200105291538.f4TFc4H07995@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105291110550.8330-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

The tree has been updated for everyone with all newest changes since
friday, so this fix can be checked out?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Tue, 29 May 2001, Steve Lord wrote:

> > That means it's been tagged?
>
> I am not sure what you mean by tagged, I checked in a fix for the problem
> with the implementation I checked in on Friday, and in cleaning my mail
> box I saw that I had said I would do a followup under the same heading.
>
> Steve
>
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
> > On Tue, 29 May 2001, Steve Lord wrote:
> >
> > > >
> > > > Sod's law says you find the hole right after you ship the code. There is
> > a
> > > > bug in this code, I would not do a cvs update until I get a fix in, I kno
> > w
> > > > roughly how to fix it, but it will take me a while to code and test it.
> > > >
> > > > I would hold off on the cvs tree for a while until you see another messag
> > e
> > > > from me on this thread - probably not today.
> > > >
> > > > Steve
> > > >
> > >
> > > This was fixed over the weekend by the way.
> > >
> > > Steve
> > >
>


From owner-linux-xfs@oss.sgi.com Wed May 30 02:56:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4U9uc225274
	for linux-xfs-outgoing; Wed, 30 May 2001 02:56:38 -0700
Received: from ccsd.tsure.ru (mail.ccsd.tsure.ru [213.24.19.38])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4U9uVh25271
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 02:56:32 -0700
Received: from ccsd.tsure.ru (localhost [127.0.0.1])
	by ccsd.tsure.ru (8.11.0/8.10.1) with ESMTP id f4U80Rt02370
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:00:27 +0400
Message-ID: <3B14A89A.6080509@ccsd.tsure.ru>
Date: Wed, 30 May 2001 12:00:26 +0400
From: Piter Kravtchenko <lb@ccsd.tsure.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-XFS i686; en-US; 0.8.1) Gecko/20010326
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Cannot repair XFS partition
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I have a problem. During data reading from 25G XFS partition a catch 
kernel panic errors. Also, this errors occurs when i trying xfs_repair 
on this partition. How can i rescue my data?


From owner-linux-xfs@oss.sgi.com Wed May 30 03:12:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UAC2W25482
	for linux-xfs-outgoing; Wed, 30 May 2001 03:12:02 -0700
Received: from dmz.tecosim.de ([194.24.222.241])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UABth25479
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 03:11:56 -0700
Received: (from uucp@localhost)
	by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f4UA6f521538
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:06:41 +0200
Received: from ns.tecosim.de(194.24.222.9)
 via SMTP by dmz.tecosim.de, id smtpdHDm37c; Wed May 30 12:06:39 2001
Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109])
	by ns.tecosim.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f4UAB7E31623
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:11:07 +0200
Received: (from leh@localhost)
	by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4UAB7600466
	for linux-xfs@oss.sgi.com; Wed, 30 May 2001 12:11:07 +0200
Date: Wed, 30 May 2001 12:11:07 +0200
From: Utz Lehmann <leh@de.tecosim.com>
To: linux-xfs@oss.sgi.com
Subject: Fwd: Fwd: compiler issues with gcc-2.96-81
Message-ID: <20010530121107.A32073@de.tecosim.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

I have made some tests with the Redhat 7.1 gcc-2.96-81.
If I remember correctly Steve mailed that he has no problemes with the gcc
and I always had problems. So I think about the difference about Steves and
my compilations. One thing is, that it could be for a different processor
type. I test it with a interesting result:

All test was using a CVS kernel from 2001-05-24. This source is stable with
kgcc. I have a k6-2 500 System. I normaly compilied the kernel for k6 of
course.

The first test with gcc-2.96-81 was using "pentium classic" as processor
family in make xconfig (-march=i586).
This kernel made no problems. I have used it for several days and medium
stressed it.

The second test was using k6 as processor family (-march=k6).
The 3rd reboot (after a unclean shutdown) crashed while processing the boot
scripts. It trapped in kdb (sorry no serial console this time).
I rebooted the system and it hangs in the boot scripts (no kdb). One error
message told me that /var/run/utmp is a directory.

I booted the XFS install CD and run xfs_check and xfs_repair. The usual
thing: pid files from /var/run were in /lost+found. If you want I can mail
you the output from xfs_check and xfs_repair.

I thing the code generation for k6 processors are buggy in gcc-2.96-81.


ps: Good luck for the future Russell and many thanks.

utz

From owner-linux-xfs@oss.sgi.com Wed May 30 06:15:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UDF2n28203
	for linux-xfs-outgoing; Wed, 30 May 2001 06:15:02 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UDEwh28195
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 06:14:58 -0700
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4U4dOa13883;
	Tue, 29 May 2001 23:39:24 -0500 (CDT)
Message-ID: <3B147A60.E1359FA@sgi.com>
Date: Tue, 29 May 2001 23:43:12 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: kris buggenhout <kris.buggenhout@skynet.be>
CC: "linux-xfs@oss.sgi.com" <linux-xfs@oss.sgi.com>
Subject: Re: whats wrong with the cvs repository ( cvsup )
References: <3B13F63C.8C5F3EB3@skynet.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

kris buggenhout wrote:
> 
> for 2 days in a row i cannot make contact with the cvs repository for
> xfs .. ( with cvsup to linux-xfs.sgi.com)
> 
> any hope on restoring that service ?

We've had some um... trouble with all services on oss.sgi.com &
linux-xfs.sgi.com.  Hopefully all this will be back in order soon.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Wed May 30 06:50:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UDojr28852
	for linux-xfs-outgoing; Wed, 30 May 2001 06:50:45 -0700
Received: from mail.newearth.org (IDENT:0@unityhill.com [207.106.123.146])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UDogh28848
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 06:50:42 -0700
Received: from sapphire.newearth.org (IDENT:1001@sapphire.newearth.org [207.106.123.148])
	by mail.newearth.org (8.11.4/8.11.4) with ESMTP id f4UDoeD03016
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:50:40 -0400
Date: Wed, 30 May 2001 09:50:40 -0400 (EDT)
From: Michael David <michael@newearth.org>
To: <linux-xfs@oss.sgi.com>
Subject: 2.4.5-xfs panic while starting aic7xxx
In-Reply-To: <200105291408.f4TE8w506689@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.32.0105300944520.2552-100000@sapphire.newearth.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

SCSI subsystem driver Revision: 1.00
PCI: Found IRQ 11 for device 00:0c.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
        <Adaptec 2940 Ultra2 SCSI adapter>
        aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message
SCSIID = 7, target_mask = 1
Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000
In interrupt handler - not syncing

Prior versions from 2.4.0-xfs to 2.4.4-xfs all worked.


-- 
Michael V. David, AAO (Acronym Assignment Officer), NewEarth Swedenborg BBS
michael@newearth.org - http://www.newearth.org/~michael - Penguin 2.4.3-XFS
"Never apply a Star Trek solution to a Babylon 5 problem" -- Nicholas C. Weaver


From owner-linux-xfs@oss.sgi.com Wed May 30 07:06:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UE6S029394
	for linux-xfs-outgoing; Wed, 30 May 2001 07:06:28 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UE6Oh29391
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 07:06:24 -0700
Received: (qmail 4228 invoked from network); 30 May 2001 14:06:20 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 30 May 2001 14:06:20 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Michael David <michael@newearth.org>
cc: linux-xfs@oss.sgi.com
Subject: Re: 2.4.5-xfs panic while starting aic7xxx 
In-reply-to: Your message of "Wed, 30 May 2001 09:50:40 -0400."
             <Pine.LNX.4.32.0105300944520.2552-100000@sapphire.newearth.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 31 May 2001 00:06:19 +1000
Message-ID: <20787.991231579@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 30 May 2001 09:50:40 -0400 (EDT), 
Michael David <michael@newearth.org> wrote:
>SCSI subsystem driver Revision: 1.00
>PCI: Found IRQ 11 for device 00:0c.0
>scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
>        <Adaptec 2940 Ultra2 SCSI adapter>
>        aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
>ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message
>SCSIID = 7, target_mask = 1
>Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000
>In interrupt handler - not syncing

There are lots of changes to aic7xxx sequencer code between 2.4.4 and
2.4.5, the 2.4.5-xfs patch has exactly the same code as 2.4.5 base in
this area.  This is almost certainly a generic 2.4.5 aic7xxx problem,
not XFS related.  I suggest you take this to linux-kernel, linux-scsi
or the aic7xxx maintainer.


From owner-linux-xfs@oss.sgi.com Wed May 30 07:12:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UECEM29519
	for linux-xfs-outgoing; Wed, 30 May 2001 07:12:14 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UECAh29516
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 07:12:10 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4UEC6aJ054332;
	Wed, 30 May 2001 09:12:06 -0500 (CDT)
Message-ID: <3B14FFB1.1B8669F0@thebarn.com>
Date: Wed, 30 May 2001 09:12:01 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Keith Owens <kaos@melbourne.sgi.com>
CC: Michael David <michael@newearth.org>, linux-xfs@thebarn.com
Subject: Re: 2.4.5-xfs panic while starting aic7xxx
References: <20787.991231579@ocs3.ocs-net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Owens wrote:

> On Wed, 30 May 2001 09:50:40 -0400 (EDT),
> Michael David <michael@newearth.org> wrote:
> >SCSI subsystem driver Revision: 1.00
> >PCI: Found IRQ 11 for device 00:0c.0
> >scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
> >        <Adaptec 2940 Ultra2 SCSI adapter>
> >        aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
> >ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message
> >SCSIID = 7, target_mask = 1
> >Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000
> >In interrupt handler - not syncing
>
> There are lots of changes to aic7xxx sequencer code between 2.4.4 and
> 2.4.5, the 2.4.5-xfs patch has exactly the same code as 2.4.5 base in
> this area.  This is almost certainly a generic 2.4.5 aic7xxx problem,
> not XFS related.  I suggest you take this to linux-kernel, linux-scsi
> or the aic7xxx maintainer.

Yes agreed.

One side note: This looks very similar to the APIC problem the 1200's were
having.
Try enabling APIC and see if that helps the problem.



--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed May 30 08:09:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UF9IK30779
	for linux-xfs-outgoing; Wed, 30 May 2001 08:09:18 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UF9Eh30775
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 08:09:14 -0700
Received: from hermes.aoe.vt.edu (IDENT:root@hps.aoe.vt.edu [128.173.191.43])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4UF97aJ055021;
	Wed, 30 May 2001 10:09:07 -0500 (CDT)
Received: from localhost (jmd@localhost)
	by hermes.aoe.vt.edu (8.9.3/8.9.3) with ESMTP id LAA19359;
	Wed, 30 May 2001 11:09:06 -0400
Date: Wed, 30 May 2001 11:09:06 -0400 (EDT)
From: Josh Durham <jmd@aoe.vt.edu>
To: Russell Cattelan <cattelan@thebarn.com>
cc: kris buggenhout <kris.buggenhout@skynet.be>, linux-xfs@thebarn.com
Subject: Re: whats wrong with the cvs repository ( cvsup )
In-Reply-To: <3B14895B.AB22EEC7@thebarn.com>
Message-ID: <Pine.LNX.4.21.0105301108010.19092-100000@hermes.aoe.vt.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Would using the new IP address work, or is there more going on than just
that, to do plain CVS?

If so, what is the new IP address?

- Josh

On Wed, 30 May 2001, Russell Cattelan wrote:

> I apologize for interruption of service.
> 
> oss and linux-xfs were moved inside of a firewall this past Friday,
> which
> also involved a change of ip address for both machines.
> 
> Due to some poor planing the DNS  configuration were not correctly
> updated, and certain ports (namely cvsup) were also not correctly
> configured.
> 
> I have contacted the admin and he is trying to contact the appropriate
> people
> in control of the DNS and firewall configurations..
> 
> short answer: hopefully soon.
> 
> 
> 
> --
> Russell Cattelan
> cattelan@thebarn.com
> 
> 
> 


From owner-linux-xfs@oss.sgi.com Wed May 30 08:23:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UFNLP31007
	for linux-xfs-outgoing; Wed, 30 May 2001 08:23:21 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UFNHh31003
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 08:23:17 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4UFNAaJ055384;
	Wed, 30 May 2001 10:23:10 -0500 (CDT)
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA03533; Wed, 30 May 2001 08:23:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA2006068; Wed, 30 May 2001 10:23:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60503; Wed, 30 May 2001 10:23:07 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UFQ9P18298; Wed, 30 May 2001 10:26:09 -0500
Message-Id: <200105301526.f4UFQ9P18298@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Josh Durham <jmd@aoe.vt.edu>
cc: Russell Cattelan <cattelan@thebarn.com>,
   kris buggenhout <kris.buggenhout@skynet.be>, linux-xfs@thebarn.com
Subject: Re: whats wrong with the cvs repository ( cvsup ) 
In-Reply-To: Message from Josh Durham <jmd@aoe.vt.edu> 
   of "Wed, 30 May 2001 11:09:06 EDT." <Pine.LNX.4.21.0105301108010.19092-100000@hermes.aoe.vt.edu> 
Date: Wed, 30 May 2001 10:26:09 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Would using the new IP address work, or is there more going on than just
> that, to do plain CVS?
> 
> If so, what is the new IP address?
> 
> - Josh

The new oss IP address is 216.32.174.27 it appears you can do cvs updates
with this.

I could cheerfully strangle some people over the move of this machine
if I knew who they were.

Steve

p.s. the message did not make it out, but the tree is at 2.4.5 now.



From owner-linux-xfs@oss.sgi.com Wed May 30 08:41:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UFfPJ32676
	for linux-xfs-outgoing; Wed, 30 May 2001 08:41:25 -0700
Received: from dcs.qmw.ac.uk (nick.dcs.qmw.ac.uk [138.37.88.61])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UFfKh32673
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 08:41:20 -0700
Received: from mb (helo=localhost)
	by dcs.qmw.ac.uk with local-esmtp (Exim 3.22 #6)
	id 15585y-0001GS-00; Wed, 30 May 2001 16:41:14 +0100
Date: Wed, 30 May 2001 16:41:05 +0100 (BST)
From: Matt Bernstein <mb@dcs.qmw.ac.uk>
To: <linux-xfs@oss.sgi.com>
cc: <linux-kernel@vger.kernel.org>
Subject: Re: Oops with 2.4.3-XFS
In-Reply-To: <Pine.LNX.4.33.0105161159400.2837-100000@nick.dcs.qmw.ac.uk>
Message-ID: <Pine.LNX.4.33.0105301632280.26680-100000@nick.dcs.qmw.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After some more testing it's entirely plausible (though unfortunately we
don't have anything conclusive) that we have a hardware problem.

Having added a new drive (hdc as reported below) and booted root=/dev/hdc2
with nothing mounted on hda, we have thus far failed to recreate the crash.

VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: WDC WD400BB-00AUA1, ATA DISK drive
hdc: FUJITSU MPG3102AT E, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(66)
hdc: 20015856 sectors (10248 MB) w/512KiB Cache, CHS=19857/16/63, UDMA(33)

On May 16 Matt Bernstein wrote:

>We have managed to get a Debian potato system (with the 2.4 updates from
>http://people.debian.org/~bunk/debian plus xfs-tools which we imported
>from woody) to run 2.4.3-XFS.
>
>However, in testing a directory with lots (~177000) of files, we get the
>following oops (copied by hand, and run through ksymoops on a Red Hat box
>since the Debian one segfaulted :( )
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7FRSV1vU/2MhEp5cRApffAKDJcNLh6pp/iXyHjdWRC/x/zpabfwCgszG0
6mClfT2pCZwNjo2etYuI0mI=
=hE/Z
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Wed May 30 09:40:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UGejW01058
	for linux-xfs-outgoing; Wed, 30 May 2001 09:40:45 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGedh01054
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:40:39 -0700
Received: from [195.20.224.209] (helo=mrvdom02.schlund.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 154o6y-0003ON-00
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 20:20:56 +0200
Received: from pd9574f01.dip.t-dialin.net ([217.87.79.1] helo=kernelpanix.aura.of.mankind)
	by mrvdom02.schlund.de with esmtp (Exim 2.12 #2)
	id 154o4g-00083m-00
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 20:18:34 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4THdDm13330
	for linux-xfs@oss.sgi.com; Tue, 29 May 2001 19:39:13 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Tue, 29 May 2001 19:39:13 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: linux-xfs@oss.sgi.com
Subject: compiler issues with gcc-2.96-81
Message-ID: <20010529193913.A13073@s2y4n2c.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

I have made some tests with the Redhat 7.1 gcc-2.96-81.
If I remember correctly Steve mailed that he has no problemes with the gcc
and I always had problems. So I think about the difference about Steves and
my compilations. One thing is, that it could be for a different processor
type. I test it with a interesting result:

All test was using a CVS kernel from 2001-05-24. This source is stable with
kgcc. I have a k6-2 500 System. I normaly compilied the kernel for k6 of
course.

The first test with gcc-2.96-81 was using "pentium classic" as processor
family in make xconfig (-march=i586).
This kernel made no problems. I have used it for several days and medium
stressed it.

The second test was using k6 as processor family (-march=k6).
The 3rd reboot (after a unclean shutdown) crashed while processing the boot
scripts. It trapped in kdb (sorry no serial console this time).
I rebooted the system and it hangs in the boot scripts (no kdb). One error
message told me that /var/run/utmp is a directory.

I booted the XFS install CD and run xfs_check and xfs_repair. The usual
thing: pid files from /var/run were in /lost+found. If you want I can mail
you the output from xfs_check and xfs_repair.

I thing the code generation for k6 processors are buggy in gcc-2.96-81.


ps: Good luck for the future Russell and many thanks.

utz

From owner-linux-xfs@oss.sgi.com Wed May 30 09:42:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UGgCH01074
	for linux-xfs-outgoing; Wed, 30 May 2001 09:42:12 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGg7h01071
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:42:07 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4UGg3aJ056377;
	Wed, 30 May 2001 11:42:03 -0500 (CDT)
Message-ID: <3B1522D5.6760AC1C@thebarn.com>
Date: Wed, 30 May 2001 11:41:58 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Josh Durham <jmd@aoe.vt.edu>
CC: kris buggenhout <kris.buggenhout@skynet.be>, linux-xfs@thebarn.com
Subject: Re: whats wrong with the cvs repository ( cvsup )
References: <Pine.LNX.4.21.0105301108010.19092-100000@hermes.aoe.vt.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Josh Durham wrote:

> Would using the new IP address work, or is there more going on than just
> that, to do plain CVS?

The  CVS  port to oss is open
CVSup and CVS ports  to linux-xfs is not   sorry.:-(



>
> If so, what is the new IP address?

Non-authoritative answer:
Name:   oss.sgi.com
Address: 216.32.174.27

Non-authoritative answer:
Name:   linux-xfs.sgi.com
Address: 216.32.174.30


>
>
> - Josh
>
> On Wed, 30 May 2001, Russell Cattelan wrote:
>
> > I apologize for interruption of service.
> >
> > oss and linux-xfs were moved inside of a firewall this past Friday,
> > which
> > also involved a change of ip address for both machines.
> >
> > Due to some poor planing the DNS  configuration were not correctly
> > updated, and certain ports (namely cvsup) were also not correctly
> > configured.
> >
> > I have contacted the admin and he is trying to contact the appropriate
> > people
> > in control of the DNS and firewall configurations..
> >
> > short answer: hopefully soon.
> >
> >
> >
> > --
> > Russell Cattelan
> > cattelan@thebarn.com
> >
> >
> >

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed May 30 09:51:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UGpTh01315
	for linux-xfs-outgoing; Wed, 30 May 2001 09:51:29 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGpHh01310
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:51:17 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA06580
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 08:37:19 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1991589; Tue, 29 May 2001 10:36:02 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA15074; Tue, 29 May 2001 10:36:02 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4TFc4H07995; Tue, 29 May 2001 10:38:04 -0500
Message-Id: <200105291538.f4TFc4H07995@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: Steve Lord <lord@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to xfs 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Tue, 29 May 2001 10:30:09 CDT." <Pine.LNX.4.33.0105291029560.8330-100000@UberGeek.coremetrics.com> 
Date: Tue, 29 May 2001 10:38:04 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> That means it's been tagged?

I am not sure what you mean by tagged, I checked in a fix for the problem
with the implementation I checked in on Friday, and in cleaning my mail
box I saw that I had said I would do a followup under the same heading.

Steve

> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Tue, 29 May 2001, Steve Lord wrote:
> 
> > >
> > > Sod's law says you find the hole right after you ship the code. There is 
> a
> > > bug in this code, I would not do a cvs update until I get a fix in, I kno
> w
> > > roughly how to fix it, but it will take me a while to code and test it.
> > >
> > > I would hold off on the cvs tree for a while until you see another messag
> e
> > > from me on this thread - probably not today.
> > >
> > > Steve
> > >
> >
> > This was fixed over the weekend by the way.
> >
> > Steve
> >



From owner-linux-xfs@oss.sgi.com Wed May 30 09:53:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UGr6S01449
	for linux-xfs-outgoing; Wed, 30 May 2001 09:53:06 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGr3h01446
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:53:03 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id NAA07185
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 13:51:48 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id PAA1977200 for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 15:50:32 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA34585 for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 15:50:32 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4RKqqM06890; Sun, 27 May 2001 15:52:52 -0500
Message-Id: <200105272052.f4RKqqM06890@jen.americas.sgi.com>
Date: Sun, 27 May 2001 15:52:52 -0500
Subject: TAKE - fix xfs inode handling code
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Previous version did not cope with prune_icache and iget racing in the
xfs cache.

Date:  Sun May 27 13:46:48 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96003a
linux/fs/xfs/xfs_iget.c - 1.144
	- Look out for inode which are being freed or cleared when scanning
	  the xfs inode hash for a match, skip these entries, drop the locks
	  and try again.

linux/fs/xfs/linux/xfs_super.c - 1.125
	- remove unreachable case



From owner-linux-xfs@oss.sgi.com Wed May 30 09:57:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UGvMY02391
	for linux-xfs-outgoing; Wed, 30 May 2001 09:57:22 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UGvBh02372
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 09:57:12 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA01588
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 08:54:00 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id KAA1982611; Mon, 28 May 2001 10:52:44 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA20468; Mon, 28 May 2001 10:52:43 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4SFstT24666; Mon, 28 May 2001 10:54:55 -0500
Message-Id: <200105281554.f4SFstT24666@jen.americas.sgi.com>
To: Seth Mos <knuffie@xs4all.nl>
cc: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>,
   Eric Sandeen <sandeen@sgi.com>, linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down 
References: <3B10A64B.E85EA958@sgi.com> <20010526165417.A12668@ladystrange.bluehorizon.nl> <3B10A64B.E85EA958@sgi.com> <4.3.2.7.2.20010528094149.03074660@pop.xs4all.nl>
Comments: In-reply-to Seth Mos <knuffie@xs4all.nl>
   message dated "Mon, 28 May 2001 09:45:42 +0200."
Date: Mon, 28 May 2001 10:54:55 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> 
> So the linux-xfs.sgi.com machine is now unreachable or was it part of a 
> transplant?

linux-xfs has been folded back into the oss machine, I do not know
the details of what happens next, but I think there are more changes
coming.

Hopefully the admins get the message about propogating dns changes.

Steve

> 
> Cheers
> 
> --
> Seth
> Every program has two purposes one for which
> it was written and another for which it wasn't
> I use the last kind.

From owner-linux-xfs@oss.sgi.com Wed May 30 10:07:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UH72o03635
	for linux-xfs-outgoing; Wed, 30 May 2001 10:07:02 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UH6vh03624
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:06:57 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4UH6v8i030755
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:06:57 -0700
Date: Wed, 30 May 2001 10:06:57 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to
 xfs 
In-Reply-To: <200105291538.f4TFc4H07995@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105301002350.712-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

My fileserver has the latest XFS CVS kernel.  Yesterday the machine
crashed/froze  It stopped at 8PM right after this allocation failed
error.  Notice the time when the machine came back, 1AM (it was physically
rebooted).  

I did a search for this error and saw a correlation with xfs and this
error.  Do any of you know if the error and the crash was due to xfs bug?

May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.      
May 30 01:34:19 gauss syslogd 1.3-3: restart.    
*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Tue, 29 May 2001, Steve Lord wrote:

> > That means it's been tagged?
> 
> I am not sure what you mean by tagged, I checked in a fix for the problem
> with the implementation I checked in on Friday, and in cleaning my mail
> box I saw that I had said I would do a followup under the same heading.
> 
> Steve
> 
> > 
> > -- 
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> > 
> > On Tue, 29 May 2001, Steve Lord wrote:
> > 
> > > >
> > > > Sod's law says you find the hole right after you ship the code. There is 
> > a
> > > > bug in this code, I would not do a cvs update until I get a fix in, I kno
> > w
> > > > roughly how to fix it, but it will take me a while to code and test it.
> > > >
> > > > I would hold off on the cvs tree for a while until you see another messag
> > e
> > > > from me on this thread - probably not today.
> > > >
> > > > Steve
> > > >
> > >
> > > This was fixed over the weekend by the way.
> > >
> > > Steve
> > >
> 
> 


From owner-linux-xfs@oss.sgi.com Wed May 30 10:09:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UH9K204098
	for linux-xfs-outgoing; Wed, 30 May 2001 10:09:20 -0700
Received: from sws5.ctd.ornl.gov (sws5.ctd.ornl.gov [160.91.20.105])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UH9Fh04081
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:09:15 -0700
Received: (qmail 23038 invoked by uid 3995); 30 May 2001 15:39:35 -0000
From: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
Mail-Followup-To: linux-xfs@oss.sgi.com
To: linux-xfs@oss.sgi.com
Subject: Oops
Date: 30 May 2001 11:39:35 -0400
Message-ID: <wx0ae3uu9qg.fsf@sws5.ctd.ornl.gov>
Lines: 44
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Delivery-Agent: TMDA v0.10 <http://tmda.sourceforge.net/>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dual-processor Dell with AMI MegaRAID's running SGI XFS 1.0 Red Hat
7.1 (2.4.2-SGI_XFS_1.0smp). One of the MegaRAID fs's is xfs and is
exported to a couple of SGI O200's. Around the same time I did a chown
and chmod on the XFS fs via NFS, the Linux box reported:

May 30 09:47:12 daacsnfs kernel: xfs_iget_core: ambiguous vns: vp/0xf38e7ab0, invp/0xf7067570
May 30 09:47:12 daacsnfs kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008
May 30 09:47:12 daacsnfs kernel:  printing eip:
May 30 09:47:12 daacsnfs kernel: c01e7892
May 30 09:47:12 daacsnfs kernel: pgd entry f697b000: 0000000000000000
May 30 09:47:12 daacsnfs kernel: pmd entry f697b000: 0000000000000000
May 30 09:47:12 daacsnfs kernel: ... pmd not present!
May 30 09:47:12 daacsnfs kernel: Oops: 0000
May 30 09:47:12 daacsnfs kernel: CPU:    1
May 30 09:47:12 daacsnfs kernel: EIP:    0010:[vn_revalidate+34/232]
May 30 09:47:12 daacsnfs kernel: EIP:    0010:[<c01e7892>]
May 30 09:47:12 daacsnfs kernel: EFLAGS: 00010286
May 30 09:47:12 daacsnfs kernel: eax: 00000084   ebx: f7067570   ecx: f7ba6400   edx: 00000000
May 30 09:47:12 daacsnfs kernel: esi: f7067570   edi: 00000084   ebp: f7067570   esp: f6b7dc20
May 30 09:47:12 daacsnfs kernel: ds: 0018   es: 0018   ss: 0018
May 30 09:47:12 daacsnfs kernel: Process nfsd (pid: 719, stackpage=f6b7d000)
May 30 09:47:12 daacsnfs kernel: Stack: f7067570 f7067570 f89048a8 00000001 14003fff f89048c8 ffffffff ffffffff 
May 30 09:47:12 daacsnfs kernel:        00000019 f713fe60 00000002 00000000 00000001 00000002 00000000 00000000 
May 30 09:47:12 daacsnfs kernel:        00000001 c22ea000 f6b7dc94 00000082 f89048ac 00000246 f89048a8 00000046 
May 30 09:47:12 daacsnfs kernel: Call Trace: [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329560/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329528/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329556/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329560/96] [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329524/96] [xfs_iget_core+1916/1956] [ip_rcv+926/992] 
May 30 09:47:12 daacsnfs kernel: Call Trace: [<f89048a8>] [<f89048c8>] [<f89048ac>] [<f89048a8>] [<f89048cc>] [<c01bd320>] [<c0258c5e>] 
May 30 09:47:12 daacsnfs kernel:        [eepro100:__insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329556/96] [xfs_vn_iget+52/60] [vn_initialize+213/344] [linvfs_read_inode+30/80] [get_new_inode+227/376] [iget4+221/232] [<f8981d1d>] [<f89822fd>] 
May 30 09:47:12 daacsnfs kernel:        [<f89048ac>] [<c01bd3b8>] [<c01e7649>] [<c01e6b86>] [<c01505f7>] [<c0150945>] [<f8981d1d>] [<f89822fd>] 
May 30 09:47:12 daacsnfs kernel:        [<f89827a4>] [<f89838bd>] [<f8983ec0>] [do_ccupdate_local+0/64] [smp_call_function_interrupt+50/88] [csum_partial+185/232] [call_call_function_interrupt+5/12] [csum_partial+185/232] 
May 30 09:47:12 daacsnfs kernel:        [<f89827a4>] [<f89838bd>] [<f8983ec0>] [<c012f074>] [<c01134da>] [<c0291a69>] [<c029f12d>] [<c0291a69>] 
May 30 09:47:12 daacsnfs kernel:        [<f8989173>] [<f8991480>] [<f89805c3>] [<f8991480>] [<f89656f8>] [<f8991340>] [<f8990e18>] [<f8980369>] 
May 30 09:47:12 daacsnfs kernel:        [kernel_thread+35/48] 
May 30 09:47:12 daacsnfs kernel:        [<c01075e3>] 
May 30 09:47:12 daacsnfs kernel: 
May 30 09:47:12 daacsnfs kernel: Code: 8b 4a 08 6a 00 25 80 00 00 00 50 8d 44 24 18 50 52 8b 41 14 

I was able to unmount all the filesystems on the SGI's, but the nfsd's
on the Linux box wouldn't die. Had to power cycle to get it back
up. (Why isn't there a way to kill processes in I/O wait?)

Is this a known bug that would be fixed by installing the current CVS'd
kernel?

-Dave

From owner-linux-xfs@oss.sgi.com Wed May 30 10:11:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHBEi04512
	for linux-xfs-outgoing; Wed, 30 May 2001 10:11:14 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHBBh04507
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:11:11 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA06335
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 09:52:31 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1976828; Sun, 27 May 2001 11:51:14 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA61076; Sun, 27 May 2001 11:51:14 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4RGrZ305997; Sun, 27 May 2001 11:53:35 -0500
Message-Id: <200105271653.f4RGrZ305997@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS CVS server seems to be down 
In-Reply-To: Message from "P.A.M. van Dam (Pascal)" <tormentor@ramoth.xs4all.nl> 
   of "Sat, 26 May 2001 16:54:17 +0200." <20010526165417.A12668@ladystrange.bluehorizon.nl> 
Date: Sun, 27 May 2001 11:53:35 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi!
> 
> I'm probably not the first one who notices it, but I'm unable tot reach the
> CVS server. The server responds with a connection refused message.
> 
> Best regards,
> 
> 	Pascal van Dam

Yep - along with most of oss - I am surpised your email made it through. I 
know there were ip address changes this weekend, looks like a number of 
things went wrong.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 30 10:12:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHCFh04787
	for linux-xfs-outgoing; Wed, 30 May 2001 10:12:15 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHC9h04773
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:12:09 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id GAA09279
	for <linux-xfs@oss.sgi.com>; Mon, 28 May 2001 06:02:39 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id IAA1982180; Mon, 28 May 2001 08:00:41 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA38574; Mon, 28 May 2001 08:00:41 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4SD2s607813; Mon, 28 May 2001 08:02:54 -0500
Message-Id: <200105281302.f4SD2s607813@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: CVS Request: tag merges 
In-Reply-To: Message from "Marcelo E. Magallon" <marcelo.magallon@bigfoot.com> 
   of "Mon, 28 May 2001 11:04:08 +0200." <20010528110408.A10827@informatik.uni-stuttgart.de> 
Date: Mon, 28 May 2001 08:02:53 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> >> Eric Sandeen <sandeen@sgi.com> writes:
> 
>  > I'm not sure what the advantage would be?  It's no more stable right
>  > after a kernel merge, or anything like that.  But if you convince me
>  > that it's useful, I could probably do it.  No promises though, I just
>  > got a whole lot more(!) busy as of last week.
> 
>  I sympathize.  The point is to make it easier to compare the XFS tree
>  with the kernel tree, that is, to be able to check out the version
>  right after a given merge at any point in time.  I'm asking this
>  because yesterday I was merging current XFS CVS with 2.4.5 and there
>  were a couple of points where I was left wondering when and why a
>  change was made, and I wished I could have the status of the CVS tree
>  right after 2.4.4 was merged.  I ended up figuring out the dates for
>  the merge, but using tags is easier...


One thing you do not know is that this cvs tree is recreated from scratch
every hour, from a different tree which uses a different (still rcs) based
internal tree. The reason for this is that the internal tree includes
revisions of the files prior to the open source release of XFS, and 
therefore potentially has code which the legal people insist we do not
allow outside the company. However, we internally need to keep the old
revisions and source code mechanism to match up with yet other trees 
within SGI.

Because of this, adding tags to the cvs tree actually means adding tags to
the other tree, and that may be harder than adding a cvs tag to the files.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 30 10:16:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHGqA05453
	for linux-xfs-outgoing; Wed, 30 May 2001 10:16:52 -0700
Received: from bobas.nowytarg.top.pl (ghostwheel.underley.eu.org [217.97.235.9])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHGlh05448
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:16:49 -0700
Received: by bobas.nowytarg.top.pl with BSMTP id <S188509AbRE3RRa>;
	Wed, 30 May 2001 19:17:30 +0200
Received: by witch.underley.eu.org id <S5258587AbRE3QaN>;
	Wed, 30 May 2001 18:30:13 +0200
Date:   Wed, 30 May 2001 18:30:13 +0200
From: Daniel Podlejski <underley@underley.eu.org>
To: linux-xfs@oss.sgi.com
Subject: resizing xfs
Message-ID: <20010530183013.A12752@witch.underley.eu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.17i
X-PGP-Fingerprint: 4D 72 53 F8 FE 8C 53 B9  66 AD F6 EA C9 17 CD 82
X-GPG-Fingerprint: 299F 1820 582B 283A 5F50  37D9 AA0B 6E10 03D4 EA5D
X-Homepage: http://www.underley.eu.org/
X-Cert: http://www.brainbench.com/transcript.jsp?pid=124954
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is posible to decrease xfs filesystem ?

-- 
Daniel Podlejski <underley@underley.eu.org>
   ... You know the day destroys the night
   Night divides the day ...

From owner-linux-xfs@oss.sgi.com Wed May 30 10:23:33 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHNXR05967
	for linux-xfs-outgoing; Wed, 30 May 2001 10:23:33 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHMWh05947
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:22:32 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id NAA00723
	for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 13:01:21 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA1994215 for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 14:59:36 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA50330 for <linux-xfs@oss.sgi.com>; Tue, 29 May 2001 14:59:36 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4TK2we01843; Tue, 29 May 2001 15:02:58 -0500
Message-Id: <200105292002.f4TK2we01843@jen.americas.sgi.com>
Date: Tue, 29 May 2001 15:02:58 -0500
Subject: TAKE - bring xfs up to 2.4.5 kernel
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

merge up to linux 2.4.5

Date:  Tue May 29 12:53:13 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/linux-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96018a
linux/arch/ppc/boot/tree/misc.S - 1.1
linux/include/asm-ppc/ppc4xx.h - 1.1
linux/include/asm-ppc/ppc4xx_serial.h - 1.1
linux/include/asm-alpha/mmzone.h - 1.1
linux/include/asm-ppc/rpxhiox.h - 1.1
linux/include/asm-ppc/rwsem.h - 1.1
linux/fs/nls/nls_koi8-ru.c - 1.1
linux/arch/sparc64/kernel/isa.c - 1.1
linux/fs/freevxfs/vxfs_super.c - 1.1
linux/fs/freevxfs/vxfs_subr.c - 1.1
linux/drivers/net/fealnx.c - 1.1
linux/fs/freevxfs/vxfs_olt.h - 1.1
linux/fs/freevxfs/vxfs_olt.c - 1.1
linux/fs/freevxfs/vxfs_lookup.c - 1.1
linux/fs/freevxfs/vxfs_inode.h - 1.1
linux/drivers/media/video/w9966.c - 1.1
linux/drivers/net/irda/irda-usb.c - 1.1
linux/fs/freevxfs/vxfs_inode.c - 1.1
linux/arch/ppc/kernel/apus_pci.h - 1.1
linux/arch/ppc/kernel/apus_pci.c - 1.1
linux/fs/freevxfs/vxfs_immed.c - 1.1
linux/fs/freevxfs/vxfs_fshead.h - 1.1
linux/drivers/net/wireless/Config.in - 1.1
linux/drivers/net/wireless/Makefile - 1.1
linux/fs/freevxfs/vxfs_fshead.c - 1.1
linux/drivers/net/wireless/README - 1.1
linux/drivers/net/wireless/airport.c - 1.1
linux/drivers/net/wireless/hermes.c - 1.1
linux/Documentation/sound/cs46xx - 1.1
linux/drivers/net/wireless/hermes.h - 1.1
linux/include/asm-sparc64/isa.h - 1.1
linux/Documentation/usb/philips.txt - 1.1
linux/drivers/net/wireless/orinoco.c - 1.1
linux/drivers/net/wireless/orinoco.h - 1.1
linux/drivers/net/wireless/orinoco_cs.c - 1.1
linux/drivers/net/wireless/todo.txt - 1.1
linux/drivers/media/video/bt856.c - 1.1
linux/drivers/media/video/bt819.c - 1.1
linux/drivers/media/video/adv7175.c - 1.1
linux/fs/freevxfs/vxfs_extern.h - 1.1
linux/fs/freevxfs/vxfs_dir.h - 1.1
linux/fs/freevxfs/vxfs_bmap.c - 1.1
linux/fs/freevxfs/vxfs.h - 1.1
linux/fs/freevxfs/Makefile - 1.1
linux/include/linux/mii.h - 1.1
linux/fs/char_dev.c - 1.1
linux/arch/ppc/boot/utils/size - 1.1
linux/arch/ppc/boot/utils/sisize - 1.1
linux/arch/ppc/boot/utils/sioffset - 1.1
linux/arch/ppc/boot/utils/piggyback.c - 1.1
linux/arch/ppc/boot/utils/offset - 1.1
linux/arch/ppc/boot/utils/mksimage.c - 1.1
linux/arch/ppc/boot/utils/mkprep.c - 1.1
linux/arch/ppc/boot/utils/mknote.c - 1.1
linux/arch/alpha/mm/numa.c - 1.1
linux/arch/ppc/boot/utils/mkirimg - 1.1
linux/arch/ppc/boot/utils/mkevimg - 1.1
linux/arch/ppc/boot/utils/hack-coff.c - 1.1
linux/arch/ppc/boot/utils/elf.pl - 1.1
linux/arch/ppc/boot/utils/addnote.c - 1.1
linux/arch/ppc/boot/utils/Makefile - 1.1
linux/arch/ppc/boot/tree/main.c - 1.1
linux/arch/ppc/boot/tree/ld.script - 1.1
linux/arch/arm/lib/csumpartialcopygeneric.S - 1.1
linux/arch/ppc/boot/tree/irSect.h - 1.1
linux/arch/ppc/boot/tree/irSect.c - 1.1
linux/arch/ppc/boot/tree/Makefile - 1.1
linux/arch/ppc/boot/prep/vreset.c - 1.1
linux/arch/ppc/boot/prep/of1275.h - 1.1
linux/arch/ppc/boot/prep/of1275.c - 1.1
linux/arch/ppc/boot/prep/misc.c - 1.1
linux/arch/ppc/boot/prep/kbd.c - 1.1
linux/arch/ppc/boot/prep/iso_font.h - 1.1
linux/arch/ppc/boot/prep/head.S - 1.1
linux/arch/ppc/boot/prep/Makefile - 1.1
linux/arch/ppc/boot/pmac/start.c - 1.1
linux/arch/ppc/boot/pmac/misc.S - 1.1
linux/arch/ppc/boot/pmac/ld.script - 1.1
linux/arch/ppc/boot/pmac/dummy.c - 1.1
linux/arch/ppc/boot/pmac/coffmain.c - 1.1
linux/arch/ppc/boot/pmac/chrpmain.c - 1.1
linux/arch/ppc/boot/pmac/Makefile - 1.1
linux/arch/cris/drivers/ds1302.c - 1.1
linux/arch/cris/drivers/eeprom.c - 1.1
linux/drivers/usb/pwc_timon.h - 1.1
linux/drivers/usb/pwc_nala.h - 1.1
linux/arch/ppc/boot/mbx/rdimage.c - 1.1
linux/arch/ppc/boot/mbx/qspan_pci.c - 1.1
linux/arch/cris/drivers/parport.c - 1.1
linux/arch/ppc/boot/mbx/pci.c - 1.1
linux/arch/ppc/boot/mbx/misc.c - 1.1
linux/arch/ppc/boot/mbx/m8xx_tty.c - 1.1
linux/arch/ppc/boot/mbx/m8260_tty.c - 1.1
linux/arch/ppc/boot/mbx/iic.c - 1.1
linux/arch/ppc/boot/mbx/head_8260.S - 1.1
linux/arch/ppc/boot/mbx/head.S - 1.1
linux/arch/ppc/boot/mbx/gzimage.c - 1.1
linux/arch/ppc/boot/mbx/embed_config.c - 1.1
linux/arch/ppc/boot/mbx/Makefile - 1.1
linux/arch/ppc/boot/lib/zlib.c - 1.1
linux/arch/ppc/boot/lib/Makefile - 1.1
linux/drivers/usb/pwc_kiara.h - 1.1
linux/include/net/irda/irda-usb.h - 1.1
linux/drivers/usb/pwc.h - 1.1
linux/arch/ppc/boot/include/zlib.h - 1.1
linux/arch/ppc/boot/include/rs6000.h - 1.1
linux/arch/ppc/boot/include/nonstdio.h - 1.1
linux/arch/cris/lib/hw_settings.S - 1.1
linux/arch/ppc/boot/images/Makefile - 1.1
linux/drivers/usb/pwc-uncompress.h - 1.1
linux/arch/ppc/boot/common/string.S - 1.1
linux/arch/ppc/boot/common/ns16550.c - 1.1
linux/arch/ppc/boot/common/no_initrd.c - 1.1
linux/arch/ppc/boot/common/misc-simple.c - 1.1
linux/arch/ppc/boot/common/misc-common.c - 1.1
linux/arch/ppc/boot/common/crt0.S - 1.1
linux/arch/ppc/boot/common/Makefile - 1.1
linux/arch/ppc/boot/chrp/start.c - 1.1
linux/arch/ppc/boot/chrp/misc.S - 1.1
linux/arch/ppc/boot/chrp/main.c - 1.1
linux/arch/ppc/boot/chrp/Makefile - 1.1
linux/drivers/usb/pwc-uncompress.c - 1.1
linux/drivers/usb/pwc-misc.c - 1.1
linux/drivers/usb/pwc-ioctl.h - 1.1
linux/drivers/usb/pwc-if.c - 1.1
linux/drivers/usb/pwc-ctrl.c - 1.1
linux/scripts/checkconfig.pl - 1.5
linux/scripts/Menuconfig - 1.10
linux/net/wanrouter/wanproc.c - 1.14
linux/net/wanrouter/Makefile - 1.5
linux/net/irda/wrapper.c - 1.10
linux/net/irda/qos.c - 1.11
linux/net/irda/irttp.c - 1.13
linux/net/irda/af_irda.c - 1.20
linux/net/ipx/sysctl_net_ipx.c - 1.5
linux/net/ipx/af_spx.c - 1.12
linux/net/ipx/af_ipx.c - 1.20
linux/net/ipv6/sit.c - 1.15
linux/net/ipv6/route.c - 1.17
linux/net/ipv6/protocol.c - 1.7
linux/net/ipv6/ndisc.c - 1.13
linux/net/ipv6/addrconf.c - 1.16
linux/net/ipv6/Config.in - 1.6
linux/net/ipv4/tcp_input.c - 1.25
linux/net/ipv4/tcp.c - 1.27
linux/net/ipv4/syncookies.c - 1.10
linux/net/ipv4/route.c - 1.22
linux/net/ipv4/raw.c - 1.18
linux/net/ipv4/protocol.c - 1.7
linux/net/ipv4/proc.c - 1.11
linux/net/ipv4/ipip.c - 1.16
linux/net/ipv4/ipconfig.c - 1.17
linux/net/ipv4/ip_gre.c - 1.16
linux/net/ipv4/icmp.c - 1.17
linux/net/ipv4/fib_rules.c - 1.7
linux/net/ipv4/fib_frontend.c - 1.9
linux/net/ipv4/devinet.c - 1.12
linux/net/ipv4/arp.c - 1.18
linux/net/ipv4/af_inet.c - 1.25
linux/net/ipv4/Config.in - 1.10
linux/net/core/filter.c - 1.8
linux/net/core/dev.c - 1.33
linux/net/README - 1.8
linux/mm/vmscan.c - 1.54
linux/mm/vmalloc.c - 1.31
linux/mm/swapfile.c - 1.31
linux/mm/swap_state.c - 1.24
linux/mm/slab.c - 1.24
linux/mm/page_alloc.c - 1.41
linux/mm/mmap.c - 1.36
linux/mm/filemap.c - 1.74
linux/kernel/resource.c - 1.15
linux/kernel/module.c - 1.22
linux/kernel/ksyms.c - 1.90
linux/kernel/kmod.c - 1.14
linux/kernel/fork.c - 1.32
linux/kernel/exit.c - 1.28
linux/ipc/shm.c - 1.48
linux/init/main.c - 1.54
linux/include/net/snmp.h - 1.8
linux/include/net/protocol.h - 1.6
linux/include/net/irda/irda.h - 1.13
linux/include/net/ipconfig.h - 1.3
linux/include/net/addrconf.h - 1.7
linux/include/linux/videodev.h - 1.15
linux/include/linux/timer.h - 1.9
linux/include/linux/sysctl.h - 1.33
linux/include/linux/synclink.h - 1.6
linux/include/linux/swap.h - 1.26
linux/include/linux/smb_fs_sb.h - 1.5
linux/include/linux/smb_fs_i.h - 1.5
linux/include/linux/smb_fs.h - 1.13
linux/include/linux/smb.h - 1.5
linux/include/linux/skbuff.h - 1.19
linux/include/linux/serial_reg.h - 1.6
linux/include/linux/proc_fs.h - 1.29
linux/include/linux/pci.h - 1.42
linux/include/linux/parport_pc.h - 1.7
linux/include/linux/parport.h - 1.17
linux/include/linux/nfsd/nfsfh.h - 1.9
linux/include/linux/nfs_fs.h - 1.15
linux/include/linux/nbd.h - 1.8
linux/include/linux/msdos_fs_sb.h - 1.7
linux/include/linux/msdos_fs.h - 1.10
linux/include/linux/mount.h - 1.14
linux/include/linux/mm.h - 1.53
linux/include/linux/locks.h - 1.4
linux/include/linux/kernel.h - 1.17
linux/include/linux/iso_fs.h - 1.10
linux/include/linux/isdnif.h - 1.10
linux/include/linux/isdn_ppp.h - 1.9
linux/include/linux/isdn.h - 1.16
linux/include/linux/init.h - 1.13
linux/include/linux/inetdevice.h - 1.5
linux/include/linux/fs.h - 1.94
linux/include/linux/b1lli.h - 1.5
linux/include/asm-sparc64/semaphore.h - 1.8
linux/include/asm-sparc64/semaphore-helper.h - 1.3
linux/include/asm-sparc64/pbm.h - 1.11
linux/include/asm-sparc64/floppy.h - 1.12
linux/include/asm-ppc/vga.h - 1.7
linux/include/asm-ppc/vc_ioctl.h - 1.3
linux/include/asm-ppc/user.h - 1.4
linux/include/asm-ppc/unistd.h - 1.15
linux/include/asm-ppc/unaligned.h - 1.4
linux/include/asm-ppc/ucontext.h - 1.4
linux/include/asm-ppc/uaccess.h - 1.9
linux/include/asm-ppc/types.h - 1.9
linux/include/asm-ppc/traps.h - 1.3
linux/include/asm-ppc/timex.h - 1.5
linux/include/asm-ppc/termios.h - 1.7
linux/include/asm-ppc/termbits.h - 1.5
linux/include/asm-ppc/system.h - 1.18
linux/include/asm-ppc/string.h - 1.5
linux/include/asm-ppc/statfs.h - 1.3
linux/include/asm-ppc/stat.h - 1.7
linux/include/asm-ppc/spinlock.h - 1.10
linux/include/asm-ppc/softirq.h - 1.9
linux/include/asm-ppc/sockios.h - 1.3
linux/include/asm-ppc/socket.h - 1.6
linux/include/asm-ppc/smplock.h - 1.7
linux/include/asm-ppc/smp.h - 1.12
linux/include/asm-ppc/signal.h - 1.5
linux/include/asm-ppc/siginfo.h - 1.7
linux/include/asm-ppc/sigcontext.h - 1.3
linux/include/asm-ppc/shmparam.h - 1.5
linux/include/asm-ppc/setup.h - 1.4
linux/include/asm-ppc/serial.h - 1.9
linux/include/asm-ppc/semaphore.h - 1.8
linux/include/asm-ppc/semaphore-helper.h - 1.4
linux/include/asm-ppc/segment.h - 1.4
linux/include/asm-ppc/scatterlist.h - 1.4
linux/include/asm-ppc/resource.h - 1.9
linux/include/asm-ppc/residual.h - 1.4
linux/include/asm-ppc/raven.h - 1.5
linux/include/asm-ppc/ptrace.h - 1.8
linux/include/asm-ppc/prom.h - 1.10
linux/include/asm-ppc/processor.h - 1.24
linux/include/asm-ppc/prep_nvram.h - 1.5
linux/include/asm-ppc/posix_types.h - 1.7
linux/include/asm-ppc/poll.h - 1.3
linux/include/asm-ppc/pnp.h - 1.4
linux/include/asm-ppc/pgtable.h - 1.25
linux/include/asm-ppc/pci-bridge.h - 1.8
linux/include/asm-ppc/param.h - 1.4
linux/include/asm-ppc/page.h - 1.12
linux/include/asm-ppc/ohare.h - 1.5
linux/include/asm-ppc/nvram.h - 1.6
linux/include/asm-ppc/namei.h - 1.5
linux/include/asm-ppc/mmu_context.h - 1.9
linux/include/asm-ppc/mmu.h - 1.8
linux/include/asm-ppc/mman.h - 1.6
linux/include/asm-ppc/mk48t59.h - 1.3
linux/include/asm-ppc/mediabay.h - 1.5
linux/include/asm-ppc/md.h - 1.4
linux/include/asm-ppc/mbx.h - 1.6
linux/include/asm-ppc/machdep.h - 1.15
linux/include/asm-ppc/linux_logo.h - 1.7
linux/include/asm-ppc/kgdb.h - 1.4
linux/include/asm-ppc/keyboard.h - 1.8
linux/include/asm-ppc/irq.h - 1.14
linux/include/asm-ppc/ipc.h - 1.3
linux/include/asm-ppc/ioctls.h - 1.4
linux/include/asm-ppc/ioctl.h - 1.3
linux/include/asm-ppc/io.h - 1.13
linux/include/asm-ppc/init.h - 1.9
linux/include/asm-ppc/ide.h - 1.11
linux/include/asm-ppc/hydra.h - 1.4
linux/include/asm-ppc/hardirq.h - 1.12
linux/include/asm-ppc/gg2.h - 1.3
linux/include/asm-ppc/floppy.h - 1.4
linux/include/asm-ppc/feature.h - 1.10
linux/include/asm-ppc/fcntl.h - 1.7
linux/include/asm-ppc/fads.h - 1.3
linux/include/asm-ppc/errno.h - 1.3
linux/include/asm-ppc/elf.h - 1.9
linux/include/asm-ppc/dma.h - 1.8
linux/include/asm-ppc/delay.h - 1.5
linux/include/asm-ppc/dbdma.h - 1.4
linux/include/asm-ppc/current.h - 1.4
linux/include/asm-ppc/checksum.h - 1.4
linux/include/asm-ppc/cache.h - 1.8
linux/include/asm-ppc/byteorder.h - 1.6
linux/include/asm-ppc/bugs.h - 1.3
linux/include/asm-ppc/bootx.h - 1.5
linux/include/asm-ppc/bootinfo.h - 1.6
linux/include/asm-ppc/bitops.h - 1.9
linux/include/asm-ppc/atomic.h - 1.6
linux/include/asm-ppc/amipcmcia.h - 1.4
linux/include/asm-ppc/amigayle.h - 1.4
linux/include/asm-ppc/amigappc.h - 1.5
linux/include/asm-ppc/amigaints.h - 1.5
linux/include/asm-ppc/amigahw.h - 1.5
linux/include/asm-ppc/a.out.h - 1.3
linux/include/asm-ppc/8xx_immap.h - 1.4
linux/include/asm-mips/pci.h - 1.9
linux/include/asm-i386/unaligned.h - 1.3
linux/include/asm-i386/system.h - 1.17
linux/include/asm-i386/mtrr.h - 1.5
linux/include/asm-i386/bitops.h - 1.8
linux/include/asm-arm/uaccess.h - 1.6
linux/include/asm-arm/arch-ebsa285/system.h - 1.11
linux/include/asm-alpha/system.h - 1.15
linux/include/asm-alpha/spinlock.h - 1.11
linux/include/asm-alpha/smp.h - 1.16
linux/include/asm-alpha/semaphore.h - 1.8
linux/include/asm-alpha/pgtable.h - 1.26
linux/include/asm-alpha/pci.h - 1.13
linux/include/asm-alpha/page.h - 1.10
linux/include/asm-alpha/core_tsunami.h - 1.11
linux/include/asm-alpha/compiler.h - 1.8
linux/include/asm-alpha/bitops.h - 1.9
linux/fs/umsdos/inode.c - 1.16
linux/fs/ufs/super.c - 1.18
linux/fs/super.c - 1.46
linux/fs/smbfs/sock.c - 1.8
linux/fs/smbfs/proc.c - 1.10
linux/fs/smbfs/ioctl.c - 1.7
linux/fs/smbfs/inode.c - 1.21
linux/fs/smbfs/file.c - 1.19
linux/fs/smbfs/dir.c - 1.14
linux/fs/select.c - 1.15
linux/fs/proc/root.c - 1.23
linux/fs/proc/procfs_syms.c - 1.12
linux/fs/proc/generic.c - 1.19
linux/fs/proc/base.c - 1.23
linux/fs/proc/array.c - 1.28
linux/fs/proc/Makefile - 1.10
linux/fs/nls/Makefile - 1.8
linux/fs/nls/Config.in - 1.8
linux/fs/nfsd/vfs.c - 1.34
linux/fs/nfsd/nfssvc.c - 1.13
linux/fs/nfsd/nfsproc.c - 1.15
linux/fs/nfsd/nfsfh.c - 1.25
linux/fs/nfsd/nfsctl.c - 1.20
linux/fs/nfsd/nfs3xdr.c - 1.17
linux/fs/nfs/write.c - 1.26
linux/fs/nfs/inode.c - 1.25
linux/fs/nfs/file.c - 1.20
linux/fs/nfs/dir.c - 1.27
linux/fs/namei.c - 1.29
linux/fs/isofs/util.c - 1.5
linux/fs/inode.c - 1.41
linux/fs/fcntl.c - 1.15
linux/fs/fat/misc.c - 1.8
linux/fs/fat/inode.c - 1.22
linux/fs/fat/file.c - 1.13
linux/fs/fat/cache.c - 1.10
linux/fs/fat/buffer.c - 1.6
linux/fs/ext2/super.c - 1.17
linux/fs/dquot.c - 1.26
linux/fs/devices.c - 1.14
linux/fs/dcache.c - 1.24
linux/fs/buffer.c - 1.62
linux/fs/block_dev.c - 1.21
linux/fs/binfmt_elf.c - 1.27
linux/fs/Makefile - 1.31
linux/fs/Config.in - 1.58
linux/drivers/video/chipsfb.c - 1.14
linux/drivers/video/atyfb.c - 1.29
linux/drivers/video/aty.h - 1.7
linux/drivers/usb/usb.c - 1.48
linux/drivers/usb/uhci.c - 1.43
linux/drivers/usb/audio.c - 1.30
linux/drivers/usb/Makefile - 1.36
linux/drivers/usb/Config.in - 1.39
linux/drivers/sound/yss225.h - 1.3
linux/drivers/sound/wavfront.c - 1.15
linux/drivers/sound/sb_card.c - 1.24
linux/drivers/sound/es1371.c - 1.32
linux/drivers/sound/es1370.c - 1.31
linux/drivers/scsi/u14-34f.h - 1.7
linux/drivers/scsi/u14-34f.c - 1.15
linux/drivers/scsi/sr.c - 1.25
linux/drivers/scsi/sd.c - 1.35
linux/drivers/scsi/scsi_proc.c - 1.9
linux/drivers/scsi/scsi.c - 1.35
linux/drivers/scsi/qlogicfas.c - 1.8
linux/drivers/scsi/pci2220i.c - 1.18
linux/drivers/scsi/ibmmca.c - 1.14
linux/drivers/scsi/gdth_proc.h - 1.4
linux/drivers/scsi/gdth_proc.c - 1.8
linux/drivers/scsi/gdth_ioctl.h - 1.3
linux/drivers/scsi/gdth.h - 1.5
linux/drivers/scsi/gdth.c - 1.12
linux/drivers/scsi/fdomain.c - 1.14
linux/drivers/scsi/eata.h - 1.6
linux/drivers/scsi/eata.c - 1.16
linux/drivers/scsi/aic7xxx/aic7xxx.seq - 1.8
linux/drivers/scsi/aic7xxx/aic7xxx.reg - 1.6
linux/drivers/scsi/aha1542.c - 1.16
linux/drivers/scsi/README.ibmmca - 1.6
linux/drivers/scsi/NCR53c406a.c - 1.8
linux/drivers/scsi/Makefile - 1.26
linux/drivers/sbus/char/zs.c - 1.16
linux/drivers/sbus/char/su.c - 1.16
linux/drivers/sbus/char/pcikbd.c - 1.17
linux/drivers/pci/quirks.c - 1.20
linux/drivers/pci/proc.c - 1.19
linux/drivers/pci/pci.c - 1.36
linux/drivers/pci/Makefile - 1.15
linux/drivers/net/yellowfin.c - 1.21
linux/drivers/net/sunhme.c - 1.25
linux/drivers/net/net_init.c - 1.19
linux/drivers/net/mace.c - 1.13
linux/drivers/net/irda/Makefile - 1.12
linux/drivers/net/irda/Config.in - 1.9
linux/drivers/net/hp100.h - 1.3
linux/drivers/net/eql.c - 1.12
linux/drivers/net/epic100.c - 1.20
linux/drivers/net/bmac.c - 1.14
linux/drivers/net/acenic_firmware.h - 1.12
linux/drivers/net/acenic.h - 1.13
linux/drivers/net/Makefile - 1.42
linux/drivers/net/Config.in - 1.38
linux/drivers/net/8390.c - 1.21
linux/drivers/macintosh/via-cuda.c - 1.8
linux/drivers/isdn/isdn_ppp.c - 1.14
linux/drivers/isdn/isdn_net.h - 1.8
linux/drivers/isdn/isdn_net.c - 1.19
linux/drivers/isdn/isdn_common.c - 1.24
linux/drivers/isdn/avmb1/capiutil.c - 1.8
linux/drivers/isdn/avmb1/capidrv.h - 1.3
linux/drivers/isdn/avmb1/capidrv.c - 1.17
linux/drivers/isdn/avmb1/capidev.h - 1.7
linux/drivers/isdn/avmb1/capi.c - 1.21
linux/drivers/isdn/avmb1/b1pci.c - 1.13
linux/drivers/char/wdt.c - 1.10
linux/drivers/char/synclink.c - 1.15
linux/drivers/char/specialix.c - 1.10
linux/drivers/char/softdog.c - 1.11
linux/drivers/char/serial167.c - 1.8
linux/drivers/char/serial.c - 1.40
linux/drivers/char/riscom8.c - 1.9
linux/drivers/char/random.c - 1.14
linux/drivers/char/pcxx.h - 1.4
linux/drivers/char/pcxx.c - 1.13
linux/drivers/char/pcwd.c - 1.14
linux/drivers/char/pc110pad.c - 1.11
linux/drivers/char/misc.c - 1.25
linux/drivers/char/mem.c - 1.35
linux/drivers/char/epca.c - 1.15
linux/drivers/char/acquirewdt.c - 1.11
linux/drivers/char/Makefile - 1.44
linux/drivers/cdrom/sbpcd.c - 1.12
linux/drivers/cdrom/cdrom.c - 1.31
linux/drivers/block/xd.c - 1.19
linux/drivers/block/swim3.c - 1.11
linux/drivers/block/ps2esdi.c - 1.14
linux/drivers/block/paride/pd.c - 1.14
linux/drivers/block/nbd.c - 1.19
linux/drivers/block/genhd.c - 1.14
linux/drivers/block/amiflop.c - 1.14
linux/drivers/block/acsi_slm.c - 1.9
linux/drivers/block/acsi.c - 1.12
linux/drivers/acorn/block/mfmhd.c - 1.9
linux/drivers/Makefile - 1.21
linux/arch/sparc64/mm/init.c - 1.25
linux/arch/sparc64/kernel/sys_sunos32.c - 1.30
linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.28
linux/arch/sparc64/kernel/ioctl32.c - 1.34
linux/arch/sparc64/kernel/devices.c - 1.9
linux/arch/sparc64/kernel/Makefile - 1.19
linux/arch/sparc64/defconfig - 1.35
linux/arch/sparc64/config.in - 1.38
linux/arch/sparc/prom/console.c - 1.7
linux/arch/sparc/kernel/sys_sunos.c - 1.29
linux/arch/sparc/kernel/irq.c - 1.16
linux/arch/sparc/kernel/head.S - 1.9
linux/arch/sparc/defconfig - 1.22
linux/arch/sparc/config.in - 1.29
linux/arch/ppc/mm/init.c - 1.33
linux/arch/ppc/mm/fault.c - 1.15
linux/arch/ppc/mm/extable.c - 1.5
linux/arch/ppc/mm/Makefile - 1.5
linux/arch/ppc/mbxboot/size - 1.3
linux/arch/ppc/mbxboot/offset - 1.3
linux/arch/ppc/mbxboot/misc.c - 1.8
linux/arch/ppc/mbxboot/head.S - 1.4
linux/arch/ppc/mbxboot/Makefile - 1.10
linux/arch/ppc/lib/string.S - 1.6
linux/arch/ppc/lib/strcase.c - 1.3
linux/arch/ppc/lib/locks.c - 1.7
linux/arch/ppc/lib/checksum.S - 1.5
linux/arch/ppc/lib/Makefile - 1.7
linux/arch/ppc/kernel/traps.c - 1.18
linux/arch/ppc/kernel/time.c - 1.13
linux/arch/ppc/kernel/syscalls.c - 1.10
linux/arch/ppc/kernel/softemu8xx.c - 1.6
linux/arch/ppc/kernel/smp.c - 1.24
linux/arch/ppc/kernel/signal.c - 1.12
linux/arch/ppc/kernel/setup.c - 1.31
linux/arch/ppc/kernel/residual.c - 1.6
linux/arch/ppc/kernel/ptrace.c - 1.8
linux/arch/ppc/kernel/prom.c - 1.20
linux/arch/ppc/kernel/process.c - 1.27
linux/arch/ppc/kernel/prep_time.c - 1.6
linux/arch/ppc/kernel/prep_setup.c - 1.19
linux/arch/ppc/kernel/prep_pci.c - 1.9
linux/arch/ppc/kernel/prep_nvram.c - 1.7
linux/arch/ppc/kernel/ppc_ksyms.c - 1.30
linux/arch/ppc/kernel/ppc_htab.c - 1.12
linux/arch/ppc/kernel/ppc8xx_pic.h - 1.5
linux/arch/ppc/kernel/ppc8xx_pic.c - 1.7
linux/arch/ppc/kernel/ppc-stub.c - 1.8
linux/arch/ppc/kernel/pmac_time.c - 1.11
linux/arch/ppc/kernel/pmac_setup.c - 1.21
linux/arch/ppc/kernel/pmac_pic.h - 1.4
linux/arch/ppc/kernel/pmac_pic.c - 1.18
linux/arch/ppc/kernel/pmac_pci.c - 1.13
linux/arch/ppc/kernel/pci.h - 1.5
linux/arch/ppc/kernel/pci.c - 1.19
linux/arch/ppc/kernel/open_pic.h - 1.8
linux/arch/ppc/kernel/open_pic.c - 1.18
linux/arch/ppc/kernel/mk_defs.c - 1.11
linux/arch/ppc/kernel/misc.S - 1.27
linux/arch/ppc/kernel/local_irq.h - 1.9
linux/arch/ppc/kernel/irq.c - 1.27
linux/arch/ppc/kernel/indirect_pci.c - 1.5
linux/arch/ppc/kernel/idle.c - 1.16
linux/arch/ppc/kernel/i8259.h - 1.3
linux/arch/ppc/kernel/i8259.c - 1.7
linux/arch/ppc/kernel/head.S - 1.25
linux/arch/ppc/kernel/find_name.c - 1.3
linux/arch/ppc/kernel/feature.c - 1.11
linux/arch/ppc/kernel/chrp_time.c - 1.9
linux/arch/ppc/kernel/chrp_setup.c - 1.21
linux/arch/ppc/kernel/chrp_pci.c - 1.16
linux/arch/ppc/kernel/checks.c - 1.4
linux/arch/ppc/kernel/bitops.c - 1.4
linux/arch/ppc/kernel/apus_setup.c - 1.15
linux/arch/ppc/kernel/align.c - 1.7
linux/arch/ppc/kernel/Makefile - 1.20
linux/arch/ppc/defconfig - 1.29
linux/arch/ppc/config.in - 1.35
linux/arch/ppc/coffboot/zlib.h - 1.3
linux/arch/ppc/coffboot/zlib.c - 1.3
linux/arch/ppc/coffboot/string.S - 1.3
linux/arch/ppc/coffboot/start.c - 1.4
linux/arch/ppc/coffboot/rs6000.h - 1.3
linux/arch/ppc/coffboot/nonstdio.h - 1.3
linux/arch/ppc/coffboot/misc.S - 1.5
linux/arch/ppc/coffboot/ld.script - 1.3
linux/arch/ppc/coffboot/hack-coff.c - 1.3
linux/arch/ppc/coffboot/crt0.S - 1.4
linux/arch/ppc/coffboot/Makefile - 1.12
linux/arch/ppc/chrpboot/start.c - 1.4
linux/arch/ppc/chrpboot/piggyback.c - 1.4
linux/arch/ppc/chrpboot/no_initrd.c - 1.3
linux/arch/ppc/chrpboot/misc.S - 1.3
linux/arch/ppc/chrpboot/main.c - 1.10
linux/arch/ppc/chrpboot/crt0.S - 1.3
linux/arch/ppc/chrpboot/Makefile - 1.12
linux/arch/ppc/boot/vreset.c - 1.4
linux/arch/ppc/boot/size - 1.3
linux/arch/ppc/boot/offset - 1.3
linux/arch/ppc/boot/of1275.h - 1.3
linux/arch/ppc/boot/of1275.c - 1.3
linux/arch/ppc/boot/ns16550.h - 1.3
linux/arch/ppc/boot/ns16550.c - 1.3
linux/arch/ppc/boot/mkprep.c - 1.3
linux/arch/ppc/boot/misc.c - 1.6
linux/arch/ppc/boot/kbd.c - 1.3
linux/arch/ppc/boot/iso_font.h - 1.3
linux/arch/ppc/boot/head.S - 1.6
linux/arch/ppc/boot/Makefile - 1.14
linux/arch/ppc/amiga/time.c - 1.5
linux/arch/ppc/amiga/ints.c - 1.6
linux/arch/ppc/amiga/config.c - 1.10
linux/arch/ppc/amiga/cia.c - 1.5
linux/arch/ppc/amiga/chipram.c - 1.5
linux/arch/ppc/amiga/bootinfo.c - 1.5
linux/arch/ppc/amiga/amisound.c - 1.3
linux/arch/ppc/amiga/amiints.c - 1.10
linux/arch/ppc/amiga/amiga_ksyms.c - 1.3
linux/arch/ppc/amiga/Makefile - 1.7
linux/arch/ppc/Makefile - 1.18
linux/arch/ppc/8xx_io/uart.c - 1.13
linux/arch/ppc/8xx_io/fec.c - 1.13
linux/arch/ppc/8xx_io/enet.c - 1.13
linux/arch/ppc/8xx_io/commproc.h - 1.8
linux/arch/ppc/8xx_io/commproc.c - 1.8
linux/arch/ppc/8xx_io/Makefile - 1.5
linux/arch/m68k/mm/memory.c - 1.9
linux/arch/m68k/lib/semaphore.S - 1.4
linux/arch/m68k/config.in - 1.22
linux/arch/i386/mm/fault.c - 1.17
linux/arch/i386/kernel/traps.c - 1.36
linux/arch/i386/kernel/setup.c - 1.46
linux/arch/i386/kernel/mtrr.c - 1.26
linux/arch/i386/kernel/i386_ksyms.c - 1.37
linux/arch/i386/defconfig - 1.55
linux/arch/i386/config.in - 1.56
linux/arch/i386/boot/setup.S - 1.20
linux/arch/arm/mm/fault-armv.c - 1.14
linux/arch/arm/lib/Makefile - 1.17
linux/arch/arm/kernel/setup.c - 1.20
linux/arch/arm/defconfig - 1.16
linux/arch/alpha/mm/init.c - 1.18
linux/arch/alpha/mm/extable.c - 1.5
linux/arch/alpha/mm/Makefile - 1.3
linux/arch/alpha/kernel/traps.c - 1.11
linux/arch/alpha/kernel/sys_miata.c - 1.10
linux/arch/alpha/kernel/sys_dp264.c - 1.14
linux/arch/alpha/kernel/smp.c - 1.22
linux/arch/alpha/kernel/setup.c - 1.20
linux/arch/alpha/kernel/process.c - 1.16
linux/arch/alpha/kernel/entry.S - 1.18
linux/arch/alpha/kernel/core_tsunami.c - 1.17
linux/arch/alpha/kernel/core_cia.c - 1.18
linux/arch/alpha/kernel/alpha_ksyms.c - 1.21
linux/arch/alpha/defconfig - 1.16
linux/arch/alpha/config.in - 1.30
linux/arch/alpha/boot/tools/objstrip.c - 1.4
linux/Makefile - 1.87
linux/MAINTAINERS - 1.58
linux/Documentation/sysrq.txt - 1.10
linux/Documentation/sound/Opti - 1.5
linux/Documentation/sound/MAD16 - 1.4
linux/Documentation/scsi-generic.txt - 1.8
linux/Documentation/rtc.txt - 1.5
linux/Documentation/pci.txt - 1.12
linux/Documentation/parport.txt - 1.13
linux/Documentation/networking/ipddp.txt - 1.5
linux/Documentation/networking/ip-sysctl.txt - 1.9
linux/Documentation/networking/filter.txt - 1.4
linux/Documentation/networking/ethertap.txt - 1.5
linux/Documentation/networking/cops.txt - 1.4
linux/Documentation/ioctl-number.txt - 1.17
linux/Documentation/fb/framebuffer.txt - 1.8
linux/Documentation/devices.txt - 1.9
linux/Documentation/Configure.help - 1.80
linux/Documentation/Changes - 1.38
linux/CREDITS - 1.52
linux/net/decnet/af_decnet.c - 1.24
linux/include/linux/ide.h - 1.29
linux/include/linux/i2o.h - 1.12
linux/include/asm-ppc/hdreg.h - 1.2
linux/drivers/usb/printer.c - 1.35
linux/drivers/usb/acm.c - 1.37
linux/drivers/sbus/char/aurora.c - 1.8
linux/drivers/net/irda/toshoboe.c - 1.22
linux/drivers/isdn/eicon/eicon.h - 1.10
linux/drivers/i2o/i2o_scsi.c - 1.11
linux/drivers/i2o/i2o_proc.c - 1.14
linux/drivers/i2o/i2o_pci.c - 1.16
linux/drivers/i2o/i2o_lan.c - 1.18
linux/drivers/i2o/i2o_core.c - 1.25
linux/drivers/i2o/i2o_config.c - 1.15
linux/drivers/i2o/i2o_block.c - 1.22
linux/drivers/block/blkpg.c - 1.7
linux/arch/ppc/xmon/xmon.c - 1.14
linux/arch/ppc/xmon/subr_prf.c - 1.3
linux/arch/ppc/xmon/start.c - 1.15
linux/arch/ppc/xmon/setjmp.c - 1.2
linux/arch/ppc/xmon/privinst.h - 1.4
linux/arch/ppc/xmon/ppc.h - 1.2
linux/arch/ppc/xmon/ppc-opc.c - 1.3
linux/arch/ppc/xmon/ppc-dis.c - 1.2
linux/arch/ppc/xmon/nonstdio.h - 1.2
linux/arch/ppc/xmon/ansidecl.h - 1.2
linux/arch/ppc/xmon/adb.c - 1.2
linux/arch/ppc/xmon/Makefile - 1.4
linux/arch/ppc/chrpboot/mknote.c - 1.2
linux/drivers/char/ppdev.c - 1.21
linux/drivers/block/smart1,2.h - 1.5
linux/drivers/block/cpqarray.h - 1.6
linux/drivers/block/cpqarray.c - 1.22
linux/arch/arm/def-configs/ebsa110 - 1.7
linux/drivers/parport/share.c - 1.15
linux/drivers/parport/probe.c - 1.6
linux/drivers/parport/parport_pc.c - 1.33
linux/drivers/parport/parport_mfc3.c - 1.8
linux/drivers/parport/parport_amiga.c - 1.7
linux/drivers/parport/init.c - 1.10
linux/drivers/parport/ieee1284_ops.c - 1.11
linux/drivers/parport/ieee1284.c - 1.11
linux/drivers/parport/BUGS-parport - 1.3
linux/drivers/char/raw.c - 1.16
linux/include/asm-sparc64/parport.h - 1.10
linux/drivers/usb/uss720.c - 1.18
linux/drivers/sound/esssolo1.c - 1.28
linux/include/linux/b1pcmcia.h - 1.2
linux/fs/partitions/check.c - 1.23
linux/drivers/isdn/avmb1/t1isa.c - 1.11
linux/drivers/isdn/avmb1/kcapi.c - 1.12
linux/drivers/isdn/avmb1/b1pcmcia.c - 1.11
linux/drivers/isdn/avmb1/b1isa.c - 1.9
linux/drivers/isdn/avmb1/b1.c - 1.12
linux/drivers/isdn/avmb1/avmcard.h - 1.6
linux/drivers/atm/eni.c - 1.10
linux/net/atm/mpoa_proc.c - 1.7
linux/arch/ppc/math-emu/fdivs.c - 1.2
linux/arch/ppc/math-emu/fdiv.c - 1.2
linux/arch/ppc/math-emu/fctiwz.c - 1.2
linux/arch/ppc/math-emu/fctiw.c - 1.2
linux/arch/ppc/math-emu/fcmpu.c - 1.2
linux/arch/ppc/math-emu/fcmpo.c - 1.2
linux/arch/ppc/math-emu/fadds.c - 1.2
linux/arch/ppc/math-emu/fadd.c - 1.2
linux/arch/ppc/math-emu/fabs.c - 1.2
linux/arch/ppc/math-emu/double.h - 1.2
linux/arch/ppc/math-emu/Makefile - 1.3
linux/arch/ppc/kernel/semaphore.c - 1.5
linux/arch/ppc/kernel/ppc_asm.h - 1.6
linux/arch/ppc/kernel/head_8xx.S - 1.10
linux/arch/ppc/kernel/hashtable.S - 1.10
linux/arch/ppc/kernel/gemini_setup.c - 1.17
linux/arch/ppc/kernel/gemini_prom.S - 1.6
linux/arch/ppc/kernel/gemini_pci.c - 1.7
linux/arch/ppc/kernel/entry.S - 1.18
linux/arch/arm/vmlinux-armv.lds.in - 1.14
linux/arch/alpha/kernel/pci_impl.h - 1.8
linux/arch/alpha/kernel/pci.c - 1.15
linux/drivers/block/DAC960.c - 1.26
linux/arch/sparc64/kernel/semaphore.c - 1.7
linux/arch/sparc64/kernel/pci_sabre.c - 1.19
linux/arch/sparc64/kernel/pci_psycho.c - 1.17
linux/arch/sparc64/kernel/pci_iommu.c - 1.10
linux/arch/sparc64/kernel/pci_impl.h - 1.7
linux/arch/sparc64/kernel/pci_common.c - 1.10
linux/arch/sparc64/kernel/pci.c - 1.19
linux/arch/ppc/math-emu/udivmodti4.c - 1.2
linux/arch/ppc/math-emu/types.c - 1.2
linux/arch/ppc/math-emu/stfs.c - 1.2
linux/arch/ppc/math-emu/stfiwx.c - 1.2
linux/arch/ppc/math-emu/stfd.c - 1.2
linux/arch/ppc/math-emu/soft-fp.h - 1.2
linux/arch/ppc/math-emu/single.h - 1.2
linux/arch/ppc/math-emu/sfp-machine.h - 1.3
linux/arch/ppc/math-emu/op-common.h - 1.2
linux/arch/ppc/math-emu/op-4.h - 1.2
linux/arch/ppc/math-emu/op-2.h - 1.2
linux/arch/ppc/math-emu/op-1.h - 1.2
linux/arch/ppc/math-emu/mtfsfi.c - 1.2
linux/arch/ppc/math-emu/mtfsf.c - 1.2
linux/arch/ppc/math-emu/mtfsb1.c - 1.2
linux/arch/ppc/math-emu/mtfsb0.c - 1.2
linux/arch/ppc/math-emu/mffs.c - 1.2
linux/arch/ppc/math-emu/mcrfs.c - 1.2
linux/arch/ppc/math-emu/math.c - 1.3
linux/arch/ppc/math-emu/lfs.c - 1.2
linux/arch/ppc/math-emu/lfd.c - 1.2
linux/arch/ppc/math-emu/fsubs.c - 1.2
linux/arch/ppc/math-emu/fsub.c - 1.2
linux/arch/ppc/math-emu/fsqrts.c - 1.2
linux/arch/ppc/math-emu/fsqrt.c - 1.2
linux/arch/ppc/math-emu/fsel.c - 1.2
linux/arch/ppc/math-emu/frsqrte.c - 1.2
linux/arch/ppc/math-emu/frsp.c - 1.2
linux/arch/ppc/math-emu/fres.c - 1.2
linux/arch/ppc/math-emu/fnmsubs.c - 1.2
linux/arch/ppc/math-emu/fnmsub.c - 1.2
linux/arch/ppc/math-emu/fnmadds.c - 1.2
linux/arch/ppc/math-emu/fnmadd.c - 1.2
linux/arch/ppc/math-emu/fneg.c - 1.2
linux/arch/ppc/math-emu/fnabs.c - 1.2
linux/arch/ppc/math-emu/fmuls.c - 1.2
linux/arch/ppc/math-emu/fmul.c - 1.2
linux/arch/ppc/math-emu/fmsubs.c - 1.2
linux/arch/ppc/math-emu/fmsub.c - 1.2
linux/arch/ppc/math-emu/fmr.c - 1.2
linux/arch/ppc/math-emu/fmadds.c - 1.2
linux/arch/ppc/math-emu/fmadd.c - 1.2
linux/drivers/scsi/ips.h - 1.9
linux/drivers/scsi/ips.c - 1.16
linux/drivers/parport/parport_sunbpp.c - 1.6
linux/include/asm-ppc/m48t35.h - 1.2
linux/include/asm-ppc/gemini_serial.h - 1.7
linux/include/asm-ppc/gemini.h - 1.5
linux/include/asm-i386/pci.h - 1.8
linux/drivers/pcmcia/i82365.c - 1.18
linux/drivers/block/swim_iop.c - 1.8
linux/include/asm-sparc64/pci.h - 1.8
linux/include/asm-sparc/pci.h - 1.7
linux/include/asm-ppc/pci.h - 1.11
linux/drivers/net/pcmcia/Makefile - 1.16
linux/drivers/net/pcmcia/Config.in - 1.22
linux/drivers/char/drm/fops.c - 1.9
linux/drivers/sound/nm256_audio.c - 1.11
linux/drivers/net/dmfe.c - 1.14
linux/drivers/net/wan/cycx_main.c - 1.10
linux/drivers/net/tokenring/olympic.c - 1.13
linux/drivers/net/tokenring/ibmtr.h - 1.4
linux/arch/ppc/mbxboot/qspan_pci.c - 1.3
linux/arch/ppc/mbxboot/pci.c - 1.3
linux/arch/ppc/mbxboot/m8xx_tty.c - 1.3
linux/arch/ppc/mbxboot/iic.c - 1.3
linux/arch/ppc/mbxboot/embed_config.c - 1.5
linux/arch/ppc/kernel/sleep.S - 1.3
linux/arch/ppc/kernel/qspan_pci.c - 1.4
linux/arch/ppc/kernel/m8xx_setup.c - 1.12
linux/arch/ppc/amiga/pcmcia.c - 1.2
linux/arch/ppc/8xx_io/Config.in - 1.4
linux/arch/i386/lib/mmx.c - 1.7
linux/arch/i386/kernel/pci-i386.c - 1.16
linux/include/linux/pci_ids.h - 1.35
linux/drivers/net/wan/syncppp.c - 1.10
linux/drivers/net/wan/sdladrv.c - 1.7
linux/include/asm-ppc/rpxlite.h - 1.3
linux/drivers/net/wan/sdla_ppp.c - 1.10
linux/include/asm-ppc/bseip.h - 1.2
linux/include/asm-ppc/rpxclassic.h - 1.5
linux/include/asm-ppc/mpc8xx.h - 1.6
linux/drivers/scsi/ChangeLog.ips - 1.4
linux/drivers/net/tokenring/tms380tr.h - 1.5
linux/drivers/net/tokenring/tms380tr.c - 1.16
linux/arch/sh/mm/cache.c - 1.11
linux/mm/highmem.c - 1.20
linux/mm/bootmem.c - 1.14
linux/include/asm-arm/pci.h - 1.10
linux/drivers/usb/dc2xx.c - 1.18
linux/drivers/isdn/avmb1/t1pci.c - 1.12
linux/include/asm-ppc/div64.h - 1.2
linux/drivers/pci/pci.ids - 1.28
linux/include/asm-ppc/pgalloc.h - 1.7
linux/include/asm-alpha/pgalloc.h - 1.10
linux/arch/ppc/treeboot/mkirimg - 1.3
linux/arch/ppc/treeboot/mkevimg - 1.4
linux/arch/ppc/treeboot/misc.S - 1.3
linux/arch/ppc/treeboot/main.c - 1.3
linux/arch/ppc/treeboot/ld.script - 1.2
linux/arch/ppc/treeboot/irSect.h - 1.2
linux/arch/ppc/treeboot/irSect.c - 1.2
linux/arch/ppc/treeboot/elf.pl - 1.2
linux/arch/ppc/treeboot/crt0.S - 1.3
linux/arch/ppc/treeboot/Makefile - 1.4
linux/arch/ppc/mm/mem_pieces.h - 1.3
linux/arch/ppc/mm/mem_pieces.c - 1.5
linux/arch/ppc/kernel/pmac_nvram.c - 1.7
linux/arch/ppc/kernel/oak_setup.h - 1.4
linux/arch/ppc/kernel/oak_setup.c - 1.6
linux/arch/ppc/kernel/head_4xx.S - 1.5
linux/arch/ppc/configs/walnut_defconfig - 1.9
linux/arch/ppc/configs/oak_defconfig - 1.9
linux/arch/ppc/configs/mbx_defconfig - 1.4
linux/arch/ppc/configs/gemini_defconfig - 1.11
linux/arch/ppc/configs/common_defconfig - 1.17
linux/arch/ppc/configs/apus_defconfig - 1.5
linux/arch/ppc/coffboot/piggyback.c - 1.3
linux/arch/ppc/coffboot/no_initrd.c - 1.2
linux/arch/ppc/coffboot/mknote.c - 1.2
linux/arch/ppc/coffboot/coffmain.c - 1.4
linux/arch/ppc/coffboot/coffcrt0.S - 1.2
linux/arch/ppc/coffboot/chrpmain.c - 1.5
linux/arch/alpha/kernel/sys_nautilus.c - 1.7
linux/include/linux/mmzone.h - 1.14
linux/include/asm-ppc/walnut.h - 1.3
linux/include/asm-ppc/oak.h - 1.4
linux/include/asm-ppc/board.h - 1.4
linux/drivers/sound/trident.c - 1.22
linux/drivers/char/agp/agpgart_fe.c - 1.10
linux/drivers/scsi/scsi_lib.c - 1.30
linux/drivers/usb/uhci-debug.h - 1.7
linux/drivers/usb/dabusb.c - 1.10
linux/arch/sparc64/kernel/sbus.c - 1.10
linux/include/asm-ppc/hw_irq.h - 1.6
linux/drivers/usb/usbmouse.c - 1.11
linux/drivers/usb/usbkbd.c - 1.14
linux/drivers/usb/ov511.c - 1.21
linux/drivers/usb/hid.c - 1.24
linux/drivers/telephony/ixj.c - 1.13
linux/drivers/net/tokenring/smctr_firmware.h - 1.2
linux/drivers/net/tokenring/smctr.h - 1.4
linux/Documentation/networking/smctr.txt - 1.4
linux/Documentation/networking/tms380tr.txt - 1.3
linux/drivers/net/tokenring/smctr.c - 1.11
linux/include/linux/ppdev.h - 1.2
linux/arch/ppc/mm/4xx_tlb.h - 1.2
linux/include/linux/usbdev_fs_sb.h - 1.2
linux/arch/ppc/kernel/ppc4xx_pic.c - 1.3
linux/arch/ppc/kernel/ppc4xx_pic.h - 1.2
linux/arch/ppc/mm/4xx_tlb.c - 1.3
linux/drivers/usb/inode.c - 1.13
linux/arch/arm/lib/csumpartial.S - 1.3
linux/arch/arm/lib/csumpartialcopy.S - 1.4
linux/arch/arm/lib/csumpartialcopyuser.S - 1.5
linux/drivers/char/moxa.c - 1.5
linux/drivers/char/mxser.c - 1.8
linux/include/asm-ppc/shmbuf.h - 1.3
linux/include/asm-ppc/sembuf.h - 1.3
linux/include/asm-ppc/msgbuf.h - 1.3
linux/include/asm-ppc/ipcbuf.h - 1.3
linux/drivers/pci/setup-res.c - 1.7
linux/drivers/pci/setup-irq.c - 1.2
linux/drivers/pci/setup-bus.c - 1.3
linux/drivers/net/tokenring/tmspci.c - 1.5
linux/drivers/net/tokenring/madgemc.c - 1.4
linux/drivers/net/tokenring/abyss.c - 1.5
linux/drivers/char/mixcomwd.c - 1.7
linux/Documentation/DMA-mapping.txt - 1.9
linux/include/asm-m68k/pci.h - 1.4
linux/drivers/usb/usb-uhci.h - 1.7
linux/drivers/usb/usb-uhci.c - 1.20
linux/drivers/usb/usb-ohci.h - 1.10
linux/drivers/usb/usb-ohci.c - 1.20
linux/drivers/usb/scanner.h - 1.13
linux/drivers/usb/ibmcam.c - 1.12
linux/drivers/usb/usb-uhci-debug.h - 1.4
linux/drivers/net/irda/nsc-ircc.c - 1.13
linux/arch/ppc/kernel/walnut_setup.h - 1.2
linux/arch/ppc/kernel/walnut_setup.c - 1.4
linux/arch/ppc/kernel/pci-dma.c - 1.3
linux/arch/ppc/kernel/galaxy_pci.c - 1.3
linux/arch/ppc/coffboot/dummy.c - 1.2
linux/arch/alpha/kernel/pci_iommu.c - 1.12
linux/drivers/sound/via82cxxx_audio.c - 1.14
linux/drivers/net/gmac.c - 1.9
linux/drivers/net/gmac.h - 1.4
linux/include/linux/raid/md_k.h - 1.10
linux/include/linux/raid/md.h - 1.6
linux/include/asm-ia64/pci.h - 1.8
linux/include/asm-ppc/heathrow.h - 1.5
linux/drivers/net/8139too.c - 1.19
linux/drivers/isdn/avmb1/c4.c - 1.12
linux/drivers/isdn/avmb1/b1dma.c - 1.13
linux/include/linux/hysdn_if.h - 1.3
linux/drivers/usb/plusb.c - 1.11
linux/drivers/isdn/hysdn/hysdn_defs.h - 1.6
linux/drivers/isdn/hysdn/hysdn_net.c - 1.7
linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.10
linux/fs/devfs/base.c - 1.15
linux/drivers/isdn/hysdn/hysdn_sched.c - 1.7
linux/drivers/isdn/hysdn/boardergo.c - 1.9
linux/Documentation/networking/8139too.txt - 1.10
linux/drivers/video/matrox/matroxfb_crtc2.c - 1.5
linux/drivers/net/tulip/tulip_core.c - 1.21
linux/drivers/net/tulip/tulip.h - 1.12
linux/drivers/net/tulip/pnic.c - 1.7
linux/drivers/net/tulip/media.c - 1.9
linux/drivers/net/tulip/interrupt.c - 1.10
linux/drivers/net/tulip/eeprom.c - 1.10
linux/drivers/net/tulip/21142.c - 1.8
linux/drivers/net/ioc3-eth.c - 1.11
linux/drivers/char/wdt285.c - 1.7
linux/include/asm-mips64/pci.h - 1.5
linux/drivers/usb/wacom.c - 1.12
linux/drivers/usb/rio500.c - 1.10
linux/drivers/usb/pegasus.c - 1.16
linux/include/asm-sh/pci.h - 1.7
linux/drivers/net/appletalk/ipddp.c - 1.6
linux/drivers/net/appletalk/cops_ltdrv.h - 1.2
linux/drivers/net/appletalk/cops_ffdrv.h - 1.2
linux/drivers/net/appletalk/cops.h - 1.2
linux/drivers/net/appletalk/cops.c - 1.11
linux/drivers/usb/serial/keyspan_pda_fw.h - 1.2
linux/drivers/usb/serial/ftdi_sio.h - 1.4
linux/drivers/parport/ChangeLog - 1.14
linux/drivers/ide/sis5513.c - 1.9
linux/drivers/ide/rz1000.c - 1.4
linux/drivers/ide/pdc202xx.c - 1.8
linux/drivers/ide/opti621.c - 1.5
linux/drivers/ide/ide.c - 1.22
linux/drivers/ide/ide-pnp.c - 1.5
linux/drivers/ide/ide-pci.c - 1.12
linux/drivers/ide/ide-cd.c - 1.13
linux/drivers/ide/hpt366.c - 1.8
linux/drivers/ide/hpt34x.c - 1.5
linux/drivers/ide/hd.c - 1.9
linux/drivers/ide/cy82c693.c - 1.5
linux/drivers/ide/amd7409.c - 1.7
linux/drivers/ide/alim15x3.c - 1.9
linux/Documentation/DocBook/Makefile - 1.14
linux/drivers/usb/dsbr100.c - 1.9
linux/drivers/net/wan/comx.c - 1.10
linux/drivers/net/wan/comx-hw-comx.c - 1.4
linux/Documentation/DocBook/kernel-api.tmpl - 1.10
linux/net/ipv4/netfilter/ip_tables.c - 1.9
linux/net/ipv4/netfilter/ip_nat_core.c - 1.6
linux/drivers/isdn/avmb1/capifs.c - 1.10
linux/fs/nfs/flushd.c - 1.9
linux/drivers/usb/mdc800.c - 1.9
linux/drivers/char/wdt_pci.c - 1.5
linux/arch/i386/kernel/pci-irq.c - 1.13
linux/fs/ramfs/inode.c - 1.12
linux/drivers/usb/serial/keyspan_pda.c - 1.13
linux/drivers/usb/serial/ftdi_sio.c - 1.15
linux/drivers/usb/serial/usbserial.c - 1.15
linux/drivers/usb/serial/whiteheat.c - 1.13
linux/drivers/usb/serial/visor.c - 1.15
linux/drivers/usb/serial/omninet.c - 1.12
linux/drivers/sound/i810_audio.c - 1.11
linux/drivers/sound/emu10k1/midi.c - 1.6
linux/drivers/sound/emu10k1/main.c - 1.9
linux/drivers/sound/emu10k1/cardwo.c - 1.3
linux/fs/partitions/ibm.c - 1.4
linux/include/asm-ppc/mpc8260.h - 1.3
linux/include/asm-ppc/immap_8260.h - 1.4
linux/include/asm-ppc/est8260.h - 1.3
linux/include/asm-ppc/cpm_8260.h - 1.6
linux/drivers/usb/serial/digi_acceleport.c - 1.12
linux/drivers/net/pppoe.c - 1.12
linux/arch/ppc/xmon/start_8xx.c - 1.2
linux/arch/ppc/mbxboot/m8260_tty.c - 1.3
linux/arch/ppc/mbxboot/head_8260.S - 1.4
linux/arch/ppc/kernel/ppc8260_pic.h - 1.2
linux/arch/ppc/kernel/ppc8260_pic.c - 1.3
linux/arch/ppc/kernel/m8260_setup.c - 1.8
linux/arch/ppc/8260_io/uart.c - 1.8
linux/arch/ppc/8260_io/enet.c - 1.7
linux/arch/ppc/8260_io/commproc.c - 1.3
linux/arch/ppc/8260_io/Makefile - 1.4
linux/drivers/s390/char/hwc_tty.c - 1.4
linux/drivers/s390/block/dasd.c - 1.6
linux/net/ipv6/netfilter/ip6_tables.c - 1.5
linux/arch/ppc/mbxboot/rdimage.c - 1.2
linux/arch/ppc/mbxboot/gzimage.c - 1.2
linux/Documentation/DocBook/kernel-hacking.tmpl - 1.5
linux/Documentation/DocBook/kernel-locking.tmpl - 1.6
linux/kdb/modules/kdbm_pg.c - 1.38
linux/include/asm-ppc/backlight.h - 1.4
linux/include/asm-ppc/mc146818rtc.h - 1.3
linux/drivers/char/drm/ffb_drv.c - 1.6
linux/include/asm-ppc/time.h - 1.5
linux/drivers/char/sbc60xxwdt.c - 1.5
linux/drivers/usb/serial/keyspan.c - 1.9
linux/drivers/usb/microtek.c - 1.8
linux/drivers/usb/bluetooth.c - 1.9
linux/fs/jffs/inode-v23.c - 1.7
linux/drivers/acpi/driver.c - 1.9
linux/drivers/ieee1394/video1394.c - 1.5
linux/drivers/mtd/ftl.c - 1.4
linux/drivers/mtd/mtdblock.c - 1.5
linux/drivers/mtd/mtdchar.c - 1.5
linux/drivers/mtd/nftl.c - 1.4
linux/arch/ppc/kernel/xics.h - 1.2
linux/arch/ppc/kernel/xics.c - 1.3
linux/arch/ppc/kernel/pmac_backlight.c - 1.3
linux/arch/ppc/configs/rpxlite_defconfig - 1.4
linux/arch/ppc/configs/rpxcllf_defconfig - 1.5
linux/arch/ppc/configs/est8260_defconfig - 1.5
linux/arch/ppc/configs/bseip_defconfig - 1.4
linux/fs/smbfs/ChangeLog - 1.5
linux/arch/ppc/chrpboot/addnote.c - 1.3
linux/drivers/usb/storage/dpcm.c - 1.2
linux/drivers/sound/cs46xx.c - 1.9
linux/drivers/net/natsemi.c - 1.7
linux/drivers/media/video/zr36120.c - 1.5
linux/drivers/media/video/videodev.c - 1.4
linux/drivers/media/video/tda9875.c - 1.5
linux/drivers/media/video/stradis.c - 1.6
linux/drivers/media/video/saa7185.c - 1.3
linux/drivers/media/video/saa7111.c - 1.3
linux/drivers/media/video/saa7110.c - 1.2
linux/drivers/media/video/saa5249.c - 1.3
linux/drivers/media/video/pms.c - 1.5
linux/drivers/media/video/planb.c - 1.5
linux/drivers/media/video/cpia.c - 1.5
linux/drivers/media/video/c-qcam.c - 1.6
linux/drivers/media/video/bw-qcam.c - 1.6
linux/drivers/media/video/bttv-driver.c - 1.8
linux/drivers/media/radio/radio-zoltrix.c - 1.6
linux/drivers/media/radio/radio-typhoon.c - 1.6
linux/drivers/media/radio/radio-trust.c - 1.6
linux/drivers/media/radio/radio-terratec.c - 1.6
linux/drivers/media/radio/radio-sf16fmi.c - 1.6
linux/drivers/media/radio/radio-rtrack2.c - 1.6
linux/drivers/media/radio/radio-miropcm20.c - 1.5
linux/drivers/media/radio/radio-gemtek.c - 1.6
linux/drivers/media/radio/radio-cadet.c - 1.5
linux/drivers/media/radio/radio-aztech.c - 1.6
linux/drivers/media/radio/radio-aimslab.c - 1.6
linux/drivers/isdn/hysdn/hycapi.c - 1.6
linux/drivers/isdn/eicon/kprintf.c - 1.3
linux/drivers/isdn/eicon/common.c - 1.4
linux/drivers/isdn/eicon/bri.c - 1.3
linux/drivers/char/i810-tco.c - 1.4
linux/drivers/md/raid1.c - 1.8
linux/drivers/md/raid5.c - 1.15
linux/arch/arm/def-configs/clps7500 - 1.2
linux/arch/i386/kernel/bluesmoke.c - 1.7
linux/arch/ppc/8260_io/fcc_enet.c - 1.4
linux/arch/ppc/kernel/mol.h - 1.2
linux/drivers/block/cciss.c - 1.8
linux/drivers/block/cciss.h - 1.4
linux/drivers/block/cciss_cmd.h - 1.3
linux/drivers/md/md.c - 1.13
linux/drivers/media/radio/radio-maestro.c - 1.4
linux/drivers/net/hamachi.c - 1.6
linux/drivers/usb/net1080.c - 1.5
linux/include/asm-ppc/highmem.h - 1.4
linux/include/asm-ppc/keylargo.h - 1.3
linux/include/asm-ppc/kmap_types.h - 1.4
linux/include/asm-ppc/uninorth.h - 1.3
linux/include/linux/cciss_ioctl.h - 1.2
linux/drivers/ide/osb4.c - 1.4
linux/drivers/ide/slc90e66.c - 1.3
linux/mm/oom_kill.c - 1.3
linux/drivers/net/tulip/ChangeLog - 1.6
linux/drivers/usb/pegasus.h - 1.2
linux/drivers/usb/serial/belkin_sa.c - 1.6
linux/drivers/video/sis/sis_main.c - 1.3
linux/drivers/media/video/tvaudio.c - 1.4
linux/Documentation/usb/hotplug.txt - 1.3
linux/net/irda/irnet/irnet_ppp.h - 1.2
linux/net/irda/irnet/irnet_ppp.c - 1.3
linux/net/irda/irnet/irnet_irda.h - 1.2
linux/net/irda/irnet/irnet_irda.c - 1.3
linux/net/irda/irnet/irnet.h - 1.3
linux/include/asm-ppc/module.h - 1.2
linux/include/asm-ppc/xor.h - 1.2
linux/kernel/context.c - 1.4
linux/drivers/parport/parport_gsc.c - 1.5
linux/drivers/usb/serial/mct_u232.c - 1.5
linux/arch/arm/def-configs/integrator - 1.2
linux/include/asm-parisc/pci.h - 1.2
linux/drivers/usb/serial/empeg.c - 1.5
linux/drivers/sound/ymfpci.h - 1.3
linux/drivers/sound/ymfpci.c - 1.6
linux/mm/shmem.c - 1.6
linux/arch/sh/kernel/rtc.c - 1.3
linux/include/asm-ppc/parport.h - 1.2
linux/fs/reiserfs/prints.c - 1.3
linux/arch/sparc64/kernel/pci_schizo.c - 1.5
linux/arch/ppc/kernel/proc_rtas.c - 1.2
linux/drivers/usb/storage/unusual_devs.h - 1.2
linux/arch/ppc/kernel/open_pic_defs.h - 1.3
linux/arch/ppc/kernel/error_log.h - 1.2
linux/arch/ppc/kernel/error_log.c - 1.2
linux/arch/ppc/configs/power3_defconfig - 1.2
linux/arch/ppc/configs/ibmchrp_defconfig - 1.2
linux/Documentation/cris/README - 1.3
linux/drivers/sound/cs4281/cs4281m.c - 1.3
linux/arch/cris/Makefile - 1.3
linux/arch/cris/boot/compressed/Makefile - 1.3
linux/arch/cris/boot/compressed/head.S - 1.3
linux/arch/cris/boot/compressed/misc.c - 1.3
linux/arch/cris/config.in - 1.3
linux/arch/cris/cris.ld - 1.3
linux/arch/cris/defconfig - 1.3
linux/arch/cris/drivers/Config.in - 1.3
linux/arch/cris/drivers/Makefile - 1.3
linux/arch/cris/drivers/axisflashmap.c - 1.3
linux/arch/cris/drivers/ethernet.c - 1.3
linux/arch/cris/drivers/serial.c - 1.4
linux/arch/cris/drivers/serial.h - 1.3
linux/arch/cris/kernel/Makefile - 1.2
linux/arch/cris/kernel/debugport.c - 1.2
linux/arch/cris/kernel/entry.S - 1.4
linux/arch/cris/kernel/head.S - 1.3
linux/arch/cris/kernel/irq.c - 1.3
linux/arch/cris/kernel/kgdb.c - 1.3
linux/arch/cris/kernel/process.c - 1.3
linux/arch/cris/kernel/ptrace.c - 1.2
linux/arch/cris/kernel/setup.c - 1.3
linux/arch/cris/kernel/shadows.c - 1.2
linux/arch/cris/kernel/signal.c - 1.3
linux/arch/cris/kernel/sys_cris.c - 1.4
linux/arch/cris/kernel/traps.c - 1.3
linux/arch/cris/lib/memset.c - 1.2
linux/arch/cris/lib/string.c - 1.2
linux/arch/cris/mm/extable.c - 1.2
linux/arch/cris/mm/fault.c - 1.4
linux/arch/cris/mm/init.c - 1.3
linux/arch/cris/mm/tlb.c - 1.2
linux/include/asm-cris/stat.h - 1.2
linux/include/asm-cris/unistd.h - 1.3
linux/include/asm-cris/timex.h - 1.2
linux/include/asm-cris/system.h - 1.2
linux/include/asm-cris/axisflashmap.h - 1.2
linux/include/asm-cris/elf.h - 1.2
linux/include/asm-cris/semaphore-helper.h - 1.2
linux/include/asm-cris/segment.h - 1.2
linux/include/asm-cris/rtc.h - 1.2
linux/include/asm-cris/ptrace.h - 1.3
linux/include/asm-cris/processor.h - 1.3
linux/include/asm-cris/pgtable.h - 1.2
linux/include/asm-cris/pgalloc.h - 1.3
linux/include/asm-cris/irq.h - 1.3
linux/include/asm-cris/io.h - 1.3
linux/drivers/net/pcmcia/hermes.h - 1.3
linux/include/net/syncppp.h - 1.2
linux/include/asm-ppc/tqm8xx.h - 1.3
linux/include/asm-ppc/tlb.h - 1.2
linux/include/asm-ppc/spd8xx.h - 1.2
linux/include/asm-ppc/ivms8.h - 1.2
linux/drivers/usb/serial/io_edgeport.c - 1.3
linux/drivers/scsi/aic7xxx/aicasm/aicasm_symbol.c - 1.2
linux/drivers/scsi/aic7xxx/aicasm/Makefile - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.3
linux/drivers/scsi/aic7xxx/aic7xxx_linux_pci.c - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_linux_host.h - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.3
linux/drivers/scsi/aic7xxx/aic7xxx_inline.h - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx.h - 1.2
linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.2
linux/drivers/scsi/aic7xxx/aic7770_linux.c - 1.2
linux/drivers/scsi/aic7xxx/aic7770.c - 1.2
linux/drivers/scsi/aic7xxx/Makefile - 1.2
linux/drivers/scsi/aic7xxx/Config.in - 1.2
linux/drivers/net/pcmcia/orinoco_cs.c - 1.3
linux/drivers/net/pcmcia/hermes.c - 1.3
linux/drivers/media/radio/radio-maxiradio.c - 1.2
linux/drivers/char/machzwd.c - 1.3
linux/drivers/char/advantechwdt.c - 1.2
linux/arch/ppc/configs/TQM860L_defconfig - 1.2
linux/arch/ppc/configs/TQM850L_defconfig - 1.2
linux/arch/ppc/configs/TQM823L_defconfig - 1.2
linux/arch/ppc/configs/SPD823TS_defconfig - 1.2
linux/arch/ppc/configs/SM850_defconfig - 1.2
linux/arch/ppc/configs/IVMS8_defconfig - 1.2
linux/drivers/net/wan/wanpipe_multppp.c - 1.2
linux/Documentation/DocBook/deviceiobook.tmpl - 1.2
linux/Documentation/s390/3270.txt - 1.2
linux/drivers/video/epson1355fb.c - 1.2
linux/arch/sh/kernel/setup_ec3104.c - 1.2
linux/arch/sh/kernel/setup_dc.c - 1.2
linux/fs/nls/nls_cp1255.c - 1.2
linux/fs/nls/nls_iso8859-13.c - 1.2
linux/arch/sh/kernel/mach_dc.c - 1.2
linux/arch/sh/kernel/irq_intc2.c - 1.2
linux/fs/nls/nls_koi8-u.c - 1.2
linux/arch/sh/kernel/io_ec3104.c - 1.2
linux/arch/sh/kernel/io_dc.c - 1.2
linux/arch/sh/kernel/io_cat68701.c - 1.2
linux/arch/sh/kernel/hd64465_gpio.c - 1.2
linux/include/asm-arm/arch-l7200/keyboard.h - 1.2
linux/arch/arm/mach-ebsa110/io.c - 1.2
linux/arch/arm/mach-sa1100/dma.h - 1.2
linux/include/asm-cris/etraxgpio.h - 1.2
linux/arch/cris/boot/rescue/head.S - 1.2
linux/arch/cris/boot/rescue/kimagerescue.S - 1.2
linux/arch/cris/boot/rescue/testrescue.S - 1.2
linux/arch/cris/drivers/gpio.c - 1.2
linux/arch/cris/drivers/i2c.c - 1.2
linux/arch/cris/drivers/i2c.h - 1.2
linux/arch/cris/drivers/sync_serial.c - 1.2
linux/arch/cris/drivers/usb-host.c - 1.2
linux/arch/cris/lib/dram_init.S - 1.2
linux/arch/cris/mm/ioremap.c - 1.2
linux/include/asm-sh/hd64465_gpio.h - 1.2
linux/include/linux/compiler.h - 1.2
linux/include/linux/rwsem-spinlock.h - 1.2
linux/include/linux/rwsem.h - 1.2


From owner-linux-xfs@oss.sgi.com Wed May 30 10:27:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHRqQ06383
	for linux-xfs-outgoing; Wed, 30 May 2001 10:27:52 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHRlh06374
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:27:47 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4UHRjaJ058050
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:27:46 -0500 (CDT)
Message-ID: <3B152D8B.64BD33D9@thebarn.com>
Date: Wed, 30 May 2001 12:27:39 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: oss DNS FINALLY corrected.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Looks like the DNS disaster has finally been resolved.

lupo[12:19pm]-=>dig @rs1.netsol.com oss.sgi.com | grep oss
; <<>> DiG 8.3 <<>> @rs1.netsol.com oss.sgi.com
;;      oss.sgi.com, type = A, class = IN
oss.sgi.com.            2H IN A         216.32.174.27

lupo[12:22pm]-=>nslookup 216.32.174.27
Server:  localhost.thebarn.com
Address:  127.0.0.1

Name:    oss.sgi.com
Address:  216.32.174.27


At this point the top level DNS s are up-to-date  and should
be handing out the correct IPs. It may take some time
for local caches  to flush the old data but hopefully that should happen

within 6 hours and everybody can access oss normally again.


--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Wed May 30 10:29:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHTvs06748
	for linux-xfs-outgoing; Wed, 30 May 2001 10:29:57 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHTqh06728
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:29:52 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA07422
	for <linux-xfs@oss.sgi.com>; Sun, 27 May 2001 09:51:11 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id LAA1975859; Sun, 27 May 2001 11:49:55 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA92942; Sun, 27 May 2001 11:49:54 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4RGqGU05976; Sun, 27 May 2001 11:52:16 -0500
Message-Id: <200105271652.f4RGqGU05976@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: stimits@idcomm.com
cc: linux-xfs@oss.sgi.com
Subject: Re: Kernel patches 
In-Reply-To: Message from "D. Stimits" <stimits@idcomm.com> 
   of "Sat, 26 May 2001 19:46:30 MDT." <3B105C76.1F73D2F0@idcomm.com> 
Date: Sun, 27 May 2001 11:52:16 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> About a year ago I attended a Linux Expo where the XFS filesystem was
> demonstrated (and it was impressive). At the time it was still being
> "unencumbered", so I was unable to do anything with it. I'm now in the
> process of trying to load a new machine, but find the patches haven't
> kept up with newer kernel releases. I'm using SMP x86 which has had a
> number of kernel changes which fix problems which were serious enough
> that I can't see using the 2.4.2 or 2.4.3 kernel with, and want to
> instead use the 2.4.5 kernel. Of the available patches, 2.4.5 works
> completely with the patch "linux-2.4-xfs-1.0.patch", but the 2nd patch,
> "linux-2.4.3-core-xfs-1.0.patch", fails in several places on 2.4.5
> source (regardless of whether linux-2.4-xfs-1.0.patch is applied first
> or 2nd). Normally I would be willing to test something like this out to
> see if the failed chunks will cause failure, but with a filesystem, this
> leaves me nervous.

There should be a later set of patches for populating a cvs tree, then
you can get our changes faster. I would tell you where, but various
parts of oss seem to be out to lunch this weekend.

> 
> My hopes are that XFS can make its way directly into the kernel source,
> even if it is marked as "experimental". Until then, the next best thing
> would be new patches becoming available very quickly after a new kernel
> is announced. Can anyone give me an estimate on when a patch suitable
> for 2.4.5 kernel will be available? Is there any kind of announcement or
> devel email list I can join to track XFS development?

The reason we do not have instant patches available after a release comes
out is that we have about 40 files in that core patch, which touch things
like the VM in minor ways. Sure I could put out a patch in about 2 hours
from downloading Linus's latest version, but it would come with zero
testing, and would end up generating more work for us than doing some
testing before we put out a new version. Since you are nervous about
fixing diff conflicts yourself, consider yourself multiplied several
thousand times complaining that we got something wrong in the latest
version of the code.

> 
> Thanks,
> D. Stimits, stimits@idcomm.com

Steve



From owner-linux-xfs@oss.sgi.com Wed May 30 10:43:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHhEI08207
	for linux-xfs-outgoing; Wed, 30 May 2001 10:43:14 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHh3h08177
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:43:03 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4UHh28i012595;
	Wed, 30 May 2001 10:43:02 -0700
Date: Wed, 30 May 2001 10:43:02 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Galen Arnold <arnoldg@ncsa.uiuc.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to
 xfs 
In-Reply-To: <Pine.SOL.3.95.1010530121407.17698H-100000@pecos.ncsa.uiuc.edu>
Message-ID: <Pine.LNX.4.21.0105301042500.712-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

linux-2.4.4-xfs

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Wed, 30 May 2001, Galen Arnold wrote:

> Walter,
> 
> Welcome to the club!  I can reproduce that behavior with 2.4.4-xfs and
> this iozone test (my host has 2G mem, so I test with big files):
> 
> 	iozone -s 4000m -r 64k
> 
> My box also hangs (doesn't crash or panic).  Was that 2.4.5-xfs you
> tested, if so, you saved me the trouble and I'll delay my next cvs
> checkout/rebuild?
> 
> -Galen
> 
> +
> Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> National Center for Supercomputing Applications           (217) 244-3473
> 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
> 
> On Wed, 30 May 2001 marchuk@ee.washington.edu wrote:
> 
> > My fileserver has the latest XFS CVS kernel.  Yesterday the machine
> > crashed/froze  It stopped at 8PM right after this allocation failed
> > error.  Notice the time when the machine came back, 1AM (it was physically
> > rebooted).  
> > 
> > I did a search for this error and saw a correlation with xfs and this
> > error.  Do any of you know if the error and the crash was due to xfs bug?
> > 
> > May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.      
> > May 30 01:34:19 gauss syslogd 1.3-3: restart.    
> > *****************************
> > Walter Marchuk
> > Senior Computer Specialist
> > University of Washington
> > Electrical Engineering
> > Room: 307g
> > 206-221-5421
> > marchuk@ee.washington.edu
> > *****************************
> > 
> > On Tue, 29 May 2001, Steve Lord wrote:
> > 
> > > > That means it's been tagged?
> > > 
> > > I am not sure what you mean by tagged, I checked in a fix for the problem
> > > with the implementation I checked in on Friday, and in cleaning my mail
> > > box I saw that I had said I would do a followup under the same heading.
> > > 
> > > Steve
> > > 
> > > > 
> > > > -- 
> > > > Austin Gonyou
> > > > Systems Architect, CCNA
> > > > Coremetrics, Inc.
> > > > Phone: 512-796-9023
> > > > email: austin@coremetrics.com
> > > > 
> > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > 
> > > > > >
> > > > > > Sod's law says you find the hole right after you ship the code. There is 
> > > > a
> > > > > > bug in this code, I would not do a cvs update until I get a fix in, I kno
> > > > w
> > > > > > roughly how to fix it, but it will take me a while to code and test it.
> > > > > >
> > > > > > I would hold off on the cvs tree for a while until you see another messag
> > > > e
> > > > > > from me on this thread - probably not today.
> > > > > >
> > > > > > Steve
> > > > > >
> > > > >
> > > > > This was fixed over the weekend by the way.
> > > > >
> > > > > Steve
> > > > >
> > > 
> > > 
> > 
> 


From owner-linux-xfs@oss.sgi.com Wed May 30 10:45:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHj6F08565
	for linux-xfs-outgoing; Wed, 30 May 2001 10:45:06 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHj3h08560
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:45:03 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA01588
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:45:10 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2007572; Wed, 30 May 2001 12:43:46 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA67155; Wed, 30 May 2001 12:43:45 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UHklL18596; Wed, 30 May 2001 12:46:47 -0500
Message-Id: <200105301746.f4UHklL18596@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Daniel Podlejski <underley@underley.eu.org>
cc: linux-xfs@oss.sgi.com
Subject: Re: resizing xfs 
In-Reply-To: Message from Daniel Podlejski <underley@underley.eu.org> 
   of "Wed, 30 May 2001 18:30:13 +0200." <20010530183013.A12752@witch.underley.eu.org> 
Date: Wed, 30 May 2001 12:46:47 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Is posible to decrease xfs filesystem ?
> 
> -- 
> Daniel Podlejski <underley@underley.eu.org>
>    ... You know the day destroys the night
>    Night divides the day ...


This should be a FAQ question I think, unfortunately, no you cannot do
this.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 30 10:46:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHk4O08800
	for linux-xfs-outgoing; Wed, 30 May 2001 10:46:04 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHjwh08791
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:45:58 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA05077
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:46:05 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2007136; Wed, 30 May 2001 12:44:40 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA47036; Wed, 30 May 2001 12:44:40 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UHlfk18611; Wed, 30 May 2001 12:47:41 -0500
Message-Id: <200105301747.f4UHlfk18611@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov>
cc: linux-xfs@oss.sgi.com
Subject: Re: Oops 
In-Reply-To: Message from "Dave Sill" <ds-linux-xfs@sws5.ctd.ornl.gov> 
   of "30 May 2001 11:39:35 EDT." <wx0ae3uu9qg.fsf@sws5.ctd.ornl.gov> 
Date: Wed, 30 May 2001 12:47:41 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


This should be fixed in the development cvs tree.

Steve

> Dual-processor Dell with AMI MegaRAID's running SGI XFS 1.0 Red Hat
> 7.1 (2.4.2-SGI_XFS_1.0smp). One of the MegaRAID fs's is xfs and is
> exported to a couple of SGI O200's. Around the same time I did a chown
> and chmod on the XFS fs via NFS, the Linux box reported:
> 
> May 30 09:47:12 daacsnfs kernel: xfs_iget_core: ambiguous vns: vp/0xf38e7ab0,
>  invp/0xf7067570
> May 30 09:47:12 daacsnfs kernel: Unable to handle kernel NULL pointer derefer
> ence at virtual address 00000008
> May 30 09:47:12 daacsnfs kernel:  printing eip:
> May 30 09:47:12 daacsnfs kernel: c01e7892
> May 30 09:47:12 daacsnfs kernel: pgd entry f697b000: 0000000000000000
> May 30 09:47:12 daacsnfs kernel: pmd entry f697b000: 0000000000000000
> May 30 09:47:12 daacsnfs kernel: ... pmd not present!
> May 30 09:47:12 daacsnfs kernel: Oops: 0000
> May 30 09:47:12 daacsnfs kernel: CPU:    1
> May 30 09:47:12 daacsnfs kernel: EIP:    0010:[vn_revalidate+34/232]
> May 30 09:47:12 daacsnfs kernel: EIP:    0010:[<c01e7892>]
> May 30 09:47:12 daacsnfs kernel: EFLAGS: 00010286
> May 30 09:47:12 daacsnfs kernel: eax: 00000084   ebx: f7067570   ecx: f7ba640
> 0   edx: 00000000
> May 30 09:47:12 daacsnfs kernel: esi: f7067570   edi: 00000084   ebp: f706757
> 0   esp: f6b7dc20
> May 30 09:47:12 daacsnfs kernel: ds: 0018   es: 0018   ss: 0018
> May 30 09:47:12 daacsnfs kernel: Process nfsd (pid: 719, stackpage=f6b7d000)
> May 30 09:47:12 daacsnfs kernel: Stack: f7067570 f7067570 f89048a8 00000001 1
> 4003fff f89048c8 ffffffff ffffffff 
> May 30 09:47:12 daacsnfs kernel:        00000019 f713fe60 00000002 00000000 0
> 0000001 00000002 00000000 00000000 
> May 30 09:47:12 daacsnfs kernel:        00000001 c22ea000 f6b7dc94 00000082 f
> 89048ac 00000246 f89048a8 00000046 
> May 30 09:47:12 daacsnfs kernel: Call Trace: [eepro100:__insmod_eepro100_O/li
> b/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329560/96] [eepro100:__insmod_eepro100
> _O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329528/96] [eepro100:__insmod_eep
> ro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329556/96] [eepro100:__insmo
> d_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329560/96] [eepro100:__
> insmod_eepro100_O/lib/modules/2.4.2-SGI_XFS_1.0smp/kernel+-329524/96] [xfs_ig
> et_core+1916/1956] [ip_rcv+926/992] 
> May 30 09:47:12 daacsnfs kernel: Call Trace: [<f89048a8>] [<f89048c8>] [<f890
> 48ac>] [<f89048a8>] [<f89048cc>] [<c01bd320>] [<c0258c5e>] 
> May 30 09:47:12 daacsnfs kernel:        [eepro100:__insmod_eepro100_O/lib/mod
> ules/2.4.2-SGI_XFS_1.0smp/kernel+-329556/96] [xfs_vn_iget+52/60] [vn_initiali
> ze+213/344] [linvfs_read_inode+30/80] [get_new_inode+227/376] [iget4+221/232]
>  [<f8981d1d>] [<f89822fd>] 
> May 30 09:47:12 daacsnfs kernel:        [<f89048ac>] [<c01bd3b8>] [<c01e7649>
> ] [<c01e6b86>] [<c01505f7>] [<c0150945>] [<f8981d1d>] [<f89822fd>] 
> May 30 09:47:12 daacsnfs kernel:        [<f89827a4>] [<f89838bd>] [<f8983ec0>
> ] [do_ccupdate_local+0/64] [smp_call_function_interrupt+50/88] [csum_partial+
> 185/232] [call_call_function_interrupt+5/12] [csum_partial+185/232] 
> May 30 09:47:12 daacsnfs kernel:        [<f89827a4>] [<f89838bd>] [<f8983ec0>
> ] [<c012f074>] [<c01134da>] [<c0291a69>] [<c029f12d>] [<c0291a69>] 
> May 30 09:47:12 daacsnfs kernel:        [<f8989173>] [<f8991480>] [<f89805c3>
> ] [<f8991480>] [<f89656f8>] [<f8991340>] [<f8990e18>] [<f8980369>] 
> May 30 09:47:12 daacsnfs kernel:        [kernel_thread+35/48] 
> May 30 09:47:12 daacsnfs kernel:        [<c01075e3>] 
> May 30 09:47:12 daacsnfs kernel: 
> May 30 09:47:12 daacsnfs kernel: Code: 8b 4a 08 6a 00 25 80 00 00 00 50 8d 44
>  24 18 50 52 8b 41 14 
> 
> I was able to unmount all the filesystems on the SGI's, but the nfsd's
> on the Linux box wouldn't die. Had to power cycle to get it back
> up. (Why isn't there a way to kill processes in I/O wait?)
> 
> Is this a known bug that would be fixed by installing the current CVS'd
> kernel?
> 
> -Dave



From owner-linux-xfs@oss.sgi.com Wed May 30 10:50:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHoqq09398
	for linux-xfs-outgoing; Wed, 30 May 2001 10:50:52 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHonh09392
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:50:49 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id FAA06268
	for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 05:49:26 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id HAA1942234 for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 07:48:10 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA89909 for <linux-xfs@oss.sgi.com>; Sat, 26 May 2001 07:48:10 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4QConr30550; Sat, 26 May 2001 07:50:49 -0500
Message-Id: <200105261250.f4QConr30550@jen.americas.sgi.com>
Date: Sat, 26 May 2001 07:50:49 -0500
Subject: TAKE - fix kdb inode printing
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Debug only change

Date:  Sat May 26 05:47:39 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:95998a
linux/kdb/modules/kdbm_pg.c - 1.37
	- Fix i_state printing, the wrong inode field was being interpreted.



From owner-linux-xfs@oss.sgi.com Wed May 30 10:57:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UHvk110053
	for linux-xfs-outgoing; Wed, 30 May 2001 10:57:46 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UHvbh10035
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 10:57:37 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1095226
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 19:57:34 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2003555; Wed, 30 May 2001 12:56:17 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA38629; Wed, 30 May 2001 12:56:17 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UHxIh18635; Wed, 30 May 2001 12:59:18 -0500
Message-Id: <200105301759.f4UHxIh18635@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: marchuk@ee.washington.edu
cc: Galen Arnold <arnoldg@ncsa.uiuc.edu>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to xfs 
In-Reply-To: Message from <marchuk@ee.washington.edu> 
   of "Wed, 30 May 2001 10:43:02 PDT." <Pine.LNX.4.21.0105301042500.712-100000@darkstar.ee.washington.edu> 
Date: Wed, 30 May 2001 12:59:18 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi,

I am running iozone on a 2Gbyte box on 2.4.5-xfs right now it is still in
the first pass - I only have a striped md filesystem, not hardware raid.
I have not been running long enough to say if the problem is fixed or not.

There continue to be general highmem problems in 2.4 linux right now, there
are known deadlocks in the generic code - nothing to do with XFS itself,
but XFS may be better at exposing them. Things do appear to be improving,
the 2.4.2 kernel did not last 10 seconds on this test for Galen, the 2.4.4
kernel lasted several hours. There are more changes in 2.4.5, but Linus rushed
them in right before he put out the 2.4.5 release and he left for Japan,
there was continuing discussion that this would not fix the deadlocks.

Since then there has been a patch to change how I/O is done for highmem
boxes, which a) improves performance and b) should if I understand it
get rid of deadlocks.

I would recommend trying the 2.4.5 kernel, and should that still have
problems I can try the patch from Jens Axboe for changing the way the
I/O is done and pass it on to you.

Thanks for continuing to pound on xfs though.

Steve

> linux-2.4.4-xfs
> 
> *****************************
> Walter Marchuk
> Senior Computer Specialist
> University of Washington
> Electrical Engineering
> Room: 307g
> 206-221-5421
> marchuk@ee.washington.edu
> *****************************
> 
> On Wed, 30 May 2001, Galen Arnold wrote:
> 
> > Walter,
> > 
> > Welcome to the club!  I can reproduce that behavior with 2.4.4-xfs and
> > this iozone test (my host has 2G mem, so I test with big files):
> > 
> > 	iozone -s 4000m -r 64k
> > 
> > My box also hangs (doesn't crash or panic).  Was that 2.4.5-xfs you
> > tested, if so, you saved me the trouble and I'll delay my next cvs
> > checkout/rebuild?
> > 
> > -Galen
> > 
> > +
> > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > National Center for Supercomputing Applications           (217) 244-3473
> > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
> > 
> > On Wed, 30 May 2001 marchuk@ee.washington.edu wrote:
> > 
> > > My fileserver has the latest XFS CVS kernel.  Yesterday the machine
> > > crashed/froze  It stopped at 8PM right after this allocation failed
> > > error.  Notice the time when the machine came back, 1AM (it was physicall
> y
> > > rebooted).  
> > > 
> > > I did a search for this error and saw a correlation with xfs and this
> > > error.  Do any of you know if the error and the crash was due to xfs bug?
> > > 
> > > May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.  
>     
> > > May 30 01:34:19 gauss syslogd 1.3-3: restart.    
> > > *****************************
> > > Walter Marchuk
> > > Senior Computer Specialist
> > > University of Washington
> > > Electrical Engineering
> > > Room: 307g
> > > 206-221-5421
> > > marchuk@ee.washington.edu
> > > *****************************
> > > 
> > > On Tue, 29 May 2001, Steve Lord wrote:
> > > 
> > > > > That means it's been tagged?
> > > > 
> > > > I am not sure what you mean by tagged, I checked in a fix for the probl
> em
> > > > with the implementation I checked in on Friday, and in cleaning my mail
> > > > box I saw that I had said I would do a followup under the same heading.
> > > > 
> > > > Steve
> > > > 
> > > > > 
> > > > > -- 
> > > > > Austin Gonyou
> > > > > Systems Architect, CCNA
> > > > > Coremetrics, Inc.
> > > > > Phone: 512-796-9023
> > > > > email: austin@coremetrics.com
> > > > > 
> > > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > > 
> > > > > > >
> > > > > > > Sod's law says you find the hole right after you ship the code. T
> here is 
> > > > > a
> > > > > > > bug in this code, I would not do a cvs update until I get a fix i
> n, I kno
> > > > > w
> > > > > > > roughly how to fix it, but it will take me a while to code and te
> st it.
> > > > > > >
> > > > > > > I would hold off on the cvs tree for a while until you see anothe
> r messag
> > > > > e
> > > > > > > from me on this thread - probably not today.
> > > > > > >
> > > > > > > Steve
> > > > > > >
> > > > > >
> > > > > > This was fixed over the weekend by the way.
> > > > > >
> > > > > > Steve
> > > > > >
> > > > 
> > > > 
> > > 
> > 



From owner-linux-xfs@oss.sgi.com Wed May 30 11:01:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UI1cP10572
	for linux-xfs-outgoing; Wed, 30 May 2001 11:01:38 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UI1Ph10567
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 11:01:25 -0700
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4UI1N8i023909;
	Wed, 30 May 2001 11:01:23 -0700
Date: Wed, 30 May 2001 11:01:23 -0700 (PDT)
From: <marchuk@ee.washington.edu>
To: Steve Lord <lord@sgi.com>
cc: Galen Arnold <arnoldg@ncsa.uiuc.edu>, linux-xfs@oss.sgi.com
Subject: Re: TAKE - fix panic caused by mix of local and remote access to
 xfs 
In-Reply-To: <200105301759.f4UHxIh18635@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.21.0105301059490.712-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.  
.....after a reboot
May 30 03:27:39 gauss kernel: __alloc_pages: 0-order allocation failed. 
another crash.


*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************

On Wed, 30 May 2001, Steve Lord wrote:

> 
> Hi,
> 
> I am running iozone on a 2Gbyte box on 2.4.5-xfs right now it is still in
> the first pass - I only have a striped md filesystem, not hardware raid.
> I have not been running long enough to say if the problem is fixed or not.
> 
> There continue to be general highmem problems in 2.4 linux right now, there
> are known deadlocks in the generic code - nothing to do with XFS itself,
> but XFS may be better at exposing them. Things do appear to be improving,
> the 2.4.2 kernel did not last 10 seconds on this test for Galen, the 2.4.4
> kernel lasted several hours. There are more changes in 2.4.5, but Linus rushed
> them in right before he put out the 2.4.5 release and he left for Japan,
> there was continuing discussion that this would not fix the deadlocks.
> 
> Since then there has been a patch to change how I/O is done for highmem
> boxes, which a) improves performance and b) should if I understand it
> get rid of deadlocks.
> 
> I would recommend trying the 2.4.5 kernel, and should that still have
> problems I can try the patch from Jens Axboe for changing the way the
> I/O is done and pass it on to you.
> 
> Thanks for continuing to pound on xfs though.
> 
> Steve
> 
> > linux-2.4.4-xfs
> > 
> > *****************************
> > Walter Marchuk
> > Senior Computer Specialist
> > University of Washington
> > Electrical Engineering
> > Room: 307g
> > 206-221-5421
> > marchuk@ee.washington.edu
> > *****************************
> > 
> > On Wed, 30 May 2001, Galen Arnold wrote:
> > 
> > > Walter,
> > > 
> > > Welcome to the club!  I can reproduce that behavior with 2.4.4-xfs and
> > > this iozone test (my host has 2G mem, so I test with big files):
> > > 
> > > 	iozone -s 4000m -r 64k
> > > 
> > > My box also hangs (doesn't crash or panic).  Was that 2.4.5-xfs you
> > > tested, if so, you saved me the trouble and I'll delay my next cvs
> > > checkout/rebuild?
> > > 
> > > -Galen
> > > 
> > > +
> > > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.edu
> > > National Center for Supercomputing Applications           (217) 244-3473
> > > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 61820
> > > 
> > > On Wed, 30 May 2001 marchuk@ee.washington.edu wrote:
> > > 
> > > > My fileserver has the latest XFS CVS kernel.  Yesterday the machine
> > > > crashed/froze  It stopped at 8PM right after this allocation failed
> > > > error.  Notice the time when the machine came back, 1AM (it was physicall
> > y
> > > > rebooted).  
> > > > 
> > > > I did a search for this error and saw a correlation with xfs and this
> > > > error.  Do any of you know if the error and the crash was due to xfs bug?
> > > > 
> > > > May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.  
> >     
> > > > May 30 01:34:19 gauss syslogd 1.3-3: restart.    
> > > > *****************************
> > > > Walter Marchuk
> > > > Senior Computer Specialist
> > > > University of Washington
> > > > Electrical Engineering
> > > > Room: 307g
> > > > 206-221-5421
> > > > marchuk@ee.washington.edu
> > > > *****************************
> > > > 
> > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > 
> > > > > > That means it's been tagged?
> > > > > 
> > > > > I am not sure what you mean by tagged, I checked in a fix for the probl
> > em
> > > > > with the implementation I checked in on Friday, and in cleaning my mail
> > > > > box I saw that I had said I would do a followup under the same heading.
> > > > > 
> > > > > Steve
> > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > Austin Gonyou
> > > > > > Systems Architect, CCNA
> > > > > > Coremetrics, Inc.
> > > > > > Phone: 512-796-9023
> > > > > > email: austin@coremetrics.com
> > > > > > 
> > > > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > > > 
> > > > > > > >
> > > > > > > > Sod's law says you find the hole right after you ship the code. T
> > here is 
> > > > > > a
> > > > > > > > bug in this code, I would not do a cvs update until I get a fix i
> > n, I kno
> > > > > > w
> > > > > > > > roughly how to fix it, but it will take me a while to code and te
> > st it.
> > > > > > > >
> > > > > > > > I would hold off on the cvs tree for a while until you see anothe
> > r messag
> > > > > > e
> > > > > > > > from me on this thread - probably not today.
> > > > > > > >
> > > > > > > > Steve
> > > > > > > >
> > > > > > >
> > > > > > > This was fixed over the weekend by the way.
> > > > > > >
> > > > > > > Steve
> > > > > > >
> > > > > 
> > > > > 
> > > > 
> > > 
> 
> 


From owner-linux-xfs@oss.sgi.com Wed May 30 11:02:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UI2Lq10735
	for linux-xfs-outgoing; Wed, 30 May 2001 11:02:21 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UI2Fh10713
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 11:02:15 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id UAA1112653
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 20:02:13 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA2008991 for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:00:56 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA56823 for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:00:50 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UI3pK18660; Wed, 30 May 2001 13:03:51 -0500
Message-Id: <200105301803.f4UI3pK18660@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: Re: 2.4.5 panic while starting aic7xxx (fwd)
Date: Wed, 30 May 2001 13:03:51 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Forwarded from linux-kernel, since this was originally asked on the xfs list.

Steve

------- Forwarded Message

Date:    Wed, 30 May 2001 09:19:02 -0600
From:    "Justin T. Gibbs" <gibbs@scsiguy.com>
To:      Michael David <michael@newearth.org>
cc:      linux-kernel@vger.kernel.org
Subject: Re: 2.4.5 panic while starting aic7xxx 

>SCSI subsystem driver Revision: 1.00
>PCI: Found IRQ 11 for device 00:0c.0
>scsi0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.13
>        <Adaptec 2940 Ultra2 SCSI adapter>
>        aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/255 SCBs
>ahc_intr: AWAITING_MSG for an SCB that does not have a waiting message
>SCSIID = 7, target_mask = 1
>Kernel panic: SCB = 3, SCB Control = 40, MSG_OUT = 80 SCB flags = 6000
>In interrupt handler - not syncing

This looks like the firmware file is not in sync with the rest
of the driver.  Depending on the host environment, you may be
able to rebuild the firmware yourself.  Just check the box in
the kernel config section for the aic7xxx driver to rebuild
the firmware.

- --
Justin
- -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


------- End of Forwarded Message




From owner-linux-xfs@oss.sgi.com Wed May 30 11:06:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UI67I11219
	for linux-xfs-outgoing; Wed, 30 May 2001 11:06:07 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UI5th11207
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 11:05:55 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA03821
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 11:05:53 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id NAA1940655; Wed, 30 May 2001 13:04:34 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA20005; Wed, 30 May 2001 13:04:34 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UI7Z018680; Wed, 30 May 2001 13:07:35 -0500
Message-Id: <200105301807.f4UI7Z018680@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: marchuk@ee.washington.edu
cc: Steve Lord <lord@sgi.com>, Galen Arnold <arnoldg@ncsa.uiuc.edu>,
   linux-xfs@oss.sgi.com
Subject: __alloc_pages: 0-order allocation failed
In-Reply-To: Message from marchuk@ee.washington.edu 
   of "Wed, 30 May 2001 11:01:23 PDT." <Pine.LNX.4.21.0105301059490.712-100000@darkstar.ee.washington.edu> 
Date: Wed, 30 May 2001 13:07:35 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I changed the subject line, it was not relevant.

Not clear which kernel version you are running, your previous message said 
2.4.4-xfs. 2.4.5-xfs is out there now.

Steve

> May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation failed.  
> .....after a reboot
> May 30 03:27:39 gauss kernel: __alloc_pages: 0-order allocation failed. 
> another crash.
> 
> 
> *****************************
> Walter Marchuk
> Senior Computer Specialist
> University of Washington
> Electrical Engineering
> Room: 307g
> 206-221-5421
> marchuk@ee.washington.edu
> *****************************
> 
> On Wed, 30 May 2001, Steve Lord wrote:
> 
> > 
> > Hi,
> > 
> > I am running iozone on a 2Gbyte box on 2.4.5-xfs right now it is still in
> > the first pass - I only have a striped md filesystem, not hardware raid.
> > I have not been running long enough to say if the problem is fixed or not.
> > 
> > There continue to be general highmem problems in 2.4 linux right now, there
> > are known deadlocks in the generic code - nothing to do with XFS itself,
> > but XFS may be better at exposing them. Things do appear to be improving,
> > the 2.4.2 kernel did not last 10 seconds on this test for Galen, the 2.4.4
> > kernel lasted several hours. There are more changes in 2.4.5, but Linus rus
> hed
> > them in right before he put out the 2.4.5 release and he left for Japan,
> > there was continuing discussion that this would not fix the deadlocks.
> > 
> > Since then there has been a patch to change how I/O is done for highmem
> > boxes, which a) improves performance and b) should if I understand it
> > get rid of deadlocks.
> > 
> > I would recommend trying the 2.4.5 kernel, and should that still have
> > problems I can try the patch from Jens Axboe for changing the way the
> > I/O is done and pass it on to you.
> > 
> > Thanks for continuing to pound on xfs though.
> > 
> > Steve
> > 
> > > linux-2.4.4-xfs
> > > 
> > > *****************************
> > > Walter Marchuk
> > > Senior Computer Specialist
> > > University of Washington
> > > Electrical Engineering
> > > Room: 307g
> > > 206-221-5421
> > > marchuk@ee.washington.edu
> > > *****************************
> > > 
> > > On Wed, 30 May 2001, Galen Arnold wrote:
> > > 
> > > > Walter,
> > > > 
> > > > Welcome to the club!  I can reproduce that behavior with 2.4.4-xfs and
> > > > this iozone test (my host has 2G mem, so I test with big files):
> > > > 
> > > > 	iozone -s 4000m -r 64k
> > > > 
> > > > My box also hangs (doesn't crash or panic).  Was that 2.4.5-xfs you
> > > > tested, if so, you saved me the trouble and I'll delay my next cvs
> > > > checkout/rebuild?
> > > > 
> > > > -Galen
> > > > 
> > > > +
> > > > Galen Arnold, system engineer--systems group       arnoldg@ncsa.uiuc.ed
> u
> > > > National Center for Supercomputing Applications           (217) 244-347
> 3
> > > > 152 Computer Applications Bldg., 605 E. Spfld. Ave., Champaign, IL 6182
> 0
> > > > 
> > > > On Wed, 30 May 2001 marchuk@ee.washington.edu wrote:
> > > > 
> > > > > My fileserver has the latest XFS CVS kernel.  Yesterday the machine
> > > > > crashed/froze  It stopped at 8PM right after this allocation failed
> > > > > error.  Notice the time when the machine came back, 1AM (it was physi
> call
> > > y
> > > > > rebooted).  
> > > > > 
> > > > > I did a search for this error and saw a correlation with xfs and this
> > > > > error.  Do any of you know if the error and the crash was due to xfs 
> bug?
> > > > > 
> > > > > May 29 20:01:09 gauss kernel: __alloc_pages: 0-order allocation faile
> d.  
> > >     
> > > > > May 30 01:34:19 gauss syslogd 1.3-3: restart.    
> > > > > *****************************
> > > > > Walter Marchuk
> > > > > Senior Computer Specialist
> > > > > University of Washington
> > > > > Electrical Engineering
> > > > > Room: 307g
> > > > > 206-221-5421
> > > > > marchuk@ee.washington.edu
> > > > > *****************************
> > > > > 
> > > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > > 
> > > > > > > That means it's been tagged?
> > > > > > 
> > > > > > I am not sure what you mean by tagged, I checked in a fix for the p
> robl
> > > em
> > > > > > with the implementation I checked in on Friday, and in cleaning my 
> mail
> > > > > > box I saw that I had said I would do a followup under the same head
> ing.
> > > > > > 
> > > > > > Steve
> > > > > > 
> > > > > > > 
> > > > > > > -- 
> > > > > > > Austin Gonyou
> > > > > > > Systems Architect, CCNA
> > > > > > > Coremetrics, Inc.
> > > > > > > Phone: 512-796-9023
> > > > > > > email: austin@coremetrics.com
> > > > > > > 
> > > > > > > On Tue, 29 May 2001, Steve Lord wrote:
> > > > > > > 
> > > > > > > > >
> > > > > > > > > Sod's law says you find the hole right after you ship the cod
> e. T
> > > here is 
> > > > > > > a
> > > > > > > > > bug in this code, I would not do a cvs update until I get a f
> ix i
> > > n, I kno
> > > > > > > w
> > > > > > > > > roughly how to fix it, but it will take me a while to code an
> d te
> > > st it.
> > > > > > > > >
> > > > > > > > > I would hold off on the cvs tree for a while until you see an
> othe
> > > r messag
> > > > > > > e
> > > > > > > > > from me on this thread - probably not today.
> > > > > > > > >
> > > > > > > > > Steve
> > > > > > > > >
> > > > > > > >
> > > > > > > > This was fixed over the weekend by the way.
> > > > > > > >
> > > > > > > > Steve
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > 
> > 



From owner-linux-xfs@oss.sgi.com Wed May 30 12:07:12 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJ7Cc13660
	for linux-xfs-outgoing; Wed, 30 May 2001 12:07:12 -0700
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJ78h13656
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:07:08 -0700
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA17610
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:06:57 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id MAA12506
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:07:06 -0700 (PDT)
Received: from pipcws.ca.boeing.com by slb-hub-01.boeing.com with ESMTP for linux-xfs@oss.sgi.com; Wed, 30 May 2001 12:07:01 -0700
Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id MAA53358
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:07:01 -0700
Message-Id: <3B1544D8.6000505@pipcws.ca.boeing.com>
Date: Wed, 30 May 2001 12:07:04 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: resizing xfs
References: <200105301746.f4UHklL18596@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord wrote:

>>Is posible to decrease xfs filesystem ?
>>
>>-- 
>>Daniel Podlejski <underley@underley.eu.org>
>>   ... You know the day destroys the night
>>   Night divides the day ...
>>
> 
> 
> This should be a FAQ question I think, unfortunately, no you cannot do
> this.


Sure you can! In only 4 easy steps

1) backup the data.
2) delete the filesystem
3) re-create it in a new, smaller size
4) restore the data

		Sorry... Been one of those days...
			I couldn't resist.

	Ric


From owner-linux-xfs@oss.sgi.com Wed May 30 12:11:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJBcL14004
	for linux-xfs-outgoing; Wed, 30 May 2001 12:11:38 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJBYh13997
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:11:35 -0700
Received: from crom.corp.sgi.com ([130.62.63.32]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAA01574
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:11:34 -0700 (PDT)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA78234; Wed, 30 May 2001 12:15:28 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP
	id 48E9A15A223; Wed, 30 May 2001 12:09:45 -0700 (PDT)
Subject: Re: i440LX and DAC960 again
From: Florin Andrei <florin@sgi.com>
To: Eric Sandeen <sandeen@sgi.com>
Cc: mrlancealot@hotmail.com, linux-xfs@oss.sgi.com
In-Reply-To: <3B0D8648.9FABD382@sgi.com>
References: <3AFAD3AE.F51806B8@sgi.com>
	<990741473.8059.6.camel@stantz.corp.sgi.com>  <3B0D8648.9FABD382@sgi.com>
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 30 May 2001 12:09:45 -0700
Message-Id: <991249785.28852.3.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On 24 May 2001 17:08:08 -0500, Eric Sandeen wrote:
> 
> The driver disk doesn't work so well after all, it drops the updated
> driver in drivers/scsi rather than drivers/block (this seems to be an
> anaconda limitation).

Yes, your fix works.
It looks like the guys from Red Hat also fixed the installer:

http://people.redhat.com/dledford/440gx/

The idea is to put "linux apic" at the boot: prompt.

-- 
Florin Andrei

"All operating systems suck.
Linux just sucks less" - an MIT guy


From owner-linux-xfs@oss.sgi.com Wed May 30 12:14:15 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJEFi14313
	for linux-xfs-outgoing; Wed, 30 May 2001 12:14:15 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJEAh14309
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:14:11 -0700
Received: from crom.corp.sgi.com (crom.corp.sgi.com [130.62.63.32]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id VAA1120677
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 21:14:08 +0200 (CEST)
	mail_from (florin@sgi.com)
Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.175.86]) by crom.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA26413 for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:18:00 -0700 (PDT)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by stantz.corp.sgi.com (Postfix) with ESMTP id 5606415A223
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:12:17 -0700 (PDT)
Subject: question
From: Florin Andrei <florin@sgi.com>
To: linux-xfs@oss.sgi.com
Content-Type: text/plain
X-Mailer: Evolution/0.10 (Preview Release)
Date: 30 May 2001 12:12:17 -0700
Message-Id: <991249937.28873.4.camel@stantz.corp.sgi.com>
Mime-Version: 1.0
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

While reading the ReiserFS FAQ, i saw this:

#############################################
Is Qmail *NOT* reliable with ReiserFS?
    Qmail integration instructions are here:
http://www.jedi.claranet.fr/qmail-ReiserFS-howto.html.
    Qmail assumes that link() and unlink() are synchronous operations.
Therefore, as soon as a message is received, Qmail writes it in mess and
intd, creates a link in the todo directory for further processing, and
tells the SMTP client that everything is all right.
    With ReiserFS, link() is not synchronous. There is no guarantee that
the message will be flagged for further processing by qmail-send if
there is a power outage before the link is committed. The same problem
may affect local deliveries.
Here is a patch against Qmail 1.03 to correct that behavior.
#############################################

Is this also true for XFS?

-- 
Florin Andrei

"All operating systems suck.
Linux just sucks less" - an MIT guy


From owner-linux-xfs@oss.sgi.com Wed May 30 12:29:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJTIV15157
	for linux-xfs-outgoing; Wed, 30 May 2001 12:29:18 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJTDh15154
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:29:13 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id MAA01991
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:29:08 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2004293; Wed, 30 May 2001 14:27:51 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA55355; Wed, 30 May 2001 14:27:51 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UJUqk19091; Wed, 30 May 2001 14:30:52 -0500
Message-Id: <200105301930.f4UJUqk19091@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Florin Andrei <florin@sgi.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: question 
In-Reply-To: Message from Florin Andrei <florin@sgi.com> 
   of "30 May 2001 12:12:17 PDT." <991249937.28873.4.camel@stantz.corp.sgi.com> 
Date: Wed, 30 May 2001 14:30:52 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Link is also not a synchronous operation on xfs, if there is a crash before
the link is flushed from the log to disk then the link will disappear after
recovery. Running with the -o wsync mount option will make all transactions
synchronous - with a corresponding slowdown in all operations. This will make
the filesystem very safe, but not too fast. The patch mentioned - if it is
doing fsyncs in the correct place should also fix the issue for xfs.

Steve


> While reading the ReiserFS FAQ, i saw this:
> 
> #############################################
> Is Qmail *NOT* reliable with ReiserFS?
>     Qmail integration instructions are here:
> http://www.jedi.claranet.fr/qmail-ReiserFS-howto.html.
>     Qmail assumes that link() and unlink() are synchronous operations.
> Therefore, as soon as a message is received, Qmail writes it in mess and
> intd, creates a link in the todo directory for further processing, and
> tells the SMTP client that everything is all right.
>     With ReiserFS, link() is not synchronous. There is no guarantee that
> the message will be flagged for further processing by qmail-send if
> there is a power outage before the link is committed. The same problem
> may affect local deliveries.
> Here is a patch against Qmail 1.03 to correct that behavior.
> #############################################
> 
> Is this also true for XFS?
> 
> -- 
> Florin Andrei
> 
> "All operating systems suck.
> Linux just sucks less" - an MIT guy



From owner-linux-xfs@oss.sgi.com Wed May 30 12:30:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJUPs15363
	for linux-xfs-outgoing; Wed, 30 May 2001 12:30:25 -0700
Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJUMh15357
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:30:22 -0700
Received: from online.no (217-13-10-85.dd.nextgentel.com [217.13.10.85])
	by mail.broadpark.no (Postfix) with SMTP id D2E4D7DD5
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 21:30:15 +0200 (MET DST)
Message-ID: <3B159E5B.B6224CA4@online.no>
Date: Wed, 30 May 2001 21:28:59 -0400
From: Knut J Bjuland <knutjbj@online.no>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: When'll XFS be part of Linux vanila or RedHat Linux.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

When'll XFS be part of Linux vanila or RedHat Linux. Reiserfs become
part of Linux in 2.4.1.


From owner-linux-xfs@oss.sgi.com Wed May 30 12:37:17 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UJbHt15884
	for linux-xfs-outgoing; Wed, 30 May 2001 12:37:17 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UJbEh15881
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:37:14 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20875
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 12:37:09 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id OAA2007751; Wed, 30 May 2001 14:35:43 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA78559; Wed, 30 May 2001 14:35:43 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4UJcia19124; Wed, 30 May 2001 14:38:44 -0500
Message-Id: <200105301938.f4UJcia19124@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Knut J Bjuland <knutjbj@online.no>
cc: linux-xfs@oss.sgi.com
Subject: Re: When'll XFS be part of Linux vanila or RedHat Linux. 
In-Reply-To: Message from Knut J Bjuland <knutjbj@online.no> 
   of "Wed, 30 May 2001 21:28:59 EDT." <3B159E5B.B6224CA4@online.no> 
Date: Wed, 30 May 2001 14:38:44 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> When'll XFS be part of Linux vanila or RedHat Linux. Reiserfs become
> part of Linux in 2.4.1.

Hans Reiser started a campaign to get into Linus's kernel several months
before 2.4 came out, and everyone screamed, not while we are in the
final weeks of 2.3.xxx - which turned into months. Linus told me in July
last year that it would go into 2.4.1, and it did. The fact that it had
had several months air time in a major distribution (Suse) probably had
a lot to do with it.

We have not yet asked distributors or Linus to take the code, but things
are starting to happen, and we will probably be asking Linus soon.

Steve



From owner-linux-xfs@oss.sgi.com Wed May 30 13:22:30 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UKMUo17357
	for linux-xfs-outgoing; Wed, 30 May 2001 13:22:30 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UKMPh17353
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:22:26 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4UKJtg20441
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 15:19:56 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 30 May 2001 15:19:55 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: 2.4.5 compiles, almost:(
Message-ID: <Pine.LNX.4.33.0105301519030.17597-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I get the following error at the end of the build after patching the 2.4.5
SGI tree with LVM 0.9.1b7:

drivers/md/mddev.o: In function `__update_hardblocksize':
drivers/md/mddev.o(.text+0xaba1): undefined reference to
`get_hardblocksize'
drivers/md/mddev.o(.text+0xabed): undefined reference to
`get_hardblocksize'
make[1]: *** [kallsyms] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux'
make: *** [vmlinux] Error 2

I've also sent this to the LVM list and I'll post if they come up with the
answer first.
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com


From owner-linux-xfs@oss.sgi.com Wed May 30 13:39:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UKd0c18146
	for linux-xfs-outgoing; Wed, 30 May 2001 13:39:00 -0700
Received: from digitaltux.com (zoltan@24.68.90.83.on.wave.home.com [24.68.90.83])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UKcvh18142
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:38:57 -0700
Received: from digitaltux.com (localhost [127.0.0.1] (may be forged))
        by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) with SMTP id f4UKcZkS017492
        for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:38:35 -0400
Message-Id: <200105302038.f4UKcZkS017492@digitaltux.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From: "Zoltan Kraus" <zoltan@digitaltux.com>
To: linux-xfs@oss.sgi.com
Subject: No menu in 2.4.5-xfs
X-Mailer: Pronto v2.2.5 On linux/mysql
Date: 30 May 2001 16:38:33 EDT
Reply-To: "Zoltan Kraus" <zoltan@digitaltux.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk




From owner-linux-xfs@oss.sgi.com Wed May 30 13:48:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UKmEK18670
	for linux-xfs-outgoing; Wed, 30 May 2001 13:48:14 -0700
Received: from digitaltux.com (zoltan@24.68.90.83.on.wave.home.com [24.68.90.83])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UKm9h18667
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:48:09 -0700
Received: from digitaltux.com (localhost [127.0.0.1] (may be forged))
        by localhost (8.12.0.Beta10/8.12.0.Beta10/Debian 8.12.0.Beta10-1) with SMTP id f4UKm5kS017714
        for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:48:05 -0400
Message-Id: <200105302048.f4UKm5kS017714@digitaltux.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From: "Zoltan Kraus" <zoltan@digitaltux.com>
To: linux-xfs@oss.sgi.com
Subject: No menu in 2.4.5-xfs
X-Mailer: Pronto v2.2.5 On linux/mysql
Date: 30 May 2001 16:48:04 EDT
Reply-To: "Zoltan Kraus" <zoltan@digitaltux.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Sorry about my other email, my client was broken =P

Anyhow, make menuconfig doesn't give me a menu and make xconfig gives me the
following error message
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts'
cat header.tk >> ./kconfig.tk
./tkparse < ../arch/i386/config.in >> kconfig.tk
drivers/net/Config.in: 270: unable to open drivers/net/wireless/Config.in
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/scripts'
make: *** [xconfig] Error 2

Any solutions?

- -Zoltan Kraus

BTW: markybobdeb.sourceforge.net/zoltan/disks/xfs for debian woody xfs disks,
READ THE README!!!! :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7FVyEp0iq+lfR+9YRAvGFAJ46X+I46qjMsRtEK9qTrodzTSomiACfetKn
DaNADTMTPvI/3qSlRxXvgQI=
=VJvg
-----END PGP SIGNATURE-----


From owner-linux-xfs@oss.sgi.com Wed May 30 13:57:06 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UKv6h19188
	for linux-xfs-outgoing; Wed, 30 May 2001 13:57:06 -0700
Received: from graze.net (graze.net [216.0.112.53])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UKv1h19181
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 13:57:01 -0700
Received: from localhost (sheep@localhost)
	by graze.net (8.11.2/8.11.2) with ESMTP id f4UKutp02079
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:56:55 -0400
Date: Wed, 30 May 2001 16:56:55 -0400 (EDT)
From: "Brian C. Huffman" <sheep@graze.net>
To: <linux-xfs@oss.sgi.com>
Subject: VMWare on XFS
Message-ID: <Pine.LNX.4.33.0105301648420.2049-100000@graze.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

All,

	When I first installed my linux box using XFS I installed vmware
and found the vmware message about file locking.  I fixed that and
attempted to install my NT4 in a guest vmware.  It locked when it came to
formatting the filesystem....don't know why.

	At that point, I gave up and put an ext2 filesystem on there and
installed.  Since I figured that XFS has become much more stable, I
figured I'd give XFS another try.  I backed up the ext2, did mkfs.xfs and
restored.  (Didn't have to worry about the NTFS format since I already
have my NT guest system running).  So I run vmware and it hangs at the
prom screen right after it detects the disks...I aborted and restarted and
this time it works!?  Don't know why.

My main question is:  Is XFS ok to use for this purpose
(performance-wise)?  Are there any mount options I ought to use that would
help with the performance of *very* large files (like the image file that
vmware uses)?

Thanks in advance!
Brian


From owner-linux-xfs@oss.sgi.com Wed May 30 14:12:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ULC4G19761
	for linux-xfs-outgoing; Wed, 30 May 2001 14:12:04 -0700
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [12.13.237.21])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ULC0h19758
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 14:12:00 -0700
Received: from slb-av-01.boeing.com ([129.172.13.4])
	by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA00963
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 14:11:50 -0700 (PDT)
Received: from slb-hub-01.boeing.com (localhost [127.0.0.1])
	by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA16264
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 14:11:59 -0700 (PDT)
Received: from pipcws.ca.boeing.com by slb-hub-01.boeing.com with ESMTP; Wed, 30 May 2001 14:11:43 -0700
Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA138540;
	Wed, 30 May 2001 14:11:43 -0700
Message-Id: <3B156212.3070009@pipcws.ca.boeing.com>
Date: Wed, 30 May 2001 14:11:46 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Zoltan Kraus <zoltan@digitaltux.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: No menu in 2.4.5-xfs
References: <200105302048.f4UKm5kS017714@digitaltux.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Zoltan Kraus wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Sorry about my other email, my client was broken =P
> 
> Anyhow, make menuconfig doesn't give me a menu and make xconfig gives me the
> following error message
> rm -f include/asm
> ( cd include ; ln -sf asm-i386 asm)
> make -C scripts kconfig.tk
> make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts'
> cat header.tk >> ./kconfig.tk
> ./tkparse < ../arch/i386/config.in >> kconfig.tk
> drivers/net/Config.in: 270: unable to open drivers/net/wireless/Config.in
> make[1]: *** [kconfig.tk] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/scripts'
> make: *** [xconfig] Error 2
> 
> Any solutions?


Try "make mrproper" first. Then try to config it.


From owner-linux-xfs@oss.sgi.com Wed May 30 14:32:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ULWsR20557
	for linux-xfs-outgoing; Wed, 30 May 2001 14:32:54 -0700
Received: from server.home.fliegl.de ([195.180.174.246])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ULWoh20554
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 14:32:50 -0700
Received: from fliegl.de (server.home.fliegl.de [172.16.1.1])
	by server.home.fliegl.de (Maggifix) with ESMTP
	id 1D2B949FF2; Wed, 30 May 2001 23:32:43 +0200 (CEST)
Message-ID: <3B1566FA.FD9C84FE@fliegl.de>
Date: Wed, 30 May 2001 23:32:42 +0200
From: Deti Fliegl <deti@fliegl.de>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.4-xfs i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Brian C. Huffman" <sheep@graze.net>
Cc: linux-xfs@oss.sgi.com
Subject: Re: VMWare on XFS
References: <Pine.LNX.4.33.0105301648420.2049-100000@graze.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Brian 

>         When I first installed my linux box using XFS I installed vmware
> and found the vmware message about file locking.  I fixed that and
> attempted to install my NT4 in a guest vmware.  It locked when it came to
> formatting the filesystem....don't know why.
> 
>         At that point, I gave up and put an ext2 filesystem on there and
> installed.  Since I figured that XFS has become much more stable, I
> figured I'd give XFS another try.  I backed up the ext2, did mkfs.xfs and
> restored.  (Didn't have to worry about the NTFS format since I already
> have my NT guest system running).  So I run vmware and it hangs at the
> prom screen right after it detects the disks...I aborted and restarted and
> this time it works!?  Don't know why.
> 
> My main question is:  Is XFS ok to use for this purpose
> (performance-wise)?  Are there any mount options I ought to use that would
> help with the performance of *very* large files (like the image file that
> vmware uses)?

Here on my computer it works perfectly: I have a kernel 2.4.5-xfs
(latest CVS tree) running whith vmware 2.0.3-799 with its virtual disk
on a xfs partition. So I can not see a general problem using vmware.

BTW: XFS works great here on a couple of servers since months. We
currently have more than 4.000.000 files and 400GB on our harddisks
which are all production systems for our working group. We are really
happy having found such a stable and reliable filesystem (much better
than reiserfs). 


Deti
-- 
Deti Fliegl

From owner-linux-xfs@oss.sgi.com Wed May 30 14:34:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4ULYbt20776
	for linux-xfs-outgoing; Wed, 30 May 2001 14:34:37 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4ULYWh20771
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 14:34:32 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4ULVDp21244;
	Wed, 30 May 2001 16:31:13 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 30 May 2001 16:31:13 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
cc: Zoltan Kraus <zoltan@digitaltux.com>, <linux-xfs@oss.sgi.com>
Subject: Re: No menu in 2.4.5-xfs
In-Reply-To: <3B156212.3070009@pipcws.ca.boeing.com>
Message-ID: <Pine.LNX.4.33.0105301630160.17597-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

if you look, with this issue, you'll see that awk segfaults and cores. You
have to do more than update the source. I had to delete my whole tree, mr
proper didn't work, checkout the tree again, then it was fine.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Wed, 30 May 2001, Ric Tibbetts wrote:

> Zoltan Kraus wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > Sorry about my other email, my client was broken =P
> >
> > Anyhow, make menuconfig doesn't give me a menu and make xconfig gives me the
> > following error message
> > rm -f include/asm
> > ( cd include ; ln -sf asm-i386 asm)
> > make -C scripts kconfig.tk
> > make[1]: Entering directory `/usr/src/linux-2.4-xfs/linux/scripts'
> > cat header.tk >> ./kconfig.tk
> > ./tkparse < ../arch/i386/config.in >> kconfig.tk
> > drivers/net/Config.in: 270: unable to open drivers/net/wireless/Config.in
> > make[1]: *** [kconfig.tk] Error 1
> > make[1]: Leaving directory `/usr/src/linux-2.4-xfs/linux/scripts'
> > make: *** [xconfig] Error 2
> >
> > Any solutions?
>
>
> Try "make mrproper" first. Then try to config it.
>


From owner-linux-xfs@oss.sgi.com Wed May 30 15:57:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UMvsZ22963
	for linux-xfs-outgoing; Wed, 30 May 2001 15:57:54 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UMvoh22958
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 15:57:50 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4UMtMa26575
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 17:55:22 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Wed, 30 May 2001 17:55:22 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <linux-xfs@oss.sgi.com>
Subject: XFS/LVM Bug(I've had it -grin-)
Message-ID: <Pine.LNX.4.33.0105301740430.21655-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Ok,
  I'm simply stumped with this dumb bug. I've gone down every path I feel
I can go down, and to no avail does this bug get fixed. I've not yet tried
it on the target system, but I will in time. Here is the issue, still:

With the most recent 2.4.5-xfs cvs tree, even the newest tools from both
the LVM install and XFS progs, i still get that darn "Unknown error 990".

Additionally, something I may have missed before is this message when
creating the FS:

mkfs.xfs: warning - cannot set blocksize on block device
^^^^^^^^^^^^^^------------Anyone know what that's all about?
/dev/oracle/oravol1: Invalid argument
meta-data=/dev/oracle/oravol1    isize=256    agcount=8, agsize=204800
blks
data     =                       bsize=4096   blocks=1638400, imaxpct=25
         =                       sunit=2      swidth=4 blks, unwritten=0
naming   =version 2              bsize=4096
log      =internal log           bsize=4096   blocks=1200
realtime =none                   extsz=16384  blocks=0, rtextents=0

Austin
-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com



From owner-linux-xfs@oss.sgi.com Wed May 30 16:34:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UNYoX23849
	for linux-xfs-outgoing; Wed, 30 May 2001 16:34:50 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UNYkh23842
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:34:46 -0700
Received: from surfers.oz.agile.tv (fw.oz.agile.tv [210.9.52.165]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA07434
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:34:34 -0700 (PDT)
	mail_from (ksingh@oz.agile.tv)
Received: from oz.agile.tv (IDENT:ksingh@budds.oz.agile.tv [192.168.16.7])
	by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f4UNYSQ13186
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 09:34:28 +1000
Message-ID: <3B158385.8010800@oz.agile.tv>
Date: Thu, 31 May 2001 09:34:29 +1000
From: Kalvinder Singh <ksingh@oz.agile.tv>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: XFS over RAID 5
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

Sorry to hear about all the layoffs. You guys have done a great job.

I have been running XFS over RAID 5. However, I heard that Martin was 
still working on getting better performance out of XFS when RAID starts 
to run in degraded mode.

Did I get my wires crossed and there was no such mini project?

What is the status of XFS and RAID 5?

Thanks for everything,
Kal.


From owner-linux-xfs@oss.sgi.com Wed May 30 16:51:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4UNpEC24229
	for linux-xfs-outgoing; Wed, 30 May 2001 16:51:14 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4UNpBh24226
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:51:11 -0700
Received: from maxwell.ee.washington.edu (maxwell.ee.washington.edu [128.95.42.10]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA09261
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:51:07 -0700 (PDT)
	mail_from (marchuk@ee.washington.edu)
From: marchuk@ee.washington.edu
Received: from darkstar.ee.washington.edu (darkstar.ee.washington.edu [128.95.196.85])
	by maxwell.ee.washington.edu (8.12.0.Beta7/8.12.0) with ESMTP id f4UNp68i022603
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 16:51:06 -0700
Date: Wed, 30 May 2001 16:51:05 -0700 (PDT)
To: linux-xfs@oss.sgi.com
Subject: compilation problems with cvs
Message-ID: <Pine.LNX.4.21.0105301659290.249-100000@darkstar.ee.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I just downloaded the latest cvs tree and tried compiling it.  I receive
compile error during the scsi compilation..  Ib

*****************************
Walter Marchuk
Senior Computer Specialist
University of Washington
Electrical Engineering
Room: 307g
206-221-5421
marchuk@ee.washington.edu
*****************************


From owner-linux-xfs@oss.sgi.com Wed May 30 17:29:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V0TO824962
	for linux-xfs-outgoing; Wed, 30 May 2001 17:29:24 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V0TJh24958
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 17:29:19 -0700
Received: from noth.n0th.org (c999639-a.carneg1.pa.home.com [24.180.243.111]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id RAA08984
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 17:29:01 -0700 (PDT)
	mail_from (noth@noth.is.eleet.ca)
Received: from warblade (warblade.n0th.org [10.1.1.2])
	by noth.n0th.org (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id UAA11843
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 20:28:59 -0400
Message-Id: <200105310028.UAA11843@noth.n0th.org>
X-Authentication-Warning: noth.n0th.org: Host warblade.n0th.org [10.1.1.2] claimed to be warblade
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
From: Jim Crilly <noth@noth.is.eleet.ca>
To: linux-xfs@oss.sgi.com
Reply-To: Jim Crilly <noth@noth.is.eleet.ca>
Subject: ACLs on non-Intel
X-Mailer: CSCMail v1.7.9
Date: 30 May 2001 20:28:54 EDT
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I got XFS running on my Alpha and it appears to be really stable, but I've
noticed that there's no syscall for the ACLs yet, is there any timeframe on
when ACL syscalls will be available to non-i386/ia64 users?

Thanks,
    Jim
-- 
Help protect your rights on-line.
Join the Electronic Frontiers Foundation today: http://www.eff.org/join
-----------------------------------------------------------------------
"If a nation values anything more than freedom, it will lose its freedom; and
the irony of it is that if it is comfort or money it values more, it will lose
that, too." -W. Somerset Maugham 


From owner-linux-xfs@oss.sgi.com Wed May 30 18:11:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V1BD126072
	for linux-xfs-outgoing; Wed, 30 May 2001 18:11:13 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V1B9h26066
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 18:11:09 -0700
Received: from boing.melbourne.sgi.com ([134.14.55.141]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id SAA02816
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 18:11:07 -0700 (PDT)
	mail_from (tes@boing.melbourne.sgi.com)
Received: (from tes@localhost)
	by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA35875;
	Thu, 31 May 2001 11:09:48 +1000 (EST)
Date: Thu, 31 May 2001 11:09:48 +1000
From: Timothy Shimmin <tes@boing.melbourne.sgi.com>
To: Jim Crilly <noth@noth.is.eleet.ca>
Cc: linux-xfs@oss.sgi.com
Subject: Re: ACLs on non-Intel
Message-ID: <20010531110948.R97441@boing.melbourne.sgi.com>
References: <200105310028.UAA11843@noth.n0th.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0us
In-Reply-To: <200105310028.UAA11843@noth.n0th.org>; from noth@noth.is.eleet.ca on Wed, May 30, 2001 at 08:28:54PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi Jim,

On Wed, May 30, 2001 at 08:28:54PM -0400, Jim Crilly wrote:
> I got XFS running on my Alpha and it appears to be really stable, but I've
> noticed that there's no syscall for the ACLs yet, is there any timeframe on
> when ACL syscalls will be available to non-i386/ia64 users?
When someone else does it ;-)

We have no access to non-i386 (other than SGIs ;-) in our
group and thus we have no way of testing it.

I would think that you need to update:
    cmd/acl/libacl/acl.c
    linux/include/asm-alpha/unistd.h
    linux/arch/alpha/kernel/entry.S
with appropriate syscall numbers for acl_get/acl_set.

And if you want to get Extended Attributes working from user space
then you'll need to update:
    cmd/attr/libattr/attr.c
    linux/include/asm-alpha/unistd.h
    linux/arch/alpha/kernel/entry.S
with an appropriate syscall number for attrctl.

I think that's it; I may have missed something ? :)

Cheers,
Tim.

From owner-linux-xfs@oss.sgi.com Wed May 30 19:35:59 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V2Zxj27406
	for linux-xfs-outgoing; Wed, 30 May 2001 19:35:59 -0700
Received: from donkeykong.gpcc.itd.umich.edu (smtp@donkeykong.gpcc.itd.umich.edu [141.211.2.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V2Zth27403
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 19:35:55 -0700
Received: from joust.gpcc.itd.umich.edu (smtp@joust.gpcc.itd.umich.edu [141.211.2.148])
        by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id WAA27854
        for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:35:50 -0400 (EDT)
Received: from localhost (klochner@localhost)
	by joust.gpcc.itd.umich.edu (8.8.8/5.1-client) with ESMTP id WAA02953
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:35:49 -0400 (EDT)
Date: Wed, 30 May 2001 22:35:49 -0400 (EDT)
From: Kevin Lochner <klochner@umich.edu>
X-X-Sender:  <klochner@joust.gpcc.itd.umich.edu>
To: <linux-xfs@oss.sgi.com>
Subject: redhat 7.1
Message-ID: <Pine.SOL.4.33.0105302228420.6902-100000@joust.gpcc.itd.umich.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Redhat linux 7.1 is supposed to have all the compiler problems ironed out
(I'm able to build 2.4.2+ kernels with no problems),

After I install the patches provided at the SGI site for 2.4.2 to provide
xfs capability, I'm no longer able to compile the kernel until I download
kgcc. (I get errors about 'cc0' and 'cc1' as documented in your mail
archive about RHat 7.0)

Could you clear this up for me, is the problem that gcc is still broken in
redhat 7.1, or is there some problem that the sgi patches are
introducing??  If the latter, you may want to look at your patches.

btw -- no problems using kgcc, but odd that I had to install kgcc for a
supposedly *fixed* compiler.

kevin

klochner@umich.edu
Doctoral Candidate, CSE
University of Michigan



From owner-linux-xfs@oss.sgi.com Wed May 30 19:42:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V2gAV27610
	for linux-xfs-outgoing; Wed, 30 May 2001 19:42:10 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V2g5h27604
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 19:42:05 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 155IPR-0006UF-00; Thu, 31 May 2001 14:42:01 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "'Kevin Lochner'" <klochner@umich.edu>, <linux-xfs@oss.sgi.com>
Subject: RE: redhat 7.1
Date: Thu, 31 May 2001 14:41:36 +1200
Message-ID: <011101c0e97b$35e98700$0a01a8c0@den2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <Pine.SOL.4.33.0105302228420.6902-100000@joust.gpcc.itd.umich.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Redhat linux 7.1 is supposed to have all the compiler 
:: problems ironed out
:: (I'm able to build 2.4.2+ kernels with no problems),
:: 
:: After I install the patches provided at the SGI site for 
:: 2.4.2 to provide
:: xfs capability, I'm no longer able to compile the kernel 
:: until I download
:: kgcc. (I get errors about 'cc0' and 'cc1' as documented in your mail
:: archive about RHat 7.0)
:: 
:: Could you clear this up for me, is the problem that gcc is 
:: still broken in
:: redhat 7.1, or is there some problem that the sgi patches are
:: introducing??  If the latter, you may want to look at your patches.
:: 
:: btw -- no problems using kgcc, but odd that I had to install 
:: kgcc for a
:: supposedly *fixed* compiler.

Well, is it gcc 2.96-81, or is it the code itself? I think that's the
question everybody would like to have answered, but I think SGI's OSS
team is a little pressed for time at the moment.

I got file system corruption with 2.96-81, but it went away with
2.91-66. I can't tell you why exactly though.

-- Juha


From owner-linux-xfs@oss.sgi.com Wed May 30 20:17:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V3H2128092
	for linux-xfs-outgoing; Wed, 30 May 2001 20:17:02 -0700
Received: from home.smithconcepts.com ([65.35.28.151])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V3Gvh28089
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 20:16:57 -0700
Received: from ieee.org (IDENT:bjsmith@bitman.oviedo.smithconcepts.com [172.24.24.192])
	by home.smithconcepts.com (8.9.3/8.9.3) with ESMTP id XAA26228;
	Wed, 30 May 2001 23:09:41 -0400
Message-ID: <3B15BA11.B01037F2@ieee.org>
Date: Wed, 30 May 2001 23:27:13 -0400
From: "Bryan J. Smith" <b.j.smith@ieee.org>
Organization: SmithConcepts, Inc.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Lord <lord@sgi.com>
CC: Knut J Bjuland <knutjbj@online.no>, linux-xfs@oss.sgi.com
Subject: Re: When'll XFS be part of Linux vanila or RedHat Linux.
References: <200105301938.f4UJcia19124@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Steve Lord wrote:
> Hans Reiser started a campaign to get into Linus's kernel several months
> before 2.4 came out, and everyone screamed, not while we are in the
> final weeks of 2.3.xxx - which turned into months. Linus told me in July
> last year that it would go into 2.4.1, and it did. The fact that it had
> had several months air time in a major distribution (Suse) probably had
> a lot to do with it.

As an end-user, I think Steve makes some excellent points here.  The
key is to get the distributors and OEMs on-board.  That's the first
step.

So far, RedHat and VALinux have snubbed ReiserFS because of its lack
of a traditional inode structure that has issues with some services
(like NFS).  They have shown support for Ext3.  Unfortunately, Ext3
is not available on 2.4 yet.  And, in the end, Tweedie has said that
he's not taking Ext3 any farther than being a journal atop of Ext2
because of projects like ReiserFS, XFS and JFS.  As such, we
end-users should be pushing RedHat and VALinux to start looking at
XFS since it bypasses some of their concerns with ReiserFS.

I had a recent /. response on this (I usually boycott /., but the
mention of XFS on NewsForge caught my eye):
http://slashdot.org/comments.pl?sid=01/05/26/0743254&cid=86

> We have not yet asked distributors or Linus to take the code,
> but things are starting to happen, and we will probably be
> asking Linus soon.

I think the key is to not get "pushy."  Hans' recent "jealousy"
comment is fresh in my mind, although he made some good points.  The
developers know where the code is at and what Linus expects (there
is a very good reason to his madness ;-).

So, as end-users (which is what I'm assume some of us are on this
list), we should be taking this up with our distributors and OEMs. 
RedHat ran a "beta" program for Ext3 and VALinux eventually released
a distro and products using Ext3.  I would like to see this done
with XFS as well.

-- TheBS

-- 
Bryan J. Smith, President        mailto:b.j.smith@ieee.org
(407)366-7013 pager:(888)694-5793 chat:thebs413@AOL/MS/Yho
==========================================================
SmithConcepts, Inc.           http://www.SmithConcepts.com
        Consulting Engineers and IT Professionals

From owner-linux-xfs@oss.sgi.com Wed May 30 22:17:19 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V5HJA30171
	for linux-xfs-outgoing; Wed, 30 May 2001 22:17:19 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V5HGh30168
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:17:16 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA08267
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:17:15 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id PAA20620
	for linux-xfs@oss.sgi.com; Thu, 31 May 2001 15:17:13 +1000
Date: Thu, 31 May 2001 15:17:13 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310517.PAA20620@sherman.melbourne.sgi.com>
Subject: TAKE - Remove spurious white space changes from base kernel
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Remove spurious white space changes from base kernel

Date:  Wed May 30 22:16:19 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96134a
linux/include/linux/vmalloc.h - 1.14


From owner-linux-xfs@oss.sgi.com Wed May 30 22:54:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V5sft30843
	for linux-xfs-outgoing; Wed, 30 May 2001 22:54:41 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V5sah30840
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:54:37 -0700
Received: from solo.ned.dem.csiro.au (solo.ned.dem.CSIRO.AU [130.116.144.65]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id WAA02346
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 22:54:34 -0700 (PDT)
	mail_from (gordon@ned.dem.csiro.au)
Received: from ned.dem.csiro.au (IDENT:gordon@typo.ned.dem.CSIRO.AU [130.116.145.30])
	by solo.ned.dem.csiro.au (8.9.1a/8.9.0) with ESMTP id NAA07678
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:54:27 +0800 (WST)
Message-ID: <3B15DC9B.A00BE995@ned.dem.csiro.au>
Date: Thu, 31 May 2001 13:54:35 +0800
From: Gordon German <gordon@ned.dem.csiro.au>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.3-XFS i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: FIFO errors
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Dear all,
   I'm running the XFS filesystem on a Linux 2.4.3 kernel. The disk is a
76Gb Quantum partitioned into approx 20Gb lots. I seem to be getting
some intermittent behaviour when using FIFOs on this disk. Sometimes
they'll open, sometimes not :-(

The same FIFOs open fine on the other local hard disk, which I have not
yet formatted for XFS. Are you aware of any problems regarding this?

Many thanks,

        Gordon German

--
PS: Pls note new mobile number!!
--------------------------------------------------------
Dr. G.W.H. German

Division of Exploration and Mining
Commonwealth Scientific and Industrial Research Organisation
39 Fairway, Nedlands
Western Australia 6009

phone : +618 9389 8421
mob: +61 (0) 405 101 609
email: gordon@ned.dem.csiro.au
------------------------------------------------------------




From owner-linux-xfs@oss.sgi.com Thu May 31 00:11:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V7BL832350
	for linux-xfs-outgoing; Thu, 31 May 2001 00:11:21 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V7BHh32347
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 00:11:17 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA07805
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 00:11:24 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA05108;
	Thu, 31 May 2001 17:11:14 +1000
Date: Thu, 31 May 2001 17:11:14 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310711.RAA05108@sherman.melbourne.sgi.com>
Subject: TAKE - Move acl.h, attr_kern.h from global to fs/xfs
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

acl.h and attr_kern.h were in include/linux with global scope.  To
avoid arguments about which acl and external attributes should be
global, move the files to fs/xfs/linux and adjust fs/Makefile
accordingly.

Date:  Thu May 31 00:08:46 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96138a
linux/fs/Makefile - 1.32


From owner-linux-xfs@oss.sgi.com Thu May 31 00:44:49 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V7inU00808
	for linux-xfs-outgoing; Thu, 31 May 2001 00:44:49 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V7ijh00805
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 00:44:45 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id JAA1144921
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 09:44:41 +0200 (CEST)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id RAA15373;
	Thu, 31 May 2001 17:44:34 +1000
Date: Thu, 31 May 2001 17:44:34 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310744.RAA15373@sherman.melbourne.sgi.com>
Subject: TAKE - Remove spurious blank lines
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Minimizing differences from base kernel.

Date:  Thu May 31 00:43:46 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96139a
linux/kernel/ksyms.c - 1.91
linux/include/linux/fs.h - 1.95


From owner-linux-xfs@oss.sgi.com Thu May 31 01:07:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V87Ru01412
	for linux-xfs-outgoing; Thu, 31 May 2001 01:07:27 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V87Oh01406
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:07:24 -0700
Received: from sherman.melbourne.sgi.com ([134.14.55.175]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id BAA01829
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:07:13 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA22690;
	Thu, 31 May 2001 18:07:11 +1000
Date: Thu, 31 May 2001 18:07:11 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310807.SAA22690@sherman.melbourne.sgi.com>
Subject: TAKE - Update commands for moved include files
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Update command scripts to reflect the move of acl.h and attr_kern.h
from include/linux to fs/xfs/linux.

Date:  Thu May 31 01:05:47 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96141a
cmd/xfstests/tools/srcdiff - 1.6
cmd/xfsmisc/XFSgenPatch.pl - 1.4


From owner-linux-xfs@oss.sgi.com Thu May 31 01:23:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V8Ni202027
	for linux-xfs-outgoing; Thu, 31 May 2001 01:23:44 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V8Nfh02024
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:23:41 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA23172
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:23:39 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA23996;
	Thu, 31 May 2001 18:23:37 +1000
Date: Thu, 31 May 2001 18:23:37 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310823.SAA23996@sherman.melbourne.sgi.com>
Subject: TAKE - Make attrctl code conditional on CONFIG_HAVE_ATTRCTL
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

XFS cannot assume that struct inode contains attrctl, that feature is
still under discussion.  Make all references to attrctl conditional on
CONFIG_HAVE_ATTRCTL.

Date:  Thu May 31 01:21:33 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96142a
linux/fs/xfs/linux/xfs_iops.c - 1.106
linux/fs/xfs/linux/xfs_ioctl.c - 1.40


From owner-linux-xfs@oss.sgi.com Thu May 31 01:27:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V8RA902234
	for linux-xfs-outgoing; Thu, 31 May 2001 01:27:10 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V8R8h02230
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:27:08 -0700
Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.175]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id BAA08929
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:27:15 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id SAA24278;
	Thu, 31 May 2001 18:27:03 +1000
Date: Thu, 31 May 2001 18:27:03 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105310827.SAA24278@sherman.melbourne.sgi.com>
Subject: TAKE - Define CONFIG_HAVE_ATTRCTL
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Define CONFIG_HAVE_ATTRCTL when XFS is selected.

Date:  Thu May 31 01:26:17 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96143a
linux/fs/Config.in - 1.59


From owner-linux-xfs@oss.sgi.com Thu May 31 01:50:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V8opI02843
	for linux-xfs-outgoing; Thu, 31 May 2001 01:50:51 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V8ojh02838
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:50:46 -0700
Received: from n05.sp.bs.dlr.de (n05.sp.bs.dlr.de [129.247.26.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id BAA06253
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:50:43 -0700 (PDT)
	mail_from (Reiner.Suikat@dlr.de)
Received: from excsrv.bs.dlr.de (excsrv.bs.dlr.de [129.247.41.200])
	by n05.sp.bs.dlr.de (8.11.2/8.11.2) with ESMTP id f4V8ofE07848
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:50:42 +0200
Received: by excsrv.bs.dlr.de with Internet Mail Service (5.5.2650.21)
	id <K322VLVP>; Thu, 31 May 2001 10:49:14 +0200
Message-ID: <E55B46CB134CD4119EEC00306E007023013188@excsrv.bs.dlr.de>
From: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Compile error with latest CVS version
Date: Thu, 31 May 2001 10:49:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id f4V8okh02839
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

first let me say thanks for the great work! It's neat to finally have xfs on
linux.

We are experiencing a crash with xfsdump every time we try to back up our
/home partition (SGI XFS RedHat7.1 version on Dual CPU system). Since there
were reports of a similar problem on the mailling list and a fix has been
checked into the repository, I just checked out the latest version.

Problem: it doesn't compile!
First I got errors compiling the aic7xxx module, using the old driver
instead compiles.

Then compiling the kernel I get the following:
gcc -D__KERNEL__ -I/root/linux-2.4-xfs/linux/include  -Wall
-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe
-mpreferred-stack-boundary=2 -march=i686    -c -o ext_attr.o ext_attr.c
ext_attr.c:39:29: linux/attr_kern.h: Datei oder Verzeichnis nicht gefunden
ext_attr.c:56: parse error before `obj'
ext_attr.c:57: warning: function declaration isn't a prototype
ext_attr.c: In function `sys_attrctl':
ext_attr.c:64: `count' undeclared (first use in this function)
ext_attr.c:64: (Each undeclared identifier is reported only once
ext_attr.c:64: for each function it appears in.)
ext_attr.c:69: `type' undeclared (first use in this function)
ext_attr.c:70: `ATTR_TYPE_FD' undeclared (first use in this function)
ext_attr.c:71: `obj' undeclared (first use in this function)
ext_attr.c:76: break statement not within loop or switch
ext_attr.c:78: `ATTR_TYPE_PATH' undeclared (first use in this function)
ext_attr.c:84: break statement not within loop or switch
ext_attr.c:86: `ATTR_TYPE_LPATH' undeclared (first use in this function)
ext_attr.c:91: break statement not within loop or switch
ext_attr.c:93: `ATTR_TYPE_PID' undeclared (first use in this function)
ext_attr.c:97: default label not within a switch statement
ext_attr.c:123: `ops' undeclared (first use in this function)
make[2]: *** [ext_attr.o] Fehler 1
make[2]: Verlassen des Verzeichnisses Verzeichnis
»/root/linux-2.4-xfs/linux/fs«
make[1]: *** [first_rule] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis
»/root/linux-2.4-xfs/linux/fs«
make: *** [_dir_fs] Fehler 2


any ideas?

regards

Reiner Suikat

--
German Aerospace Center (DLR)
Institute of Flight Guidance
Dr.-Ing. Reiner Suikat
Tel: (49) 531-295-2552
Fax: (49) 531-295-2550
E-Mail: Reiner.Suikat@dlr.de

 

From owner-linux-xfs@oss.sgi.com Thu May 31 02:00:00 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V900v03278
	for linux-xfs-outgoing; Thu, 31 May 2001 02:00:00 -0700
Received: from bastjon.mgm-net.de (bastjon.mgm-net.de [195.254.50.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V8xuh03274
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 01:59:56 -0700
Received: from cepheus.mgm-net.de (IDENT:root@cepheus.mgm-net.de [192.168.1.2])
	by bastjon.mgm-net.de (8.9.3/8.9.3) with ESMTP id KAA28028;
	Thu, 31 May 2001 10:59:53 +0200 (CEST)
Received: from gilmour.mgm-net.de (IDENT:root@gilmour.mgm-net.de [192.168.1.37])
	by cepheus.mgm-net.de (8.9.3/8.9.3) with ESMTP id KAA12545;
	Thu, 31 May 2001 10:59:53 +0200
Received: (from js@localhost)
	by gilmour.mgm-net.de (8.11.0/8.11.0) id f4V8xqU17706;
	Thu, 31 May 2001 10:59:53 +0200
From: Jochen Scharrlach <Jochen.Scharrlach@BW.Nextra.De>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15126.2056.681579.26679@gilmour.mgm-net.de>
Date: Thu, 31 May 2001 10:59:52 +0200 (CEST)
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
Cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version
In-Reply-To: <E55B46CB134CD4119EEC00306E007023013188@excsrv.bs.dlr.de>
References: <E55B46CB134CD4119EEC00306E007023013188@excsrv.bs.dlr.de>
X-Mailer: VM 6.75 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

it is _not_ safe to compile a kernel with gcc-2.96-RH, use kgcc
instead, e.g. say:

make CC=kgcc dep bzImage modules install modules_install

Bye,
Jochen

-- 
----------------------------------------------------------------
Nextra Baden-Wuerttemberg           | Jochen Scharrlach
Communication Service Provider GmbH | Technik
Sophienstr.26                       | Tel.:  +49 (0)711 96683-5
D-70178 Stuttgart                   | Fax:   +49 (0)711 96683-99
----------------------------------------------------------------

  "An innovation a day keeps the monopolist away" -- Alan Cox

From owner-linux-xfs@oss.sgi.com Thu May 31 02:00:54 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V90sT03431
	for linux-xfs-outgoing; Thu, 31 May 2001 02:00:54 -0700
Received: from smtp8.xs4all.nl (smtp8.xs4all.nl [194.109.127.134])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V90oh03428
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 02:00:50 -0700
Received: from xs4.xs4all.nl (xs4.xs4all.nl [194.109.6.45])
	by smtp8.xs4all.nl (8.9.3/8.9.3) with ESMTP id LAA22178;
	Thu, 31 May 2001 11:00:43 +0200 (CEST)
Received: from localhost (knuffie@localhost)
	by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id LAA25874;
	Thu, 31 May 2001 11:00:41 +0200 (CEST)
Date: Thu, 31 May 2001 11:00:41 +0200 (CEST)
From: Seth Mos <knuffie@xs4all.nl>
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version
In-Reply-To: <E55B46CB134CD4119EEC00306E007023013188@excsrv.bs.dlr.de>
Message-ID: <Pine.BSI.4.10.10105311055480.24588-100000@xs4.xs4all.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001, Suikat, Reiner wrote:

> Hello,
> 
> first let me say thanks for the great work! It's neat to finally have xfs on
> linux.
> 
> We are experiencing a crash with xfsdump every time we try to back up our
> /home partition (SGI XFS RedHat7.1 version on Dual CPU system). Since there
> were reports of a similar problem on the mailling list and a fix has been
> checked into the repository, I just checked out the latest version.
> 
> Problem: it doesn't compile!
> First I got errors compiling the aic7xxx module, using the old driver
> instead compiles.

> ext_attr.c:39:29: linux/attr_kern.h: Datei oder Verzeichnis nicht gefunden

Your missing a extended attribute include file here.

Update your CVS tree please, they just updated the tree to reflect a
change of the attr code and its locations. Maybe they missed this one.

It could also be that you checked out the tree before they could check in
the other patches.


From owner-linux-xfs@oss.sgi.com Thu May 31 02:16:03 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4V9G3H04023
	for linux-xfs-outgoing; Thu, 31 May 2001 02:16:03 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4V9Fvh04017
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 02:15:58 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id LAA1131017
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 11:15:52 +0200 (CEST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA11517; Thu, 31 May 2001 19:14:32 +1000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version 
In-reply-to: Your message of "Thu, 31 May 2001 10:49:13 +0200."
             <E55B46CB134CD4119EEC00306E007023013188@excsrv.bs.dlr.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 31 May 2001 19:14:32 +1000
Message-ID: <18151.991300472@kao2.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 10:49:13 +0200, 
"Suikat, Reiner" <Reiner.Suikat@dlr.de> wrote:
>We are experiencing a crash with xfsdump every time we try to back up our
>/home partition (SGI XFS RedHat7.1 version on Dual CPU system). Since there
>were reports of a similar problem on the mailling list and a fix has been
>checked into the repository, I just checked out the latest version.
>
>Then compiling the kernel I get the following:
>gcc -D__KERNEL__ -I/root/linux-2.4-xfs/linux/include  -Wall
>-Wstrict-prototypes -O2 -fno-strict-aliasing -fomit-frame-pointer -pipe
>-mpreferred-stack-boundary=2 -march=i686    -c -o ext_attr.o ext_attr.c
>ext_attr.c:39:29: linux/attr_kern.h: Datei oder Verzeichnis nicht gefunden
>ext_attr.c:56: parse error before `obj'

The joys of using a development CVS tree :).  You got a checkout in the
middle of my changes to minimize the differences between XFS and the
base kernel.  I have finished that change (I hope), please update CVS
again and see if the problem goes away.  You probably need make
mrproper to be on the safe side, a few files got moved around.


From owner-linux-xfs@oss.sgi.com Thu May 31 04:02:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VB2Dl06089
	for linux-xfs-outgoing; Thu, 31 May 2001 04:02:13 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VB28h06069
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:02:08 -0700
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA08756
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:02:07 -0700 (PDT)
	mail_from (keith_m@sweeney.demon.co.uk)
Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk)
	by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1)
	id 155QG8-000541-0U
	for linux-xfs@oss.sgi.com; Thu, 31 May 2001 12:04:56 +0100
Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3])
	by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id 4AFDE27EF
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 08:11:45 +0100 (BST)
Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001)
	id 307CB125E6; Thu, 31 May 2001 08:10:25 +0100 (BST)
Date: Thu, 31 May 2001 08:10:25 +0100 (BST)
From: Keith Matthews <keith_m@sweeney.demon.co.uk>
Subject: Re[2]: When'll XFS be part of Linux vanila or RedHat Linux.
To: linux-xfs@oss.sgi.com
In-Reply-To: <3B15BA11.B01037F2@ieee.org>
References: <200105301938.f4UJcia19124@jen.americas.sgi.com>,
 <3B15BA11.B01037F2@ieee.org>
X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Disposition: INLINE
Message-Id: <20010531071025.307CB125E6@rebutia.sweeney.demon.co.uk>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id f4VB29h06073
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, 30 May 2001 23:27:13 -0400 Bryan J. Smith <Bryan J. Smith <b.j.smith@ieee.org>> wrote:


> So far, RedHat and VALinux have snubbed ReiserFS because of its lack
> of a traditional inode structure that has issues with some services
> (like NFS).  They have shown support for Ext3.  Unfortunately, Ext3
> is not available on 2.4 yet. 

No longer true - there was something about 2 weeks ago, a couple of
other guys  have taken over from Stephen and ar porting it to 2.4

Unfortunately I've lost the URL, ISTR it was on sourceforge but
wouldn't like to bet.



--
Keith Matthews 			Spam trap - my real account at this 
							node is keith_m
Frequentous Consultants  - Linux Services, 
		Oracle development & database administration



From owner-linux-xfs@oss.sgi.com Thu May 31 04:10:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBATC06469
	for linux-xfs-outgoing; Thu, 31 May 2001 04:10:29 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBANh06459
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:10:23 -0700
Received: from dmz.tecosim.de ([194.24.222.241]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA06909
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:10:19 -0700 (PDT)
	mail_from (leh@mail.tecosim.de)
Received: (from uucp@localhost)
	by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f4VB4Bc26480;
	Thu, 31 May 2001 13:04:11 +0200
Received: from ns.tecosim.de(194.24.222.9)
 via SMTP by dmz.tecosim.de, id smtpdRXVz9m; Thu May 31 13:04:03 2001
Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109])
	by ns.tecosim.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f4VB8hE07781;
	Thu, 31 May 2001 13:08:43 +0200
Received: (from leh@localhost)
	by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4VB8gN31429;
	Thu, 31 May 2001 13:08:42 +0200
Date: Thu, 31 May 2001 13:08:42 +0200
From: Utz Lehmann <leh@de.tecosim.com>
To: marchuk@ee.washington.edu
Cc: linux-xfs@oss.sgi.com
Subject: Re: compilation problems with cvs
Message-ID: <20010531130842.B23844@de.tecosim.com>
References: <Pine.LNX.4.21.0105301659290.249-100000@darkstar.ee.washington.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0105301659290.249-100000@darkstar.ee.washington.edu>; from marchuk@ee.washington.edu on Wed, May 30, 2001 at 04:51:05PM -0700
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

Are you using the Adaptec driver?
Then configure "Build Adapter Firmware with Kernel Build
(CONFIG_AIC7XXX_BUILD_FIRMWARE)" to Yes and try again.


utz

marchuk@ee.washington.edu [marchuk@ee.washington.edu] wrote:
> I just downloaded the latest cvs tree and tried compiling it.  I receive
> compile error during the scsi compilation..  Ib
> 
> *****************************
> Walter Marchuk
> Senior Computer Specialist
> University of Washington
> Electrical Engineering
> Room: 307g
> 206-221-5421
> marchuk@ee.washington.edu
> *****************************

From owner-linux-xfs@oss.sgi.com Thu May 31 04:18:20 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBIKU06845
	for linux-xfs-outgoing; Thu, 31 May 2001 04:18:20 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBIFh06840
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:18:15 -0700
Received: from dmz.tecosim.de ([194.24.222.241]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA01659
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:18:13 -0700 (PDT)
	mail_from (leh@mail.tecosim.de)
Received: (from uucp@localhost)
	by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id f4VBDWg26522
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:13:32 +0200
Received: from ns.tecosim.de(194.24.222.9)
 via SMTP by dmz.tecosim.de, id smtpdLWfL16; Thu May 31 13:13:29 2001
Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109])
	by ns.tecosim.de (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) with ESMTP id f4VBI9E08375
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:18:09 +0200
Received: (from leh@localhost)
	by donner.tecosim.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id f4VBI9N31931
	for linux-xfs@oss.sgi.com; Thu, 31 May 2001 13:18:09 +0200
Date: Thu, 31 May 2001 13:18:09 +0200
From: Utz Lehmann <leh@de.tecosim.com>
To: linux-xfs@oss.sgi.com
Subject: Error in fs/Config.in
Message-ID: <20010531131809.C23844@de.tecosim.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi

With the lastest CVS tree make xconfig failed:

donner:/usr/src/linux # make xconfig
rm -f include/asm
( cd include ; ln -sf asm-i386 asm)
make -C scripts kconfig.tk
make[1]: Entering directory /usr/src/linux-2.4-xfs-20010531/linux/scripts'
cat header.tk >> ./kconfig.tk
/tkparse < ../arch/i386/config.in >> kconfig.tk
fs/Config.in: 84: unknown define_bool value
make[1]: *** [kconfig.tk] Error 1
make[1]: Leaving directory /usr/src/linux-2.4-xfs-20010531/linux/scripts'
make: *** [xconfig] Error 2


With this patch it works:

--- fs/Config.in.orig   Thu May 31 13:13:22 2001
+++ fs/Config.in        Thu May 31 13:14:17 2001
@@ -81,7 +81,7 @@
 else
    dep_tristate 'SGI XFS filesystem support' CONFIG_XFS_FS $CONFIG_PAGE_BUF
    if [ "$CONFIG_XFS_FS" != "n" ]; then
-      define_bool CONFIG_HAVE_ATTRCTL
+      define_bool CONFIG_HAVE_ATTRCTL y
       dep_mbool '  Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS
       dep_mbool '  Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS
$CONFIG_QUOTA
    fi


I'm not sure "y" is right value.


utz
 

From owner-linux-xfs@oss.sgi.com Thu May 31 04:23:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBNYj07153
	for linux-xfs-outgoing; Thu, 31 May 2001 04:23:34 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBNUh07147
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:23:30 -0700
Received: (qmail 12465 invoked from network); 31 May 2001 11:23:26 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 31 May 2001 11:23:26 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: Utz Lehmann <leh@de.tecosim.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: Error in fs/Config.in 
In-reply-to: Your message of "Thu, 31 May 2001 13:18:09 +0200."
             <20010531131809.C23844@de.tecosim.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 31 May 2001 21:23:25 +1000
Message-ID: <19932.991308205@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 13:18:09 +0200, 
Utz Lehmann <leh@de.tecosim.com> wrote:
>--- fs/Config.in.orig   Thu May 31 13:13:22 2001
>    if [ "$CONFIG_XFS_FS" != "n" ]; then
>-      define_bool CONFIG_HAVE_ATTRCTL
>+      define_bool CONFIG_HAVE_ATTRCTL y
>       dep_mbool '  Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS

One of the annoying differences between the various config tools, they
do not all accept the same syntax.  Patch will be applied as soon as I
can dial in.  Thanks.


From owner-linux-xfs@oss.sgi.com Thu May 31 04:29:27 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBTRW07461
	for linux-xfs-outgoing; Thu, 31 May 2001 04:29:27 -0700
Received: from inbound0.mv.meer.net (inbound0.mv.meer.net [209.157.152.23])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBTNh07458
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:29:23 -0700
Received: from meer.meer.net (mail.meer.net [209.157.152.14])
	by inbound0.mv.meer.net (8.11.3/8.11.3) with ESMTP id f4VBTMG43634
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:29:22 -0700 (PDT)
Received: from netfall.com (netfall-adsl.mv.meer.net [209.157.145.14])
	by meer.meer.net (8.9.3/8.9.3/meer) with ESMTP id EAA936091
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:29:22 -0700 (PDT)
Message-ID: <3B162A69.57FE9148@netfall.com>
Date: Thu, 31 May 2001 04:26:33 -0700
From: Andrew Sharp <andy@netfall.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17usb i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: location of list archives?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I'm not on this list, but I wanted to try xfs, but of course it
seems to want to require egcs-2.91.66, which is obsolete, I'm sure. 
[Using cvs, I downloaded linux-2.4-xfs-r1.0]  I wanted peruse the
archives to see if the solution to this has already been discussed.

Thanks,

a

From owner-linux-xfs@oss.sgi.com Thu May 31 04:48:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBm2c07962
	for linux-xfs-outgoing; Thu, 31 May 2001 04:48:02 -0700
Received: from relais-int6.globalintranet.net (mailgate.globalintranet.net [194.206.181.244])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBlvh07958
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:47:58 -0700
Received: from passerelle.gtmh.fr ([10.255.7.31]) by
          relais-int6.globalintranet.net (Netscape Messaging Server 4.15)
          with ESMTP id GE5LA803.O9Y for <linux-xfs@oss.sgi.com>; Wed, 30
          May 2001 16:51:44 +0200 
Subject: new patches ?
To: linux-xfs@oss.sgi.com
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <OFC13F8B33.84D3824D-ONC1256A5C.00514EC6@gtmh.fr>
From: f.aide@gtmh.fr
Date: Wed, 30 May 2001 16:53:51 +0200
X-MIMETrack: Serialize by Router on passerelle/GTMH(Release 5.0.5 |September 22, 2000) at
 05/30/2001 06:36:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello,

firstly I would like to thank you for that great work you have done here.

I have already patched and compiled a 2.4.2 kernel with your patches and I
really enjoy using my new xfs partitions... :-)
Will there be any release of patches for 2.4.4 or later kernels? this is a
crucial question since 2.4.2 has a nasty bug in its netfilter code and I
relly would like to change to 2.4.5 ...
My concern is that I would like to be able to continue to upgrade my kernel
regularly and that I did not succeed in patching a 2.4.4 kernel tree with
these patches ( yes I tried...)

Thanks in advance


From owner-linux-xfs@oss.sgi.com Thu May 31 04:54:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VBsEU08339
	for linux-xfs-outgoing; Thu, 31 May 2001 04:54:14 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VBsBh08335
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:54:11 -0700
Received: from sherman.melbourne.sgi.com ([134.14.55.175]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id EAA04238
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 04:54:01 -0700 (PDT)
	mail_from (kaos@sherman.melbourne.sgi.com)
Received: (from kaos@localhost)
	by sherman.melbourne.sgi.com (8.9.3/8.9.3) id VAA02123
	for linux-xfs@oss.sgi.com; Thu, 31 May 2001 21:53:59 +1000
Date: Thu, 31 May 2001 21:53:59 +1000
From: Keith Owens <kaos@sherman.melbourne.sgi.com>
Message-Id: <200105311153.VAA02123@sherman.melbourne.sgi.com>
Subject: TAKE - Correct define_bool
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Date:  Thu May 31 04:53:28 PDT 2001
Workarea:  sherman.melbourne.sgi.com:/build/kaos/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96144a
linux/fs/Config.in - 1.60


From owner-linux-xfs@oss.sgi.com Thu May 31 06:12:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VDCvR10682
	for linux-xfs-outgoing; Thu, 31 May 2001 06:12:57 -0700
Received: from n05.sp.bs.dlr.de (n05.sp.bs.dlr.de [129.247.26.2])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VDCrh10678
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:12:54 -0700
Received: from excsrv.bs.dlr.de (excsrv.bs.dlr.de [129.247.41.200])
	by n05.sp.bs.dlr.de (8.11.2/8.11.2) with ESMTP id f4VDCqE61158
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 15:12:52 +0200
Received: by excsrv.bs.dlr.de with Internet Mail Service (5.5.2650.21)
	id <K322VL7Z>; Thu, 31 May 2001 15:11:24 +0200
Message-ID: <E55B46CB134CD4119EEC00306E00702301318B@excsrv.bs.dlr.de>
From: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Compile error with latest CVS version fixed, now I get a kernel p
	anic on boot
Date: Thu, 31 May 2001 15:11:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks for your inputs,

after updating my CVS tree I can now compile the kernel again. However, the
new aic7xxx module does not compile, so I used the old version.
When I boot the system, right after initialising the SCSI controller and
showing the devices on the screen I get a kernel panic and the system halts.

Is there a way to get the output shown on the screen into a file? I was
unable to find it in the logs.

regards

Reiner

From owner-linux-xfs@oss.sgi.com Thu May 31 06:20:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VDKPb10979
	for linux-xfs-outgoing; Thu, 31 May 2001 06:20:25 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VDKMh10975
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:20:22 -0700
Received: from mail15.jump.net (mail15.jump.net [206.196.91.15]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id GAA07989
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:20:19 -0700 (PDT)
	mail_from (sandeen@sgi.com)
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail15.jump.net (8.10.2/) with ESMTP id f4VDK6105029;
	Thu, 31 May 2001 08:20:06 -0500 (CDT)
Message-ID: <3B1645E7.19978B06@sgi.com>
Date: Thu, 31 May 2001 08:23:51 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Andrew Sharp <andy@netfall.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: location of list archives?
References: <3B162A69.57FE9148@netfall.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Andrew Sharp wrote:
> 
> I'm not on this list, but I wanted to try xfs, but of course it
> seems to want to require egcs-2.91.66, which is obsolete, I'm sure.
> [Using cvs, I downloaded linux-2.4-xfs-r1.0]  I wanted peruse the
> archives to see if the solution to this has already been discussed.

Archives are here:  http://oss.sgi.com/projects/xfs/ml.html

Although 2.91.66 is not really quite obsolete, it's still the
recommended compiler for Linus' kernel, according to the kernel FAQ.

http://www.tux.org/lkml/#s8-2

Compiler independence is an issue that we plan to work on, but using
2.91.66 isn't the end of the world.  :)

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 31 06:23:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VDNSk11204
	for linux-xfs-outgoing; Thu, 31 May 2001 06:23:28 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VDNNh11195
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:23:24 -0700
Received: (qmail 13257 invoked from network); 31 May 2001 13:23:21 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 31 May 2001 13:23:21 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version fixed, now I get a kernel p anic on boot 
In-reply-to: Your message of "Thu, 31 May 2001 15:11:23 +0200."
             <E55B46CB134CD4119EEC00306E00702301318B@excsrv.bs.dlr.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 31 May 2001 23:23:20 +1000
Message-ID: <20601.991315400@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 15:11:23 +0200, 
"Suikat, Reiner" <Reiner.Suikat@dlr.de> wrote:
>after updating my CVS tree I can now compile the kernel again. However, the
>new aic7xxx module does not compile, so I used the old version.

The aic7xxx maintainer recommends rebuilding the sequencer data.
Select 'Build Adapter Firmware with Kernel Build'.

To capture the panic, use a serial console and capture the logs on the
second machine.  See Documentation/serial-console.txt.


From owner-linux-xfs@oss.sgi.com Thu May 31 06:24:02 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VDO2h11341
	for linux-xfs-outgoing; Thu, 31 May 2001 06:24:02 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VDNvh11326
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:23:58 -0700
Received: from mail11.jump.net (mail11.jump.net [206.196.91.11]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id GAA00385
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:23:56 -0700 (PDT)
	mail_from (sandeen@sgi.com)
Received: from sgi.com (aus-dsl-dhcp1-26.customer.jump.net [63.163.168.26])
	by mail11.jump.net (8.10.2/) with ESMTP id f4VDNoR08140;
	Thu, 31 May 2001 08:23:50 -0500 (CDT)
Message-ID: <3B1646C7.A5A8811@sgi.com>
Date: Thu, 31 May 2001 08:27:35 -0500
From: Eric Sandeen <sandeen@sgi.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: f.aide@gtmh.fr
CC: linux-xfs@oss.sgi.com
Subject: Re: new patches ?
References: <OFC13F8B33.84D3824D-ONC1256A5C.00514EC6@gtmh.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

f.aide@gtmh.fr wrote:

> I have already patched and compiled a 2.4.2 kernel with your patches and I
> really enjoy using my new xfs partitions... :-)
> Will there be any release of patches for 2.4.4 or later kernels? this is a
> crucial question since 2.4.2 has a nasty bug in its netfilter code and I
> relly would like to change to 2.4.5 ...


In general, patches will only be issued for stable point releases, 1.0,
1.0.1, etc.  Otherwise, it's just a CVS snapshot, which may or may not
even compile or boot.  


Bottom line: if you want stable XFS, use the point release patches, if
you want cutting edge, use CVS.  CVS is currently at 2.4.5.

-Eric

-- 
Eric Sandeen      XFS for Linux     http://oss.sgi.com/projects/xfs
sandeen@sgi.com   SGI, Inc.

From owner-linux-xfs@oss.sgi.com Thu May 31 06:46:45 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VDkjP12025
	for linux-xfs-outgoing; Thu, 31 May 2001 06:46:45 -0700
Received: from smtpgate.pcquote.com (smtpgate.hyperfeed.com [206.217.179.196])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VDkdh12022
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 06:46:40 -0700
Received: by smtpgate.hyperfeed.com with Internet Mail Service (5.5.2653.19)
	id <LC13V3LQ>; Thu, 31 May 2001 08:46:32 -0500
Received: from coredump.pcqt.com (198.206.236.19 [198.206.236.19]) by smtpgate.pcquote.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id LC13V3LP; Thu, 31 May 2001 08:46:23 -0500
Received: (qmail 4390 invoked by uid 1006); 31 May 2001 13:46:17 -0000
From: John Palkovic <jpalkovic@hyperfeed.com>
To: linux-xfs@oss.sgi.com
Subject: xfs cvsup offline
Date: 31 May 2001 08:46:17 -0500
Message-ID: <8166eheimu.fsf@coredump.pcqt.com>
Lines: 16
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

CVSup to linux-xfs.sgi.com is failing now for at least a day. Here's
my supfile:

  *default host=linux-xfs.sgi.com
  *default base=.
  *default release=cvs tag=.
  *default delete use-rel-suffix
  *default prefix=/u/palkovic/linux-2.4-xfs
  linux-xfs

-John

-- 
John Palkovic
Software Engineer
HyperFeed Technologies

From owner-linux-xfs@oss.sgi.com Thu May 31 07:07:55 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VE7tL12923
	for linux-xfs-outgoing; Thu, 31 May 2001 07:07:55 -0700
Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VE7nh12919
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:07:49 -0700
Received: from thebarn.com (nic-25-c96-156.mn.mediaone.net [24.25.96.156])
	by lips.borg.umn.edu (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id f4VE7laJ068249;
	Thu, 31 May 2001 09:07:48 -0500 (CDT)
Message-ID: <3B16502E.4EBE4E5E@thebarn.com>
Date: Thu, 31 May 2001 09:07:42 -0500
From: Russell Cattelan <cattelan@thebarn.com>
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: John Palkovic <jpalkovic@hyperfeed.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: xfs cvsup offline
References: <8166eheimu.fsf@coredump.pcqt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

John Palkovic wrote:

> CVSup to linux-xfs.sgi.com is failing now for at least a day. Here's
> my supfile:
>
>   *default host=linux-xfs.sgi.com
>   *default base=.
>   *default release=cvs tag=.
>   *default delete use-rel-suffix
>   *default prefix=/u/palkovic/linux-2.4-xfs
>   linux-xfs
>
> -John

Still working on getting the firewall port opened up.

>
>
> --
> John Palkovic
> Software Engineer
> HyperFeed Technologies

--
Russell Cattelan
cattelan@thebarn.com




From owner-linux-xfs@oss.sgi.com Thu May 31 07:08:23 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VE8N913016
	for linux-xfs-outgoing; Thu, 31 May 2001 07:08:23 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VE8Hh12997
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:08:17 -0700
Received: from babel.spoiled.org (babel.spoiled.org [212.84.234.227]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id HAA09207
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:08:13 -0700 (PDT)
	mail_from (list-linux.sgi.xfs@spoiled.org)
Received: (qmail 21893 invoked by uid 8); 31 May 2001 14:08:01 -0000
From: Juri Haberland <list-linux.sgi.xfs@spoiled.org>
Reply-To: Juri Haberland <juri@koschikode.com>
X-Newsgroups: spoiled.linux.sgi.xfs
Subject: Re: When'll XFS be part of Linux vanila or RedHat Linux.
Date: Thu, 31 May 2001 14:08:01 +0000 (UTC)
Organization: spoiled dot org
Lines: 23
Distribution: local
Message-ID: <news2mail-9f5j81$c1g$2@babel.spoiled.org>
References: <200105301938.f4UJcia19124@jen.americas.sgi.com>  <3B15BA11.B01037F2@ieee.org> <20010531071025.307CB125E6@rebutia.sweeney.demon.co.uk>
X-Complaints-To: newsmaster@spoiled.org
User-Agent: tin/1.4.4-20000803 ("Vet for the Insane") (UNIX) (OpenBSD/2.9 (i386))
To: linux-xfs@oss.sgi.com
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Keith Matthews <keith_m@sweeney.demon.co.uk> wrote:
> On Wed, 30 May 2001 23:27:13 -0400 Bryan J. Smith <Bryan J. Smith <b.j.smith@ieee.org>> wrote:
> 
> 
>> So far, RedHat and VALinux have snubbed ReiserFS because of its lack
>> of a traditional inode structure that has issues with some services
>> (like NFS).  They have shown support for Ext3.  Unfortunately, Ext3
>> is not available on 2.4 yet. 
> 
> No longer true - there was something about 2 weeks ago, a couple of
> other guys  have taken over from Stephen and ar porting it to 2.4
> 
> Unfortunately I've lost the URL, ISTR it was on sourceforge but
> wouldn't like to bet.

Have a look at http://www.uow.edu.au/~andrewm/linux/ext3/
or the cvs at gkernel.sourceforge.net.

Juri

-- 
Juri Haberland  <juri@koschikode.com> 


From owner-linux-xfs@oss.sgi.com Thu May 31 07:09:25 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VE9Pk13199
	for linux-xfs-outgoing; Thu, 31 May 2001 07:09:25 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VE9Jh13183
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:09:19 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id HAA01874
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:09:27 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2014087; Thu, 31 May 2001 09:08:01 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA59300; Thu, 31 May 2001 09:08:01 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VEArJ19951; Thu, 31 May 2001 09:10:53 -0500
Message-Id: <200105311410.f4VEArJ19951@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: John Palkovic <jpalkovic@hyperfeed.com>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs cvsup offline 
In-Reply-To: Message from John Palkovic <jpalkovic@hyperfeed.com> 
   of "31 May 2001 08:46:17 CDT." <8166eheimu.fsf@coredump.pcqt.com> 
Date: Thu, 31 May 2001 09:10:53 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> CVSup to linux-xfs.sgi.com is failing now for at least a day. Here's
> my supfile:
> 
>   *default host=linux-xfs.sgi.com
>   *default base=.
>   *default release=cvs tag=.
>   *default delete use-rel-suffix
>   *default prefix=/u/palkovic/linux-2.4-xfs
>   linux-xfs


The machines were moved behind a firewall, and not all the ports required are
open. You could try oss.sgi.com instead of linux-xfs, and failing that use 
regular cvs which is working.

Steve

> 
> -John
> 
> -- 
> John Palkovic
> Software Engineer
> HyperFeed Technologies



From owner-linux-xfs@oss.sgi.com Thu May 31 07:26:47 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEQll13836
	for linux-xfs-outgoing; Thu, 31 May 2001 07:26:47 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VEQXh13830
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:26:34 -0700
Received: from falka.mfa.kfki.hu (falka.mfa.kfki.hu [148.6.72.6]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA09141
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:26:32 -0700 (PDT)
	mail_from (dice@mfa.kfki.hu)
Received: from localhost (dice@localhost)
	by falka.mfa.kfki.hu (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id QAA06247;
	Thu, 31 May 2001 16:25:32 +0200
Date: Thu, 31 May 2001 16:25:32 +0200 (CEST)
From: Gergely Tamas <dice@mfa.kfki.hu>
To: Austin Gonyou <austin@coremetrics.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: 2.4.5 compiles, almost:(
In-Reply-To: <Pine.LNX.4.33.0105301519030.17597-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.32.0105311624310.5851-100000@falka.mfa.kfki.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi!

 > drivers/md/mddev.o: In function `__update_hardblocksize':
 > drivers/md/mddev.o(.text+0xaba1): undefined reference to
 > `get_hardblocksize'
 > drivers/md/mddev.o(.text+0xabed): undefined reference to
 > `get_hardblocksize'

Try the following patch. get_hardblocksize changed to get_hardsect_size a
while ago...

Gergely

--- linux-2.4.4/drivers/md/lvm.c.orig	Sun May  6 14:54:39 2001
+++ linux-2.4.4/drivers/md/lvm.c	Sun May  6 14:55:06 2001
@@ -1791,7 +1791,7 @@
 	int max_hardblocksize = 0, hardblocksize;

 	for (le = 0; le < lv->lv_allocated_le; le++) {
-		hardblocksize = get_hardblocksize(lv->lv_current_pe[le].dev);
+		hardblocksize = get_hardsect_size(lv->lv_current_pe[le].dev);
 		if (hardblocksize == 0)
 			hardblocksize = 512;
 		if (hardblocksize > max_hardblocksize)
@@ -1801,7 +1801,7 @@
 	if (lv->lv_access & LV_SNAPSHOT) {
 		for (e = 0; e < lv->lv_remap_end; e++) {
 			hardblocksize =
-				get_hardblocksize(
+				get_hardsect_size(
 					lv->lv_block_exception[e].rdev_new);
 			if (hardblocksize == 0)
 				hardblocksize = 512;


From owner-linux-xfs@oss.sgi.com Thu May 31 07:44:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEik514420
	for linux-xfs-outgoing; Thu, 31 May 2001 07:44:46 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VEidh14417
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:44:40 -0700
Received: from n05.sp.bs.dlr.de (n05.sp.bs.dlr.de [129.247.26.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA04609
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:44:03 -0700 (PDT)
	mail_from (Reiner.Suikat@dlr.de)
Received: from excsrv.bs.dlr.de (excsrv.bs.dlr.de [129.247.41.200])
	by n05.sp.bs.dlr.de (8.11.2/8.11.2) with ESMTP id f4VEhrE39884
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:43:53 +0200
Received: by excsrv.bs.dlr.de with Internet Mail Service (5.5.2650.21)
	id <K322VL01>; Thu, 31 May 2001 16:42:25 +0200
Message-ID: <E55B46CB134CD4119EEC00306E00702301318D@excsrv.bs.dlr.de>
From: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Compile error with latest CVS version fixed, now I get a kernel p
	anic on boot
Date: Thu, 31 May 2001 16:42:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks again for the hint, the aic7xxx module compiles fine with the
firmware bit enabled.

Howeverr, I still get a kernel panic on boot. Unfortunately, I don't have a
serial console available, so trying to get that output is a bit difficult
for me.

The kernel panics when "trying to unmount old root",
it tries to dereference a null pointer, and the very last thing that appears
after all the register contents and stack trace is
kernel panic: attempting to kill init!

any idea?

Regards
Reiner

From owner-linux-xfs@oss.sgi.com Thu May 31 07:53:05 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEr5v14908
	for linux-xfs-outgoing; Thu, 31 May 2001 07:53:05 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VEr1h14905
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:53:01 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03570
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:53:00 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA1990169; Thu, 31 May 2001 09:51:44 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA52107; Thu, 31 May 2001 09:51:44 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VEsam20211; Thu, 31 May 2001 09:54:36 -0500
Message-Id: <200105311454.f4VEsam20211@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Kalvinder Singh <ksingh@oz.agile.tv>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS over RAID 5 
In-Reply-To: Message from Kalvinder Singh <ksingh@oz.agile.tv> 
   of "Thu, 31 May 2001 09:34:29 +1000." <3B158385.8010800@oz.agile.tv> 
Date: Thu, 31 May 2001 09:54:36 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> Sorry to hear about all the layoffs. You guys have done a great job.
> 
> I have been running XFS over RAID 5. However, I heard that Martin was 
> still working on getting better performance out of XFS when RAID starts 
> to run in degraded mode.
> 
> Did I get my wires crossed and there was no such mini project?
> 
> What is the status of XFS and RAID 5?
> 
> Thanks for everything,
> Kal.

Well, there are probably things we can do in this direction, and Martin is
not totally gone, although he has been MIA for a few weeks now, I think he
is taking some time back in Denmark and is out of touch with email.

The key is to use buffer heads which cover a larger range if at all possible,
md and lvm both work by redirecting a buffer head to a new location, they
never split a buffer head into two. XFS has some 512 byte chunks of metadata
and the simplistic approach taken so far is that we do everything at this
size to avoid crossing boundaries with a buffer head. However, it would
be possible with some knowledge of the raid layout to say that a buffer
head woud not cross a disk boundary, and use larger ones. So for example
a striped volume with 4K boundaries would I think be safe to use a
single buffer head per page approach.

Not having spent too much time inside the md/lvm code, I do not know how
hard or easy working this out would be.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 31 07:53:44 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEris15014
	for linux-xfs-outgoing; Thu, 31 May 2001 07:53:44 -0700
Received: from mail.ocs.com.au (ppp0.ocs.com.au [203.34.97.3])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VErdh15006
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:53:40 -0700
Received: (qmail 13844 invoked from network); 31 May 2001 14:53:32 -0000
Received: from ocs3.ocs-net (192.168.255.3)
  by mail.ocs.com.au with SMTP; 31 May 2001 14:53:31 -0000
X-Mailer: exmh version 2.1.1 10/15/1999
From: Keith Owens <kaos@melbourne.sgi.com>
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version fixed, now I get a kernel p anic on boot 
In-reply-to: Your message of "Thu, 31 May 2001 16:42:22 +0200."
             <E55B46CB134CD4119EEC00306E00702301318D@excsrv.bs.dlr.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Jun 2001 00:53:29 +1000
Message-ID: <21015.991320809@ocs3.ocs-net>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 16:42:22 +0200, 
"Suikat, Reiner" <Reiner.Suikat@dlr.de> wrote:
>The kernel panics when "trying to unmount old root",
>it tries to dereference a null pointer, and the very last thing that appears

Sounds like a known bug in 2.4.5, fixed in 2.4.5-ac3.  See
http://www.mail-archive.com/linux-kernel%40vger.kernel.org/msg47378.html


From owner-linux-xfs@oss.sgi.com Thu May 31 07:56:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEuSZ15280
	for linux-xfs-outgoing; Thu, 31 May 2001 07:56:28 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VEuNh15275
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:56:23 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA03985
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:56:22 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id JAA2018704; Thu, 31 May 2001 09:55:05 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA77936; Thu, 31 May 2001 09:55:05 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VEvvM20224; Thu, 31 May 2001 09:57:57 -0500
Message-Id: <200105311457.f4VEvvM20224@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Compile error with latest CVS version fixed, now I get a kernel p anic on boot 
In-Reply-To: Message from "Suikat, Reiner" <Reiner.Suikat@dlr.de> 
   of "Thu, 31 May 2001 16:42:22 +0200." <E55B46CB134CD4119EEC00306E00702301318D@excsrv.bs.dlr.de> 
Date: Thu, 31 May 2001 09:57:57 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hmm, you may want to fall back to an older compiler - kgcc is available
in redhat 7.1 in the compat_egcs rpm. Various people have reported similar
problems on assorted architectures.

Sorry not to be of more help, but we are short handed right now, Eric is
moving from Texas to Minnesota, Ananth is in India, and I am actually at
home sick today.

Steve

> Thanks again for the hint, the aic7xxx module compiles fine with the
> firmware bit enabled.
> 
> Howeverr, I still get a kernel panic on boot. Unfortunately, I don't have a
> serial console available, so trying to get that output is a bit difficult
> for me.
> 
> The kernel panics when "trying to unmount old root",
> it tries to dereference a null pointer, and the very last thing that appears
> after all the register contents and stack trace is
> kernel panic: attempting to kill init!
> 
> any idea?
> 
> Regards
> Reiner



From owner-linux-xfs@oss.sgi.com Thu May 31 07:58:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VEwYP15557
	for linux-xfs-outgoing; Thu, 31 May 2001 07:58:34 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VEwRh15507
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:58:27 -0700
Received: from main.braxis.co.uk (main.braxis.co.uk [213.77.40.29]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA04286
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 07:57:42 -0700 (PDT)
	mail_from (kszysiu@braxis.co.uk)
Received: (from kszysiu@localhost)
	by main.braxis.co.uk (8.9.3/8.9.3) id QAA08980;
	Thu, 31 May 2001 16:56:51 +0200
Date: Thu, 31 May 2001 16:56:51 +0200
From: Krzysztof Rusocki <kszysiu@braxis.co.uk>
To: "Suikat, Reiner" <Reiner.Suikat@dlr.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Compile error with latest CVS version fixed, now I get a kernel p anic on boot
Message-ID: <20010531165651.B2531@main.braxis.co.uk>
References: <E55B46CB134CD4119EEC00306E00702301318D@excsrv.bs.dlr.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E55B46CB134CD4119EEC00306E00702301318D@excsrv.bs.dlr.de>; from Reiner.Suikat@dlr.de on Thu, May 31, 2001 at 04:42:22PM +0200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Hi Reiner,

I've issued such things while compiling using gcc-2.95.2 or gcc-2.95.3,
moving back to gcc-2.91.66 (aka egcs-1.1.2) solved such things.

But maybe it's not compiler related problem. I think that kdb output would
be a good source for xfs developers. Compile in KDB
(CONFIG_KDB,CONFIG_KALLSYMS,CONFIG_FRAME_POINTER) and really get a serial
console :)

Cheers,
Krzysztof


On Thu, May 31, 2001 at 04:42:22PM +0200, Suikat, Reiner wrote:
> Thanks again for the hint, the aic7xxx module compiles fine with the
> firmware bit enabled.
> 
> Howeverr, I still get a kernel panic on boot. Unfortunately, I don't have a
> serial console available, so trying to get that output is a bit difficult
> for me.
> 
> The kernel panics when "trying to unmount old root",
> it tries to dereference a null pointer, and the very last thing that appears
> after all the register contents and stack trace is
> kernel panic: attempting to kill init!
> 
> any idea?
> 
> Regards
> Reiner

From owner-linux-xfs@oss.sgi.com Thu May 31 08:06:38 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VF6co16028
	for linux-xfs-outgoing; Thu, 31 May 2001 08:06:38 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VF6Vh16022
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 08:06:31 -0700
Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id TAA01069
	for <linux-xfs@oss.sgi.com>; Wed, 30 May 2001 19:09:39 -0700 (PDT)
	mail_from (jkrahn@nc.rr.com)
Received: from nc.rr.com ([24.162.230.11]) by mail8.nc.rr.com  with Microsoft SMTPSVC(5.5.1877.687.68);
	 Wed, 30 May 2001 22:09:35 -0400
Message-ID: <3B15A7E0.BF08E07A@nc.rr.com>
Date: Wed, 30 May 2001 22:09:36 -0400
From: Joe Krahn <jkrahn@nc.rr.com>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.5-pre1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Files with zeros, crash, questions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I installed RH7.1/XFS on a system with a root aic7xxx scsi
drive and a DAC960. I did XFS for all partitions. The install
went smoothly. Everything worked great. Then, I rebooted
(no reason, a mistake actually...)

When it came back up, /etc/sysconfig/hwconf was replaced with
all zeros, the XFS log is corrupted, and it immediately gives
Oopses in nfsd. Not sure what happened, but these look like\
problems addressed earlier, and probably fixed in CVS.

A few questions:
Why do I get zero-filled files on a crash, but I never see
them on an SGI crash? Also, I never see it with ext2, which
probably leaves the previous contents for unsynced files
insteds of zeros. It would be nice if unsynced XFS would
leave the previous contents for unsynced files, and it would
also be good to store a list of suspect files on reboot.

It seems like almost half the questions stem from devfs
differences, which probably also is the culprit for install
problems with DAC960 root. Maybe devfs should be an optional
feature.

Thanks, Joe Krahn

From owner-linux-xfs@oss.sgi.com Thu May 31 08:29:42 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VFTgo16849
	for linux-xfs-outgoing; Thu, 31 May 2001 08:29:42 -0700
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VFTbh16835
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 08:29:37 -0700
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 706431E248; Thu, 31 May 2001 17:29:31 +0200 (MEST)
Date: Thu, 31 May 2001 17:29:23 +0200
From: Andi Kleen <ak@suse.de>
To: Joe Krahn <jkrahn@nc.rr.com>
Cc: linux-xfs@oss.sgi.com
Subject: Re: Files with zeros, crash, questions
Message-ID: <20010531172923.A8190@gruyere.muc.suse.de>
References: <3B15A7E0.BF08E07A@nc.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B15A7E0.BF08E07A@nc.rr.com>; from jkrahn@nc.rr.com on Wed, May 30, 2001 at 10:09:36PM -0400
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Wed, May 30, 2001 at 10:09:36PM -0400, Joe Krahn wrote:
> A few questions:
> Why do I get zero-filled files on a crash, but I never see
> them on an SGI crash? Also, I never see it with ext2, which
> probably leaves the previous contents for unsynced files
> insteds of zeros. It would be nice if unsynced XFS would
> leave the previous contents for unsynced files, and it would
> also be good to store a list of suspect files on reboot.

XFS/Irix supports "unwritten extents", XFS/Linux doesn't and the 
not yet flushed but extents turn into zeroed holes after crash. See the
"might have found a bug" thread some time ago for more information.

-Andi

From owner-linux-xfs@oss.sgi.com Thu May 31 09:05:22 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VG5Ms19543
	for linux-xfs-outgoing; Thu, 31 May 2001 09:05:22 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VG5Gh19534
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 09:05:16 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4VG2M418672;
	Thu, 31 May 2001 11:02:22 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 31 May 2001 11:02:22 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Gergely Tamas <dice@mfa.kfki.hu>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: 2.4.5 compiles, almost:(
In-Reply-To: <Pine.LNX.4.32.0105311624310.5851-100000@falka.mfa.kfki.hu>
Message-ID: <Pine.LNX.4.33.0105311102160.13367-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

THanks for the patch!

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 31 May 2001, Gergely Tamas wrote:

> Hi!
>
>  > drivers/md/mddev.o: In function `__update_hardblocksize':
>  > drivers/md/mddev.o(.text+0xaba1): undefined reference to
>  > `get_hardblocksize'
>  > drivers/md/mddev.o(.text+0xabed): undefined reference to
>  > `get_hardblocksize'
>
> Try the following patch. get_hardblocksize changed to get_hardsect_size a
> while ago...
>
> Gergely
>
> --- linux-2.4.4/drivers/md/lvm.c.orig	Sun May  6 14:54:39 2001
> +++ linux-2.4.4/drivers/md/lvm.c	Sun May  6 14:55:06 2001
> @@ -1791,7 +1791,7 @@
>  	int max_hardblocksize = 0, hardblocksize;
>
>  	for (le = 0; le < lv->lv_allocated_le; le++) {
> -		hardblocksize = get_hardblocksize(lv->lv_current_pe[le].dev);
> +		hardblocksize = get_hardsect_size(lv->lv_current_pe[le].dev);
>  		if (hardblocksize == 0)
>  			hardblocksize = 512;
>  		if (hardblocksize > max_hardblocksize)
> @@ -1801,7 +1801,7 @@
>  	if (lv->lv_access & LV_SNAPSHOT) {
>  		for (e = 0; e < lv->lv_remap_end; e++) {
>  			hardblocksize =
> -				get_hardblocksize(
> +				get_hardsect_size(
>  					lv->lv_block_exception[e].rdev_new);
>  			if (hardblocksize == 0)
>  				hardblocksize = 512;
>


From owner-linux-xfs@oss.sgi.com Thu May 31 09:59:50 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VGxoe21185
	for linux-xfs-outgoing; Thu, 31 May 2001 09:59:50 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VGxkh21180
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 09:59:46 -0700
Received: from cyclone.stortek.com (cyclone.stortek.com [129.80.22.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAB04893
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 09:59:43 -0700 (PDT)
	mail_from (coumop@europe.stortek.com)
Received: from cyclone.stortek.com (localhost [127.0.0.1])
	by cyclone.stortek.com (8.9.3/8.9.3) with ESMTP id KAA22869
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:59:42 -0600 (MDT)
Received: from vinson-atm6.stortek.com (root@vinson.stortek.com [129.80.40.134] (may be forged))
	by cyclone.stortek.com (8.9.3/8.9.3) with ESMTP id KAA22848
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:59:41 -0600 (MDT)
Received: from [129.80.178.150] ([129.80.178.150])
	by vinson-atm6.stortek.com (8.9.3/8.9.3) with ESMTP id KAA00280
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:59:40 -0600 (MDT)
Received: from eur-bridge.europe.stortek.com (unverified) by 
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T53dc658ae58150b296764@> for <linux-xfs@oss.sgi.com>;
 Thu, 31 May 2001 17:58:47 +0100
Received: by eur-bridge.europe.stortek.com with Internet Mail Service (5.5.2653.19)
	id <L9BAPTRR>; Thu, 31 May 2001 17:50:49 +0100
Message-ID: <004C7365D3FF4644A4D5F232CFD23B50656F07@FRA-MSG01.europe.stortek.com>
From: "Coumoul, Philippe" <coumop@europe.stortek.com>
To: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Path failover with xfs on linux
Date: Thu, 31 May 2001 17:59:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hi,

I m looking for a path failover software solution to secure acces from Red
Hat 7.x server to an external Raid Storage Subsystem.
I ve seen that there is not XLV on XFS for Linux, but is there a failover
possibility without XLV ?

Thanks

Phil


From owner-linux-xfs@oss.sgi.com Thu May 31 10:17:10 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VHHAI22090
	for linux-xfs-outgoing; Thu, 31 May 2001 10:17:10 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VHH5h22087
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:17:05 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07251
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:17:13 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2020272; Thu, 31 May 2001 12:15:47 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA56756; Thu, 31 May 2001 12:15:47 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VHIcN25368; Thu, 31 May 2001 12:18:38 -0500
Message-Id: <200105311718.f4VHIcN25368@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Coumoul, Philippe" <coumop@europe.stortek.com>
cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Path failover with xfs on linux 
In-Reply-To: Message from "Coumoul, Philippe" <coumop@europe.stortek.com> 
   of "Thu, 31 May 2001 17:59:18 BST." <004C7365D3FF4644A4D5F232CFD23B50656F07@FRA-MSG01.europe.stortek.com> 
Date: Thu, 31 May 2001 12:18:38 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Hi,
> 
> I m looking for a path failover software solution to secure acces from Red
> Hat 7.x server to an external Raid Storage Subsystem.
> I ve seen that there is not XLV on XFS for Linux, but is there a failover
> possibility without XLV ?
> 
> Thanks
> 
> Phil

This question might be better directed at the linux kernel list, hardware
failover is usually invisible to the filesystem, being handled at the
block layer. SGI does have ports of some of the Irix SCSI code which
includes failover capability for certain device types, but I cannot
say when or how this would be available.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 31 10:22:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VHMVd22552
	for linux-xfs-outgoing; Thu, 31 May 2001 10:22:31 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VHMRh22545
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:22:28 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id TAA1206729
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 19:22:24 +0200 (CEST)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id MAA2020574 for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 12:21:07 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA48027 for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 12:21:07 -0500 (CDT)
From: Steve Lord <lord@sgi.com>
Received: by jen.americas.sgi.com (8.11.0/SGI-client-1.7) id f4VHNxY25457; Thu, 31 May 2001 12:23:59 -0500
Message-Id: <200105311723.f4VHNxY25457@jen.americas.sgi.com>
Date: Thu, 31 May 2001 12:23:59 -0500
Subject: TAKE - code cleanup
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Not worth a cvs update to get this.

Date:  Thu May 31 10:20:34 PDT 2001
Workarea:  jen.americas.sgi.com:/src/lord/xfs-linux.2.4

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96168a
linux/fs/xfs/linux/xfs_lrw.c - 1.100
	- Tidy up some write path code to make reuse by CXFS simpler - no
	  functional change to XFS.



From owner-linux-xfs@oss.sgi.com Thu May 31 10:45:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VHjWe23840
	for linux-xfs-outgoing; Thu, 31 May 2001 10:45:32 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VHjSh23831
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 10:45:28 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4VHgJw20080;
	Thu, 31 May 2001 12:42:19 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 31 May 2001 12:42:19 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Steve Lord <lord@sgi.com>
cc: "Coumoul, Philippe" <coumop@europe.stortek.com>,
   "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: Re: Path failover with xfs on linux 
In-Reply-To: <200105311718.f4VHIcN25368@jen.americas.sgi.com>
Message-ID: <Pine.LNX.4.33.0105311242080.13367-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

SteelEye perhaps? Not free, but seems to work.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 31 May 2001, Steve Lord wrote:

> > Hi,
> >
> > I m looking for a path failover software solution to secure acces from Red
> > Hat 7.x server to an external Raid Storage Subsystem.
> > I ve seen that there is not XLV on XFS for Linux, but is there a failover
> > possibility without XLV ?
> >
> > Thanks
> >
> > Phil
>
> This question might be better directed at the linux kernel list, hardware
> failover is usually invisible to the filesystem, being handled at the
> block layer. SGI does have ports of some of the Irix SCSI code which
> includes failover capability for certain device types, but I cannot
> say when or how this would be available.
>
> Steve
>


From owner-linux-xfs@oss.sgi.com Thu May 31 13:07:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VK7kC04578
	for linux-xfs-outgoing; Thu, 31 May 2001 13:07:46 -0700
Received: from post.aecom.yu.edu (post.aecom.yu.edu [129.98.1.4])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VK7hh04568
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:07:43 -0700
Received: from [129.98.91.150] (usseinstein.aecom.yu.edu [129.98.91.150])
	by post.aecom.yu.edu (8.9.3/8.9.3) with ESMTP id QAA07523
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:07:37 -0400 (EDT)
Mime-Version: 1.0
X-Sender: mvolaski@mailserver.aecom.yu.edu
Message-Id: <a05100303b73c4a85db5f@[129.98.91.150]>
Date: Thu, 31 May 2001 16:07:35 -0400
To: linux-xfs@oss.sgi.com
From: Maurice Volaski <mvolaski@aecom.yu.edu>
Subject: XFS: SGI or Linux
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

I know this is an unusual question for the list, but I hoping to get 
the perspective of people who are on both sides of the fence...
The endpoint is a highly stable box to serve files (appleshare, smb 
and maybe nfs) from a hardware raid (up to 2TB).
If one had a choice between a reasonably equipped PC with the latest 
Linux and XFS versus a new SGI box (similarly configured) running the 
latest IRIX (which has XFS), which one would you choose? Would you 
change your answer in six months?
-- 

Maurice Volaski, mvolaski@aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

From owner-linux-xfs@oss.sgi.com Thu May 31 13:27:37 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VKRb006767
	for linux-xfs-outgoing; Thu, 31 May 2001 13:27:37 -0700
Received: from pipt.oz.cc.utah.edu (jdr1529@pipt.oz.cc.utah.edu [155.99.2.7])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VKRXh06750
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:27:33 -0700
Received: from localhost (jdr1529@localhost)
	by pipt.oz.cc.utah.edu (8.9.2/8.9.2) with ESMTP id OAA11325;
	Thu, 31 May 2001 14:27:27 -0600 (MDT)
Date: Thu, 31 May 2001 14:27:26 -0600 (MDT)
From: james rich <james.rich@m.cc.utah.edu>
To: Maurice Volaski <mvolaski@aecom.yu.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: XFS: SGI or Linux
In-Reply-To: <a05100303b73c4a85db5f@[129.98.91.150]>
Message-ID: <Pine.GSO.4.05.10105311420590.25565-100000@pipt.oz.cc.utah.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001, Maurice Volaski wrote:

> The endpoint is a highly stable box to serve files (appleshare, smb 
> and maybe nfs) from a hardware raid (up to 2TB).
> If one had a choice between a reasonably equipped PC with the latest 
> Linux and XFS versus a new SGI box (similarly configured) running the 
> latest IRIX (which has XFS), which one would you choose? Would you 
> change your answer in six months?

It depends on how much demand you put on that server.  You can get a
machine from SGI that can do amazing amount of processing and file serving
- far beyond that of x86 hardware.  But if you only have 20-80 (or so -
I'm just guessing at numbers here) people use x86 hardware and save some
cash.  You can even get it from SGI who understands XFS.  That might be a
plus if anything goes wrong.  A new Itanium machine from SGI might be just
what you are looking for.  On the other hand VA linux has some cool stuff
that allows you to increase your hardware modularly as your needs increase
(but no XFS from VA - have to do it yourself).

Of course you could just get a new Origin....

James Rich
james.rich@m.cc.utah.edu


From owner-linux-xfs@oss.sgi.com Thu May 31 13:33:51 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VKXpg08122
	for linux-xfs-outgoing; Thu, 31 May 2001 13:33:51 -0700
Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VKXmh08103
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:33:48 -0700
Received: from engr.colostate.edu (wrigley_field.engr.colostate.edu [129.82.224.14])
	by goku.engr.colostate.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4VKLKOS023195
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:21:20 -0600 (MDT)
Message-ID: <3B16A7AE.CE7A495E@engr.colostate.edu>
Date: Thu, 31 May 2001 14:21:02 -0600
From: "C. J. Keist" <cjay@engr.colostate.edu>
Organization: Colorado State University
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Log file size?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Is there a standard formula on how to determine what log file size for
xfs on a given file system size?
I'll be looking a creating a 500Gb size xfs file system.

Thanks...
-- 
C. J. Keist                     Email: cjay@engr.colostate.edu
UNIX/Network Manager            Phone: 970-491-0630
Engineering Network Services    Fax:   970-491-2465
College of Engineering, CSU
Ft. Collins, CO 80523-1301

From owner-linux-xfs@oss.sgi.com Thu May 31 13:36:52 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VKaqq10184
	for linux-xfs-outgoing; Thu, 31 May 2001 13:36:52 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VKamh10118
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:36:48 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA09758
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:36:43 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id NAA24302
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:36:46 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 31 May 2001 13:36:35 -0700
Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id NAA159638;
	Thu, 31 May 2001 13:36:35 -0700
Message-Id: <3B16AB52.6090607@pipcws.ca.boeing.com>
Date: Thu, 31 May 2001 13:36:34 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Maurice Volaski <mvolaski@aecom.yu.edu>
CC: linux-xfs@oss.sgi.com
Subject: Re: XFS: SGI or Linux
References: <a05100303b73c4a85db5f@[129.98.91.150]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Maurice Volaski wrote:

> I know this is an unusual question for the list, but I hoping to get the 
> perspective of people who are on both sides of the fence...
> The endpoint is a highly stable box to serve files (appleshare, smb and 
> maybe nfs) from a hardware raid (up to 2TB).
> If one had a choice between a reasonably equipped PC with the latest 
> Linux and XFS versus a new SGI box (similarly configured) running the 
> latest IRIX (which has XFS), which one would you choose? Would you 
> change your answer in six months?

This depends on what you're going to use the box for, and what the loads 
will be (how many users, how much smb/nfs/apple traffic will there be?). 
If the loads will be high (200+ users, then you might do well to look at 
a risc solution (Be that SGI/IBM/HP/Sun ...). If the loads will be low, 
then you can save some cash, and use Intel hardware.

Personally, If I was just looking to build a disk farm, with high 
capacity, I'd look at either an HP, or possibly a Sun solution (disk 
farms really aren't SGI's strength.. (sorry SGI!).

So the answer I'd give is:
There's not enough information here to give an answer. :)

Ric



From owner-linux-xfs@oss.sgi.com Thu May 31 13:52:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VKqGS15449
	for linux-xfs-outgoing; Thu, 31 May 2001 13:52:16 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VKqCh15431
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 13:52:12 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id QAA23300;
	Thu, 31 May 2001 16:52:09 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Thu, 31 May 2001 16:52:09 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: "C. J. Keist" <cjay@engr.colostate.edu>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: Log file size?
In-Reply-To: <3B16A7AE.CE7A495E@engr.colostate.edu>
Message-ID: <Pine.LNX.4.30.0105311647420.22473-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 at 2:21pm, C. J. Keist wrote

> Is there a standard formula on how to determine what log file size for
> xfs on a given file system size?
> I'll be looking a creating a 500Gb size xfs file system.
>
I asked the same question back in March (for a 560GB hardware IDE-SCSI
RAID), and Steve Lord suggested 16384b or 32768b.  There was mention of
adding heuristics to mfks.xfs for this at some point, but I don't recall
seeing any TAKEs for that...

Steve also suggested mounting with -o logbufs=8 if you expect heavy
traffic.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University



From owner-linux-xfs@oss.sgi.com Thu May 31 14:10:46 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLAk718370
	for linux-xfs-outgoing; Thu, 31 May 2001 14:10:46 -0700
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLAfh18353
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:10:41 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id OAA05436
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:10:49 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id QAA2023860; Thu, 31 May 2001 16:09:18 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA09791; Thu, 31 May 2001 16:09:18 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VLC8E07613; Thu, 31 May 2001 16:12:08 -0500
Message-Id: <200105312112.f4VLC8E07613@jen.americas.sgi.com>
To: Joshua Baker-LePain <jlb17@duke.edu>
cc: "C. J. Keist" <cjay@engr.colostate.edu>, linux-xfs@oss.sgi.com
Subject: Re: Log file size? 
References: <Pine.LNX.4.30.0105311647420.22473-100000@chaos.egr.duke.edu>
Comments: In-reply-to Joshua Baker-LePain <jlb17@duke.edu>
   message dated "Thu, 31 May 2001 16:52:09 -0400."
Date: Thu, 31 May 2001 16:12:08 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> On Thu, 31 May 2001 at 2:21pm, C. J. Keist wrote
> 
> > Is there a standard formula on how to determine what log file size for
> > xfs on a given file system size?
> > I'll be looking a creating a 500Gb size xfs file system.
> >
> I asked the same question back in March (for a 560GB hardware IDE-SCSI
> RAID), and Steve Lord suggested 16384b or 32768b.  There was mention of
> adding heuristics to mfks.xfs for this at some point, but I don't recall
> seeing any TAKEs for that...
> 
> Steve also suggested mounting with -o logbufs=8 if you expect heavy
> traffic.
> 
> -- 
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University
> 

We have done some more thinking about this since then, and the heuristics
are in the latest mkfs, but I do not think it will bump the log size for
a filesystem this small ;-), it probably does not start until you are
in the terabyte range.

Anyway, the size of the log (those are 4K blocks by the way) governs
how much metadata you can have in modified state without having to
flush it to disk. A bigger log means there will be more occasions
when you do not end up in what we call tail pushing where each new
transaction going into the filesystem has to push some metadata
out to disk before it can get log space. Of course, constant sustained
activity can always get you there - unless you disk runs at memory
speeds. So a bigger log makes the filesystem run faster more of the
time, it also slows down how long it takes to mount, especially if
recovery is involved. You pays your money and takes your choice.

Log size is not a function of filesystem size, but a function of how
much metadata is changing per second.

I would maybe go for 4096b (which is 16 Mbytes) for a fairly active
large filesystem (I am calling yours large), but you might want to
benchmark a bit if you really care, mkfs will not take too long to
run (there are no inodes to create).

The iclog buffers is also useful - it represents how many log writes
can be in flight to disk at once. If all your buffers are in transit
then transactions will get backed up waiting for them.

Steve


From owner-linux-xfs@oss.sgi.com Thu May 31 14:12:16 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLCGi18817
	for linux-xfs-outgoing; Thu, 31 May 2001 14:12:16 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLCCh18806
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:12:12 -0700
Received: from blv-av-01.boeing.com ([192.54.3.60])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA26946
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:12:07 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA25798
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:12:09 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 31 May 2001 14:12:03 -0700
Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA158048;
	Thu, 31 May 2001 14:12:02 -0700
Message-Id: <3B16B3A2.4040901@pipcws.ca.boeing.com>
Date: Thu, 31 May 2001 14:12:02 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Joshua Baker-LePain <jlb17@duke.edu>
CC: "C. J. Keist" <cjay@engr.colostate.edu>, linux-xfs@oss.sgi.com
Subject: Re: Log file size?
References: <Pine.LNX.4.30.0105311647420.22473-100000@chaos.egr.duke.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Joshua Baker-LePain wrote:

> On Thu, 31 May 2001 at 2:21pm, C. J. Keist wrote
> 
> 
>>Is there a standard formula on how to determine what log file size for
>>xfs on a given file system size?
>>I'll be looking a creating a 500Gb size xfs file system.
>>
>>
> I asked the same question back in March (for a 560GB hardware IDE-SCSI
> RAID), and Steve Lord suggested 16384b or 32768b.  There was mention of
> adding heuristics to mfks.xfs for this at some point, but I don't recall
> seeing any TAKEs for that...
> 
> Steve also suggested mounting with -o logbufs=8 if you expect heavy
> traffic.
> 
> 

Whoa!
Did I miss something BIG here? I thought that the log was created 
automatically when you create the filesystem. Is that not true?
I have a machine at home purring away on LVM/XFS, and I never manually 
created a log file.

Can someone shed some more lite on this?

Ric



From owner-linux-xfs@oss.sgi.com Thu May 31 14:16:48 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLGme19800
	for linux-xfs-outgoing; Thu, 31 May 2001 14:16:48 -0700
Received: from chaos.egr.duke.edu (IDENT:root@chaos.egr.duke.edu [152.3.195.82])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLGih19794
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:16:45 -0700
Received: from localhost (jlb@localhost)
	by chaos.egr.duke.edu (8.9.3/8.9.3) with ESMTP id RAA23397;
	Thu, 31 May 2001 17:16:32 -0400
X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs
Date: Thu, 31 May 2001 17:16:32 -0400 (EDT)
From: Joshua Baker-LePain <jlb17@duke.edu>
X-Sender:  <jlb@chaos.egr.duke.edu>
To: Ric Tibbetts <ric@pipcws.ca.boeing.com>
cc: "C. J. Keist" <cjay@engr.colostate.edu>, <linux-xfs@oss.sgi.com>
Subject: Re: Log file size?
In-Reply-To: <3B16B3A2.4040901@pipcws.ca.boeing.com>
Message-ID: <Pine.LNX.4.30.0105311714210.22473-100000@chaos.egr.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

On Thu, 31 May 2001 at 2:12pm, Ric Tibbetts wrote

> Whoa!
> Did I miss something BIG here? I thought that the log was created
> automatically when you create the filesystem. Is that not true?
> I have a machine at home purring away on LVM/XFS, and I never manually
> created a log file.
>
The log *is* created automatically (breathe, Ric... ;), but the default
size is 1000b.  All we are talking about is asking mkfs to make it bigger
than the default.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University



From owner-linux-xfs@oss.sgi.com Thu May 31 14:21:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLLT420744
	for linux-xfs-outgoing; Thu, 31 May 2001 14:21:29 -0700
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [192.161.36.5])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLLQh20738
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:21:26 -0700
Received: from blv-av-02.boeing.com ([192.54.3.92])
	by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA09127
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:21:18 -0700 (PDT)
Received: from blv-hub-01.boeing.com (localhost [127.0.0.1])
	by blv-av-02.boeing.com (8.9.3/8.9.2/MBS-AV-01) with ESMTP id OAA23487
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:21:16 -0700 (PDT)
Received: from pipcws.ca.boeing.com by blv-hub-01.boeing.com with ESMTP; Thu, 31 May 2001 14:21:08 -0700
Received: from pipcws.ca.boeing.com (e218766.evt.boeing.com [136.203.14.68])
	by pipcws.ca.boeing.com (AIX4.3/8.9.3/8.9.3-B1) with ESMTP id OAA51906;
	Thu, 31 May 2001 14:21:07 -0700
Message-Id: <3B16B5C3.9090906@pipcws.ca.boeing.com>
Date: Thu, 31 May 2001 14:21:07 -0700
From: Ric Tibbetts <ric@pipcws.ca.boeing.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9) Gecko/20010505
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Joshua Baker-LePain <jlb17@duke.edu>
CC: "C. J. Keist" <cjay@engr.colostate.edu>, linux-xfs@oss.sgi.com
Subject: Re: Log file size?
References: <Pine.LNX.4.30.0105311714210.22473-100000@chaos.egr.duke.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Joshua Baker-LePain wrote:

> On Thu, 31 May 2001 at 2:12pm, Ric Tibbetts wrote
> 
> 
>>Whoa!
>>Did I miss something BIG here? I thought that the log was created
>>automatically when you create the filesystem. Is that not true?
>>I have a machine at home purring away on LVM/XFS, and I never manually
>>created a log file.
>>
>>
> The log *is* created automatically (breathe, Ric... ;), but the default
> size is 1000b.  All we are talking about is asking mkfs to make it bigger
> than the default.
> 
> 

Whew.. (drawing a deep breath!).
Thanks Josh!  I really expected it was, but I got caught up in the 
moment there. :)

Ric



From owner-linux-xfs@oss.sgi.com Thu May 31 14:23:21 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLNLA21227
	for linux-xfs-outgoing; Thu, 31 May 2001 14:23:21 -0700
Received: from tsunami.reflectively.net (qmailr@tsunami.reflectively.net [216.85.76.11])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLNIh21221
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:23:18 -0700
Received: (qmail 25237 invoked by uid 1096); 31 May 2001 21:23:16 -0000
Date: 31 May 2001 21:23:16 -0000
Message-ID: <20010531212316.25236.qmail@tsunami.reflectively.net>
To: linux-xfs@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-URL: http://oss.sgi.com/projects/xfs/1.0_release.html
X-Mailer: Lynx, Version 2.8.3rel.1
X-Personal_name: George B.
From: georgeb@unitbv.ro
Subject: does it work on 2.4.4
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

i user kernel 2.4.4 
i wanna know if xfs works on it.
10x


From owner-linux-xfs@oss.sgi.com Thu May 31 14:49:32 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLnWe25095
	for linux-xfs-outgoing; Thu, 31 May 2001 14:49:32 -0700
Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLnPh25077
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:49:25 -0700
Received: from engr.colostate.edu (wrigley_field.engr.colostate.edu [129.82.224.14])
	by goku.engr.colostate.edu (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id f4VLnJOS029965;
	Thu, 31 May 2001 15:49:19 -0600 (MDT)
Message-ID: <3B16BC4C.5ECC4DA7@engr.colostate.edu>
Date: Thu, 31 May 2001 15:49:00 -0600
From: "C. J. Keist" <cjay@engr.colostate.edu>
Organization: Colorado State University
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Lord <lord@sgi.com>
CC: linux-xfs@oss.sgi.com
Subject: Re: Log file size?
References: <Pine.LNX.4.30.0105311647420.22473-100000@chaos.egr.duke.edu> <200105312112.f4VLC8E07613@jen.americas.sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Thanks, this helps explain what the log is actually doing.  The FAQ's
says that xfs for linux is still largely experimental and should not be
put on any production system.  Is anyone running xfs on a 500+Gb file
system with a fairly heavy user load?  I would be interested in your
successes/failers with xfs.

Thanks...

Steve Lord wrote:
> 
> > On Thu, 31 May 2001 at 2:21pm, C. J. Keist wrote
> >
> > > Is there a standard formula on how to determine what log file size for
> > > xfs on a given file system size?
> > > I'll be looking a creating a 500Gb size xfs file system.
> > >
> > I asked the same question back in March (for a 560GB hardware IDE-SCSI
> > RAID), and Steve Lord suggested 16384b or 32768b.  There was mention of
> > adding heuristics to mfks.xfs for this at some point, but I don't recall
> > seeing any TAKEs for that...
> >
> > Steve also suggested mounting with -o logbufs=8 if you expect heavy
> > traffic.
> >
> > --
> > Joshua Baker-LePain
> > Department of Biomedical Engineering
> > Duke University
> >
> 
> We have done some more thinking about this since then, and the heuristics
> are in the latest mkfs, but I do not think it will bump the log size for
> a filesystem this small ;-), it probably does not start until you are
> in the terabyte range.
> 
> Anyway, the size of the log (those are 4K blocks by the way) governs
> how much metadata you can have in modified state without having to
> flush it to disk. A bigger log means there will be more occasions
> when you do not end up in what we call tail pushing where each new
> transaction going into the filesystem has to push some metadata
> out to disk before it can get log space. Of course, constant sustained
> activity can always get you there - unless you disk runs at memory
> speeds. So a bigger log makes the filesystem run faster more of the
> time, it also slows down how long it takes to mount, especially if
> recovery is involved. You pays your money and takes your choice.
> 
> Log size is not a function of filesystem size, but a function of how
> much metadata is changing per second.
> 
> I would maybe go for 4096b (which is 16 Mbytes) for a fairly active
> large filesystem (I am calling yours large), but you might want to
> benchmark a bit if you really care, mkfs will not take too long to
> run (there are no inodes to create).
> 
> The iclog buffers is also useful - it represents how many log writes
> can be in flight to disk at once. If all your buffers are in transit
> then transactions will get backed up waiting for them.
> 
> Steve

-- 
C. J. Keist                     Email: cjay@engr.colostate.edu
UNIX/Network Manager            Phone: 970-491-0630
Engineering Network Services    Fax:   970-491-2465
College of Engineering, CSU
Ft. Collins, CO 80523-1301

From owner-linux-xfs@oss.sgi.com Thu May 31 14:51:35 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VLpZW25616
	for linux-xfs-outgoing; Thu, 31 May 2001 14:51:35 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VLpVh25601
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 14:51:31 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4VLmnU24265;
	Thu, 31 May 2001 16:48:49 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 31 May 2001 16:48:49 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <georgeb@unitbv.ro>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: does it work on 2.4.4
In-Reply-To: <20010531212316.25236.qmail@tsunami.reflectively.net>
Message-ID: <Pine.LNX.4.33.0105311648280.24235-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

latest kernel is 2.4.5, previous kernel was 2.4.4. Patches are currently
available for both.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On 31 May 2001 georgeb@unitbv.ro wrote:

> i user kernel 2.4.4
> i wanna know if xfs works on it.
> 10x
>


From owner-linux-xfs@oss.sgi.com Thu May 31 15:09:14 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VM9EP28685
	for linux-xfs-outgoing; Thu, 31 May 2001 15:09:14 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VM9Ah28665
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 15:09:10 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f4VM6Yt24422;
	Thu, 31 May 2001 17:06:34 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Thu, 31 May 2001 17:06:34 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: <georgeb@unitbv.ro>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: does it work on 2.4.4
In-Reply-To: <Pine.LNX.4.33.0105311648280.24235-100000@UberGeek.coremetrics.com>
Message-ID: <Pine.LNX.4.33.0105311706190.24235-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Woops..No 2.4.5 yet..but 2.4.4 is still out there.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 31 May 2001, Austin Gonyou wrote:

> latest kernel is 2.4.5, previous kernel was 2.4.4. Patches are currently
> available for both.
>
>


From owner-linux-xfs@oss.sgi.com Thu May 31 15:11:57 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VMBvV29403
	for linux-xfs-outgoing; Thu, 31 May 2001 15:11:57 -0700
Received: from sa-bwmail1.storageapps.com (smtp.storageapps.com [63.101.83.13])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VMBrh29392
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 15:11:53 -0700
Received: by SA-BWMAIL1 with Internet Mail Service (5.5.2653.19)
	id <L82P0KGP>; Thu, 31 May 2001 18:11:56 -0400
Message-ID: <23D04BDBA646D411BDDD00D0B774B539028C8971@SA-BWMAIL1>
From: "Christian, Chip" <chip.christian@storageapps.com>
To: "'Steve Lord'" <lord@sgi.com>,
   "Coumoul, Philippe"
	 <coumop@europe.stortek.com>
Cc: "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: RE: Path failover with xfs on linux 
Date: Thu, 31 May 2001 18:11:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

RedHat 7.1 has a multipath block driver that has worked well in our testing.  We put XFS on top.  

-----Original Message-----
From: Steve Lord [mailto:lord@sgi.com]
Sent: Thursday, May 31, 2001 13:19
To: Coumoul, Philippe
Cc: 'linux-xfs@oss.sgi.com'
Subject: Re: Path failover with xfs on linux 


> Hi,
> 
> I m looking for a path failover software solution to secure acces from Red
> Hat 7.x server to an external Raid Storage Subsystem.
> I ve seen that there is not XLV on XFS for Linux, but is there a failover
> possibility without XLV ?
> 
> Thanks
> 
> Phil

This question might be better directed at the linux kernel list, hardware
failover is usually invisible to the filesystem, being handled at the
block layer. SGI does have ports of some of the Irix SCSI code which
includes failover capability for certain device types, but I cannot
say when or how this would be available.

Steve


From owner-linux-xfs@oss.sgi.com Thu May 31 15:29:56 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VMTu200315
	for linux-xfs-outgoing; Thu, 31 May 2001 15:29:56 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VMTmh32765
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 15:29:49 -0700
Received: from zeus-fddi.americas.sgi.com (128-162-8-103.americas.sgi.com [128.162.8.103]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA02014
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 15:29:42 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id RAA2005755; Thu, 31 May 2001 17:28:24 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA26123; Thu, 31 May 2001 17:26:20 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VMT9T14628; Thu, 31 May 2001 17:29:09 -0500
Message-Id: <200105312229.f4VMT9T14628@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Austin Gonyou <austin@coremetrics.com>
cc: georgeb@unitbv.ro, linux-xfs@oss.sgi.com
Subject: Re: does it work on 2.4.4 
In-Reply-To: Message from Austin Gonyou <austin@coremetrics.com> 
   of "Thu, 31 May 2001 17:06:34 CDT." <Pine.LNX.4.33.0105311706190.24235-100000@UberGeek.coremetrics.com> 
Date: Thu, 31 May 2001 17:29:09 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

> Woops..No 2.4.5 yet..but 2.4.4 is still out there.

Looking into it now, not sure I am going to put out patches in the same
manner as Russell did .....

Steve

> 
> -- 
> Austin Gonyou
> Systems Architect, CCNA
> Coremetrics, Inc.
> Phone: 512-796-9023
> email: austin@coremetrics.com
> 
> On Thu, 31 May 2001, Austin Gonyou wrote:
> 
> > latest kernel is 2.4.5, previous kernel was 2.4.4. Patches are currently
> > available for both.
> >
> >



From owner-linux-xfs@oss.sgi.com Thu May 31 16:11:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VNBO007511
	for linux-xfs-outgoing; Thu, 31 May 2001 16:11:24 -0700
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VNBJh07498
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:11:19 -0700
Received: from zeus-fddi.americas.sgi.com (zeus-fddi.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA27176
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:11:17 -0700 (PDT)
	mail_from (lord@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.americas.sgi.com [128.162.185.214]) by zeus-fddi.americas.sgi.com (8.9.3/americas-smart-nospam1.1) with ESMTP id SAA800662 for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 18:10:02 -0500 (CDT)
Received: from jen.americas.sgi.com (IDENT:root@jen.americas.sgi.com [128.162.184.86]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id SAA62181 for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 18:10:02 -0500 (CDT)
Received: from jen.americas.sgi.com by jen.americas.sgi.com (8.11.0/SGI-client-1.7) via ESMTP id f4VNCpB20388; Thu, 31 May 2001 18:12:51 -0500
Message-Id: <200105312312.f4VNCpB20388@jen.americas.sgi.com>
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: linux-xfs@oss.sgi.com
Subject: New files on xfs ftp site
Date: Thu, 31 May 2001 18:12:51 -0500
From: Steve Lord <lord@sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


I just pushed out some patches to the xfs ftp site on oss.sgi.com, I could
not reach linux-xfs.sgi.com, so that site is not updated.

In the cmd_tars directory are tar files of the latest source of the various
command packages, these can be used to build rpms and debian packages.

In the patches directory there are two new patches:

linux-2.4.5-xfs-05312001.patch.bz2
linux-2.4.5-xfs-05312001.patch.gz

This just patch a vanilla 2.5.4 kernel with the xfs code base, they do
not contain cvs files, or the command source. The existing cvs seed
patch can still be used to setup an initial cvs tree.

Steve



From owner-linux-xfs@oss.sgi.com Thu May 31 16:22:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VNMSq09902
	for linux-xfs-outgoing; Thu, 31 May 2001 16:22:28 -0700
Received: from post.aecom.yu.edu (post.aecom.yu.edu [129.98.1.4])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VNMPh09884
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:22:25 -0700
Received: from [129.98.91.150] (usseinstein.aecom.yu.edu [129.98.91.150])
	by post.aecom.yu.edu (8.9.3/8.9.3) with ESMTP id TAA28934;
	Thu, 31 May 2001 19:21:43 -0400 (EDT)
Mime-Version: 1.0
X-Sender: mvolaski@mailserver.aecom.yu.edu
Message-Id: <a05100303b73c80490e17@[129.98.91.150]>
In-Reply-To: 
 <Pine.GSO.4.05.10105311420590.25565-100000@pipt.oz.cc.utah.edu>
References: <Pine.GSO.4.05.10105311420590.25565-100000@pipt.oz.cc.utah.edu>
Date: Thu, 31 May 2001 19:21:42 -0400
To: james rich <james.rich@m.cc.utah.edu>
From: Maurice Volaski <mvolaski@aecom.yu.edu>
Subject: Re: XFS: SGI or Linux
Cc: linux-xfs@oss.sgi.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

>It depends on how much demand you put on that server.  You can get a
>machine from SGI that can do amazing amount of processing and file serving
>- far beyond that of x86 hardware.  But if you only have 20-80 (or so -

Thanks for your comments. Performance hadn't crossed my mind: my 
concern is stability and the apparent difficulty in migrating toward 
more stability on a production server. It seems that Linux is still 
very fragile for this purpose.
-- 

Maurice Volaski, mvolaski@aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

From owner-linux-xfs@oss.sgi.com Thu May 31 16:42:24 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f4VNgOL13696
	for linux-xfs-outgoing; Thu, 31 May 2001 16:42:24 -0700
Received: from opus.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f4VNgKh13679
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 16:42:20 -0700
Received: from localhost (chuckr@localhost)
	by opus.sandiegoca.ncr.com (8.11.1/8.11.1) with ESMTP id f4VNj6F43535;
	Thu, 31 May 2001 16:45:06 -0700 (PDT)
	(envelope-from chuckr@opus.sandiegoca.ncr.com)
Date: Thu, 31 May 2001 16:45:06 -0700 (PDT)
From: Chuck Rouillard <chuckr@opus.sandiegoca.ncr.com>
To: Steve Lord <lord@sgi.com>
cc: Austin Gonyou <austin@coremetrics.com>, <georgeb@unitbv.ro>,
   <linux-xfs@oss.sgi.com>
Subject: Re: does it work on 2.4.4 
In-Reply-To: <200105312229.f4VMT9T14628@jen.americas.sgi.com>
Message-ID: <Pine.BSF.4.31.0105311555490.43041-100000@opus.sandiegoca.ncr.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Steve,

Could you elaborate? The singular patch method has been kinda
handy (and speedy) for local test system builds. I guess that
the patches were provided to prime the CVS pump but we really
don't need the newest, just consistency. Applying the patches
works nicely for us... so far :-). We're currently testing on
(with) highly modified Debian matter.

Thanks,

.cr

On Thu, 31 May 2001, Steve Lord wrote:

> > Woops..No 2.4.5 yet..but 2.4.4 is still out there.
>
> Looking into it now, not sure I am going to put out patches in the same
> manner as Russell did .....
>
> Steve
>
> >
> > --
> > Austin Gonyou
> > Systems Architect, CCNA
> > Coremetrics, Inc.
> > Phone: 512-796-9023
> > email: austin@coremetrics.com
> >
> > On Thu, 31 May 2001, Austin Gonyou wrote:
> >
> > > latest kernel is 2.4.5, previous kernel was 2.4.4. Patches are currently
> > > available for both.
> > >
> > >



From owner-linux-xfs@oss.sgi.com Thu May 31 17:19:29 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f510JTp20060
	for linux-xfs-outgoing; Thu, 31 May 2001 17:19:29 -0700
Received: from mail.gmx.net (pop.gmx.net [194.221.183.20])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f510JOh20042
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 17:19:25 -0700
Received: (qmail 10028 invoked by uid 0); 1 Jun 2001 00:19:17 -0000
Received: from unknown (HELO gmx.de) (212.224.51.140)
  by mail.gmx.net (mail06) with SMTP; 1 Jun 2001 00:19:17 -0000
Message-ID: <3B16DFA0.AEFA4C50@gmx.de>
Date: Fri, 01 Jun 2001 02:19:46 +0200
From: Martin Stricker <shugal@gmx.de>
Organization: http://martin-stricker.de/ http://www.surfo.net/ 
 http://www.masterportal24.com/cgi-bin/YaBB.cgi
X-Mailer: Mozilla 4.75 [en]C-CCK-MCD BDP81800  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: Re: redhat 7.1
References: <011101c0e97b$35e98700$0a01a8c0@den2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



Juha Saarinen wrote:
> Kevin Lochner wrote:
> :: Redhat linux 7.1 is supposed to have all the compiler
> :: problems ironed out
> :: (I'm able to build 2.4.2+ kernels with no problems),
> ::
> :: After I install the patches provided at the SGI site for
> :: 2.4.2 to provide
> :: xfs capability, I'm no longer able to compile the kernel
> :: until I download
> :: kgcc. (I get errors about 'cc0' and 'cc1' as documented in your
> :: mail archive about RHat 7.0)
> ::
> :: Could you clear this up for me, is the problem that gcc is
> :: still broken in
> :: redhat 7.1, or is there some problem that the sgi patches are
> :: introducing??  If the latter, you may want to look at your patches.
> ::
> :: btw -- no problems using kgcc, but odd that I had to install
> :: kgcc for a
> :: supposedly *fixed* compiler.
> 
> Well, is it gcc 2.96-81, or is it the code itself? I think that's the
> question everybody would like to have answered, but I think SGI's OSS
> team is a little pressed for time at the moment.
> 
> I got file system corruption with 2.96-81, but it went away with
> 2.91-66. I can't tell you why exactly though.

Not the compiler is broken but the source code! See
http://www.bero.org/gcc296.html for more information. After a close look
of some of my own source and contemplating about Beros comments I
finally got to the conclusion Red Hat did a Good Thing (TM) deciding to
use gcc 2.96-RH. But decide yourself. It may take *some* fixing in the
XFS code but after that you're standards compliant, so your code should
work with any compiler (that is, if that compilers is ANSI C compliant!
Not all are...)

FWIW I asked on the Red Hat mailing list about XFS and RHL, but no
employee of Red Hat shed any light to the issue...

Best regards,
Martin Stricker
-- 
Homepage: http://www.martin-stricker.de/
Registered Linux user #210635: http://counter.li.org/

From owner-linux-xfs@oss.sgi.com Thu May 31 17:38:13 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f510cD023454
	for linux-xfs-outgoing; Thu, 31 May 2001 17:38:13 -0700
Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f510c7h23436
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 17:38:07 -0700
Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de)
	by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2)
	id 155cx3-0003yR-00; Fri, 1 Jun 2001 02:38:05 +0200
Received: from pd9007f40.dip.t-dialin.net ([217.0.127.64] helo=kernelpanix.aura.of.mankind)
	by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2)
	id 155cws-0001fl-00; Fri, 1 Jun 2001 02:37:54 +0200
Received: (from utz@localhost)
	by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id f4VNwbk12105;
	Fri, 1 Jun 2001 01:58:37 +0200
X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f
Date: Fri, 1 Jun 2001 01:58:37 +0200
From: utz lehmann <xfs@s2y4n2c.de>
To: Martin Stricker <shugal@gmx.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: redhat 7.1
Message-ID: <20010601015837.A12033@s2y4n2c.de>
References: <011101c0e97b$35e98700$0a01a8c0@den2> <3B16DFA0.AEFA4C50@gmx.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B16DFA0.AEFA4C50@gmx.de>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Martin Stricker [shugal@gmx.de] wrote:
> 
> 
> Juha Saarinen wrote:
> > Kevin Lochner wrote:
> > :: Redhat linux 7.1 is supposed to have all the compiler
> > :: problems ironed out
> > :: (I'm able to build 2.4.2+ kernels with no problems),
> > ::
> > :: After I install the patches provided at the SGI site for
> > :: 2.4.2 to provide
> > :: xfs capability, I'm no longer able to compile the kernel
> > :: until I download
> > :: kgcc. (I get errors about 'cc0' and 'cc1' as documented in your
> > :: mail archive about RHat 7.0)
> > ::
> > :: Could you clear this up for me, is the problem that gcc is
> > :: still broken in
> > :: redhat 7.1, or is there some problem that the sgi patches are
> > :: introducing??  If the latter, you may want to look at your patches.
> > ::
> > :: btw -- no problems using kgcc, but odd that I had to install
> > :: kgcc for a
> > :: supposedly *fixed* compiler.
> > 
> > Well, is it gcc 2.96-81, or is it the code itself? I think that's the
> > question everybody would like to have answered, but I think SGI's OSS
> > team is a little pressed for time at the moment.
> > 
> > I got file system corruption with 2.96-81, but it went away with
> > 2.91-66. I can't tell you why exactly though.
> 
> Not the compiler is broken but the source code! See
> http://www.bero.org/gcc296.html for more information. After a close look
> of some of my own source and contemplating about Beros comments I
> finally got to the conclusion Red Hat did a Good Thing (TM) deciding to
> use gcc 2.96-RH. But decide yourself. It may take *some* fixing in the
> XFS code but after that you're standards compliant, so your code should
> work with any compiler (that is, if that compilers is ANSI C compliant!
> Not all are...)

I'm sure there are bugs in gcc 2.96-81. The same kernel compiled for k6 made
filecorruptions and complied for i586 it worked. I think even in 2.91.66 are
(unknown) bugs. Compiler are very complex.

I dont use a experimental state filesytem (or kernel) with an experimental
state compiler.


I also think redhat ist right using gcc 2.96. I had too many bad experience
with 2.95.2. But compiler for kernels are a different thing.


utz

From owner-linux-xfs@oss.sgi.com Thu May 31 17:54:18 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f510sIl26102
	for linux-xfs-outgoing; Thu, 31 May 2001 17:54:18 -0700
Received: from vimfuego.saarinen.org (saarinen.org [203.79.82.14])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f510sEh26084
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 17:54:14 -0700
Received: from [192.168.1.10] (helo=den2)
	by vimfuego.saarinen.org with esmtp (Exim 3.22 #1 (Red Hack))
	id 155dCd-0007Mv-00; Fri, 01 Jun 2001 12:54:11 +1200
From: "Juha Saarinen" <juha@saarinen.org>
To: "'Martin Stricker'" <shugal@gmx.de>, <linux-xfs@oss.sgi.com>
Subject: RE: redhat 7.1
Date: Fri, 1 Jun 2001 12:53:44 +1200
Message-ID: <02b401c0ea35$4f4656f0$0a01a8c0@den2>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <3B16DFA0.AEFA4C50@gmx.de>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

:: Not the compiler is broken but the source code! See
:: http://www.bero.org/gcc296.html for more information. After 
:: a close look
:: of some of my own source and contemplating about Beros comments I
:: finally got to the conclusion Red Hat did a Good Thing (TM) 
:: deciding to
:: use gcc 2.96-RH. But decide yourself. It may take *some* 
:: fixing in the
:: XFS code but after that you're standards compliant, so your 
:: code should
:: work with any compiler (that is, if that compilers is ANSI C 
:: compliant!
:: Not all are...)

Yeah, I think too that Bero's arguments are convincing, but then I'm the
last person in the world to offer any kind of expert opinion on it,
so... 

Is there a "code linter" that would pick up constructs that might create
problems? Steve Lord did say that the issue was caused by old code
inherited from IRIX/XFS, so it might be a good idea to look at it.

-- Juha


From owner-linux-xfs@oss.sgi.com Thu May 31 18:53:07 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f511r7q02348
	for linux-xfs-outgoing; Thu, 31 May 2001 18:53:07 -0700
Received: from pilot16.cl.msu.edu (pilot16.cl.msu.edu [35.9.5.36])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f511r3h02330
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 18:53:04 -0700
Received: from msu.edu (pm529-23.dialip.mich.net [35.9.48.175])
	by pilot16.cl.msu.edu (8.10.2/8.10.2) with ESMTP id f511r1X29050
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 21:53:01 -0400
Message-ID: <3B16F508.4DBE1482@msu.edu>
Date: Thu, 31 May 2001 21:51:04 -0400
From: Chris Szilagyi <szilagy2@msu.edu>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-xfs@oss.sgi.com
Subject: xfs mount warning
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Hello, I have a question.  When my system boots, it reports the
following errors when it mounts my xfs volumes:

kernel: Partition check:
kernel:  /dev/scsi/host1/bus0/target0/lun0: p1 p2
kernel: Start mounting filesystem: sd(8,1)
kernel: XFS: WARNING: recovery required on readonly filesystem.
kernel:
kernel: XFS: write access will be enabled during mount.
kernel:
kernel: Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1)
kernel: Ending XFS recovery on filesystem: sd (8,1) (dev: 8/1)
kernel: VFS: Mounted root (xfs filesystem) readonly.

Just wondering why it has to do a recovery,  and if this is common and
if it can be fixed.  When I shutdown it unmounts the volumes ok...

Thanks,
--
Chris


From owner-linux-xfs@oss.sgi.com Thu May 31 19:05:28 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f5125Sb04506
	for linux-xfs-outgoing; Thu, 31 May 2001 19:05:28 -0700
Received: from amoa.org (amoa.org [207.207.51.226])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5125Qh04503
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 19:05:26 -0700
Received: by amoa.org(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 86256A5E.000B784C ; Thu, 31 May 2001 21:05:16 -0500
X-Lotus-FromDomain: AMOA
From: ctooley@amoa.org
To: linux-xfs@oss.sgi.com
Message-ID: <86256A5E.000B76C5.00@amoa.org>
Date: Thu, 31 May 2001 21:05:11 -0500
Subject: xfs_growfs
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk



I'm looking for a good howto on the situations in which growfs works.  I have a
partition that is too small, there is free space after it, and I want XFS to
consume the rest of that space.  Any help would be appreciated.

Chris Tooley



From owner-linux-xfs@oss.sgi.com Thu May 31 20:09:31 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f5139Vc13668
	for linux-xfs-outgoing; Thu, 31 May 2001 20:09:31 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5138xh13593
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 20:08:59 -0700
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via SMTP id FAA1193551
	for <linux-xfs@oss.sgi.com>; Fri, 1 Jun 2001 05:08:55 +0200 (CEST)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17939; Fri, 1 Jun 2001 13:07:37 +1000
Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA47502; Fri, 1 Jun 2001 13:07:34 +1000 (EST)
Message-Id: <200106010307.NAA47502@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: Chris Szilagyi <szilagy2@msu.edu>
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs mount warning 
In-reply-to: Your message of "Thu, 31 May 2001 21:51:04 -0400."
             <3B16F508.4DBE1482@msu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Jun 2001 13:07:33 +1000
From: Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


Chris Szilagyi writes:
 => Hello, I have a question.  When my system boots, it reports the
 => following errors when it mounts my xfs volumes:
 => 
 => kernel: Partition check:
 => kernel:  /dev/scsi/host1/bus0/target0/lun0: p1 p2
 => kernel: Start mounting filesystem: sd(8,1)
 => kernel: XFS: WARNING: recovery required on readonly filesystem.
 => kernel:
 => kernel: XFS: write access will be enabled during mount.
 => kernel:
 => kernel: Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1)
 => kernel: Ending XFS recovery on filesystem: sd (8,1) (dev: 8/1)
 => kernel: VFS: Mounted root (xfs filesystem) readonly.
 => 
 => Just wondering why it has to do a recovery,  and if this is common and
 => if it can be fixed.  When I shutdown it unmounts the volumes ok...

If the filesystem was unmounted cleanly, the recovery phase will not
actually do anything. If the filesystem was not unmounted cleanly, then
it cannot be mounted until recovery is performed, hence the warning.

In short - don't worry, this is expected behaviour and is fine.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Thu May 31 20:09:58 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f5139wB13794
	for linux-xfs-outgoing; Thu, 31 May 2001 20:09:58 -0700
Received: from sgi.com (sgi.SGI.COM [192.48.153.1])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f5139sh13768
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 20:09:54 -0700
Received: from larry.melbourne.sgi.com ([134.14.52.130]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id UAA02083
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 20:09:52 -0700 (PDT)
	mail_from (dxm@clouds.melbourne.sgi.com)
Received: from clouds.melbourne.sgi.com (clouds.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17948; Fri, 1 Jun 2001 13:08:34 +1000
Received: from clouds.melbourne.sgi.com (localhost [127.0.0.1]) by clouds.melbourne.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id NAA88906; Fri, 1 Jun 2001 13:08:32 +1000 (EST)
Message-Id: <200106010308.NAA88906@clouds.melbourne.sgi.com>
X-Mailer: exmh version 2.0.2 2/24/98
To: ctooley@amoa.org
cc: linux-xfs@oss.sgi.com
Subject: Re: xfs_growfs 
In-reply-to: Your message of "Thu, 31 May 2001 21:05:11 EST."
             <86256A5E.000B76C5.00@amoa.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Jun 2001 13:08:32 +1000
From: Daniel Moore <dxm@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk


ctooley@amoa.org writes:
 => 
 => 
 => I'm looking for a good howto on the situations in which growfs works.  I ha
 => ve a
 => partition that is too small, there is free space after it, and I want XFS t
 => o
 => consume the rest of that space.  Any help would be appreciated.

This is exactly what xfs_growfs does. Read the man page for extra details
and don't forget to backup first.

-----------------------------------------------------
 Daniel Moore                  dxm@sgi.com
 R&D Software Engineer         Phone: +61-3-98348209
 SGI Performance Tools Group   Fax:   +61-3-98132378
-----------------------------------------------------


From owner-linux-xfs@oss.sgi.com Thu May 31 23:32:41 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f516Wfe08922
	for linux-xfs-outgoing; Thu, 31 May 2001 23:32:41 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f516Wah08908
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 23:32:37 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f516TOb04740;
	Fri, 1 Jun 2001 01:29:24 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 1 Jun 2001 01:29:24 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: "Christian, Chip" <chip.christian@storageapps.com>
cc: "'Steve Lord'" <lord@sgi.com>,
   "Coumoul, Philippe" <coumop@europe.stortek.com>,
   "'linux-xfs@oss.sgi.com'" <linux-xfs@oss.sgi.com>
Subject: RE: Path failover with xfs on linux 
In-Reply-To: <23D04BDBA646D411BDDD00D0B774B539028C8971@SA-BWMAIL1>
Message-ID: <Pine.LNX.4.33.0106010129050.4481-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Whoa, it does have that? Well shut my mouth. :) What's the driver named?

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 31 May 2001, Christian, Chip wrote:

> RedHat 7.1 has a multipath block driver that has worked well in our testing.  We put XFS on top.
>
> -----Original Message-----
> From: Steve Lord [mailto:lord@sgi.com]
> Sent: Thursday, May 31, 2001 13:19
> To: Coumoul, Philippe
> Cc: 'linux-xfs@oss.sgi.com'
> Subject: Re: Path failover with xfs on linux
>
>
> > Hi,
> >
> > I m looking for a path failover software solution to secure acces from Red
> > Hat 7.x server to an external Raid Storage Subsystem.
> > I ve seen that there is not XLV on XFS for Linux, but is there a failover
> > possibility without XLV ?
> >
> > Thanks
> >
> > Phil
>
> This question might be better directed at the linux kernel list, hardware
> failover is usually invisible to the filesystem, being handled at the
> block layer. SGI does have ports of some of the Irix SCSI code which
> includes failover capability for certain device types, but I cannot
> say when or how this would be available.
>
> Steve
>


From owner-linux-xfs@oss.sgi.com Thu May 31 23:34:34 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f516YYS09424
	for linux-xfs-outgoing; Thu, 31 May 2001 23:34:34 -0700
Received: from yog-sothoth.sgi.com (eugate.sgi.com [192.48.160.10])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f516YTh09416
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 23:34:29 -0700
Received: from fuzzy.melbourne.sgi.com (fuzzy.melbourne.sgi.com [134.14.55.199]) by yog-sothoth.sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam-europe) via ESMTP id IAA1243815
	for <linux-xfs@oss.sgi.com>; Fri, 1 Jun 2001 08:34:25 +0200 (CEST)
	mail_from (fsgqa@fuzzy.melbourne.sgi.com)
Received: (from fsgqa@localhost)
	by fuzzy.melbourne.sgi.com (8.9.3/8.9.3) id QAA10929
	for linux-xfs@oss.sgi.com; Fri, 1 Jun 2001 16:51:16 +1000
Date: Fri, 1 Jun 2001 16:51:16 +1000
From: FSG QA Account <fsgqa@fuzzy.melbourne.sgi.com>
Message-Id: <200106010651.QAA10929@fuzzy.melbourne.sgi.com>
Subject: TAKE - xfstests/tools/srcdiff
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

QA fix.

--Tim

Date:  Thu May 31 23:33:04 PDT 2001
Workarea:  fuzzy.melbourne.sgi.com:/home/fsgqa/isms/2.4.x-xfs

The following file(s) were checked into:
  bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs


Modid:  2.4.x-xfs:slinx:96222a
cmd/xfstests/tools/srcdiff - 1.7
	- Fix up paths for acl.h and attr_kern.h.



From owner-linux-xfs@oss.sgi.com Thu May 31 23:35:04 2001
Received: (from majordomo@localhost)
	by oss.sgi.com (8.11.3/8.11.3) id f516Z4709632
	for linux-xfs-outgoing; Thu, 31 May 2001 23:35:04 -0700
Received: from UberGeek.coremetrics.com ([209.184.141.163])
	by oss.sgi.com (8.11.3/8.11.3) with SMTP id f516Ywh09578
	for <linux-xfs@oss.sgi.com>; Thu, 31 May 2001 23:34:58 -0700
Received: from localhost (austin@localhost)
	by UberGeek.coremetrics.com (8.11.2/8.11.2) with ESMTP id f516V3e04753;
	Fri, 1 Jun 2001 01:31:03 -0500
X-Authentication-Warning: UberGeek.coremetrics.com: austin owned process doing -bs
Date: Fri, 1 Jun 2001 01:31:02 -0500 (CDT)
From: Austin Gonyou <austin@coremetrics.com>
To: Chuck Rouillard <chuckr@opus.sandiegoca.ncr.com>
cc: Steve Lord <lord@sgi.com>, <georgeb@unitbv.ro>, <linux-xfs@oss.sgi.com>
Subject: Re: does it work on 2.4.4 
In-Reply-To: <Pine.BSF.4.31.0105311555490.43041-100000@opus.sandiegoca.ncr.com>
Message-ID: <Pine.LNX.4.33.0106010129540.4481-100000@UberGeek.coremetrics.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Well, a good question posed to me was Why in the hell is it 3 MB. I like a
single patch myself, but it's not quite right for accuracy, with the
different kinds of things this patch touches. You've got tools, then core
linux/xfs, then xfs/fs. That's potentially 3 patches all together.

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com

On Thu, 31 May 2001, Chuck Rouillard wrote:

>
> Steve,
>
> Could you elaborate? The singular patch method has been kinda
> handy (and speedy) for local test system builds. I guess that
> the patches were provided to prime the CVS pump but we really
> don't need the newest, just consistency. Applying the patches
> works nicely for us... so far :-). We're currently testing on
> (with) highly modified Debian matter.
>
> Thanks,
>
> .cr
>
> On Thu, 31 May 2001, Steve Lord wrote:
>
> > > Woops..No 2.4.5 yet..but 2.4.4 is still out there.
> >
> > Looking into it now, not sure I am going to put out patches in the same
> > manner as Russell did .....
> >
> > Steve
> >
> > >
> > > --
> > > Austin Gonyou
> > > Systems Architect, CCNA
> > > Coremetrics, Inc.
> > > Phone: 512-796-9023
> > > email: austin@coremetrics.com
> > >
> > > On Thu, 31 May 2001, Austin Gonyou wrote:
> > >
> > > > latest kernel is 2.4.5, previous kernel was 2.4.4. Patches are currently
> > > > available for both.
> > > >
> > > >
>