From owner-xfs@oss.sgi.com Fri Dec 1 06:59:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 06:59:32 -0800 (PST) Received: from MailServer (199-241-81-62.libre.auna.net [62.81.241.199] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1ExLaG028874 for ; Fri, 1 Dec 2006 06:59:22 -0800 Received: from localhost (N2BSolutions [127.0.0.1]) by MailServer (Postfix) with ESMTP id DFA1B17ACA6 for ; Fri, 1 Dec 2006 14:29:35 +0000 (WET) Received: from MailServer ([127.0.0.1]) by localhost (N2BSolutions [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 14792-03 for ; Fri, 1 Dec 2006 14:29:33 +0000 (WET) Received: from correo.adeje.es (firewall [62.81.241.197]) by MailServer (Postfix) with ESMTP id 3B8BD16E9F6 for ; Fri, 1 Dec 2006 14:29:33 +0000 (WET) To: xfs@oss.sgi.com Subject: One problems with mount my partition xfs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: alejanhd@adeje.es Date: Fri, 1 Dec 2006 14:37:40 +0000 X-MIMETrack: Serialize by Router on adeje-lotus/Ayuntamiento de Adeje(Release 6.5.4|March 27, 2005) at 01/12/2006 14:37:40, Serialize complete at 01/12/2006 14:37:40 Content-Type: multipart/related; boundary="=_related 00503D8180257237_=" X-archive-position: 9856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alejanhd@adeje.es Precedence: bulk X-list: xfs Este es un mensaje de varios componentes en formato MIME. --=_related 00503D8180257237_= Content-Type: multipart/alternative; boundary="=_alternative 00503D8380257237_=" --=_alternative 00503D8380257237_= Content-Type: text/plain; charset="US-ASCII" Hello, my name is Alejandro, I live in Tenerife, Canary Islands in Spain Sorry for my english is very bad, My question is: In my server Supermicro, with debian sarge2 installed, I have any problems mounting my disc xfs, is posible you send me information of mount partition in xfs??? Thanks --=_alternative 00503D8380257237_= Content-Type: text/html; charset="US-ASCII"
Hello, my name is Alejandro, I live in Tenerife, Canary Islands in Spain

Sorry for my english is very bad,

My question is:

In my server Supermicro, with debian sarge2 installed, I have any problems mounting my disc xfs, is posible you send me information of mount partition in xfs???


Thanks


--=_alternative 00503D8380257237_=-- --=_related 00503D8180257237_= Content-Type: image/jpeg Content-ID: <_2_0461B8380461B6F000503D8080257237> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4QAWRXhpZgAASUkqAAgAAAAAAAAAAAD/ 2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIs IxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjL/wAARCADDAOoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo 6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL /8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKR obHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3 +Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKKKACiiigAooooAKKKyrq8mu Zza2Z2gcSTensKALl1qFrZLm4nSP2JyT+HWs4+I4mIFvZ3cxJwCECj8yadHp 0EB3CMPJnJkfkmlkBx7UAVZfFEkM4ibS52YjPyOrHH4VJH4r08kLcJcWpP8A z2iP8xmomQAkhQCepAxUEuxlKyKGU9mGaYHSQXMN1EJYJUlQ9GRgRUtcC9vJ YSm70yRoZRyyA/K/1FdVoutRavaCQYSZeJEz0PtSA1KKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCtfTmCAbTh3YIp9Ce9Vd MjSKN06sDyfUVD4lLR6T565IgkV2x6dD/PP4Vz+na8rMr78EgdTTQHXzFQMk 1iajrdhYpm4uY4x/tMOadf3T3enubdwHx+VeVQ2Fyt60urhy5PzStkg/Q+ld +BwccQ25ysl97PPx2Mlh0uVXbOxuPHOmBiIhPN/uRn+tUm8a2rH5ra5UepTP 8qqJ/ZMa/wCsH5iopXsp1MdtE8zHj5Of5V6iwGG/lf3nkf2niG9DbtNYt9Qj aS2kD46juPqO1Zej6u2neNGgRiIpj93tnIqPT4YNDinvbhlQsuNoOePT3NO8 DaHNr+uy65OClrG/yAj7x9q8XF06dOq403dHvYSpOpSUpqzPX6KKK5TpCiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBrIroUdQysM EEcEVx/iLwe07/bNJIilCgNBnCtgYGPQ4rsqry3trAdstxCh9GcCgDzmO28Q 6Zz5HmAdQrA8fTrUX9vQyE/aLZ0buVFdrqPiG2hJjhjW4YfxH7o/x/zzXm3j b4jXejS28FssEE8o3gtAHQrnGD6VcJSi/dInCM1aSNCTUdL27mRv+/IP9KoT 660h8nTtPuJ37EphRWBdfEzWU0Ga587R1uMhYy0LAk98Z+Xge9b/AID8a6nq WmyXMwSfy5fLdvJVcnAPAHbmtpV6trNmUcNSTuok+n+CNa8Q3Mc2rk29sDyv fHoB2r1XT9PttMso7S0jEcMYwAP51yn/AAl15LI32eJMpj90y9RW9omv2+sx sFBiuY/9ZC3Ue49RXO7nQa9FV5L22hOJbiJDuCYLgHceg+tNuNQtLSze8uLi KK2QZaRmwBSAmlmjgiaWWRUjQZZmOAB71xsnxP0RdQkt4m82KNSzSq2OB1IG MH864Hxx4nuPF91DDpc1za6dA2QSARcN2JQjkfWsG0lu7rWGs9Vs7RBHCGRI 1yJB0LZPXngjsfWrjHuB9EWGoW2qWMN7ZTpPbTLuSRDkEVarzfwXqf2LUVsT hYLjgKOAHxwce+MflXpFS1YAooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFNZgqlmIAAySaAMnVtRaMm2gOH/jYfw//AF6xf7PaaJnYgKxxnHNNt761 uQ90Z0ZXYsWB461Tv/ETzgWWnJub+/jp70wL2m6aqIRJh2RtgPb61l+MPBtn r9pC08bB4c7ZI/vKD/Me1dBpqm1giilYu+3943+0eTWqW+XswpgeJ/8ACr7E kCe+uJI15VVQAj8cV6B4e8OWnh/RY7O1h8tMl2yclmPck9TXQukCncIVB9cV WnuAAcmm3cDF1KKKylivUAXB2sBXMX3iGSw1L7fbIUlgfdnoGXPQ+xFa+v6i ksYgDgZ6ZOBXm+o+J/tFudD02ya81WRyodWyoX/Pc8CkIs/8JR4Vi1vXL7X1 n8mf99Y28RYSB2dicEcAgY5NRQ6nNrdnNqN/evPbF3uEthP5ojAH8WON2AO1 VdJ8Nx27NJOYr69YFJJmXdDCO6xg8MfU9Km8IXNskuoaRPaPZ3sL7o7dQNgX uTxzwQc1aVtwOhtY7Wawtb20uYZ450z8hOUOM7eceo571m69cw2xs5EJa8in UxxoMsykhXGB2Kn8wKzNKWWDX9UtrWMQ6a8yxW1ztzFHKVyyA8D1yM8ZGa94 8L+FtI0KyWazTz7i4VXkvJhmSXuOew9AMCk5Acz4U8G30+pW+tauXtYoG321 kD8xPZpPT/d/P0r0mjFFZt3GFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABXGfEDUbhdNGl2m9JbsFWkUH5R6fU12deLax4t1CPxP4hWa5nSztFcwxxxK fnUfLyQR2qoLXUTMTwt4b1u6uo9ItLxWQbjPKVyluu8jdzyzHaQOg574r0zT 7WOxub63tUXFtIEBZQSwxgk8cnIqD4R2E0PguPUrxcXmpSGeTI5Cj5UH0wMj /eq0xNv4pvombaHbd9QRn/Ghu7BF6LJ+YnJPWpy7KODVdHCnbkcU95Bg0hkM 9y4B5rmdf1220qxe6vrhYoh0yev09areK/GdnoiGGP8A0m9PCwpzgnpnH8up rzDUbS61bUUu/EjPNcHmDSonwwHrIR/q19uvvTSvsAzUdb1XxnIyWrmw0eNs S3Mg+8fTjlj6KK6PQ9ChtbUxW8Lw27/6x3/11x7uR91f9gceuak03S2zFLdC PdGMRQxrtihHoq9vr1rbDlZY7eGJ57qTiOGMZZj9Ow960SURCSCC0ty8hSKN B34Arz24vnk8bHV7RSkaRrGokH+t2nnjsCOOfeux1rRNXj1NrfVY1zGqzR28 JLhkyd2fUjiti08JaRqfie3tWgeO2ntfMLxv8wlznJznOfQ0ntcCPTfhnfPP pl9ZOg0uWVbg2dw3MQODkjoSfwPT8PZwABgVFa2sVnaRW0IIiiQIgJzgAYFT Vm3cYUUUUgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAryDxnbPpN5q0 gtoJRet5CpK20N5gzuJHZcfpXr9cd4+8HjxRp0bwMVu7Y5TH8a91/wAKqLsx NGV8LdXeG1uPCl8rJeaad0TFtyyxMSQVbvgk/hj0ONHxrE1ncW2qxnAGIpRn kc5Vv5j8q82jKaboEpjgaO/tZlVbsSGOSJyecnrjA5FSa748uYNRsbjUsoIt iSS2jCVpoDks2OBkZPBA/WqlGzEmdquv2f2cO0m0hSXJbp9PasOfWr7XFdLB zbWH8d4wwWH+wD/6EePY1z934m0LW7S11G5SL7PBuDFJBiU/wKYxyX9R0HvV NrjUfFbbHV7PSkIxAowX9N56fgKIxuMZJdQfang8OxhpckSalL8xXPXZnqff +dX9M0mKzBPzPK5y8rnLMfc1fisrewteixRRjJJ4AFY17cavqiMmmWdzDY4+ e7dCgcf7JPGPerbS2GO1jxJBpxNva4muuh7qn1/wrt/hPot2GudcvyWllXYm 4c84J/QDj3rG8F/D5L/FxclEijPIGGJP17mvZLW3htLZLeBAkaDCgVk3cDA8 XeHptYtFuNOdYdThUrFLnBKnqM9j3H5d6xvDfhnW112z1LV3Cm3hIcB8tLIe MkDIAArvuKMClfSwWFooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUlV72/g061a4uX2ovHAySewA9a848QeKb67LS/bG0yxj5GyTax92b+ g/WmlcBvxN0/TdVBtrGdo9TZ1M5iGUwDx5nv6Y59a88mvNM8Ko1nZRfbdUkG GBOT/wACPYe1R6nr1/eBLLRomiilGTelfvjPVc/zNT6L4djsxvYF5mOWduST 7+praMdNRGd4f8MnVdUvNRlgSW7hIM8cKBRGSM/cHbH8WMc9a3H1W68L63a2 9qN9jq4eK4gcFlSQAYlUdQfXtxWVrl22neKdHudNvRbXUZeG5kBIUxED5WYZ 68gD1PaugbwoutaempWxeW+UFx5rcSoegHYDH/16lvoB1mmaNbtpsWt6oYrp 2I+yWSnMUbZP3/7zDBJHQYrm9TtvFVvrc91YQw3UUrB0R2xgjnpkYGewrpdJ Fzby2mm37hpgqyr0IxtwPy2murudJ+TzF4I5BNSnqMxfCmpXUFiU1KOOK8mb fKIzkBj2+n+e9dTFqCt3rz7U7gW93FDuwz5jOPfofzqTSdXkubaKQ5BYdKlg ejLdKe9TxyBq5a1uWfHWtWCVvWkBs0VBFJuHNT0AFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQBU1Cwh1GyltZx8jjqOqnqCPcHmvm/xXo+rHxfL peoyF44mDRgcK6no2K+mSfSub8VeHItcgjuIok/tC2BMDnjcOpQn0P8AOrg7 PUDzO200R2kYC48tcg/0+lPtNPutbi82LfaaYf8AltjEtxjrsHZf9r8q37fw pf6022+jlsNMX70IOJrg+hx9xf1PtXTNpCw20dtbQLFBGoVI0GAoHYU5S7Ac I2g6a2ltYPDiJWOGB+ZCTw2fX3PXBrX8J21rpFqtis3mEsWeVgAWJ/pWnLoc 5fcoIPqKiTw3Os3mL8jeoX/I/SouBn+IJvtPi+F7MkC1tkQsB/FknH5YrrbX xFbz6eY7jEM4XBVzgH6E9aoWvhzyQfl5Y5YnksfU1pJoq4wVyPpSA811SO4u 9aMsSbghzGoOSW7fQDrk1v6Pob21rFERyoANdnFo8SfdjUfhVqOyRP4RQBlW mnlQOK1IrbbVpIgvQVJgUARom2paKKACiiigAooooAKKKKACiiigDG8ReKtH 8KWiXetTzW9s5I85bWWVFPA+ZkUhc5GM4z2zg1HF4w0WSZIpZrqzaRgiG/sZ 7RXY8BVaVFBJPYc1znxt/wCSQ67/ANu//pRHXaatZWWpaRd2eoxo9nNEyzBx xtxyfwoAuUV5H4W8c67N4X8OaNZ2E13r02km9kd1SXbAsvlI7B5YgxcDP38j uDW34l8U+J9M0vwjdfY7fTrrUtWgsL6ymxKVLk/dkVioGEPYnDDoQRQB6DRX IReJNUi8U33hi6OntfpYpqNtchXjiaEyFG3qSxDLj+982f4a5fxV8Tdb8H3F 5Zy2um6tJb6dHqP2mEPbIY3nEOAhMm47mU53AEE+mCAer0mK8/8AH2q+JdJh 0SO2v7GE6h4gtbRWW2clY2+bDZf5vmQg427gcfL3m8VeJ9d8IaDda1dz6TeR WPlLPZ28EiyOGkVN4cyEJkNnaVOOm49aAO7xSYFefXnjjW1uvG9tDZafA/hm GO5VnZ5RcI0bS4ONu0lFHrtJ/iFJP8RZ9PufDd3fQQLpWt6XPfgRqxltvKgE zZOcOCpxgKCCO9AHoW0elGxfSuL8L+JvEuuXlldXHh94dEv7YTx3BMSmDKhl ziZmkDZ67EI4yDyRRtfG+uah4R8T6ulpp9pdeH7y5glgYvOkywIGYBsoQTyA 2D24oA9C2r6CjavoK8f1b4k6jY+IrPVXuIoNGHhiLV3tDbGRnM00aeWCHGHJ IAc5C7jlT1rt73xDqHh680ka79ke31W8Sxj+yxuGt5nUlFYlj5gJUjcAuMjj rQB1OBWW3iTRE15NCOqWv9rPnFmJAZB8m/lRyPlGee1ReLvEcPhLwpqOuzxm VbSPcsecb3JCqucHGWIGccZrzL4ia/deEvF3gnXtfFrNJbx6ixSzjZAS0Kqs fJYn5mA3cdScCgD2fFY3iLxTo/hS0S71mea3tmJHnLayyopyB8zIpC5JGM4z 2zg1S8Oan4nu9SuYNb0NrS12eZBc/uk5zgxsiTyknGCH4B54HGcX42/8kh13 /t3/APSiOgDt9Pv4NTsYry2EwhlBKedA8LYzjlHAYdO45HPQ0t7f2unW/n3k 6QxFlQM56sxwqj1JJAAHJrm28Tai/wAR7jwmlrawoNK/tCC7Z2kJ/eCPDJ8u Pm3cBugByM4HnvifxDq3iWy0AO1lb3WmeOI9MkZYGZJJo87ZQN4ITk5TJJyP mGOQD2LTNUtdXtPtNoZfLDlCJoHhdWHUFHAYfiKuVyOl+INW19tSXSnsCNJu Wsbh5oHAurhEBkCDf+6XcwAJ39/qcu0+JE2s6l4Ri0qyhWy8RwXLJPO7F4JI VYupQAAgEAZ3c89OCQD0KiuJTxL4hbxu/hF4NMjuho41BL4eY6M28R8xZBA3 buN54wc9qyrD4kajd+HfCGvtZ2q2muaimmzW4DF43Z3QSK+cYBjPykE4I57U Aeiz3dtbPClxcRRNO/lxLI4UyPgnauepwCcD0NNvr6202zku7uTy4I8bm2k4 yQBwOepFcT4212/8MWk/iacaXdw6W4C2SRyGZVlkWPf5m/arFT0MfqA3PPND x54o0bw94z8RStp+oW+ma5LYi2eN4mQKYo1ZWDEFeR8hAOSx39iAex0VzEuv X+peJNU0PRGs459LhhkuJbtGkVmlDFYwFZSPlXJbnG4cGo/EWr69o+l3upLN pCCxs3unszHJLJMETc2HDLsG4MASjcYJx0oA6uiqGh6mNa8P6bqqxmIXtrFc iMnO3egbGfbNX6AOe8YeEbfxppH9lXuo39rZOczRWhjXzsEMu4sjHgrkYI98 8Yil8HG9tGstU8Ra1qNi67Htp3hRZBxwzRRI5BxggtggnOa6aigDC1DwrZXl zZXdrNcaZeWURgt7iy2ApEcZTa6shX5RwVOO2K5P4lWLW9l4StbGw1G5S21+ C9nNnayTMsaFjJIxRThiXz6kk46GvSaZNNHbwSTTOEijUu7N0UAZJNAHOXPg XS7+31aPUZ729m1SJYLi4llCv5SklUXYFVQCT0HPfNZniD4W6V4m3PqWqas1 zJarZz3KSRB5oVkWQKw8vaMOobKqp9eta/hPxFca6up29/araahp940MsA7I wDxHqeSjLn/aDdsV0VAGFrfha18QaXYWd9d3hlsJ4rqC8RkWUTxghZD8uwnk nG3bz0rNu/h1pV/YatYXd7qMtnqsouLqAyqA0w2/vAQoIPyL8udvyj5a6+ig Di2+HNs83iGaTXtZeTX4FgvmJtxlVG0bcRYB2bk+jHvghV+G9iJ/Dsj6vqso 0GBre1jcwFXjYbWVx5XOUwhxjhR0bLHqr2/tdOjiku50iWWaOCPccbpHYKqj 1JJFWaAMLRfCtroYgigvLya0tRiztbh1dLUYK/Idoc8Ej5mbAOBisuz+HdpZ aFr+krrWrPDrkrzXcjmDeHk4lK4iAG8cHIOB93aea7GigDi0+GWjqlkHvNQl Ntpv9ks0jRnz7TJIicbMYGRhlCtwOc81sW/he3jvLW5ur29vzZMWs0unUrbn btyNqgscEjLljyea1LH7Z9jj/tDyPtXO/wCz52dTjGeemKsUAVNU0y01nS7n Tb+ETWlzGY5YySMqfccj6iuV1f4Z6Zr76a+q6pqt19gWWOMSPF88cgCsjYj5 G0Y3DD853ZAI7OSRIo2kkdUjQFmZjgKB1JNRWV5BqFjb3trIJLe4iWWJx0ZW GQfyNAFHStDXTG3yX95fSIhjikuyhaKM4OxSqrkfKOWyxwMk4qn4w8I2/jTS P7KvdRv7Wyc5mitDGvnYIZdxZGPBXIwR754x0NVdRkvorCV9Nt4Li8AHlxTz GJG55ywViOM9uvHHUAHP6f4ISy8WReJJde1e9v0tDZH7R5Gx4c7tpCRKeG+b IIORySOKyP8AhUth/wBDHr3/ACFP7Y+9bf8AH3/z1/1P6fd9q3fAXiWbxh4L sNent0t5Loy5iRiQoWRkHJ9lFdJQBh3Hhe3kvLq5tb29sDesGvEtXULcHbty dykqcADKFTwOapT+BNOk1nQNRtru8sl0GMx2VrbmPylVhtcNuQsdy4U/N0GR g5NT+M/EVx4a0N760tVupYf30sR6i3QgzMORyF4H+0y54rfhmjuII54XDxSK HRh0YEZBoA5248GxT+MJfE6axqcF89kbFUj8ny44jzgBoych/nySefVflrHi +FWnQeH9I0WHXNaS00m9+3WmGgLJLnKkkxchWLkA/wB85yMAaGp+KdT034h6 F4ek0+1/s/VvPMV0s7NJ+6i3tlNoC/MQOrZHp0rraAOT1D4e6RqVrrNnc3F+ bHV5vtNzarKAnnfL86nbuB+ReCxX5RxWdf8Awp03UNO1LTm1vWorHU7o3l5B FJCFmnJBLkmIkZKg4BC8DgV2tj9s+xx/2h5H2rnf9nzs6nGM89MVYoA55/Cc P9oJqMGqajb6gYY4Lm6iaPddomcCRShTPJ+ZVU88EUy68Fadd3uoXD3N8E1K 1W0voBN8lxGqlVySC4IDNyrDO45zXSUUAUdG0uLRNHtNLglllgtIlhiaXaWC KMKCQBnAAHTPHOavUUUAFFFFABXL+KtZ00Xth4al1uPTr7UpF27Xj80IDxtD hlO5gEAIOctjJFdRRQB4/qGu2PgT4wWJvPE322PVLU22pG6aBXtWTDQu4jRA AQ2BkdCTkgCr+l+F9G0jWtb8KrpdrLpniLbf2ziIMpiXHmJkdBGSrJ6GUY6G vUaqQ2kovpLq4ljlYApAEjK+WhIJByTkkgZPA+UcCgDx6xttO07wF8UNAuoL eCRb3Ubq2sGQAiHywYZET+6CgIIGBt7YqL4f6lpd9460PTl1OO7tZ/BsEUto 915sX2lSgePyySoYImSoHYkjqa9xooA+cjc6XqOhrEZLW70rTPHw+U7ZIrfT mzjPULAcHr8px7V0fjW60N/CXiB/C+nRWmt6XLClrNbx5ujGHRi8W3LCDaWA IO3CkAAAV7VRQB4Tfanot3qHxZWTVobu3isoZ9P82881Ul8pstFljgiZkA2/ dJVRjgU8a7o66v8ADa8uNZt4P7R0e4TWLoXYjeQeQFXzJAQQRKJApyCGBAwR XudFAHgXhzUbrVPhv4NS61aRdGN3exa7cjZM8TEyNEJfMV1CHcN28EYKnjit PxK2l+GtL8HrZeIr1rP/AISSFo5p7xI4pLQ4aUosW1DCp24JXC5IGFIz7VRQ B4r4tewi+IPirQ7A26i88Izu9jDj97egsynYOsvl4bpnABp/hdtKitfDcN2u mx+FP7DU3wVFWH+0sIr/AGr+HOxWHz9wc84r2eigDkPBbXran4h8s58OfaY/ 7JJz08sebsz/AMs9/wB3HH3scYrNkaAfFLVD4l8v7Ottbf2EJs7S2H83y88e du/u/NtxXoNFAHzl4JeHUPC3hqx1jVksvDCWV2ksuyF40vftRYJN5yPGv7tk ZcgHng817x4atVsvDtnax3N9cxxKUjmv2VpnQMdpYqACMYxxnGM85rVooA4R L/SvGM+sX1l4xa3sbKM2062jWzxiIAlpHMsb4BO4ZBCkJmuF8P8Aiy6uvhR4 h8MaHqUdzrukedbWLRSfvLm1VhiSILySE3Abc8hT3r3WigD58+Jd3Z2V54Ql 8Cy20c4i1BY2hbkyNEisOOs5yRg/MXKg8kV6J4Q0bQjdX8mj65qF/De2zR3i xNBDHE+Ry3kJGyT4ZufvYHPRa7+qWpwahcWoGmX0VncK4O+a385GGCCGXcp7 54YcgdRkEA8I8KvPqvhnwvH4m1eS18Nz2F2z3UyxSI92LtuJmnR0HyY2kgHI ODXt/hq1Wy8O2drHc31zHEpSOa/ZWmdAx2lioAIxjHGcYzzmm+F/Dtp4U8NW Wh2LSNb2qEBpDlmJYsxP1Yk/jWvQAUUUUAFFFFABRRRQAUUUUAFeUaiftGl/ EHWNWVI9Y0maddMmb79rEsCtC0RI+XcxJOOpyDnFer1y2seG7nxBdSwX9tpi 2jfJ9rjXdcvATlocFcIGwAWDHIzwDg0AUZ5E1DRbfWPFNjC+lyaRFcTLLtIs 5wC7nk5ycoFKjIKds1V8L2esXngrwz/wk9ul7CbORb+G5wcbiDFJIJCM7YwQ wOTl89q0Nd0jxFqOvwstjpN3odpse3tJr+SDfMOd8gELghT91c4BG45ONseu 6T4s1aCws5YtKubAoZNRt3vZIPPkJJEW5YWzCOAeAX4BwMhgB3wylu7jwzdT TMzWEmo3LaWXLFvse/8Ad53c464/2dtTal4Y061OoalLcao95e3AcJb6lc26 PIwWNF2xOBwFQFsZwMngcb2kJqCWR/tJLaKcudsFq5eOFBwqqxVSeBnkDkkd AKhutNubvxFY3kk6fYLOKRlgxy07YUOT6Km8D3c+goAxtbtp0/s3TVh1i8sb O3Mlw9lfPFO7DCJufzEZxgyMRuJJUcGseXXrfXNT0LQtAd76xl02TU2We7ce fGGCRpLIwZ9pYtngklQCCMiumlh8VRzXkNvPp08E8jtBczlke0UqNq+Uq4lw 2TkupOaybHwKPC76Td+HIreW60/T305o7uQxLPGziQsXVGIYOGb7pB3Hp1oA dpptNR0GBdD01Y7S21KSHUNLXaANm6N41BIUAPsfHAIXGOa47TNSm/4TqTw3 YDZ4X1HV2itVjDBAtvbbriND0EZkCjA4OJB611EvhLXtO0FtO0WWyaTUb6a9 1eZ7l7Z5DI2WWJljcrn7u48hV45OVvw+G7+a2snlttO02bSpkfTLazlaWGNQ hVgzGND86uykYIGFIyc0Acr4k8QP4W8WL4O01DbWuqixFsIEIW1Es7RShccI CqggDoSSK6V5IPDPj/RNI0+3WCx1m2ut8MSYVZYtriTA4BIdgT3OM81Nc+Dj rBvb/UzDFqtyLcxNAzSJamBt8YBIUvhySThcg4wK0LTSLq416LWtWW3W5toH traK3dnVFZgWckgcsFTjHy4Iyc5oAZ4l8ZaR4W8pL+ZPtEyl4oPPiiZ1BAJD Sui8ZHBbJ7ZqjqfxD0yw8J23ie2sdR1PSJkLtPYxo3kgED51Z1I5yDgHG05x UureHr9fGNt4q0f7LJepYtp89tdyNGksRcOCHVW2kMD/AAnOe1W9Tg159Nit be203UfOEgvBeXLQDa3RE2xPkckZIBwB1JyADD1z4g3elW9iw8LapHJd6nb2 EYnktsSGQ5IQrKwJ2qQMkLkjJGDXbQSNNbxSvDJA7oGaKQqWQkfdO0kZHTgk ehNebv4Q8Z6l4X0Kx1a40eTUdD1K2voJo55St0Itw2SZjBQ4K/MN2eeB37+x OpmWc362ixnb5KwMzEddwYkDPbBAH0oAwvGWmG9m0i5ktr3UbS3uHE2kwRRy Jeb42VfM3sqgIfmyxx7ZIIz9CtrlfDGq6fY38lzeQ6i0j2Uh2taxGRXNqCcc GPKqxOPmyOMVuapZ6+mvQ6ppV1DPbratA+mXUphiZi4bzQ6ox3ADGCpGOmOc 5Fx4b16yi1vUdFlsRr2tXERuJZZGRIIUTYojOxssFHBZcZYkjA2kA47WNVn0 fxvdaf4fj+xaTfPYabdJCpVYLyaYlyu35VfySdxH8RSuzeSDwz4/0TSNPt1g sdZtrrfDEmFWWLa4kwOASHYE9zjPNMtfCd9caMdKurWx022tyk1r9lu3una5 WQSCaRnjQltyjPJ3bmz2rZtNIurjXota1Zbdbm2ge2tord2dUVmBZySBywVO MfLgjJzmgDdooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2Q== --=_related 00503D8180257237_=-- From owner-xfs@oss.sgi.com Fri Dec 1 07:21:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 07:21:36 -0800 (PST) Received: from mail.atipa.com (125.14.cm.sunflower.com [24.124.14.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1FLRaG000447 for ; Fri, 1 Dec 2006 07:21:29 -0800 Received: from [192.168.100.199] ([192.168.100.199]) by mail.atipa.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:09:40 -0600 Message-ID: <45704570.7020209@atipa.com> Date: Fri, 01 Dec 2006 09:08:32 -0600 From: Roger Heflin User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Issues with XFS on Sles9 sp2. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 15:09:40.0781 (UTC) FILETIME=[B98FFDD0:01C7155A] X-archive-position: 9857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rheflin@atipa.com Precedence: bulk X-list: xfs Hello, I have a customer that has machines whose XFS filesystem quits responding when certain applications are running. The only filesystem that uses XFS is /tmp all other filesystems still respond, anything going to tmp hangs forever. There are multiple machines with a couple of different types of motherboards that have this issue, converting the machines to ext3 eliminates the issues. Under load they were seeing 1-2 events per 24 hours on 100 machines. After the ext3 conversion they have had 0 events on 400 machines in 2 weeks, so it is fairly conclusive that XFS has something to do with it. It is not a hardware problem of the 2 different motherboard with the issue, one uses Opteron+AMDchipset+IDE and the other one uses Opteron+Nvidia+SATA, and the problems are not repeating on any 1 node, the appear to just randomly hit 1 or 2 nodes out of the test set, and the next day it will be a different one. They are using Sles9SP2, currently we cannot go to SP3 as there are some other bad driver issues unrelated to XFS (the issue preventing us from upgrading also appears to be in 2.6.16.x kernel.org kernels so that is a more than just a SLES issue). I have already had long discussions with Suse with less than useful results. Are there any patches that are likely to either produce more debugging or to get rid of this issue? There are no messages in the messages file when the event happens. Below is a sysrq generated stack trace from one of the machines. The issues do not seem to require heavy IO loads (we have verified that the application is not IO intensive), it may be something related to running short on memory, but we don't have any OOM type messages anywhere. The first type of machine to have the issue and where the issue is alot more common has only 4GB of ram, the second type of machine that has recently starting also having the error has 32GB of ram. Roger xfssyncd D 00000000000493e0 0 2760 1 3876 2755 (L-TLB) Call Trace:{:xfs:kmem_zone_zalloc+50} {:xfs:_xfs_trans_alloc+36} {__down_write+117} {:xfs:xfs_ilock+93} {:xfs:xfs_syncsub+2787} {del_timer_sync+80} {del_singleshot_timer_sync+21} {schedule_timeout+254} {:xfs:vfs_sync+40} {:xfs:vfs_sync_worker+25} {:xfs:xfssyncd+378} {:xfs:linvfs_fill_super+0} {child_rip+8} {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} {child_rip+0} res D 000000000000000a 0 16149 1 26319 16151 5825 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {do_page_fault+536} {sys_newlstat+31} {error_exit+0} {system_call+124} sbatchd D 00000000000493e0 0 16151 1 12686 16149 (NOTLB) Call Trace:{dput+33} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {sys_chdir+138} {sys_select+1244} {system_call+124} gm_mapper D 000000000000000a 0 12686 1 16834 16151 (L-TLB) Call Trace:{:xfs:xfs_trans_log_buf+107} {__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_free_extent+204} {:xfs:xfs_efd_init+68} {:xfs:kmem_zone_alloc+75} {:xfs:kmem_zone_zalloc+50} {:xfs:xfs_itruncate_finish+557} {:xfs:xfs_trans_alloc+217} {sysret_signal+28} {:xfs:xfs_inactive+591} {sysret_signal+28} {__pagevec_free+32} {sysret_signal+28} {:xfs:vn_rele+72} {:xfs:linvfs_clear_inode+18} {clear_inode+155} {generic_delete_inode+245} {iput+158} {dput+389} {__fput+270} {filp_close+126} {put_files_struct+115} {do_exit+1010} {__dequeue_signal+501} {sysret_signal+28} {do_group_exit+232} {get_signal_to_deliver+1175} {do_signal+1179} {do_signal+149} {:gm:gm_linux_ioctl+0} {:gm:gm_linux_ioctl+106} {sys_ioctl+1092} {sys_rt_sigreturn+653} {sysret_signal+28} {ptregscall_common+103} lim D 000000000000000a 0 16834 1 16835 17594 12686 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {save_i387+148} {do_signal+1501} {sys_newlstat+31} {sys_rt_sigaction+148} {system_call+124} pim D 00000000000493e0 0 16835 16834 16870 (NOTLB) Call Trace:{:xfs:xfs_buf_get_flags+877} {:xfs:kmem_zone_alloc+75} {__down+152} {default_wake_function+0} {:xfs:xfs_trans_log_buf+107} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_dir2_createname+278} {:xfs:xfs_ichgtime+301} {:xfs:xfs_create+1359} {:xfs:linvfs_mknod+521} {:xfs:xfs_iunlock+102} {:xfs:xfs_lookup+119} {:xfs:linvfs_lookup+84} {real_lookup+123} {vfs_create+251} {open_namei+464} {filp_open+87} {sys_open+159} {sys_close+229} {system_call+124} elim.uptime D 00000000000493e0 0 16873 1 14418 18756 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} res D 00000000000493e0 0 14323 16149 26319 (NOTLB) Call Trace:{inet_recvmsg+51} {sock_aio_read+346} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+175} {filp_open+87} {sys_open+159} {sys_socket+104} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14418 1 14419 16873 (NOTLB) Call Trace:{wait_on_page_writeback_range_wq+324} {__down+152} {default_wake_function+0} {__down_failed+53} {.text.lock.super+169} {do_sync+42} {sys_sync+62} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14419 1 18864 14418 (NOTLB) Call Trace:{__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_syncsub+2602} {:xfs:vfs_sync+40} {:xfs:linvfs_sync_super+68} {sync_filesystems+223} {do_sync+49} {sys_sync+62} {system_call+124} mktemp D 00000000000493e0 0 17594 1 17656 16834 (NOTLB) Call Trace:{SHATransform+25} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {sys_mkdir+220} {system_call+124} check_EWNstag D 00000000000493e0 0 17620 1 17751 17656 (NOTLB) Call Trace:{do_sync_write+173} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} Oct/27 07:40 am> sh D 00000000000493e0 0 17959 1 17793 17858 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} From owner-xfs@oss.sgi.com Fri Dec 1 10:50:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 10:50:26 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1IoFaG030326 for ; Fri, 1 Dec 2006 10:50:17 -0800 Received: from teal.hq.k1024.org (84-75-119-53.dclient.hispeed.ch [84.75.119.53]) by astra.simleu.ro (Postfix) with ESMTP id C1DE762; Fri, 1 Dec 2006 20:30:46 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id D9E0C40A0B6; Fri, 1 Dec 2006 19:30:34 +0100 (CET) Date: Fri, 1 Dec 2006 19:30:34 +0100 From: Iustin Pop To: Christian Kujau Cc: Jasmin Buchert , xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061201183034.GA20595@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , Jasmin Buchert , xfs@oss.sgi.com References: <20061129174553.e0ef3465.jasmin@pacifica.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Fri, Dec 01, 2006 at 04:23:41AM +0000, Christian Kujau wrote: > On Wed, 29 Nov 2006, Jasmin Buchert wrote: > >Is there any real advantage of making the log size 32-64 MB and > > From 'man mkfs.xfs': > > If the log is contained within the data section and size isn't > specified, mkfs.xfs will try to select a suitable log > size depending on the size of the filesystem. The actual > logsize depends on the filesystem block size and the directory > block size. > > Otherwise, the size suboption is only needed if the log > section of the filesystem should occupy less space than the size > of the special file. > > So, if you're not limited by very special space restrictions, you won't > need the "size" option. I don't understand how you took that conclusion. The explanations refer to the default log size. I believe the original poster asked about the performance advantage of *raising* the log size above the default values for internal logs, and my impression is that metadata-intensive workloads benefit from increasing the log size (however no hard numbers are available). A while back when mkfs.xfs had more conservative default value, bigger log sizes indeed helped for big filesystems. Regards, Iustin From owner-xfs@oss.sgi.com Fri Dec 1 11:23:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 11:23:16 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1JN9aG002122 for ; Fri, 1 Dec 2006 11:23:09 -0800 Received: from [134.15.160.29] (vpn-emea-sw-emea-160-29.emea.sgi.com [134.15.160.29]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB1JMIbj61994154; Fri, 1 Dec 2006 11:22:19 -0800 (PST) Message-ID: <457080EA.1010807@sgi.com> Date: Fri, 01 Dec 2006 19:22:18 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> In-Reply-To: <20061130223810.GO37654165@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9859 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: > >>Dave, >> >>Could you have changed the SB_LOCK from a spinlock to a blocking >>mutex and have achieved a similar effect? > > > Sort of - it would still be inefficient and wouldn't help solve the > underlying causes of contention. Also, everything else that uses > the SB_LOCK would now have a sleep point where there wasn't one > previously. If we are nesting the SB_LOCK somewhere else inside a > another spinlock (not sure if we are) then we can't sleep. I'd > prefer not to change the semantics of such a lock if I can avoid it. That's fair enough and I can't disagree with you. I think the SB_LOCK was/is being abused anyway and was used too genericly (if there's such a word). Using separate locks for specific purposes like you've done with the new mutex is a great start to cleaning this code up. > > I think the slow path code is somewhat clearer with a separate > mutex - it clearly documents the serialisation barrier that > the slow path uses and allows us to do slow path checks on the > per-cpu counters without needing the SB_LOCK. It's certainly an improvement over the original code. > > It also means that in future, we can slowly remove the need for > holding the SB_LOCK across the entire rebalance operation and only > use it when referencing the global superblock fields during > the rebalance. Sounds good. > > If the need arises, it also means we can move to a mutex per counter > so we can independently rebalance different types of counters at the > same time (which we can't do right now). That seems so obvious - I'm surprised we can't do it now. > > >>Has this change had much testing on a large machine? > > > 8p is the largest I've run it on (junkbond) and it's been ENOSPC > tested on a 2.7GB/s filesystem (junkbond once again) as well > as one single, slow disks. > > I've tried and tried to get the ppl that reported the problem to > test this fix but no luck so far (this bug has been open for months > and most of that time has been me waiting for someone to run a > test). I've basically got sick of waiting and I just want to > move this on. It's already too late for sles10sp1 because of > the lack of response. If it's important to them they'll test it. If the change doesn't fix their problem then I'm sure we'll hear from them again. > > >>These changes wouldn't apply cleanly to tot (3 hunks failed in >>xfs_mount.c) but I couldn't see why. > > > Whitespace issue? Try setting: > > $ export QUILT_PATCH_OPTS="--ignore-whitespace" > > I'll apply the patch to a separate tree and see if I hit the same > problem.... > > >>The changes look fine to me, couple of comments below. >> >>Lachlan >> >> >>@@ -1479,9 +1479,11 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, >> case XFS_SBS_IFREE: >> case XFS_SBS_FDBLOCKS: >> if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) { >>- status = xfs_icsb_modify_counters_locked(mp, >>+ XFS_SB_UNLOCK(mp, s); >>+ status = xfs_icsb_modify_counters(mp, >> msbp->msb_field, >> msbp->msb_delta, >> rsvd); >>+ s = XFS_SB_LOCK(mp); >> break; >> } >> /* FALLTHROUGH */ >> >>Is it safe to be releasing the SB_LOCK? > > > Yes. > > >>Is it assumed that the >>superblock wont change while we process the list of xfs_mod_sb >>structures? > > > No. We are applying deltas - it doesn't matter if other deltas are > applied at the same time by other callers because in the end all > the deltas get applied and it adds up to the same thing. Okay. > > >>@@ -1515,11 +1517,12 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, >> case XFS_SBS_IFREE: >> case XFS_SBS_FDBLOCKS: >> if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) >> { >>- status = >>- >>xfs_icsb_modify_counters_locked(mp, >>+ XFS_SB_UNLOCK(mp, s); >>+ status = xfs_icsb_modify_counters(mp, >> msbp->msb_field, >> -(msbp->msb_delta), >> rsvd); >>+ s = XFS_SB_LOCK(mp); >> break; >> } >> /* FALLTHROUGH */ >> >>Same as above. > > > Ditto ;) > > Thanks for looking at this, Lachlan. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Fri Dec 1 12:13:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 12:13:17 -0800 (PST) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1KD8aG008420 for ; Fri, 1 Dec 2006 12:13:09 -0800 Received: from [134.15.160.29] (vpn-emea-sw-emea-160-29.emea.sgi.com [134.15.160.29]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB1JsSqW70033103; Fri, 1 Dec 2006 11:54:29 -0800 (PST) Message-ID: <45708CA1.5090100@sgi.com> Date: Fri, 01 Dec 2006 20:12:17 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <20061201004112.GW37654165@melbourne.sgi.com> In-Reply-To: <20061201004112.GW37654165@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Fri, Dec 01, 2006 at 09:38:11AM +1100, David Chinner wrote: > >>On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: >> >> >>>These changes wouldn't apply cleanly to tot (3 hunks failed in >>>xfs_mount.c) but I couldn't see why. >> >>Whitespace issue? Try setting: >> >>$ export QUILT_PATCH_OPTS="--ignore-whitespace" >> >>I'll apply the patch to a separate tree and see if I hit the same >>problem.... > > > I see the problem - the next patch I am going to send out for > review which is earlier in my series.... > > The growfs fix changes the delta parameter to xfs_icsb_modify_counters() > from int to int64_t, and that is why the hunks don't apply. > > The attached patch should apply (with a 6 line offset to most hunks). > That's even worse - now it loses track of which file it's patching. [lachlan@linux (2.6.x-xfs)2.6.x-xfs]$ patch -p1 -l -i ENOSPC.patch.eml patching file fs/xfs/xfs_mount.c Hunk #2 succeeded at 543 (offset 5 lines). Hunk #3 succeeded at 1485 (offset 6 lines). Hunk #4 succeeded at 1523 (offset 6 lines). Hunk #5 succeeded at 1736 (offset 6 lines). Hunk #6 succeeded at 1758 (offset 6 lines). Hunk #7 succeeded at 1794 (offset 6 lines). Hunk #8 succeeded at 1901 (offset 6 lines). Hunk #9 succeeded at 2021 (offset 6 lines). Hunk #10 succeeded at 2060 (offset 6 lines). Hunk #11 FAILED at 2087. 1 out of 11 hunks FAILED -- saving rejects to file fs/xfs/xfs_mount.c.rej missing header for unified diff at line 256 of patch can't find file to patch at input line 256 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- | break; | -------------------------- File to patch: Skip this patch? [y] Skipping patch. 3 out of 3 hunks ignored patching file fs/xfs/xfs_mount.h It seems to have a problem with line 256 of the patch: @@ -2081,7 +2121,7 @@ again: <---- line 256 lcounter = icsbp->icsb_ifree; lcounter += delta; if (unlikely(lcounter < 0)) - goto slow_path; + goto balance_counter; icsbp->icsb_ifree = lcounter; break; I can't see what's wrong. Don't sweat over it - it's not that important now that the review is done. I'll leave it to you to merge it with tot. Lachlan From owner-xfs@oss.sgi.com Fri Dec 1 12:29:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 12:29:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1KTUaG015432 for ; Fri, 1 Dec 2006 12:29:31 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB1KSfrX028519 for ; Fri, 1 Dec 2006 15:28:41 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB1KSfKk002215 for ; Fri, 1 Dec 2006 15:28:41 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB1KSdqn024592 for ; Fri, 1 Dec 2006 15:28:40 -0500 Message-ID: <45709075.7080906@sandeen.net> Date: Fri, 01 Dec 2006 14:28:37 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: on stack space.... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9861 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs On the issue of stack space & where it goes in xfs... checkstack does not count function call arguments if you pass big-ish structures to functions things get skewed quickly the caller pushes the arguments just before the 'call' and also: btw one thing that helps modern gcc is to move variable declarations into the inner most {} scope possible does it really help? it'll allow it to share stack slots older gccs that was actually -worse- yes xfs was originally largely written that way how recent? 4.1 and later have this fixed lots of irix xfs was written this way IIRC, but I think things got moved out. Maybe it'd help to move them back in, for things like xfs_bmapi... although it's a -penalty- for older gcc's still I think. Anyway, just found that interesting, might help us get some of this under control without a huge amount of refactoring... -Eric From owner-xfs@oss.sgi.com Fri Dec 1 15:59:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 15:59:59 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1NxoaG005694 for ; Fri, 1 Dec 2006 15:59:52 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GqIHU-0007MJ-RG; Sat, 02 Dec 2006 00:59:00 +0100 Date: Fri, 1 Dec 2006 23:59:08 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Iustin Pop cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: <20061201183034.GA20595@teal.hq.k1024.org> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9862 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Fri, 1 Dec 2006, Iustin Pop wrote: > I don't understand how you took that conclusion. The explanations refer > to the default log size. I believe the original poster asked about the > performance advantage of *raising* the log size above the default values > for internal logs, I was under the assumption that the OP asked about altering the size of the log at all and the manpage only states a reason for *decreasing* the logsize. > and my impression is that metadata-intensive > workloads benefit from increasing the log size (however no hard numbers > are available). As no numbers are known to me either, I did not see a point in increasing the log, hence my statement. > A while back when mkfs.xfs had more conservative default value, bigger log > sizes indeed helped for big filesystems. As I've done a few benchmarks[0] for different filesystems lately I might find some time to play around with different fs tweaks... Christian. [0] http://nerdbynature.de/wp/?cat=4 -- BOFH excuse #353: Second-system effect. From owner-xfs@oss.sgi.com Fri Dec 1 16:26:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 16:26:45 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB20QaaG013055 for ; Fri, 1 Dec 2006 16:26:37 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GqIhO-0008CN-VT; Sat, 02 Dec 2006 01:25:47 +0100 Date: Sat, 2 Dec 2006 00:25:54 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Roger Heflin cc: xfs@oss.sgi.com Subject: Re: Issues with XFS on Sles9 sp2. In-Reply-To: <45704570.7020209@atipa.com> Message-ID: References: <45704570.7020209@atipa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9863 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Fri, 1 Dec 2006, Roger Heflin wrote: > converting the machines to ext3 eliminates the issues. Under load > they were seeing 1-2 events per 24 hours on 100 machines. just to be sure: 1-2 machines out of 100 had a hanging XFS in 24h, right? (as opposed to "each of the 100 machines had 1-2 incidents in 24h" ;)) > They are using Sles9SP2, currently we cannot go to SP3 as there > are some other bad driver issues unrelated to XFS (the issue > preventing us from upgrading also appears to be in 2.6.16.x > kernel.org kernels so that is a more than just a SLES issue). So, you can't upgrade to a more current SuSE kernel, but you've already tried vanilla kernels? OK, you won't be able to upgrade to a kernel.org kernel because of the driver issues - but do the XFS hangs go away? Did it happen with earlier SuSE kernels too? > anywhere. The first type of machine to have the issue > and where the issue is alot more common has only 4GB > of ram, the second type of machine that has recently > starting also having the error has 32GB of ram. Shot in the dark: did you try to boot with the "mem=" option? You could try to boot with e.g. "mem=512M" and see if the problem has something to do with memory... Christian. -- BOFH excuse #228: That function is not currently supported, but Bill Gates assures us it will be featured in the next upgrade. From owner-xfs@oss.sgi.com Fri Dec 1 16:44:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 16:44:45 -0800 (PST) Received: from mail.atipa.com (125.14.cm.sunflower.com [24.124.14.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB20iaaG014993 for ; Fri, 1 Dec 2006 16:44:37 -0800 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Issues with XFS on Sles9 sp2. Date: Fri, 1 Dec 2006 18:44:56 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues with XFS on Sles9 sp2. thread-index: AccVqJNVOKYLHK14QIOTqkaBn5YODgAAC7dI References: <45704570.7020209@atipa.com> From: "Roger Heflin" To: "Christian Kujau" Cc: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 4199 X-archive-position: 9864 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rheflin@atipa.com Precedence: bulk X-list: xfs -----Original Message----- From: Christian Kujau [mailto:lists@nerdbynature.de] Sent: Fri 12/1/2006 6:25 PM To: Roger Heflin Cc: xfs@oss.sgi.com Subject: Re: Issues with XFS on Sles9 sp2. >On Fri, 1 Dec 2006, Roger Heflin wrote: >> converting the machines to ext3 eliminates the issues. Under load >> they were seeing 1-2 events per 24 hours on 100 machines. > >just to be sure: 1-2 machines out of 100 had a hanging XFS in 24h, >right? (as opposed to "each of the 100 machines had 1-2 incidents in >24h" ;)) 1-2 machines out of the 100 each 24 hours, different machines will fail the next day if they are under a similar load. >> They are using Sles9SP2, currently we cannot go to SP3 as there >> are some other bad driver issues unrelated to XFS (the issue >> preventing us from upgrading also appears to be in 2.6.16.x >> kernel.org kernels so that is a more than just a SLES issue). > >So, you can't upgrade to a more current SuSE kernel, but you've already >tried vanilla kernels? OK, you won't be able to upgrade to a kernel.org >kernel because of the driver issues - but do the XFS hangs go away? >Did it happen with earlier SuSE kernels too? I tested with the earlier vanilla kernels on only a couple of machines to see if the "other" problems was also in it, as if it was not I might be able to upgrade that specific part and the "other" problem was in the kernel.org kernel, so the new driver was unlikely fix anything so I don't have any data that would tell me if the problem XFS happens or not. We did not find the XFS issue in the testing stage (where the SP3 and kernel.org testing was done), we found the XFS issues in the early production phase. The customer can duplicate it, but those machines are connected by sneakernet, at a remote site. I also don't have similar data on earlier versions of sles as the SP1 setup only uses XFS on a limited number of file servers (no general usage) but on those file servers we have not seen any issues and have ran 4 machine like that for 1.5 years. Though if it were a out of kernel memory issue those machines may not be having that condition happen. The condition does not seem to happen at idle, the machines only lockup with a load on them, we never saw the issue at idle, or with well understood loads (HPL). >> anywhere. The first type of machine to have the issue >> and where the issue is alot more common has only 4GB >> of ram, the second type of machine that has recently >> starting also having the error has 32GB of ram. > >Shot in the dark: did you try to boot with the "mem=" option? >You could try to boot with e.g. "mem=512M" and see if the problem has >something to do with memory... I don't think it has to do with real memory, it may have to do with some resource that is in short supply at some time, like maybe a shortage of kernel memory at the wrong time, the machines have never been observed to fail under idle or under controlled loads (HPL) and we have significant runs times under both of those conditions (ie 20+ times the observed failure time) so far the machines have only failed under production loads, we have yet to be able to duplicate the failure under any test loads. The machines all appear to work correctly under tests like bonnie, and the machines are found with XFS locked up several hours later, so we don't really have a way of catching exactly what happened at the time of the event to cause it, non-xfs file systems still function, and the machine is still usable so long as one avoids the locked up XFS file systems, we only have 1 xfs file system on each machine so I don't know if a second xfs would also be locked up or not. Also these file systems are build on MD stripe arrays, and that may play some part in this. The ext3 filesystems are also build on the same md arrays and work just fine. We used XFS because we observed that ext3's write rates started to drop down significantly after a few minutes of sustained IO rates (much more than was expected from moving to the inner disk tracks), and XFS did not appear to suffer from this issue, so produced more predictable results. Roger [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Dec 2 04:26:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Dec 2006 04:26:27 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB2CQFaG002586 for ; Sat, 2 Dec 2006 04:26:17 -0800 Received: from teal.hq.k1024.org (84-75-116-60.dclient.hispeed.ch [84.75.116.60]) by astra.simleu.ro (Postfix) with ESMTP id 0DEB150; Sat, 2 Dec 2006 14:25:26 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 1B43440A0D2; Sat, 2 Dec 2006 12:15:47 +0100 (CET) Date: Sat, 2 Dec 2006 12:15:46 +0100 From: Iustin Pop To: Christian Kujau Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061202111546.GA18661@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , xfs@oss.sgi.com References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9865 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Fri, Dec 01, 2006 at 11:59:08PM +0000, Christian Kujau wrote: > On Fri, 1 Dec 2006, Iustin Pop wrote: > >I don't understand how you took that conclusion. The explanations refer > >to the default log size. I believe the original poster asked about the > >performance advantage of *raising* the log size above the default values > >for internal logs, > > I was under the assumption that the OP asked about altering the size of > the log at all and the manpage only states a reason for *decreasing* the > logsize. Ah, I see. Sorry for the confusion. > >and my impression is that metadata-intensive > >workloads benefit from increasing the log size (however no hard numbers > >are available). > > As no numbers are known to me either, I did not see a point in > increasing the log, hence my statement. Hmm, I am pretty sure that it makes a difference, but only from personal experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M logs even for big filesystems[0]. Nowadays it chooses a more sane value. > >A while back when mkfs.xfs had more conservative default value, bigger log > >sizes indeed helped for big filesystems. > > As I've done a few benchmarks[0] for different filesystems lately I > might find some time to play around with different fs tweaks... That would be interesting! [0] http://oss.sgi.com/archives/xfs/2002-04/msg00443.html and the corresponding thread, especially http://oss.sgi.com/archives/xfs/2002-04/msg00441.html Iustin From owner-xfs@oss.sgi.com Sun Dec 3 15:50:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 15:50:32 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB3NoKaG032621 for ; Sun, 3 Dec 2006 15:50:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04035; Mon, 4 Dec 2006 10:49:31 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB3NnT7Y52681469; Mon, 4 Dec 2006 10:49:30 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB3NnS9e52691638; Mon, 4 Dec 2006 10:49:28 +1100 (AEDT) Date: Mon, 4 Dec 2006 10:49:28 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC Message-ID: <20061203234928.GA37654165@melbourne.sgi.com> References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457080EA.1010807@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 9872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1873 Lines: 49 On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote: > David Chinner wrote: > >On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: > >I think the slow path code is somewhat clearer with a separate > >mutex - it clearly documents the serialisation barrier that > >the slow path uses and allows us to do slow path checks on the > >per-cpu counters without needing the SB_LOCK. > > It's certainly an improvement over the original code. > > > > >It also means that in future, we can slowly remove the need for > >holding the SB_LOCK across the entire rebalance operation and only > >use it when referencing the global superblock fields during > >the rebalance. > > Sounds good. > > > > >If the need arises, it also means we can move to a mutex per counter > >so we can independently rebalance different types of counters at the > >same time (which we can't do right now). > > That seems so obvious - I'm surprised we can't do it now. Well, the reason I didn't go down this path in the first place was that typically only one type of counter would need rebalancing at a time (e.g. free blocks or free inodes, but not both at the same time). I tested this out on revenue2 with simultaneous creates and deletes of small files but could not cause contention on the single global lock under these loads. i also tried parallel writes of large files with creates and deletes, but hte create/delete was slowed sufficiently by the parallel writes that it once again didn't cause an issue. Hence it didn't seem to be an issue and a single lock simplified the initial implementation. What I'm thinking now is that it may become an issue with MDFS as acheivable create and delete rates should be much higher on one of these filesystems and then it may prove to be an issue. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 3 16:06:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 16:06:44 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB406UaG002209 for ; Sun, 3 Dec 2006 16:06:34 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04381; Mon, 4 Dec 2006 11:05:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id DC19858FF58C; Mon, 4 Dec 2006 11:05:36 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 958790 - Fix xfsidbg.c compiler warnings on ia64 Message-Id: <20061204000536.DC19858FF58C@chook.melbourne.sgi.com> Date: Mon, 4 Dec 2006 11:05:36 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 557 Lines: 17 Fix xfsidbg.c compiler warnings on ia64 Date: Mon Dec 4 11:04:57 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27611a fs/xfs/xfsidbg.c - 1.310 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.310&r2=text&tr2=1.309&f=h - Cast variables with different definitions on 32/64 bit platforms to remove compiler warnings on 64 bit platforms. From owner-xfs@oss.sgi.com Sun Dec 3 16:26:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 16:26:24 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB40QAaG009199 for ; Sun, 3 Dec 2006 16:26:15 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04696; Mon, 4 Dec 2006 11:25:15 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1994758FF58C; Mon, 4 Dec 2006 11:25:15 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952227 - Severe lock contention in xfs_icsb_xxxx running Message-Id: <20061204002515.1994758FF58C@chook.melbourne.sgi.com> Date: Mon, 4 Dec 2006 11:25:15 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1945 Lines: 42 Reduction global superblock lock contention near ENOSPC. The existing per-cpu superblock counter code uses the global superblock spin lock when we approach ENOSPC for global synchronisation. On larger machines than this code was originally tested on this can still get catastrophic spinlock contention due increasing rebalance frequency near ENOSPC. By introducing a sleeping lock that is used to serialise balances and modifications near ENOSPC we prevent contention from needlessly from wasting the CPU time of potentially hundreds of CPUs. To reduce the number of balances occuring, we separate the need rebalance case from the slow allocate case. Now, a counter running dry will trigger a rebalance during which counters are disabled. Any thread that sees a disabled counter enters a different path where it waits on the new mutex. When it gets the new mutex, it checks if the counter is disabled. If the counter is disabled, then we _know_ that we have to use the global counter and lock and it is safe to do so immediately. Otherwise, we drop the mutex and go back to trying the per-cpu counters which we know were re-enabled. Date: Mon Dec 4 11:24:40 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27612a fs/xfs/xfs_mount.h - 1.228 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.228&r2=text&tr2=1.227&f=h - Add a new per-cpu counter synchronisation mutex. fs/xfs/xfs_mount.c - 1.388 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.388&r2=text&tr2=1.387&f=h - Reduce contention on the XFS_SB_LOCK() near ENOSPC by introducing a sleeping mutex for per-cpu superblock counter synchronisation and reworking the slow path to reduce counter rebalance frequency. From owner-xfs@oss.sgi.com Sun Dec 3 17:36:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 17:36:27 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB41aHaG017481 for ; Sun, 3 Dec 2006 17:36:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06205; Mon, 4 Dec 2006 12:35:25 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB41ZN7Y29871513; Mon, 4 Dec 2006 12:35:24 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB41ZKLX52644943; Mon, 4 Dec 2006 12:35:20 +1100 (AEDT) Date: Mon, 4 Dec 2006 12:35:20 +1100 From: David Chinner To: Stephen Pollei Cc: Mike Mattie , "linux-kernel @ vger. kernel. org" , xfs@oss.sgi.com Subject: Re: "BUG: held lock freed!" lock validator tripped by kswapd & xfs Message-ID: <20061204013520.GI44411608@melbourne.sgi.com> References: <20061201095349.2a92c997@reforged> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9875 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1693 Lines: 41 On Fri, Dec 01, 2006 at 02:34:42PM -0800, Stephen Pollei wrote: > On 12/1/06, Mike Mattie wrote: > > >In an attempt to debug another kernel issue I turned on the lock validator > >and > >managed to generate this report. > > > >As a side note the first attempt to boot with the lock validator failed > >with > >a message indicating I had exceeded MAX_LOCK_DEPTH. To get this trace > >I patched sched.h: MAX_LOCK_DEPTH to 60. > > > >Dec 1 08:35:41 reforged [ 3052.513931] ========================= > >Dec 1 08:35:41 reforged [ 3052.513937] [ BUG: held lock freed! ] > >Dec 1 08:35:41 reforged [ 3052.513939] ------------------------- > >Dec 1 08:35:41 reforged [ 3052.513943] kswapd0/183 is freeing memory > >c3458000-c3458fff, with a lock still held there! Dec 1 08:35:41 > >reforged [ 3052.513947] (&(&ip->i_iolock)->mr_lock){....}, at: > >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged > >[ 3052.513959] 28 locks held by kswapd0/183: Dec 1 08:35:41 reforged > >[ 3052.513961] #0: (&(&ip->i_iolock)->mr_lock){....}, at: > >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged > >[ 3052.513968] #1: (&(&ip->i_lock)->mr_lock){....}, at: [] > >xfs_ilock+0x52/0x75 Dec 1 08:35:41 reforged [ 3052.513975] > > seems to alternate between same two locks. But both c0222289 and > c02222bb are not between the page(oxfff=4095 or about 4k) which kswapd > is trying to get rid of. > I think this trace is on crack somehow. IIRC, lockdep doesn't understand the xfs inode locks yet. We've got a patch to fix most of this, but I don't think it's been merged. Cheers, Dave -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 4 03:34:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 03:35:06 -0800 (PST) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4BYvaG002796 for ; Mon, 4 Dec 2006 03:34:59 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id kB4BY6si011799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Dec 2006 12:34:06 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id kB4BY6UV011797; Mon, 4 Dec 2006 12:34:06 +0100 Date: Mon, 4 Dec 2006 12:34:06 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] remove v_number Message-ID: <20061204113406.GC11074@lst.de> References: <20061129154729.GC6400@lst.de> <20061130003050.GG33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061130003050.GG33919298@melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 9876 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1234 Lines: 25 On Thu, Nov 30, 2006 at 11:30:50AM +1100, David Chinner wrote: > On Wed, Nov 29, 2006 at 04:47:29PM +0100, Christoph Hellwig wrote: > > v_number is unused except for the naming some locks (which is a > > functionality totally unused by Linux), so remove it and assorted > > crap. Besides saving two words in struct vnode this also gets rid > > of a spinlock per inode allocation. > > Hmm - given that I've just used the v_number in post-mortem analysis > of a nasty bug to correlate the sequence of events during a series > of mkdir operations (i.e. transactions in the incore log buffers, > the resulting xfs_inodes and some screwed up dentries) that lead to > a BUG_ON being tripped in d_instantiate. > > So, while it appears to be unused, it is _very_ useful for > determining the SOE that has occurred in certain types of problems. > > FWIW, while analysing this crash dump a couple of days ago I was > wishing that dentries had an equivalent sequence number because > there is no way to tell what dentry was supposed to be related to > what inode after it got screwed up... Putting in sequence counting is trivial using kprobes. Will you put in this patch after I write you a kprobes modules to do the sequence numbering? From owner-xfs@oss.sgi.com Mon Dec 4 08:20:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 08:20:49 -0800 (PST) Received: from mcvs4.priv.usm.edu (smtp.usm.edu [131.95.82.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4GKdaG027896 for ; Mon, 4 Dec 2006 08:20:41 -0800 Received: from anakin ([131.95.175.215]) by mcvs4.priv.usm.edu (8.12.11/8.12.11) with ESMTP id kB4GVdwV031915 for ; Mon, 4 Dec 2006 10:31:39 -0600 Message-Id: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> From: "Robert Johnson" To: Subject: Xfs errors: Date: Mon, 4 Dec 2006 09:47:46 -0600 Organization: iTech- TIU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccXu4sQQSvOIm7HRK+EshHA17F+IA== X-archive-position: 9878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: robert.e.johnson@usm.edu Precedence: bulk X-list: xfs Content-Length: 897 Lines: 24 I have just installed and configured a xfs file system on Redhat AS4 server, running on IBM eServer 366 platform. The file system was carved out of our EMC SAN, with Qlogic HBA dual port fiber channel cards. The error message is as follows: Dec 4 09:43:11 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:43:14 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:43:15 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:44:44 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x2d0) -------------------------------------------- R.E. Johnson, Linux Systems Administrator Disaster Recovery Administrator University of Southern Mississippi iTech, Technology Infrastructure Unit robert.e.johnson@usm.edu ------------------------------------------- From owner-xfs@oss.sgi.com Mon Dec 4 09:54:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 09:54:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4Hs0aG008383 for ; Mon, 4 Dec 2006 09:54:01 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB4HrATx029341; Mon, 4 Dec 2006 12:53:10 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB4HrAU5001576; Mon, 4 Dec 2006 12:53:10 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB4Hr755009834; Mon, 4 Dec 2006 12:53:09 -0500 Message-ID: <45746082.2090403@sandeen.net> Date: Mon, 04 Dec 2006 11:53:06 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Robert Johnson CC: xfs@oss.sgi.com Subject: Re: Xfs errors: References: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> In-Reply-To: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9879 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 796 Lines: 22 Robert Johnson wrote: > I have just installed and configured a xfs file system on Redhat AS4 server, RHEL4 doesn't support xfs ;-) > running on IBM eServer 366 platform. The file system was carved out of our > EMC SAN, with Qlogic HBA dual port fiber channel cards. The error message is > as follows: > > Dec 4 09:43:11 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:43:14 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:43:15 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:44:44 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x2d0) You might have highly fragmented files, and xfs_fsr might help with this... -Eric From owner-xfs@oss.sgi.com Mon Dec 4 13:57:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 13:57:51 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB4LvdaG014737 for ; Mon, 4 Dec 2006 13:57:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14131; Tue, 5 Dec 2006 08:56:40 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB4Lud7Y53620000; Tue, 5 Dec 2006 08:56:39 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB4LuaYI53617980; Tue, 5 Dec 2006 08:56:36 +1100 (AEDT) Date: Tue, 5 Dec 2006 08:56:36 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs@oss.sgi.com Subject: Re: [PATCH] remove v_number Message-ID: <20061204215636.GM33919298@melbourne.sgi.com> References: <20061129154729.GC6400@lst.de> <20061130003050.GG33919298@melbourne.sgi.com> <20061204113406.GC11074@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061204113406.GC11074@lst.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 9881 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2169 Lines: 53 On Mon, Dec 04, 2006 at 12:34:06PM +0100, Christoph Hellwig wrote: > On Thu, Nov 30, 2006 at 11:30:50AM +1100, David Chinner wrote: > > On Wed, Nov 29, 2006 at 04:47:29PM +0100, Christoph Hellwig wrote: > > > v_number is unused except for the naming some locks (which is a > > > functionality totally unused by Linux), so remove it and assorted > > > crap. Besides saving two words in struct vnode this also gets rid > > > of a spinlock per inode allocation. > > > > Hmm - given that I've just used the v_number in post-mortem analysis > > of a nasty bug to correlate the sequence of events during a series > > of mkdir operations (i.e. transactions in the incore log buffers, > > the resulting xfs_inodes and some screwed up dentries) that lead to > > a BUG_ON being tripped in d_instantiate. > > > > So, while it appears to be unused, it is _very_ useful for > > determining the SOE that has occurred in certain types of problems. > > > > FWIW, while analysing this crash dump a couple of days ago I was > > wishing that dentries had an equivalent sequence number because > > there is no way to tell what dentry was supposed to be related to > > what inode after it got screwed up... > > Putting in sequence counting is trivial using kprobes. Never used kprobes - I'll take your word that it's easy.... > Will you put > in this patch after I write you a kprobes modules to do the sequence > numbering? I wasn't NACKing your patch - I was making the point that this apparently unused code does have some useful, non-obvious, redeeming features. Pardon my lack of kprobes knowledge, but what is the point of removing this code if we have to then go and add kprobes instrumentation to every XFS installation we support to provide the same information? Where does the kprobes data get kept? In the kernel, or partially in kernel and in userspace? How would you correlate the sequence number and the vnode from the crash dump? How much extra runtime memory does it use? I'm not saying no, Christoph - I'm just trying to understand the implications of what you are suggesting.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 5 04:00:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 04:00:31 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5C0NaG020519 for ; Tue, 5 Dec 2006 04:00:24 -0800 Received: from [194.173.12.131] (helo=[172.25.16.7]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GrYl51Bwu-0003BV; Tue, 05 Dec 2006 12:46:48 +0100 Message-ID: <45755C26.2080505@gmx.net> Date: Tue, 05 Dec 2006 12:46:46 +0100 From: Klaus Strebel User-Agent: Thunderbird 3.0a1 (Windows/20061204) MIME-Version: 1.0 To: David Chinner CC: Lachlan McIlroy , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> In-Reply-To: <20061203234928.GA37654165@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 9883 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: xfs Content-Length: 2409 Lines: 62 David Chinner wrote: > On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: >>> I think the slow path code is somewhat clearer with a separate >>> mutex - it clearly documents the serialisation barrier that >>> the slow path uses and allows us to do slow path checks on the >>> per-cpu counters without needing the SB_LOCK. >> It's certainly an improvement over the original code. >> >>> It also means that in future, we can slowly remove the need for >>> holding the SB_LOCK across the entire rebalance operation and only >>> use it when referencing the global superblock fields during >>> the rebalance. >> Sounds good. >> >>> If the need arises, it also means we can move to a mutex per counter >>> so we can independently rebalance different types of counters at the >>> same time (which we can't do right now). >> That seems so obvious - I'm surprised we can't do it now. > > Well, the reason I didn't go down this path in the first place > was that typically only one type of counter would need rebalancing > at a time (e.g. free blocks or free inodes, but not both at the > same time). I tested this out on revenue2 with simultaneous creates > and deletes of small files but could not cause contention on the > single global lock under these loads. i also tried parallel > writes of large files with creates and deletes, but hte create/delete > was slowed sufficiently by the parallel writes that it once again > didn't cause an issue. > > Hence it didn't seem to be an issue and a single lock simplified > the initial implementation. What I'm thinking now is that it may > become an issue with MDFS as acheivable create and delete rates > should be much higher on one of these filesystems and then it may > prove to be an issue. > > Cheers, > > Dave. Hi guys, just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks like nobody tested on a single processor config ?? Ciao Klaus -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-xfs@oss.sgi.com Tue Dec 5 10:15:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 10:15:26 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5IFHaG010040 for ; Tue, 5 Dec 2006 10:15:19 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GreN1-0003Cf-0v; Tue, 05 Dec 2006 18:46:19 +0100 Date: Tue, 5 Dec 2006 17:46:15 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Iustin Pop cc: xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions In-Reply-To: <20061202111546.GA18661@teal.hq.k1024.org> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9884 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 553 Lines: 17 On Sat, 2 Dec 2006, Iustin Pop wrote: > Hmm, I am pretty sure that it makes a difference, but only from personal > experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > logs even for big filesystems[0]. Nowadays it chooses a more sane value. I could not stand my own curiosity, so here it is: http://nerdbynature.de/wp/?cat=4 I think I'll repeat the benchmarks with bigger test sizes. The testscript can easily be adjusted to test more options/values. Christian. -- BOFH excuse #248: Too much radiation coming from the soil. From owner-xfs@oss.sgi.com Tue Dec 5 11:39:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 11:39:14 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5Jd4aG020686 for ; Tue, 5 Dec 2006 11:39:06 -0800 Received: from teal.hq.k1024.org (84-75-117-178.dclient.hispeed.ch [84.75.117.178]) by astra.simleu.ro (Postfix) with ESMTP id EB35159; Tue, 5 Dec 2006 21:38:13 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 2D66E40A0B2; Tue, 5 Dec 2006 19:44:56 +0100 (CET) Date: Tue, 5 Dec 2006 19:44:56 +0100 From: Iustin Pop To: Christian Kujau Cc: xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions Message-ID: <20061205184456.GA12989@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , xfs@oss.sgi.com, jasmin@pacifica.ch References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 728 Lines: 18 On Tue, Dec 05, 2006 at 05:46:15PM +0000, Christian Kujau wrote: > On Sat, 2 Dec 2006, Iustin Pop wrote: > >Hmm, I am pretty sure that it makes a difference, but only from personal > >experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > >logs even for big filesystems[0]. Nowadays it chooses a more sane value. > > I could not stand my own curiosity, so here it is: > http://nerdbynature.de/wp/?cat=4 > > I think I'll repeat the benchmarks with bigger test sizes. The > testscript can easily be adjusted to test more options/values. Hmm, I see tests with 32M logs and 64M logs. Try running the file creation/deletion test also with 4M, 8M, 16M, and then I'll think there will be a difference. Iustin From owner-xfs@oss.sgi.com Tue Dec 5 13:28:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 13:28:12 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB5LS0aG009034 for ; Tue, 5 Dec 2006 13:28:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02123; Wed, 6 Dec 2006 08:26:59 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB5LQt7Y54218361; Wed, 6 Dec 2006 08:26:56 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB5LQn7g54725915; Wed, 6 Dec 2006 08:26:49 +1100 (AEDT) Date: Wed, 6 Dec 2006 08:26:49 +1100 From: David Chinner To: Christian Kujau Cc: Iustin Pop , xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions Message-ID: <20061205212649.GV44411608@melbourne.sgi.com> References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9886 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1269 Lines: 37 On Tue, Dec 05, 2006 at 05:46:15PM +0000, Christian Kujau wrote: > On Sat, 2 Dec 2006, Iustin Pop wrote: > >Hmm, I am pretty sure that it makes a difference, but only from personal > >experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > >logs even for big filesystems[0]. Nowadays it chooses a more sane value. > > I could not stand my own curiosity, so here it is: > http://nerdbynature.de/wp/?cat=4 One line summary: "The results however are a bit boring and I for one have no reason to tweak these options for a desktop machine." For that data set size you tested. However you might find a difference if your tests actually write the data back to disk because a lot of the tests are running out of cache. > I think I'll repeat the benchmarks with bigger test sizes. The > testscript can easily be adjusted to test more options/values. I think you need to to have any hope of demonstrating a difference in performance from the mkfs/mount options. Typically, you need to be writing/reading files at least 2x the size of memory and create/delete a fileset of at least 1,000,000 files to really determine differences in performance from these parameters... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 5 13:56:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 13:56:11 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB5Lu1aG011740 for ; Tue, 5 Dec 2006 13:56:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA03187; Wed, 6 Dec 2006 08:55:08 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB5Lt67Y54707816; Wed, 6 Dec 2006 08:55:07 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB5Lt4u154716683; Wed, 6 Dec 2006 08:55:04 +1100 (AEDT) Date: Wed, 6 Dec 2006 08:55:04 +1100 From: David Chinner To: Klaus Strebel Cc: David Chinner , Lachlan McIlroy , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC Message-ID: <20061205215503.GW44411608@melbourne.sgi.com> References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> <45755C26.2080505@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45755C26.2080505@gmx.net> User-Agent: Mutt/1.4.2.1i X-archive-position: 9887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 4748 Lines: 162 On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: > Hi guys, > > just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and > tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB > is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. > Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks > like nobody tested on a single processor config ?? Sorry - my bad. The code did not change for UP, so I didn't think to test it. The patch below abstracts the icsb_mutex so that it doesn't get directly referenced by code outside the per-cpu counter code. Builds with and without HAVE_PERCPU_SB defined. I'll run a test cycle on it and get it fixed up. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_mount.c | 23 ++++++++++++----------- fs/xfs/xfs_mount.h | 20 ++++++++++++++++++++ 2 files changed, 32 insertions(+), 11 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2006-12-04 11:33:54.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2006-12-06 08:43:25.389157507 +1100 @@ -536,11 +536,11 @@ xfs_readsb(xfs_mount_t *mp, int flags) ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); } - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); xfs_icsb_balance_counter(mp, XFS_SBS_ICOUNT, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_IFREE, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); mp->m_sb_bp = bp; xfs_buf_relse(bp); @@ -1726,17 +1726,17 @@ xfs_icsb_cpu_notify( memset(cntp, 0, sizeof(xfs_icsb_cnts_t)); break; case CPU_ONLINE: - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); xfs_icsb_balance_counter(mp, XFS_SBS_ICOUNT, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_IFREE, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); break; case CPU_DEAD: /* Disable all the counters, then fold the dead cpu's * count into the total on the global superblock and * re-enable the counters. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); s = XFS_SB_LOCK(mp); xfs_icsb_disable_counter(mp, XFS_SBS_ICOUNT); xfs_icsb_disable_counter(mp, XFS_SBS_IFREE); @@ -1755,7 +1755,7 @@ xfs_icsb_cpu_notify( xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, XFS_ICSB_SB_LOCKED, 0); XFS_SB_UNLOCK(mp, s); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); break; } @@ -1803,6 +1803,7 @@ xfs_icsb_destroy_counters( unregister_hotcpu_notifier(&mp->m_icsb_notifier); free_percpu(mp->m_sb_cnts); } + mutex_destroy(&mp->m_icsb_mutex); } STATIC_INLINE void @@ -2146,7 +2147,7 @@ slow_path: * the superblock lock. We still need to hold the superblock * lock, however, when we modify the global structures. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); /* * Now running atomically. @@ -2155,7 +2156,7 @@ slow_path: * Drop the lock and try again in the fast path.... */ if (!(xfs_icsb_counter_disabled(mp, field))) { - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); goto again; } @@ -2182,7 +2183,7 @@ slow_path: */ if (ret != ENOSPC) xfs_icsb_balance_counter(mp, field, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); return ret; balance_counter: @@ -2195,7 +2196,7 @@ balance_counter: * do more balances than strictly necessary but it is not * the common slowpath case. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); /* * running atomically. @@ -2206,7 +2207,7 @@ balance_counter: * another balance operation being required. */ xfs_icsb_balance_counter(mp, field, 0, delta); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); goto again; } Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.h 2006-12-04 11:33:56.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.h 2006-12-06 08:43:18.630046128 +1100 @@ -576,6 +576,26 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, } /* + * Per-cpu superblock locking functions + */ +#ifdef HAVE_PERCPU_SB +STATIC_INLINE void +xfs_icsb_lock(xfs_mount_t *mp) +{ + mutex_lock(&mp->m_icsb_mutex); +} + +STATIC_INLINE void +xfs_icsb_unlock(xfs_mount_t *mp) +{ + mutex_unlock(&mp->m_icsb_mutex); +} +#else +#define xfs_icsb_lock(mp) +#define xfs_icsb_unlock(mp) +#endif + +/* * This structure is for use by the xfs_mod_incore_sb_batch() routine. * xfs_growfs can specify a few fields which are more than int limit */ From owner-xfs@oss.sgi.com Tue Dec 5 14:29:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 14:29:16 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5MT7aG015152 for ; Tue, 5 Dec 2006 14:29:08 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Grily-00076E-L7; Tue, 05 Dec 2006 23:28:22 +0100 Date: Tue, 5 Dec 2006 22:28:18 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: Iustin Pop , xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: <20061205212649.GV44411608@melbourne.sgi.com> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9888 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 1032 Lines: 31 On Wed, 6 Dec 2006, David Chinner wrote: > For that data set size you tested. However you might find a > difference if your tests actually write the data back to disk > because a lot of the tests are running out of cache. Ha, thanks for reminding me! Now I remember why all my other tests were done with 2GB of data, having 1GB of RAM ;) > Typically, you need to be writing/reading files at least 2x the > size of memory I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... > and create/delete a fileset of at least 1,000,000 > files to really determine differences in performance from hm, that would be 'bonnie++ -n 1000' instead of the "-n 100" I'm testing right now. Thanks for the hints, David! If you/someone know any better/closer-to-real-usage benchmarks, please let me know. I'm testing with bonnie++ because it I don't know any better. is iozone any good? is tiobench still worth to try? Christian. -- BOFH excuse #208: Your mail is being routed through Germany ... and they're censoring us. From owner-xfs@oss.sgi.com Tue Dec 5 15:07:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 15:07:34 -0800 (PST) Received: from page.mel.office.aconex.com (eth2333.vic.adsl.internode.on.net [150.101.159.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5N7PaG018926 for ; Tue, 5 Dec 2006 15:07:28 -0800 Received: from localhost (page.mel.aconex.com [127.0.0.1]) by page.mel.office.aconex.com (Postfix) with ESMTP id 38D9453420D; Wed, 6 Dec 2006 10:06:23 +1100 (EST) Received: from page.mel.office.aconex.com ([127.0.0.1]) by localhost (mail.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22276-01-99; Wed, 6 Dec 2006 10:06:21 +1100 (EST) Received: from edge (unknown [192.168.0.246]) by page.mel.office.aconex.com (Postfix) with ESMTP id D7A3F534205; Wed, 6 Dec 2006 10:06:21 +1100 (EST) Subject: Recent changes in xfsprogs From: Nathan Scott Reply-To: nscott@aconex.com To: bnaujok@sgi.com Cc: xfs@oss.sgi.com Content-Type: text/plain Organization: Aconex Date: Wed, 06 Dec 2006 10:06:10 +1100 Message-Id: <1165359970.1281.51.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9889 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 936 Lines: 29 Yo Barry, xfsprogs/doc/CHANGES - Rename include/list.h to xfs_list.h so that other applications do not accidentally use it. What was the problem here? This doesnt sound like the right fix - there should be no applications outside of the XFS userspace that use libxfs.h - thats what is for (exactly this reason, preventing namespace collision, by reducing all the XFS internals being exposed). Also, there seems to be lots of checkin mail not making it out to oss.sgi.com (let alone review mail), making it difficult for people to keep up to date with changes (and keep distros, like Debian, uptodate) ... could y'all make some effort to keep us "on the outside" in the loop? Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html with recent changes either - seems like progress has come to a halt to those of us no longer in the secret cabal, anyway ;) ... just FYI. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Dec 5 17:50:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 17:50:32 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB61oLaG009568 for ; Tue, 5 Dec 2006 17:50:23 -0800 Received: from [134.14.55.18] (dhcp18.melbourne.sgi.com [134.14.55.18]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10744; Wed, 6 Dec 2006 12:49:23 +1100 Message-ID: <457621A2.7000605@melbourne.sgi.com> Date: Wed, 06 Dec 2006 12:49:22 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: nscott@aconex.com CC: bnaujok@sgi.com, xfs@oss.sgi.com Subject: Re: Recent changes in xfsprogs References: <1165359970.1281.51.camel@edge> In-Reply-To: <1165359970.1281.51.camel@edge> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1698 Lines: 52 Nathan, Nathan Scott wrote: > Yo Barry, > > xfsprogs/doc/CHANGES > > - Rename include/list.h to xfs_list.h so that other applications > do not accidentally use it. > > What was the problem here? This doesnt sound like the right fix - > there should be no applications outside of the XFS userspace that > use libxfs.h - thats what is for (exactly this reason, > preventing namespace collision, by reducing all the XFS internals > being exposed). > A classic problem with cpp is that it is possible for someone else to introduce a header that breaks your build. By introducing a header called list.h, a very common name, we have exposed products whose build may not have strictly doing the right thing (adding /usr/include/xfs to their include path) to pulling in this file rather than the one they intended. So strictly speaking XFS was doing nothing wrong, but its a simple change for us to make to be more friendly. The application that had this problem has also been fixed to use . > Also, there seems to be lots of checkin mail not making it out to > oss.sgi.com (let alone review mail), making it difficult for people > to keep up to date with changes (and keep distros, like Debian, > uptodate) ... could y'all make some effort to keep us "on the > outside" in the loop? > True, not everything has been escaping of late. > Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html > with recent changes either - seems like progress has come to a > halt to those of us no longer in the secret cabal, anyway ;) ... > just FYI. > Its now on my list of things to do. David -- David Chatterton XFS Engineering Manager SGI Australia From owner-xfs@oss.sgi.com Tue Dec 5 18:09:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 18:09:44 -0800 (PST) Received: from page.mel.office.aconex.com (eth2333.vic.adsl.internode.on.net [150.101.159.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB629aaG012288 for ; Tue, 5 Dec 2006 18:09:37 -0800 Received: from localhost (page.mel.aconex.com [127.0.0.1]) by page.mel.office.aconex.com (Postfix) with ESMTP id 9A891534117; Wed, 6 Dec 2006 13:08:34 +1100 (EST) Received: from page.mel.office.aconex.com ([127.0.0.1]) by localhost (mail.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01371-01-78; Wed, 6 Dec 2006 13:08:32 +1100 (EST) Received: from edge (unknown [192.168.0.246]) by page.mel.office.aconex.com (Postfix) with ESMTP id A0EEC534197; Wed, 6 Dec 2006 13:08:32 +1100 (EST) Subject: Re: Recent changes in xfsprogs From: Nathan Scott Reply-To: nscott@aconex.com To: chatz@melbourne.sgi.com Cc: bnaujok@sgi.com, xfs@oss.sgi.com In-Reply-To: <457621A2.7000605@melbourne.sgi.com> References: <1165359970.1281.51.camel@edge> <457621A2.7000605@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Wed, 06 Dec 2006 13:08:22 +1100 Message-Id: <1165370902.1281.72.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9891 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1639 Lines: 44 On Wed, 2006-12-06 at 12:49 +1100, David Chatterton wrote: > ... > A classic problem with cpp is that it is possible for someone else to > introduce a header that breaks your build. Heh, its a poor tradesman who blames his tools. :) > By introducing a header > called list.h, a very common name, we have exposed products whose build > may not have strictly doing the right thing (adding /usr/include/xfs to > their include path) to pulling in this file rather than the one they > intended. Well, clearly they're doing the wrong thing. We've now introduced a half-baked scheme where one random header is inconsistent with the rest, because of some other broken application. That's dopey. The convention there now is such that its easy to tell what include/ files have kernel counterparts (the xfs_* prefixed ones), and the rest are generically named (list.h, cache.h, parent.h, paths.h, linux.h, etc). This change now makes list.h sit in no-mans-land... please revert it back, since the app is fixed anyway (you are also, of course, ignoring the flip side of your own argument, which is that other equally broken apps could be using , which moved and hence broke their builds). You can't win by pandering to broken 3rd party applications... best you can do is keep the XFS stuff sane and internally consistent. > > Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html > > with recent changes either - seems like progress has come to a > > halt to those of us no longer in the secret cabal, anyway ;) ... > > just FYI. > > > > Its now on my list of things to do. > Great - thanks! cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 6 00:44:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 00:44:48 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB68idaG006283 for ; Wed, 6 Dec 2006 00:44:40 -0800 Received: from [134.15.160.6] (vpn-emea-sw-emea-160-6.emea.sgi.com [134.15.160.6]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB68hmbj62947159; Wed, 6 Dec 2006 00:43:49 -0800 (PST) Message-ID: <457682C3.6000802@sgi.com> Date: Wed, 06 Dec 2006 08:43:47 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: Klaus Strebel , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> <45755C26.2080505@gmx.net> <20061205215503.GW44411608@melbourne.sgi.com> In-Reply-To: <20061205215503.GW44411608@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9892 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 1080 Lines: 36 David Chinner wrote: > On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: > >>Hi guys, >> >>just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and >>tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB >>is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. >>Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks >>like nobody tested on a single processor config ?? > > > Sorry - my bad. The code did not change for UP, so I didn't think to > test it. The patch below abstracts the icsb_mutex so that it > doesn't get directly referenced by code outside the per-cpu counter > code. Builds with and without HAVE_PERCPU_SB defined. > > I'll run a test cycle on it and get it fixed up. > > Cheers, > > Dave. @@ -1803,6 +1803,7 @@ xfs_icsb_destroy_counters( unregister_hotcpu_notifier(&mp->m_icsb_notifier); free_percpu(mp->m_sb_cnts); } + mutex_destroy(&mp->m_icsb_mutex); } Do you need to abstract the call to mutex_destroy too? The rest of the change looks good. Lachlan From owner-xfs@oss.sgi.com Wed Dec 6 07:58:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 07:58:51 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB6FwfaG024879 for ; Wed, 6 Dec 2006 07:58:44 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Grz9g-0007JM-Mh for xfs@oss.sgi.com; Wed, 06 Dec 2006 16:57:56 +0100 Date: Wed, 6 Dec 2006 15:57:55 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9894 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 295 Lines: 14 On Tue, 5 Dec 2006, Christian Kujau wrote: > I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... took 16hrs to complete, wow: http://nerdbynature.de/bench/amd64/2.6.19-git7_xfs.2/ http://nerdbynature.de/wp/?cat=4 C. -- BOFH excuse #293: You must've hit the wrong any key. From owner-xfs@oss.sgi.com Wed Dec 6 14:10:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 14:10:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB6MA8aG001475 for ; Wed, 6 Dec 2006 14:10:12 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB6M8F5x005672; Wed, 6 Dec 2006 17:08:15 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB6M8F1u028093; Wed, 6 Dec 2006 17:08:15 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB6M8Dsp010360; Wed, 6 Dec 2006 17:08:14 -0500 Message-ID: <45773F4D.4040800@sandeen.net> Date: Wed, 06 Dec 2006 16:08:13 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: nscott@aconex.com CC: bnaujok@sgi.com, xfs@oss.sgi.com Subject: Re: Recent changes in xfsprogs References: <1165359970.1281.51.camel@edge> In-Reply-To: <1165359970.1281.51.camel@edge> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9897 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 336 Lines: 12 Nathan Scott wrote: > Also, there seems to be lots of checkin mail not making it out to > oss.sgi.com (let alone review mail), making it difficult for people > to keep up to date with changes (and keep distros, like Debian, > uptodate) ... could y'all make some effort to keep us "on the > outside" in the loop? here here! :) -Eric From owner-xfs@oss.sgi.com Wed Dec 6 15:56:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 15:56:15 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB6Nu5aG014198 for ; Wed, 6 Dec 2006 15:56:07 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05425; Tue, 7 Nov 2006 17:32:26 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5E2B458FA27C; Tue, 7 Nov 2006 17:32:26 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 956832 - Fix xfs_iunpin() sets I_DIRTY_SYNC after clear_inode() Message-Id: <20061107063226.5E2B458FA27C@chook.melbourne.sgi.com> Date: Tue, 7 Nov 2006 17:32:26 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9899 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2398 Lines: 47 Prevent a deadlock when xfslogd unpins inodes. The previous fixes for the use after free in xfs_iunpin left a nasty log deadlock when xfslogd unpinned the inode and dropped the last reference to the inode. the ->clear_inode() method can issue transactions, and if the log was full, the transaction could push on the log and get stuck trying to push the inode it was currently unpinning. To fix this, we provide xfs_iunpin a guarantee that it will always have a valid xfs_inode <-> linux inode link or a particular flag will be set on the inode. We then use log forces during lookup to ensure transactions are completed before we recycle the inode. This ensures that xfs_iunpin will never use the linux inode after it is being freed, and any lookup on an inode on the reclaim list will wait until it is safe to attach a new linux inode to the xfs inode. Date: Tue Nov 7 17:31:17 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: stripathi@agami.com,t-nagano@ah.jp.nec.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27359a fs/xfs/xfs_vnodeops.c - 1.687 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.687&r2=text&tr2=1.686&f=h - Set the reclaimable flag before we break the xfs inode - linux inode link so that xfs_iunpin doesn't have to deal with linux-inode use-after-free conditions during inode reclaim. fs/xfs/xfs_iget.c - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h - If we find a reclaimable inode, make sure it is not pinned before we reuse it so we don't get inode unpinning running incorrectly on a new linux inode. Also ensure that we don't remove unlinked reclaimable inodes from the reclaim list which would cause them to leak. fs/xfs/xfs_inode.c - 1.454 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.454&r2=text&tr2=1.453&f=h - Remove the igrab/iput form xfs_iunpin and provide it with a guarantee that either the inode will be marked reclaimable or the xfs inode - linux inode link will be intact. This fixes a deadlock that calling iput() from the xfslogd can trigger while also providing us a reliable method for avoiding use-after-free of the linux inode. From owner-xfs@oss.sgi.com Wed Dec 6 16:46:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 16:47:00 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB70kmaG023128 for ; Wed, 6 Dec 2006 16:46:51 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04190; Wed, 22 Nov 2006 18:01:18 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 9C5FB58CF865; Wed, 22 Nov 2006 18:01:18 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 958469 - Quiet mounts on XFS aren't Message-Id: <20061122070118.9C5FB58CF865@chook.melbourne.sgi.com> Date: Wed, 22 Nov 2006 18:01:18 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9900 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 598 Lines: 19 Make quiet mounts quiet The XFS quiet mount logic was inverted making quiet mounts noisy and vice versa. Fix it. Date: Wed Nov 22 18:00:45 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net,tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27520a fs/xfs/xfs_error.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h - Fix xfs_fs_mount_cmn_err() quiet flag logic inversion. From owner-xfs@oss.sgi.com Wed Dec 6 16:47:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 16:47:15 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB70l2aG023174 for ; Wed, 6 Dec 2006 16:47:05 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04824; Tue, 7 Nov 2006 17:01:43 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 0CFA558FA27C; Tue, 7 Nov 2006 17:01:42 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 956832 - xfs_iunpin() sets I_DIRTY_SYNC after clear_inode() Message-Id: <20061107060143.0CFA558FA27C@chook.melbourne.sgi.com> Date: Tue, 7 Nov 2006 17:01:42 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9901 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1288 Lines: 32 Clean up i_flags and i_flags_lock handling. Date: Tue Nov 7 17:00:11 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nscott@aconex.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27358a fs/xfs/xfs_vnodeops.c - 1.686 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.686&r2=text&tr2=1.685&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_iget.c - 1.223 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_inode.c - 1.453 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.453&r2=text&tr2=1.452&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_inode.h - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h - define common i_flags handling functions. fs/xfs/linux-2.6/xfs_super.c - 1.373 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.373&r2=text&tr2=1.372&f=h - Use prepackaged i_flags handling functions. From owner-xfs@oss.sgi.com Wed Dec 6 17:24:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 17:24:45 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB71OaaG028414 for ; Wed, 6 Dec 2006 17:24:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24668; Thu, 7 Dec 2006 12:23:41 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB71Nd7Y55668941; Thu, 7 Dec 2006 12:23:40 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB71Ncjq55707662; Thu, 7 Dec 2006 12:23:38 +1100 (AEDT) Date: Thu, 7 Dec 2006 12:23:38 +1100 From: David Chinner To: Christian Kujau Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061207012338.GK44411608@melbourne.sgi.com> References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9902 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 748 Lines: 26 On Wed, Dec 06, 2006 at 03:57:55PM +0000, Christian Kujau wrote: > On Tue, 5 Dec 2006, Christian Kujau wrote: > >I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... > > took 16hrs to complete, wow: > > http://nerdbynature.de/bench/amd64/2.6.19-git7_xfs.2/ > http://nerdbynature.de/wp/?cat=4 You should try version 2 logs and larger log buffer sizes. Also - external log I/O is not cached, so throughput to the log is determined by the hardware. If the external log is slow, it may be worse than an internal log in terms of performance. Larger log buffers (v2 logs) should improve performance for these tests on both internal and external logs. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 6 19:56:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 19:56:57 -0800 (PST) Received: from mail.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB73umaG012980 for ; Wed, 6 Dec 2006 19:56:50 -0800 X-ASG-Debug-ID: 1165458838-15a700010000-NocioJ X-Barracuda-URL: http://cuda.aconex.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: unknown[192.168.3.1] X-Barracuda-Start-Time: 1165458838 Received: from postoffice.aconex.com (unknown [192.168.3.1]) by mail.aconex.com (Spam Firewall) with ESMTP id 1D80928D; Thu, 7 Dec 2006 13:33:58 +1100 (EST) Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id A7E17AAC18E; Thu, 7 Dec 2006 13:29:23 +1100 (EST) X-ASG-Orig-Subj: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4 Subject: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4 From: Nathan Scott Reply-To: nscott@aconex.com To: David Chinner Cc: Nikolai Joukov , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20061206091100.GA33919298@melbourne.sgi.com> References: <20061204235042.GS33919298@melbourne.sgi.com> <20061206091100.GA33919298@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Thu, 07 Dec 2006 09:16:31 +1100 Message-Id: <1165443391.1281.135.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at aconex.com X-archive-position: 9903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1033 Lines: 30 On Wed, 2006-12-06 at 20:11 +1100, David Chinner wrote: > ... > If all we need to add to XFS is support for those flags, then XFS > support would be trivial to add. > > Oh, damn. I take that back. We're almost out of flag space in the on > disk inode - these two flags would use the last 2 flag bits so this > may require an on disk inode format change in XFS. This will be > a little more complex than I first thought, ... It should be OK - you can do it without an inode version revision if you take a second 16 bits for "di_flags2" from here... xfs_dinode_core { ... __uint8_t di_pad[8]; /* unused, zeroed space */ Its guaranteed zeroed initially (i.e. all flags unset) and the XFS get/set flags APIs are 32 bits, so you should be OK there. Also, it may also be possible to reclaim di_onlink at some point (maybe now, since 16 bits would be good here) if mkfs.xfs is changed to always create v2 inodes (dynamic conversion ATM IIRC)... not 100% sure though, needs more code analysis. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 09:38:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 09:38:52 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7HciaG027043 for ; Thu, 7 Dec 2006 09:38:45 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120712174462:372 ; Thu, 7 Dec 2006 12:17:44 -0500 Message-ID: <45784E71.4080605@falconstor.com> Date: Thu, 07 Dec 2006 12:25:05 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> In-Reply-To: <4560AB84.9060200@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 12:17:44 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 12:38:46 PM, Serialize complete at 12/07/2006 12:38:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9905 X-ecartis-version: Ecarti