Date: Wed, 5 Dec 2001 22:23:09 -0800 From: "Crist J . Clark" <cristjc@earthlink.net> To: Bernd Walter <ticso@cicely8.cicely.de> Cc: Greg Black <gjb@gbch.net>, Matthew Dillon <dillon@apollo.backplane.com>, Ian Dowse <iedowse@maths.tcd.ie>, Mark Hannon <markhannon@optushome.com.au>, bugs-followup@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: bin/32261: dump creates a dump file much larger than sum of dumped files Message-ID: <20011205222309.O3061@blossom.cjclark.org> In-Reply-To: <20011205160246.A84086@cicely8.cicely.de>; from ticso@cicely8.cicely.de on Wed, Dec 05, 2001 at 04:02:47PM %2B0100 References: <200112041339.aa05506@salmon.maths.tcd.ie> <200112041957.fB4Jv1j20226@apollo.backplane.com> <nospam-1007496169.54760@bambi.gbch.net> <20011204225814.E40864@blossom.cjclark.org> <nospam-1007536249.88093@bambi.gbch.net> <20011204232639.F40864@blossom.cjclark.org> <20011205160246.A84086@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 05, 2001 at 04:02:47PM +0100, Bernd Walter wrote:
> On Tue, Dec 04, 2001 at 11:26:39PM -0800, Crist J . Clark wrote:
[snip]
> > From what Ian said elsewhere in this thread, the O_TRUNC already does
> > not "act strange" on a tape device. I don't see any new POLA issues if
> > adding O_TRUNC to the write call doesn't change how dump(8) has been
> > working on tapes for FreeBSD for these n years now. The only POLA
> > issue I see is the current behavior that "regular" files are _not_
> > truncated, which was the start of the thread and the issue in the PR.
>
> That FreeBSD tape devices ignore this isn't a strong reason to do.
> People may also dump to disk devices,
I tested it. They don't care about O_TRUNC.
> unix domains sockets, fifo
I tested it. They don't care about O_TRUNC.
> devices or media your don't even know today.
How can you say if O_TRUNC or !O_TRUNC will be the desired behavior?
Right now, O_TRUNC is desired for plain ol' files. O_TRUNC doesn't
make a difference for tapes, raw disks, or FIFOs. If we need to add
support for something else in the future, fine. If a future media type
wants O_TRUNC, it's already there.
> And the fstat way don't hurt anyone but instead is an absolute save
> way without expecting anything about the output stream behavour.
So you are going to do a switch for every possible file type? But what
about the future unknown types? What do you do for the default case?
Why bother since what to do for all of the known cases can be the same
and should work for unknown cases too.
> > I don't see who would care if FreeBSD's dump(8) might have some funny
> > reactions on UNIX-like systems where O_TRUNC has a different behavior
> > on tape devices. I don't think the Project is overly concerned about
> > porting FreeBSD's dump(8) to other OSes.
>
> But we might care porting device drivers to FreeBSD.
This will have no impact on device drivers.
> Think of that we may start and run linux kernel modules someday.
If open(2) calls behave differently, dump(8) is going to be the least
of our concerns.
> I don't asume it to be very likely - but you never know.
Nope, not very likely.
How about I put this in CURRENT, let it sit for a while, and if anyone
has problems, we can deal with them? I don't see a big problem here.
--
"It's always funny until someone gets hurt. Then it's hilarious."
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011205222309.O3061>