Date: Sun, 9 Nov 2008 12:14:58 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Polytropon <freebsd@edvax.de> Cc: Jeremy Chadwick <koitsu@freebsd.org>, freebsd-questions@freebsd.org, no-spam@people.net.au Subject: Re: UFS2 limits Message-ID: <20081109111458.GA73755@owl.midgard.homeip.net> In-Reply-To: <20081109104711.e03722c4.freebsd@edvax.de> References: <50261.1226194851@people.net.au> <20081109024046.GB27423@icarus.home.lan> <20081109093521.GA73108@owl.midgard.homeip.net> <20081109104711.e03722c4.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 09, 2008 at 10:47:11AM +0100, Polytropon wrote: > On Sun, 9 Nov 2008 10:35:21 +0100, Erik Trulsson <ertr1013@student.uu.se> wrote: > > Note that this does not limit the number of files you can have in a single > > directory, since normal files do not contain hardlinks to the parent > > directory, but there are of course limits to the total number of files and > > directories you can have on a single filesystem based on how many inodes > > were created when the filesystem was first created. > > Maybe this sounds stupid, but... given that a file system > can hold n entries. What happens when a program tries to > create file number n + 1? > > I do ask this in order to explore if this could have been > the reason for my massive data loss and UFS file system > corruption. I haven't tested what actually happens, but what should happen is that the attempt to create file n+1 will simply fail with some appropriate error code (see open(2) or mkdir(2) for details.) It is certainly not supposed to cause any kind of files system corruption. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081109111458.GA73755>