I apologize for losing threading information. I've been reading from the
archives of late, instead of monitoring this list.
I was a disappointed to read many of the conclusions with regard to
this thread. Certainly sparse files should be known and understood, at
least in concept, by UNIX administrators. However - we're not talking
about regular sparse files here. We're talking about the very real
potentially of a file that requires a 64-bit integer to represents
its file size. AMD64 and Intel's entry in this arena are reaching a
price range where these will become common over the next few years.
Have you ever tried to count to 2^64? No matter how good cp, tar, or
cpio are at compacting sparse files in their representation of the
data, it still requires an insanely large number of system calls, and
byte copies (even if only re-filling a buffer with 0's over and over),
and processing effort for these applications to determine that these
blocks are in fact empty. There is no algorithm I see of detecting
this situation. Unless the operating system provided a system call to
query 'which blocks are actually used in this file', and all
applications were written to call this system call, the line of
argument that says that this is ok is completely wrong.
Also - for common file systems, is 2^64 byte file even practical to
represent? Unless I'm mistaken, the last log file will have several
levels of indirection on disk before being able to determine which
block to read from or write to. If the data was actually there, this
level of redirection would be a requirement. The data isn't, though,
and there is no reason for this file to be larger than a few blocks,
including file system metadata that the user never needs to see.
I consider this a bug. -1 should not be a valid userid, or if it is,
it should be represented differently when stored to disk. There is no
requirement that I see that this file be in the format that it is. I
would suspect that this was a matter of implementation convenience.
My file with Fedora Core 3 is 19 Mbytes. If Fedora Core 4 is going to
cause this to jump to something completely unreasonable, I am
concerned. Then again - my /etc/passwd doesn't have a -1. So, my
question then is - is this -1 caused by silly choices made by the
user? Or is some RPM or tool in Fedora Core 4 going to use -1 for me?
I suspect I would be content if negative uid's were never stored to
lastlog.
Just some thoughts and an opinion. I'm looking forward to using Fedora
Core 4 as I believe it has several packages that I have been waiting
for. After following rawhide for Fedora Core 2, and Fedora Core 3, I
decided to opt out for Fedora Core 4 and reclaim a portion of my
life allowing other people to take a turn. :-)
Cheers,
mark
--
mark@xxxxxxxxx / markm@xxxxxx / markm@xxxxxxxxxx __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/