| To: | Chris Wedgwood <cw@xxxxxxxx> |
|---|---|
| Subject: | Re: hardlink overflow |
| From: | Ragnar Kjørstad <xfs@xxxxxxxxxxxxxxxxxxx> |
| Date: | Sun, 8 Sep 2002 04:37:03 +0200 |
| Cc: | Eric Mei <ericm@xxxxxxxxxxxxxxxxxxxx>, xfs-list <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <20020907222611.GA2652@xxxxxxxxxxxxx>; from cw@xxxxxxxx on Sat, Sep 07, 2002 at 03:26:11PM -0700 |
| References: | <3D79BCE4.9050703@xxxxxxxxxxxxxxxxxxxx> <20020907222611.GA2652@xxxxxxxxxxxxx> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5.1i |
On Sat, Sep 07, 2002 at 03:26:11PM -0700, Chris Wedgwood wrote: > On Sat, Sep 07, 2002 at 04:46:28PM +0800, Eric Mei wrote: > > it seems linux-XFS didn't check it's overflow. simply add 65536 > > hardlink to a file will make their nlink to 0. > > Yes, I can confirm I've seen this too. It's not hard to patch this in > XFS, but in general I wonder if this fix doesn't really belong in the > VFS layer and there *are* system calls that can return larger than the > 16-bit value. There is a thread on l-k and reiserfs about this. Basicly it has been proposed to change VFS to truncate nlink or use special values (0 or 1) when nlink is to large to be exported to userspace. -- Ragnar Kjørstad |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: XFS & NVIDIA Bug?, Andy Ritger |
|---|---|
| Next by Date: | Re: XFS & NVIDIA Bug?, Austin Gonyou |
| Previous by Thread: | Re: hardlink overflow, Chris Wedgwood |
| Next by Thread: | TAKE - v2 log, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |