From owner-freebsd-current@freebsd.org Fri Sep 8 17:28:30 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EB22E23DEC for ; Fri, 8 Sep 2017 17:28:30 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45FD463367; Fri, 8 Sep 2017 17:28:29 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-yw0-f171.google.com with SMTP id s62so9356174ywg.0; Fri, 08 Sep 2017 10:28:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=2MkBtjLSZt1CERO8N7vuaXs8eFFh1IXnZnpDQJTTNaM=; b=HAOBgyckCGq9NT3Lz8PBPrJEbFKIIzQ4eqhOHMYm90Ja3T6hIqVPsA+rSe7+hK2LBs cZRlFug41udKDDhviGq2g9dE/IG8BUeinTvPPQMSecla8TeioDMPCdNHZUcKsTlM57HP J8uaLThVwgwXtnP5U1GXy7aicVyOM86t0HfjczvygSYVrgINho+Pl2KNu397Vn97PYsn GMKnYVYInZ9YUwmo2ndT+M452fVNCcEi4FEjF/ufM6DS6IghR6d1AzoK7FCBu/Gweg1d ZWxGrX/LZ/6aDgS/3wfH3MW1f7Mn5U5eVXIJpCVfEOS4HOfGFq+KZ35JSbpoKxVexfrU MJzQ== X-Gm-Message-State: AHPjjUgTpC4e/1y7okAz40aTCx7tW2HIn6glJSY0EUD+UOTzTjBrJXga bjMvmYWjM280BiwMpm0= X-Received: by 10.37.49.213 with SMTP id x204mr2985129ybx.40.1504891703397; Fri, 08 Sep 2017 10:28:23 -0700 (PDT) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com. [209.85.223.180]) by smtp.gmail.com with ESMTPSA id g72sm857818ywe.26.2017.09.08.10.28.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Sep 2017 10:28:23 -0700 (PDT) Received: by mail-io0-f180.google.com with SMTP id j141so7086827ioj.4; Fri, 08 Sep 2017 10:28:23 -0700 (PDT) X-Google-Smtp-Source: AOwi7QDmylPOb3whv/tuNKv4O5KPBnK9ifGcMIOY5h3XvOwOz8HvvJkn8EVmB1CGtTUDsObNq0FjJxFIqwcuJTIczl8= X-Received: by 10.107.29.149 with SMTP id d143mr2196817iod.201.1504891702611; Fri, 08 Sep 2017 10:28:22 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.81.131 with HTTP; Fri, 8 Sep 2017 10:28:22 -0700 (PDT) In-Reply-To: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> References: <0154558d-b2ad-af97-3960-3e392678f709@freebsd.org> From: Conrad Meyer Date: Fri, 8 Sep 2017 10:28:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: extending the maximum filename length To: Julian Elischer Cc: freebsd-current , Rick Macklem Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 17:28:30 -0000 On Fri, Sep 8, 2017 at 10:15 AM, Julian Elischer wrote: > Has anyone using freeBSD ever increased NAME_MAX (filename maximum length) > and have any experience with it? > > We ($JOB) would recompile the entire system so intra-system compatibility > would probably be ok, and we have our own filesystem which would support it. > > But I wonder if anyone has tried it and hit unexpected problems. > > > reason: Chinese and Japanese people who have gotten into the habit of > having a filename of 256 CHINESE/JAPANESE characters in Microsoft and want > to store their files on a FreeBSD based server witout having to rename > everything. (3 bytes for each of those characters giving a limit of 83 > characters). > > (though since each character is a word the names if I could read them must > be amazing) > > > NFS behaviour is one issue I don't know but would be interested in.. could > we SERVE such files? Hey Julian, We've done exactly this at Isilon. Basically we bumped NAME_MAX and related constants out by 4x (maximum length of a UTF-8 encoded Unicode character, in bytes). So NAME_MAX is 1023, PATH_MAX is 4096, and a bunch of follow-on equivalent/related constants are bumped similarly. To avoid breaking too many ABIs, we've retained a SHORT_NAME_MAX constant of 255 which several non-filesystem NAME_MAX users were converted to. Stuff like module name APIs, procstat, etc. Individual filesystems are free to implement and restrict maximum component lengths in VOP_LOOKUP. For us, we retained 255 bytes for basically all filesystems (see e.g. r316509, r313475) aside from IFS (the OneFS filesystem). For IFS we check that component names are 255 ("MAXNAMCHARS") unicode codepoints or fewer (not all names shorter than NAME_MAX bytes are valid). NFS commonly does not support >255 byte names, so we have a hack there to export longer names as some shorter name plus a hash (total length of 255 bytes or fewer) to uniquely identify the file. SMB exports longer names just fine. Anyway, we'd love to shift some of these patches upstream, if there is interest in supporting this kind of thing. Sure, there are a few snags here and there and some ABIs change. But overall it seems to work pretty well. Best, Conrad