From owner-freebsd-geom@FreeBSD.ORG Mon May 3 01:58:13 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D865216A4CE for ; Mon, 3 May 2004 01:58:13 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E85143D31 for ; Mon, 3 May 2004 01:58:13 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from melfina.ninth-nine.com ([IPv6:2002:d312:f91e::1]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i438wBSB051631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 May 2004 17:58:12 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 3 May 2004 17:58:10 +0900 From: Norikatsu Shigemura To: freebsd-geom@FreeBSD.org Message-Id: <20040503175810.62d3f0fb.nork@FreeBSD.org> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.0; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 08:58:14 -0000 I made a geom_vol_msdosfs GEOM module. It provides a feature like geom_vol_ffs. Its own targets are USB memories, USB Digital Cameras, and USB/IEEE1394 strorages formated MS-DOS (FAT16/FAT32) File System as typical embeded filesystem. By using it, we can get a fixed mount pointing like /dev/vol/VOLUMELABEL. So we can write following to /etc/fstab. /dev/vol/VOLUMELABEL /mnt/VOLUMELABEL msdosfs rw,noauto 0 0 I tested my md1 (newfs_msdos -L -f 1440), FAT32 formated by WindowsXP, and XOSL (Extended Operationg System Loader) Dedicated partition(slice?). Sorry, I have no external eripheral equipments. Please test in these(avobe targets) environments. And I hope to commit to FreeBSD source tree:-). From owner-freebsd-geom@FreeBSD.ORG Mon May 3 02:00:00 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E9EF16A4CE for ; Mon, 3 May 2004 02:00:00 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51DB543D1D for ; Mon, 3 May 2004 01:59:59 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from melfina.ninth-nine.com ([IPv6:2002:d312:f91e::1]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i438xvht051682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 3 May 2004 17:59:58 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 3 May 2004 17:59:57 +0900 From: Norikatsu Shigemura To: freebsd-geom@FreeBSD.org Message-Id: <20040503175957.68c07042.nork@FreeBSD.org> In-Reply-To: <20040503175810.62d3f0fb.nork@FreeBSD.org> References: <20040503175810.62d3f0fb.nork@FreeBSD.org> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.0; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Mon__3_May_2004_17_59_57_+0900_UZkFKnY6AV1vjjU+" Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 09:00:00 -0000 This is a multi-part message in MIME format. --Multipart=_Mon__3_May_2004_17_59_57_+0900_UZkFKnY6AV1vjjU+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 3 May 2004 17:58:10 +0900 Norikatsu Shigemura wrote: > I made a geom_vol_msdosfs GEOM module. It provides a feature Oops, I forgot to attach a patch file. --Multipart=_Mon__3_May_2004_17_59_57_+0900_UZkFKnY6AV1vjjU+ Content-Type: application/octet-stream; name="geom_vol_msdosfs.diff" Content-Disposition: attachment; filename="geom_vol_msdosfs.diff" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CihjZCAvdXNyL3Ny YyAmJiBwYXRjaCAtcDYpIDwgZ2VvbV92b2xfbXNkb3Nmcy5kaWZmCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gLy9kZXBvdC92ZW5kb3IvZnJlZWJzZC9z cmMvc3lzL2NvbmYvTk9URVMJMjAwNC8wNC8zMCAxNDoyMDo0OAorKysgLy9kZXBvdC91c2VyL25v cmsvbm9ya19tb2JpbGUvc3lzL2NvbmYvTk9URVMJMjAwNC8wNS8wMyAwMTowOTo0NwpAQCAtMTI2 LDcgKzEyNiw3IEBACiBvcHRpb25zIAlHRU9NX01CUgkJIyBET1MvTUJSIHBhcnRpdGlvbmluZwog b3B0aW9ucyAJR0VPTV9QQzk4CQkjIE5FQyBQQzk4MDAgcGFydGl0aW9uaW5nCiBvcHRpb25zIAlH RU9NX1NVTkxBQkVMCQkjIFN1bi9Tb2xhcmlzIHBhcnRpdGlvbmluZwotb3B0aW9ucyAJR0VPTV9W T0wJCSMgVm9sdW1lIG5hbWVzIGZyb20gVUZTIHN1cGVyYmxvY2sKK29wdGlvbnMgCUdFT01fVk9M CQkjIFVGUy9NUy1ET1NGUyB2b2x1bWUgbmFtZXMKIAogIwogIyBUaGUgcm9vdCBkZXZpY2UgYW5k IGZpbGVzeXN0ZW0gdHlwZSBjYW4gYmUgY29tcGlsZWQgaW47Ci0tLSAvL2RlcG90L3ZlbmRvci9m cmVlYnNkL3NyYy9zeXMvY29uZi9maWxlcwkyMDA0LzA1LzAxIDIyOjI1OjMyCisrKyAvL2RlcG90 L3VzZXIvbm9yay9ub3JrX21vYmlsZS9zeXMvY29uZi9maWxlcwkyMDA0LzA1LzAzIDAxOjA5OjQ3 CkBAIC05NDIsNiArOTQyLDcgQEAKIGdlb20vZ2VvbV9zdW5sYWJlbC5jCW9wdGlvbmFsIGdlb21f c3VubGFiZWwKIGdlb20vZ2VvbV9zdW5sYWJlbF9lbmMuYwlvcHRpb25hbCBnZW9tX3N1bmxhYmVs CiBnZW9tL2dlb21fdm9sX2Zmcy5jCW9wdGlvbmFsIGdlb21fdm9sCitnZW9tL2dlb21fdm9sX21z ZG9zZnMuYwlvcHRpb25hbCBnZW9tX3ZvbAogZ251L2V4dDJmcy9leHQyX2FsbG9jLmMJCW9wdGlv bmFsIGV4dDJmcyBcCiAJd2FybmluZyAia2VybmVsIGNvbnRhaW5zIEdQTCBjb250YW1pbmF0ZWQg ZXh0MmZzIGZpbGVzeXN0ZW0iCiBnbnUvZXh0MmZzL2V4dDJfYmFsbG9jLmMJb3B0aW9uYWwgZXh0 MmZzCi0tLSAvL2RlcG90L3ZlbmRvci9mcmVlYnNkL3NyYy9zeXMvbW9kdWxlcy9nZW9tL01ha2Vm aWxlCTIwMDQvMDIvMjMgMTI6MDU6MzEKKysrIC8vZGVwb3QvdXNlci9ub3JrL25vcmtfbW9iaWxl L3N5cy9tb2R1bGVzL2dlb20vTWFrZWZpbGUJMjAwNC8wNS8wMSAxMjo0NzowNwpAQCAtMTEsNSAr MTEsNiBAQAogCWdlb21fcGM5OCBcCiAJZ2VvbV9zdW5sYWJlbCBcCiAJZ2VvbV92b2xfZmZzCitT VUJESVIrPWdlb21fdm9sX21zZG9zZnMKIAogLmluY2x1ZGUgPGJzZC5zdWJkaXIubWs+Ci0tLSAv ZGV2L251bGwJTW9uIE1heSAgMyAxNzoxMTowMCAyMDA0CisrKyAvL2RlcG90L3VzZXIvbm9yay9u b3JrX21vYmlsZS9zeXMvZ2VvbS9nZW9tX3ZvbF9tc2Rvc2ZzLmMJTW9uIE1heSAgMyAxNjo1OToy MyAyMDA0CkBAIC0wLDAgKzEsMTkzIEBACisvKi0KKyAqIENvcHlyaWdodCAoYykgMjAwMiwgMjAw MyBHb3Jkb24gVGV0bG93CisgKiBDb3B5cmlnaHQgKGMpIDIwMDQsIE5vcmlrYXRzdSBTaGlnZW11 cmEKKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVz ZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmlj YXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlv bnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVz dCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2Yg Y29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmli dXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQK KyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcg ZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVy aWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FS RSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFO RAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBO T1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklM SVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlN RUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFC TEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhF TVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklD RVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJ T04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdI RVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJ TkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9G IFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJ TElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgor X19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVk ZSA8c3lzL2Vycm5vLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisjaW5jbHVkZSA8c3lzL2tl cm5lbC5oPgorI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KKyNpbmNsdWRlIDxzeXMvYmlvLmg+Cisj aW5jbHVkZSA8c3lzL2xvY2suaD4KKyNpbmNsdWRlIDxzeXMvbXV0ZXguaD4KKworI2luY2x1ZGUg PGZzL21zZG9zZnMvYnBiLmg+CisjaW5jbHVkZSA8ZnMvbXNkb3Nmcy9ib290c2VjdC5oPgorI2lu Y2x1ZGUgPGZzL21zZG9zZnMvZGlyZW50cnkuaD4KKworI2luY2x1ZGUgPGdlb20vZ2VvbS5oPgor I2luY2x1ZGUgPGdlb20vZ2VvbV9zbGljZS5oPgorCisjZGVmaW5lIFZPTF9NU0RPU0ZTX0NMQVNT X05BTUUgIlZPTF9NU0RPU0ZTIgorI2RlZmluZSBOT19OQU1FICJOTyBOQU1FICAgICIKKworc3Ry dWN0IGdfdm9sX21zZG9zZnNfc29mdGMgeworCWNoYXIgKgl2b2w7Cit9OworCitzdGF0aWMgaW50 CitnX3ZvbF9tc2Rvc2ZzX3N0YXJ0KHN0cnVjdCBiaW8gKmJwIF9fdW51c2VkKQoreworCXJldHVy bigwKTsKK30KKworc3RhdGljIHN0cnVjdCBnX2dlb20gKgorZ192b2xfbXNkb3Nmc190YXN0ZShz dHJ1Y3QgZ19jbGFzcyAqbXAsIHN0cnVjdCBnX3Byb3ZpZGVyICpwcCwgaW50IGZsYWdzKQorewor CXN0cnVjdCBnX2dlb20gKmdwOworCXN0cnVjdCBnX2NvbnN1bWVyICpjcDsKKwlzdHJ1Y3QgZ192 b2xfbXNkb3Nmc19zb2Z0YyAqbXM7CisJaW50IGksIGosIGVycm9yOworCW9mZl90IG1lZGlhc2l6 ZTsKKwl1X2ludCBzZWN0b3JzaXplOworCXN0cnVjdCBieXRlX2JwYjUwICpiNTA7CisJdW5pb24g Ym9vdHNlY3RvciAqYnNwOworCXN0cnVjdCBleHRib290ICpleHQ7CisJY2hhciAqdm9sLCBidWZb MTJdOworCisJZ190cmFjZShHX1RfVE9QT0xPR1ksICJ2b2xfdGFzdGUoJXMsJXMpIiwgbXAtPm5h bWUsIHBwLT5uYW1lKTsKKwlnX3RvcG9sb2d5X2Fzc2VydCgpOworCisJLyogCisJICogWFhYIFRo aXMgaXMgYSByZWFsbHkgd2VhayB3YXkgdG8gbWFrZSBzdXJlIHdlIGRvbid0IHJlY3Vyc2UuCisJ ICogUHJvYmFibHkgb3VnaHQgdG8gdXNlIEJJT19HRVRBVFRSIHRvIGNoZWNrIGZvciB0aGlzLgor CSAqLworCWlmIChmbGFncyA9PSBHX1RGX05PUk1BTCAmJgorCSAgICAhc3RyY21wKHBwLT5nZW9t LT5jbGFzcy0+bmFtZSwgVk9MX01TRE9TRlNfQ0xBU1NfTkFNRSkpCisJCXJldHVybiAoTlVMTCk7 CisKKwlncCA9IGdfc2xpY2VfbmV3KG1wLCAxLCBwcCwgJmNwLCAmbXMsIHNpemVvZigqbXMpLCBn X3ZvbF9tc2Rvc2ZzX3N0YXJ0KTsKKwlpZiAoZ3AgPT0gTlVMTCkKKwkJcmV0dXJuIChOVUxMKTsK KworCWdfdG9wb2xvZ3lfdW5sb2NrKCk7CisKKwlic3AgPSAodW5pb24gYm9vdHNlY3RvciAqKSBn X3JlYWRfZGF0YShjcCwgMCwgMjA0OCwgJmVycm9yKTsKKwlpZiAoYnNwID09IE5VTEwgfHwgZXJy b3IgIT0gMCkgeworCQlnX2ZyZWUoYnNwKTsKKwkJZ290byBnX3ZvbF9tc2Rvc2ZzX2V4aXQ7CisJ fQorCisjZGVmaW5lIE1TRE9TRlNfTk9DSEVDS1NJRworI2lmbmRlZiBNU0RPU0ZTX05PQ0hFQ0tT SUcKKwlpZiAoYnNwLT5iczUwLmJzQm9vdFNlY3RTaWcwICE9IEJPT1RTSUcwCisJICAgIHx8IGJz cC0+YnM1MC5ic0Jvb3RTZWN0U2lnMSAhPSBCT09UU0lHMSkgeworCQlnX2ZyZWUoYnNwKTsKKwkJ Z290byBnX3ZvbF9tc2Rvc2ZzX2V4aXQ7CisJfQorI2VuZGlmCisKKwliNTAgPSAoc3RydWN0IGJ5 dGVfYnBiNTAgKikgYnNwLT5iczUwLmJzQlBCOworCisJc2VjdG9yc2l6ZSA9IGdldHVzaG9ydChi NTAtPmJwYkJ5dGVzUGVyU2VjKTsKKwlpZiAoc2VjdG9yc2l6ZSAhPSAgNTEyICYmIHNlY3RvcnNp emUgIT0gMTAyNAorCSAmJiBzZWN0b3JzaXplICE9IDIwNDggJiYgc2VjdG9yc2l6ZSAhPSA0MDk2 KSB7CisJCWdfZnJlZShic3ApOworCQlnb3RvIGdfdm9sX21zZG9zZnNfZXhpdDsKKwl9CisKKwlt ZWRpYXNpemUgID0gZ2V0dXNob3J0KGI1MC0+YnBiU2VjdG9ycykgKiBzZWN0b3JzaXplOworCWlm IChtZWRpYXNpemUgPT0gMCkKKwkJbWVkaWFzaXplICA9IGdldHVsb25nKGI1MC0+YnBiSHVnZVNl Y3RvcnMpICogc2VjdG9yc2l6ZTsKKwlpZiAobWVkaWFzaXplID09IDApIHsKKwkJZ19mcmVlKGJz cCk7CisJCWdvdG8gZ192b2xfbXNkb3Nmc19leGl0OworCX0KKworCWlmIChtZWRpYXNpemUgPiAw eGZmZmZmZmZmIC8gc2l6ZW9mKHN0cnVjdCBkaXJlbnRyeSkgKyBzZWN0b3JzaXplKSB7CisJCWdf ZnJlZShic3ApOworCQlnb3RvIGdfdm9sX21zZG9zZnNfZXhpdDsKKwl9CisKKwlleHQgPSAoc3Ry dWN0IGV4dGJvb3QgKikgYnNwLT5iczUwLmJzRXh0OworCWlmIChleHQtPmV4Qm9vdFNpZ25hdHVy ZSAhPSBFWEJPT1RTSUcpIHsKKwkJZ19mcmVlKGJzcCk7CisJCWdvdG8gZ192b2xfbXNkb3Nmc19l eGl0OworCX0KKworCXZvbCA9IChjaGFyICopIGV4dC0+ZXhWb2x1bWVMYWJlbDsKKwlpZiAoIWJj bXAodm9sLCBOT19OQU1FLCBzaXplb2YoTk9fTkFNRSkgLSAxKSkgeworCQlnX2ZyZWUoYnNwKTsK KwkJZ290byBnX3ZvbF9tc2Rvc2ZzX2V4aXQ7CisJfQorCisJZm9yIChpID0gMCwgaiA9IDA7IGkg PCBzaXplb2YoYnVmKSAtIDE7IGkrKykgeworCQlpZiAodm9sW2ldICE9ICcgJykgeworCQkJYnVm W2orK10gPSB2b2xbaV07CisJCX0KKwl9CisJYnVmW2pdID0gJ1wwJzsKKworCS8qIENoZWNrIGZv ciB2b2x1bWUgbGFiZWwgKi8KKwlpZiAoYnVmWzBdID09ICdcMCcpIHsKKwkJZ19mcmVlKGJzcCk7 CisJCWdvdG8gZ192b2xfbXNkb3Nmc19leGl0OworCX0KKy8qCitwcmludGYoImdfdm9sX21zZG9z ZnM6IHZvbD0nJXMnLCBzZWM9JXUsIG1lZGlhPSVsdSgldSwgJWx1KVxuIiwgYnVmLCAodW5zaWdu ZWQpc2VjdG9yc2l6ZSwgKHVuc2lnbmVkIGxvbmcpbWVkaWFzaXplLCAodW5zaWduZWQpZ2V0dXNo b3J0KGI1MC0+YnBiU2VjdG9ycyksICh1bnNpZ25lZCBsb25nKWdldHVsb25nKGI1MC0+YnBiSHVn ZVNlY3RvcnMpKTsKK2dfZnJlZShic3ApOworZ290byBnX3ZvbF9tc2Rvc2ZzX2V4aXQ7CisqLwor CS8qIFhYWCBXZSBuZWVkIHRvIGNoZWNrIGZvciBuYW1lc3BhY2UgY29uZmxpY3RzLiAqLworCS8q IFhYWCBIb3cgZG8geW91IGhhbmRsZSBhIG1pcnJvciBzZXQ/ICovCisJLyogWFhYIFdlIGRvbid0 IHZhbGlkYXRlIHRoZSB2b2x1bWUgbmFtZS4gKi8KKwlnX3RvcG9sb2d5X2xvY2soKTsKKwkvKiBB bHJpZ2h0LCB3ZSBoYXZlIGEgbGFiZWwgYW5kIGEgdm9sdW1lIG5hbWUsIHJlY29uZmlnLiAqLwor CWdfc2xpY2VfY29uZmlnKGdwLCAwLCBHX1NMSUNFX0NPTkZJR19TRVQsCisJCQkob2ZmX3QpIDAs IG1lZGlhc2l6ZSwgc2VjdG9yc2l6ZSwgInZvbC8lcyIsIGJ1Zik7CisJZ19mcmVlKGJzcCk7CisJ Z190b3BvbG9neV91bmxvY2soKTsKKworZ192b2xfbXNkb3Nmc19leGl0OgorCWdfdG9wb2xvZ3lf bG9jaygpOworCWdfYWNjZXNzKGNwLCAtMSwgMCwgMCk7CisJaWYgKExJU1RfRU1QVFkoJmdwLT5w cm92aWRlcikpIHsKKwkJZ19zbGljZV9zcG9pbGVkKGNwKTsKKwkJcmV0dXJuIChOVUxMKTsKKwl9 CisJcmV0dXJuIChncCk7Cit9CisKK3N0YXRpYyBpbnQKK2dfdm9sX21zZG9zZnNfZGVzdHJveV9n ZW9tKHN0cnVjdCBnY3RsX3JlcSAqcmVxIF9fdW51c2VkLCBzdHJ1Y3QgZ19jbGFzcyAqbXAgX191 bnVzZWQsIHN0cnVjdCBnX2dlb20gKmdwKQoreworCWdfdG9wb2xvZ3lfYXNzZXJ0KCk7CisJZ19m cmVlKGdwLT5zb2Z0Yyk7CisJZ3AtPnNvZnRjID0gTlVMTDsKKwlnX3dpdGhlcl9nZW9tKGdwLCBF TlhJTyk7CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIHN0cnVjdCBnX2NsYXNzIGdfdm9sX21z ZG9zZnNfY2xhc3MgPSB7CisJLm5hbWUgPSBWT0xfTVNET1NGU19DTEFTU19OQU1FLAorCS50YXN0 ZSA9IGdfdm9sX21zZG9zZnNfdGFzdGUsCisvKgkuZGVzdHJveV9nZW9tID0gZ192b2xfbXNkb3Nm c19kZXN0cm95X2dlb20sCSovCit9OworCitERUNMQVJFX0dFT01fQ0xBU1MoZ192b2xfbXNkb3Nm c19jbGFzcywgZ192b2xfbXNkb3Nmcyk7Ci0tLSAvZGV2L251bGwJTW9uIE1heSAgMyAxNzoxMTow MCAyMDA0CisrKyAvL2RlcG90L3VzZXIvbm9yay9ub3JrX21vYmlsZS9zeXMvbW9kdWxlcy9nZW9t L2dlb21fdm9sX21zZG9zZnMvTWFrZWZpbGUJTW9uIE1heSAgMyAxNjo1OToyMyAyMDA0CkBAIC0w LDAgKzEsOCBAQAorIyAkRnJlZUJTRCQKKworLlBBVEg6ICR7LkNVUkRJUn0vLi4vLi4vLi4vZ2Vv bQorCitLTU9EPQlnZW9tX3ZvbF9tc2Rvc2ZzCitTUkNTPQlnZW9tX3ZvbF9tc2Rvc2ZzLmMKKwor LmluY2x1ZGUgPGJzZC5rbW9kLm1rPgo= --Multipart=_Mon__3_May_2004_17_59_57_+0900_UZkFKnY6AV1vjjU+-- From owner-freebsd-geom@FreeBSD.ORG Mon May 3 02:04:29 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E3F416A4CE; Mon, 3 May 2004 02:04:29 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CCC143D3F; Mon, 3 May 2004 02:04:28 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i4394Q18055895; Mon, 3 May 2004 11:04:26 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Norikatsu Shigemura From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 May 2004 17:58:10 +0900." <20040503175810.62d3f0fb.nork@FreeBSD.org> Date: Mon, 03 May 2004 11:04:26 +0200 Message-ID: <55894.1083575066@critter.freebsd.dk> cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 09:04:29 -0000 In message <20040503175810.62d3f0fb.nork@FreeBSD.org>, Norikatsu Shigemura writ es: > I made a geom_vol_msdosfs GEOM module. It provides a feature > like geom_vol_ffs. I think this is a great idea! I wonder if it would be smarter to collect all these in one geom class rather than have one for each volume label metadata format, having it in one GEOM class would simplify name-collision handling. On the other hand, name collisions are already passively neutered in DEVFS, so if we can live with "Don't do that then" handling of it, then there is no reason to not have them as different GEOM classes, which certainly makes for simpler and cleaner code. (Summary: Do it whatever way you prefer :-) Poul-Henning PS: I would love to see handling of ISO 9660 (CDROM) volume labels as well. PPS: When you commit, please put it in a subcatalog under sys/geom. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Mon May 3 02:32:29 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7F9016A4CE for ; Mon, 3 May 2004 02:32:29 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1525243D46 for ; Mon, 3 May 2004 02:32:29 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from melfina.ninth-nine.com ([IPv6:2002:d312:f91e::1]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i439WRMj052447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 May 2004 18:32:27 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 3 May 2004 18:32:27 +0900 From: Norikatsu Shigemura To: "Poul-Henning Kamp" Message-Id: <20040503183227.44e8aec7.nork@FreeBSD.org> In-Reply-To: <55894.1083575066@critter.freebsd.dk> References: <20040503175810.62d3f0fb.nork@FreeBSD.org> <55894.1083575066@critter.freebsd.dk> X-Mailer: Sylpheed version 0.9.9-gtk2-20040229 (GTK+ 2.4.0; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-geom@FreeBSD.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 09:32:29 -0000 On Mon, 03 May 2004 11:04:26 +0200 "Poul-Henning Kamp" wrote: > In message <20040503175810.62d3f0fb.nork@FreeBSD.org>, Norikatsu Shigemura writ > es: > > I made a geom_vol_msdosfs GEOM module. It provides a feature > > like geom_vol_ffs. > I think this is a great idea! Thank you. > I wonder if it would be smarter to collect all these in one geom > class rather than have one for each volume label metadata format, > having it in one GEOM class would simplify name-collision handling. > On the other hand, name collisions are already passively neutered > in DEVFS, so if we can live with "Don't do that then" handling of > it, then there is no reason to not have them as different GEOM > classes, which certainly makes for simpler and cleaner code. > (Summary: Do it whatever way you prefer :-) On perforce(when I p4-submit-ed), rwatson said that we need is an auto-mounter that listens to GEOM events and can mount using disk labels so we can have /mnt/NameOfVolume. I think so. There are many TODO lists:-). > PS: > I would love to see handling of ISO 9660 (CDROM) volume labels as well. Oh my god:-). > PPS: > When you commit, please put it in a subcatalog under sys/geom. Sorry, I don't have a src commit bit. I am a just ports committer. From owner-freebsd-geom@FreeBSD.ORG Mon May 3 03:11:32 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1FFE16A4CE; Mon, 3 May 2004 03:11:32 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 015B443D2F; Mon, 3 May 2004 03:11:32 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i43ABSk3060193; Mon, 3 May 2004 12:11:28 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Norikatsu Shigemura From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 May 2004 18:32:27 +0900." <20040503183227.44e8aec7.nork@FreeBSD.org> Date: Mon, 03 May 2004 12:11:28 +0200 Message-ID: <60192.1083579088@critter.freebsd.dk> cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 10:11:32 -0000 In message <20040503183227.44e8aec7.nork@FreeBSD.org>, Norikatsu Shigemura writ es: > On perforce(when I p4-submit-ed), rwatson said that we need > is an auto-mounter that listens to GEOM events and can mount > using disk labels so we can have /mnt/NameOfVolume. > > I think so. There are many TODO lists:-). Yeah, Robert is really good at getting ideas too :-) >> When you commit, please put it in a subcatalog under sys/geom. > > Sorry, I don't have a src commit bit. I am a just ports committer. I'm sure there's somebody here who can help you get this into the tree when they have tested it a bit. I'm stuck on real-world work right now, so I won't have time for the next week at least. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Mon May 3 05:05:08 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 430D316A4CE; Mon, 3 May 2004 05:05:08 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7803C43D5A; Mon, 3 May 2004 05:05:07 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 5381F530C; Mon, 3 May 2004 14:05:06 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 360C45309; Mon, 3 May 2004 14:04:58 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id CFD1D33CAA; Mon, 3 May 2004 14:04:57 +0200 (CEST) To: "Poul-Henning Kamp" References: <55894.1083575066@critter.freebsd.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Mon, 03 May 2004 14:04:57 +0200 In-Reply-To: <55894.1083575066@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 03 May 2004 11:04:26 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: Norikatsu Shigemura cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 12:05:08 -0000 "Poul-Henning Kamp" writes: > On the other hand, name collisions are already passively neutered > in DEVFS, so if we can live with "Don't do that then" handling of > it, then there is no reason to not have them as different GEOM > classes, which certainly makes for simpler and cleaner code. so I see a box that has /dev/vol/var mounted on /var, format a USB stick and label it as var, stick it in and press reset. the stick happens to contain a file, cron/tabs/root, which looks like this: @reboot /bin/sh -c 'echo | /sbin/pw usermod root -h 0' boom, instant root privs. ok, so it requires physical access, but still... DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Mon May 3 06:30:41 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 401E316A4CE; Mon, 3 May 2004 06:30:41 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A0F43D48; Mon, 3 May 2004 06:30:40 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i43DUbRQ064342; Mon, 3 May 2004 15:30:37 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 May 2004 14:04:57 +0200." Date: Mon, 03 May 2004 15:30:37 +0200 Message-ID: <64341.1083591037@critter.freebsd.dk> cc: Norikatsu Shigemura cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 13:30:41 -0000 In message , =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= writes: >"Poul-Henning Kamp" writes: >> On the other hand, name collisions are already passively neutered >> in DEVFS, so if we can live with "Don't do that then" handling of >> it, then there is no reason to not have them as different GEOM >> classes, which certainly makes for simpler and cleaner code. > >so I see a box that has /dev/vol/var mounted on /var, format a USB >stick and label it as var, stick it in and press reset. the stick >happens to contain a file, cron/tabs/root, which looks like this: > >@reboot /bin/sh -c 'echo | /sbin/pw usermod root -h 0' > >boom, instant root privs. ok, so it requires physical access, but >still... I guess neither of you were around when Jordan blasted the mailarchives with an ill applied automounter. You should never automount sources you have hardconfigured on any system directory. That is why automounters generally put things under /vol or similar. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Mon May 3 08:30:57 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1B3516A4CE; Mon, 3 May 2004 08:30:57 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21E0D43D54; Mon, 3 May 2004 08:30:57 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 67124ACADB; Mon, 3 May 2004 17:30:55 +0200 (CEST) Date: Mon, 3 May 2004 17:30:55 +0200 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20040503153055.GT24376@darkness.comp.waw.pl> References: <20040503175810.62d3f0fb.nork@FreeBSD.org> <55894.1083575066@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5JFuR0oMLkSLAI/x" Content-Disposition: inline In-Reply-To: <55894.1083575066@critter.freebsd.dk> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: Norikatsu Shigemura cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 15:30:57 -0000 --5JFuR0oMLkSLAI/x Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2004 at 11:04:26AM +0200, Poul-Henning Kamp wrote: +> In message <20040503175810.62d3f0fb.nork@FreeBSD.org>, Norikatsu Shigemu= ra writ +> es: +> > I made a geom_vol_msdosfs GEOM module. It provides a feature +> > like geom_vol_ffs.=20 +>=20 +> I think this is a great idea! I was wondering if slicers isn't an overkill here as we don't need any transformations. We could only connect a consumer to destination provider to be able to detect orphans and just create symbolic link to destination provider from under /dev/vol/... What do you think? In addition it will clarify the source provider if someone is interested. I can handle this if you agree with me and reimplement existing geom_vol_ffs to be able to handle many label formats in clean way. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --5JFuR0oMLkSLAI/x Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAlmWvForvXbEpPzQRAvG5AKDsmElI78dUzWLKhCz7R/RAAkt/eQCdFMVE 4ADYqalF+fTyzu3d5fJLNuo= =1ZUh -----END PGP SIGNATURE----- --5JFuR0oMLkSLAI/x-- From owner-freebsd-geom@FreeBSD.ORG Mon May 3 08:34:10 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1EDC16A4CE; Mon, 3 May 2004 08:34:10 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A108143D58; Mon, 3 May 2004 08:34:09 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i43FY7nB065073; Mon, 3 May 2004 17:34:07 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Pawel Jakub Dawidek From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 03 May 2004 17:30:55 +0200." <20040503153055.GT24376@darkness.comp.waw.pl> Date: Mon, 03 May 2004 17:34:07 +0200 Message-ID: <65072.1083598447@critter.freebsd.dk> cc: Norikatsu Shigemura cc: freebsd-geom@FreeBSD.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2004 15:34:10 -0000 In message <20040503153055.GT24376@darkness.comp.waw.pl>, Pawel Jakub Dawidek w rites: >I was wondering if slicers isn't an overkill here as we don't need any >transformations. >We could only connect a consumer to destination provider to be able to >detect orphans and just create symbolic link to destination provider >from under /dev/vol/... What do you think? >In addition it will clarify the source provider if someone is interested. How do you plan to notice when the device disappears again ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue May 4 03:04:32 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B69DB16A4CE for ; Tue, 4 May 2004 03:04:32 -0700 (PDT) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A1E543D2D for ; Tue, 4 May 2004 03:04:32 -0700 (PDT) (envelope-from xride@x12.dk) Received: from x12.dk (xforce.dk [80.164.11.218]) by pasmtp.tele.dk (Postfix) with ESMTP id 1093D1EC32F for ; Tue, 4 May 2004 12:04:30 +0200 (CEST) Received: by x12.dk (Postfix, from userid 666) id 113D156; Tue, 4 May 2004 12:04:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by x12.dk (Postfix) with ESMTP id EC14226 for ; Tue, 4 May 2004 12:04:26 +0200 (CEST) Date: Tue, 4 May 2004 12:04:26 +0200 (CEST) From: Soeren Straarup To: freebsd-geom@freebsd.org Message-ID: <20040504115919.L35168-100000@x12.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 10:04:32 -0000 Hi I was reading the vol_msdosfs thread and this is what i've seen IRL When dd'ing from a usb dongle to a file and then remove the dongle during this operation, then a kernel panic might ocour. I can't tell where the chain breaks. All this has been taken place on a 5.1-R box. Best regards S=F8ren Soeren Straarup | aka OZ2DAK aka Xride FreeBSD wannabe | FreeBSD since 2.2.6-R Don't let your brain be in idle to long it might get stuck there From owner-freebsd-geom@FreeBSD.ORG Tue May 4 08:47:16 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4206016A4CE for ; Tue, 4 May 2004 08:47:16 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5888543D39 for ; Tue, 4 May 2004 08:47:15 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id F333EACAF4; Tue, 4 May 2004 17:47:13 +0200 (CEST) Date: Tue, 4 May 2004 17:47:13 +0200 From: Pawel Jakub Dawidek To: geom@freebsd.org Message-ID: <20040504154713.GD24376@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qCPPoBTQI/bIC4sS" Content-Disposition: inline User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 Subject: geom(8) model proposal. X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2004 15:47:16 -0000 --qCPPoBTQI/bIC4sS Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello. I've quite finished I think geom(8) model that should simplify and unify control over GEOM classes. The main part is geom(8) utility that is responsible for loading shared libraries with class-specific code, for commutication with kernel (GEOM) through libgeom(3) and versions control. Geom(8) can be called in two ways: # geom or: # g What shared library should specify. I'll explain this on examples. Imagine a GEOM NULL class which implements only two commands: gnull create [-v] [dev2 [...]] gnull destroy [-fv] [dev2 [...]] Inside shared library source one should specify available commands in that way: struct g_command class_commands[] =3D { { "create", G_FLAG_VERBOSE | G_FLAG_LOADKLD, NULL, G_NULL_OPTS }, { "destroy", G_FLAG_VERBOSE, NULL, { { 'f', "force", NULL, G_TYPE_NONE }, G_OPT_SENTINEL } }, G_CMD_SENTINEL }; Ok, now: "create" stands for command name, G_FLAG_VERBOSE means that '-v' option is available, G_FLAG_LOADKLD means that geom_null.ko should be loaded if not present in kernel. NULL means it should be handle by geom(8) itself and G_NULL_OPTS means that there are no other options. Arguments after options (dev1, dev2, etc.) are passed to GEOM NULL class. 2nd command: "destroy" - command name, 'f' is option character, "force" is variable name, it will be passed with this name to the kernel, NULL means that it is boolean value (no argument after option), so if specified 1 will be passed to GEOM NULL class as 'force' variable. Other possiblities: intmax_t stripe =3D 65536; [...] { 's', "stripesize", &stripe, G_TYPE_NUMBER } Means: '-s' option is available, it is a number and its default value is 65536 (so it don't have to be specified). { 's', "stripesize", NULL, G_TYPE_NUMBER } Same as above, but '-s' have to be specified, because there is no default value. { 'n', "name", NULL, G_TYPE_STRING } Same as above, but '-n' requires string argument. int force =3D 1; [...] { 'f', "force", &force, G_TYPE_NONE } '-f' is optional with default value of 1. That were options for commands, now commands: { "clear", G_FLAG_VERBOSE, stripe_clear, G_NULL_OPTS }, Field stripe_clear means that one wants to handle this option by himself and stripe_clear is a function name to call: /* * This is simlar to how GEOM class should handle commands in kernel. */ static void stripe_clear(struct gctl_req *req, unsigned flags) { int i, *nargs, verbose =3D 0; const char *name; char param[16]; if ((flags & G_FLAG_VERBOSE) !=3D 0) verbose =3D 1; /* 'nargs' contains number of additional arguments. */ nargs =3D gctl_get_paraml(req, "nargs", sizeof(*nargs)); if (nargs =3D=3D NULL) { gctl_error(req, "No '%s' argument.", "nargs"); return; } if (*nargs < 1) { gctl_error(req, "Too few arguments."); return; } /* * Arguments after options are named "argX" * where X is argument's number. */ for (i =3D 0; i < *nargs; i++) { snprintf(param, sizeof(param), "arg%u", i); name =3D gctl_get_asciiparam(req, param); /* Clear metadata. */ error =3D g_metadata_clear(name); if (error !=3D 0) { gctl_error(req, "Can't store metadata on %s: %s.", name, strerror(error)); return; } if (verbose) printf("Metadata cleared on %s.\n", name); } } ETC. There are some more things to talk about (e.g. standard commands like 'list' and 'unload' or versions control), but for now it should be enough. Maybe it doesn't look too easy, or maybe it's my English, but I've already implemented: gconcat(8), gstripe(8), gnull(8) and gmirror(8) with this model without any problems, so I think it is flexible enough. If there are no objections I want to commit it, as few folks are waiting for geom_stripe class and it will be cool also to have geom_null class for test purposes. Some other classes could be reimplemented to use this model, for example ccd(4) and I can do that if there is such need. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --qCPPoBTQI/bIC4sS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAl7sBForvXbEpPzQRAs4kAKDQaLIKu9TdeQAS8qE70fk7kYAj1ACg5DWW tzl9wG5U8JNuzaji6Ln0K0I= =8cUJ -----END PGP SIGNATURE----- --qCPPoBTQI/bIC4sS-- From owner-freebsd-geom@FreeBSD.ORG Wed May 5 09:19:39 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB7516A4CE for ; Wed, 5 May 2004 09:19:39 -0700 (PDT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id C50F143D41 for ; Wed, 5 May 2004 09:19:39 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i45GFKGc025753; Wed, 5 May 2004 09:15:20 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i45GFHPA025752; Wed, 5 May 2004 09:15:17 -0700 (PDT) (envelope-from gtetlow) Date: Wed, 5 May 2004 09:15:17 -0700 From: Gordon Tetlow To: Soeren Straarup Message-ID: <20040505161516.GC10016@spiff.melthusia.org> References: <20040504115919.L35168-100000@x12.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wq9mPyueHGvFACwf" Content-Disposition: inline In-Reply-To: <20040504115919.L35168-100000@x12.dk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.5.1i cc: freebsd-geom@freebsd.org Subject: Re: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2004 16:19:40 -0000 --wq9mPyueHGvFACwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 04, 2004 at 12:04:26PM +0200, Soeren Straarup wrote: >=20 > Hi >=20 > I was reading the vol_msdosfs thread and this is what i've seen IRL >=20 > When dd'ing from a usb dongle to a file and then remove the dongle during > this operation, then a kernel panic might ocour. I can't tell where the > chain breaks. All this has been taken place on a 5.1-R box. Only "might occur"? I would have thought it would panic 100%! The correct solution to this problem is "Don't do that" -gordon --wq9mPyueHGvFACwf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmRMURu2t9DV9ZfsRAkByAKCeLmZgT/oSb/+SKgeR5vhujUF1AgCgnGWD o4hVTjDAKv9/MFJjyQSwrWc= =LD3i -----END PGP SIGNATURE----- --wq9mPyueHGvFACwf-- From owner-freebsd-geom@FreeBSD.ORG Wed May 5 18:13:15 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF9AE16A4CE; Wed, 5 May 2004 18:13:15 -0700 (PDT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CB1143D5E; Wed, 5 May 2004 18:13:15 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i4618sGc029483; Wed, 5 May 2004 18:08:54 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i4618q6c029482; Wed, 5 May 2004 18:08:52 -0700 (PDT) (envelope-from gtetlow) Date: Wed, 5 May 2004 18:08:51 -0700 From: Gordon Tetlow To: Poul-Henning Kamp Message-ID: <20040506010851.GD10016@spiff.melthusia.org> References: <20040503175810.62d3f0fb.nork@FreeBSD.org> <55894.1083575066@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oJ71EGRlYNjSvfq7" Content-Disposition: inline In-Reply-To: <55894.1083575066@critter.freebsd.dk> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.5.1i cc: Norikatsu Shigemura cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 01:13:15 -0000 --oJ71EGRlYNjSvfq7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2004 at 11:04:26AM +0200, Poul-Henning Kamp wrote: > In message <20040503175810.62d3f0fb.nork@FreeBSD.org>, Norikatsu Shigemur= a writ > es: > > I made a geom_vol_msdosfs GEOM module. It provides a feature > > like geom_vol_ffs.=20 >=20 > I think this is a great idea! >=20 > I wonder if it would be smarter to collect all these in one geom > class rather than have one for each volume label metadata format, > having it in one GEOM class would simplify name-collision handling. >=20 > On the other hand, name collisions are already passively neutered > in DEVFS, so if we can live with "Don't do that then" handling of > it, then there is no reason to not have them as different GEOM > classes, which certainly makes for simpler and cleaner code. I would prefer the separate code. Esp when it comes to looking at things like CD9660. I took a passing interest to see what it would take to make that happen and I wanted to claw my eyes out. -gordon --oJ71EGRlYNjSvfq7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmZAjRu2t9DV9ZfsRAkFJAJ96nxxXAqB1WW/4SxwEZWS6qAutQQCgmBtM u9Zkso3E01HbuidMQaXM+M4= =VQvK -----END PGP SIGNATURE----- --oJ71EGRlYNjSvfq7-- From owner-freebsd-geom@FreeBSD.ORG Wed May 5 18:16:35 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20D6B16A4CE; Wed, 5 May 2004 18:16:35 -0700 (PDT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2EA643D46; Wed, 5 May 2004 18:16:34 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i461CEGc029559; Wed, 5 May 2004 18:12:14 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i461CEM0029558; Wed, 5 May 2004 18:12:14 -0700 (PDT) (envelope-from gtetlow) Date: Wed, 5 May 2004 18:12:14 -0700 From: Gordon Tetlow To: Pawel Jakub Dawidek Message-ID: <20040506011214.GE10016@spiff.melthusia.org> References: <20040503175810.62d3f0fb.nork@FreeBSD.org> <55894.1083575066@critter.freebsd.dk> <20040503153055.GT24376@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IMjqdzrDRly81ofr" Content-Disposition: inline In-Reply-To: <20040503153055.GT24376@darkness.comp.waw.pl> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.5.1i cc: Poul-Henning Kamp cc: Norikatsu Shigemura cc: freebsd-geom@freebsd.org Subject: Re: new GEOM feature - geom_vol_msdosfs X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 01:16:35 -0000 --IMjqdzrDRly81ofr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 03, 2004 at 05:30:55PM +0200, Pawel Jakub Dawidek wrote: > On Mon, May 03, 2004 at 11:04:26AM +0200, Poul-Henning Kamp wrote: > +> In message <20040503175810.62d3f0fb.nork@FreeBSD.org>, Norikatsu Shige= mura writ > +> es: > +> > I made a geom_vol_msdosfs GEOM module. It provides a feature > +> > like geom_vol_ffs.=20 > +>=20 > +> I think this is a great idea! >=20 > I was wondering if slicers isn't an overkill here as we don't need any > transformations. > We could only connect a consumer to destination provider to be able to > detect orphans and just create symbolic link to destination provider > from under /dev/vol/... What do you think? > In addition it will clarify the source provider if someone is interested. >=20 > I can handle this if you agree with me and reimplement existing > geom_vol_ffs to be able to handle many label formats in clean way. By all means, geom_vol_ffs was basically a prototype for me. It worked well enough for my needs. I chose the slicer api because it made more sense to me at the time. There weren't any docs when I was writing geom_vol_ffs and all the other modules seemed to use the slicer api. In fact, feel free to rip the whole thing apart. But don't change struct ffs, that was painful. -gordon --IMjqdzrDRly81ofr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmZDuRu2t9DV9ZfsRApdZAKDLICV8hSo5AMYx9AasMvJyCr+IlACeO4r2 N1MDs3LeiDkAf/xlneuAxpY= =XJO+ -----END PGP SIGNATURE----- --IMjqdzrDRly81ofr-- From owner-freebsd-geom@FreeBSD.ORG Wed May 5 18:20:34 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42CF816A4CE for ; Wed, 5 May 2004 18:20:34 -0700 (PDT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D72F43D46 for ; Wed, 5 May 2004 18:20:34 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i461GDGc029670; Wed, 5 May 2004 18:16:13 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i461GAKn029669; Wed, 5 May 2004 18:16:10 -0700 (PDT) (envelope-from gtetlow) Date: Wed, 5 May 2004 18:16:10 -0700 From: Gordon Tetlow To: Soeren Straarup Message-ID: <20040506011610.GF10016@spiff.melthusia.org> References: <20040504115919.L35168-100000@x12.dk> <20040505161516.GC10016@spiff.melthusia.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3XA6nns4nE4KvaS/" Content-Disposition: inline In-Reply-To: <20040505161516.GC10016@spiff.melthusia.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.5.1i cc: freebsd-geom@freebsd.org Subject: Re: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 01:20:34 -0000 --3XA6nns4nE4KvaS/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 05, 2004 at 09:15:17AM -0700, Gordon Tetlow wrote: > On Tue, May 04, 2004 at 12:04:26PM +0200, Soeren Straarup wrote: > >=20 > > Hi > >=20 > > I was reading the vol_msdosfs thread and this is what i've seen IRL > >=20 > > When dd'ing from a usb dongle to a file and then remove the dongle duri= ng > > this operation, then a kernel panic might ocour. I can't tell where the > > chain breaks. All this has been taken place on a 5.1-R box. >=20 > Only "might occur"? I would have thought it would panic 100%! The correct > solution to this problem is "Don't do that" Despite my flippant response, this is a FAQ. I have heard some rumblings that this may be fixed One Day (tm), but I wouldn't hold my breath. The problem is deep in the kernel and is non-trivial to fix (from what I've been told anyway). -gordon --3XA6nns4nE4KvaS/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAmZHaRu2t9DV9ZfsRArXhAJ41G6ol1tq2hMeMKrPjLk9kxE42igCgnnbH 6QAW6xLhNXZ/iLjq99mrI+8= =xlZG -----END PGP SIGNATURE----- --3XA6nns4nE4KvaS/-- From owner-freebsd-geom@FreeBSD.ORG Wed May 5 23:12:29 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28B2E16A4CE; Wed, 5 May 2004 23:12:29 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id A73DA43D41; Wed, 5 May 2004 23:12:28 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 5B80EACC26; Thu, 6 May 2004 08:12:26 +0200 (CEST) Date: Thu, 6 May 2004 08:12:26 +0200 From: Pawel Jakub Dawidek To: Gordon Tetlow Message-ID: <20040506061226.GP24376@darkness.comp.waw.pl> References: <20040504115919.L35168-100000@x12.dk> <20040505161516.GC10016@spiff.melthusia.org> <20040506011610.GF10016@spiff.melthusia.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QKFUq+IbM9AW97yF" Content-Disposition: inline In-Reply-To: <20040506011610.GF10016@spiff.melthusia.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: Soeren Straarup cc: freebsd-geom@freebsd.org Subject: Re: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 06:12:29 -0000 --QKFUq+IbM9AW97yF Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 05, 2004 at 06:16:10PM -0700, Gordon Tetlow wrote: +> On Wed, May 05, 2004 at 09:15:17AM -0700, Gordon Tetlow wrote: +> > On Tue, May 04, 2004 at 12:04:26PM +0200, Soeren Straarup wrote: +> > >=20 +> > > Hi +> > >=20 +> > > I was reading the vol_msdosfs thread and this is what i've seen IRL +> > >=20 +> > > When dd'ing from a usb dongle to a file and then remove the dongle d= uring +> > > this operation, then a kernel panic might ocour. I can't tell where = the +> > > chain breaks. All this has been taken place on a 5.1-R box. +> >=20 +> > Only "might occur"? I would have thought it would panic 100%! The corr= ect +> > solution to this problem is "Don't do that" +>=20 +> Despite my flippant response, this is a FAQ. I have heard some rumblings +> that this may be fixed One Day (tm), but I wouldn't hold my breath. The +> problem is deep in the kernel and is non-trivial to fix (from what I've +> been told anyway). AFAIR I was having simlar problem with gbde on usb bar (da0) when file system from this device was mounted. I was able to fix panic in gbde, I was able to fix cam(4), but I wasn't able to fix UFS (maybe I should try harder). Anyway, without mounted file system it should be possible to fix this quite easy. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --QKFUq+IbM9AW97yF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAmddKForvXbEpPzQRArbpAJ9Wl8rc+UZb5wg3w28obPw2r/T0YQCfdXcx ebMNwxErGzBQYc6eSANZedA= =Cw0s -----END PGP SIGNATURE----- --QKFUq+IbM9AW97yF-- From owner-freebsd-geom@FreeBSD.ORG Sat May 8 09:22:30 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 835D816A4CF; Sat, 8 May 2004 09:22:30 -0700 (PDT) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id A282F43D5C; Sat, 8 May 2004 09:22:29 -0700 (PDT) (envelope-from xride@x12.dk) Received: from x12.dk (xforce.dk [80.164.11.218]) by pasmtp.tele.dk (Postfix) with ESMTP id 327501EC318; Sat, 8 May 2004 18:22:27 +0200 (CEST) Received: by x12.dk (Postfix, from userid 666) id 8244556; Sat, 8 May 2004 18:22:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by x12.dk (Postfix) with ESMTP id 64C4F26; Sat, 8 May 2004 18:22:27 +0200 (CEST) Date: Sat, 8 May 2004 18:22:27 +0200 (CEST) From: Soeren Straarup To: Pawel Jakub Dawidek In-Reply-To: <20040506061226.GP24376@darkness.comp.waw.pl> Message-ID: <20040508182149.R52883-100000@x12.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Gordon Tetlow cc: freebsd-geom@freebsd.org Subject: Re: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 16:22:30 -0000 On Thu, 6 May 2004, Pawel Jakub Dawidek wrote: > On Wed, May 05, 2004 at 06:16:10PM -0700, Gordon Tetlow wrote: > +> On Wed, May 05, 2004 at 09:15:17AM -0700, Gordon Tetlow wrote: > +> > On Tue, May 04, 2004 at 12:04:26PM +0200, Soeren Straarup wrote: > +> > > > +> > > Hi > +> > > > +> > > I was reading the vol_msdosfs thread and this is what i've seen IRL > +> > > > +> > > When dd'ing from a usb dongle to a file and then remove the dongle during > +> > > this operation, then a kernel panic might ocour. I can't tell where the > +> > > chain breaks. All this has been taken place on a 5.1-R box. > +> > > +> > Only "might occur"? I would have thought it would panic 100%! The correct > +> > solution to this problem is "Don't do that" > +> > +> Despite my flippant response, this is a FAQ. I have heard some rumblings > +> that this may be fixed One Day (tm), but I wouldn't hold my breath. The > +> problem is deep in the kernel and is non-trivial to fix (from what I've > +> been told anyway). > > AFAIR I was having simlar problem with gbde on usb bar (da0) when file > system from this device was mounted. I was able to fix panic in gbde, > I was able to fix cam(4), but I wasn't able to fix UFS (maybe I should > try harder). Anyway, without mounted file system it should be possible > to fix this quite easy. My problem is, is it the usb code that panic or is it from the geom layer? > > -- > Pawel Jakub Dawidek http://www.FreeBSD.org > pjd@FreeBSD.org http://garage.freebsd.pl > FreeBSD committer Am I Evil? Yes, I Am! > Soeren Straarup | aka OZ2DAK aka Xride FreeBSD wannabe | FreeBSD since 2.2.6-R Don't let your brain be in idle to long it might get stuck there From owner-freebsd-geom@FreeBSD.ORG Sat May 8 09:44:28 2004 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 538B216A4CE; Sat, 8 May 2004 09:44:28 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE85443D48; Sat, 8 May 2004 09:44:27 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 141CBACAFE; Sat, 8 May 2004 18:44:26 +0200 (CEST) Date: Sat, 8 May 2004 18:44:26 +0200 From: Pawel Jakub Dawidek To: Soeren Straarup Message-ID: <20040508164426.GF24376@darkness.comp.waw.pl> References: <20040506061226.GP24376@darkness.comp.waw.pl> <20040508182149.R52883-100000@x12.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="v9GM59ztqFZSwQjD" Content-Disposition: inline In-Reply-To: <20040508182149.R52883-100000@x12.dk> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: Gordon Tetlow cc: freebsd-geom@freebsd.org Subject: Re: USB fash devices and dd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2004 16:44:28 -0000 --v9GM59ztqFZSwQjD Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 08, 2004 at 06:22:27PM +0200, Soeren Straarup wrote: +> > AFAIR I was having simlar problem with gbde on usb bar (da0) when file +> > system from this device was mounted. I was able to fix panic in gbde, +> > I was able to fix cam(4), but I wasn't able to fix UFS (maybe I should +> > try harder). Anyway, without mounted file system it should be possible +> > to fix this quite easy. +>=20 +> My problem is, is it the usb code that panic or is it from the geom laye= r? Chances are that both, but GEOM should handle this probably and first is the USB layer. It could be also cam(4), that comes after USB. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --v9GM59ztqFZSwQjD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAnQ5qForvXbEpPzQRAnjDAJ457/A7O3q9gbhS377NV1EN0diIEgCeOPTM 9GzYOD0/6g18antOOPhnQJY= =HkuY -----END PGP SIGNATURE----- --v9GM59ztqFZSwQjD--