From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: DT_WHT (Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)) Date: Thu, 14 Mar 2013 21:57:46 +0900 Message-ID: <1402.1363265866@jrobl> References: <1363102908-28956-1-git-send-email-miklos@szeredi.hu> <20130312222350.GK21522@ZenIV.linux.org.uk> <20130313185249.GL21522@ZenIV.linux.org.uk> <20130313231918.GP21522@ZenIV.linux.org.uk> Cc: Al Viro , Linus Torvalds , linux-fsdevel , Linux Kernel Mailing List , Christoph Hellwig , Andrew Morton , Robo Bot , Felix Fietkau , Neil Brown , Jordi Pujol , ezk@fsl.cs.sunysb.edu, David Howells , Sedat Dilek To: Miklos Szeredi Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Miklos Szeredi: > On Thu, Mar 14, 2013 at 12:19 AM, Al Viro wrote: ::: > > As for whiteouts... I think we ought to pull these bits of unionmoun > > queue into the common stem and add the missing filesystems to them; > > ext* and ufs are trivial (keep in mind that FFS derivatives, including > > ext*, have d_type in directory entry and type 14 (DT_WHT) is there > > precisely for that purpose). btrfs also has "dir_type" thing - 8bit > > field... > > What about userspace interfaces? Are we allowed to extend d_type and > st_mode without breaking things? Introducing a new d_type value can be a headache for other filesystems or other OSs. Whiteout and opaque by xattr is an idea, but I prefer more primitive way (special hidden filename) since xattr may force users to change their configuration and it consumes disk space a little. Filesystems may have a limit for the consumed size by xattr. If xattr reaches the limit, then several operation in overlayfs will be unusable. J. R. Okajima