On Fri, 18 Oct 2002 09:30:17 CDT, Ed Carp said:
>
> > 1) If it's a "sparse" file with holes in it, there may not have
> > been blocks
> > allocated to start with for all-zeros blocks.
>
> From the write(2) manpage: "POSIX requires that a read() which can be
> proved to occur after a write() has returned returns the new data."
Ahh - but if the original file was sparse, and you read a block of zeros,
the spec *requires* only that you get zeros. It doesn't say anything
about whether you get a block of all-zeros off the disk, or a block that's
zero-filled by the kernel because there's no block pointed to in the inode.
> No, sir, this will not happen, because the blocks are allocated to the
> file. The kernel will *not* deallocate zero-filled blocks just because
> they happen to be zero-filled - they have to be disassociated from the file
> first.
Do *NOT* confuse "the kernel is not permitted to" with "no current systems
actually do this".
> > 3) File systems that support compression (such as AIX's "jfs") will quite
> > likely allocate DIFFERENT blocks than before, if the new data
> > compresses into
> > different number of blocks than the old data. See (2) above as a special
> > case...
>
> No, this is again not correct.
Hate to tell you this, but on AIX, it is *QUITE* possible that the new and
old file blocks will end up in different locations. On an AIX 5.1 system:
[~]1 cat filetest.c
#include <stdio.h>
#include <fcntl.h>
#include <strings.h>
int main() {
int kern, snuffle;
char buffer[65536];
unlink("./foo.1");
snuffle = open ("./foo.1",O_RDWR|O_SYNC|O_CREAT,0622);
kern = open("/unix",O_RDONLY);
read(kern,buffer,65536);
write(snuffle,buffer,65536);
system("fileplace -l ./foo.1");
lseek(snuffle,0,SEEK_SET);
bzero(buffer,65536);
write(snuffle,buffer,65536);
system("fileplace -l ./foo.1");
}
[~]1 cc filetest.c
[~]1 ./a.out
File: ./foo.1 Size: 65536 bytes Vol: /dev/lv03
Blk Size: 4096 Frag Size: 512 Nfrags: 24 Compress: yes
Logical Fragment
----------------
0021632 2 frags 1024 Bytes, 8.3%
0021634 1 frags 512 Bytes, 4.2%
0021635 1 frags 512 Bytes, 4.2%
0021636 4 frags 2048 Bytes, 16.7%
0021728 5 frags 2560 Bytes, 20.8%
0021733 1 frags 512 Bytes, 4.2%
0021734 1 frags 512 Bytes, 4.2%
0021735 1 frags 512 Bytes, 4.2%
1704423 1 frags 512 Bytes, 4.2%
1704424 1 frags 512 Bytes, 4.2%
1704425 1 frags 512 Bytes, 4.2%
1704426 1 frags 512 Bytes, 4.2%
1704427 1 frags 512 Bytes, 4.2%
1704428 1 frags 512 Bytes, 4.2%
1704429 1 frags 512 Bytes, 4.2%
1704430 1 frags 512 Bytes, 4.2%
File: ./foo.1 Size: 65536 bytes Vol: /dev/lv03
Blk Size: 4096 Frag Size: 512 Nfrags: 16 Compress: yes
Logical Fragment
----------------
0021180 1 frags 512 Bytes, 6.2%
0021181 1 frags 512 Bytes, 6.2%
0021182 1 frags 512 Bytes, 6.2%
0021183 1 frags 512 Bytes, 6.2%
0021562 1 frags 512 Bytes, 6.2%
0021563 1 frags 512 Bytes, 6.2%
0021564 1 frags 512 Bytes, 6.2%
0021565 1 frags 512 Bytes, 6.2%
0022284 1 frags 512 Bytes, 6.2%
0022285 1 frags 512 Bytes, 6.2%
0022286 1 frags 512 Bytes, 6.2%
0022287 1 frags 512 Bytes, 6.2%
0022505 1 frags 512 Bytes, 6.2%
0022506 1 frags 512 Bytes, 6.2%
0022507 1 frags 512 Bytes, 6.2%
0022508 1 frags 512 Bytes, 6.2%
[~]1
So tell me - what over-wrote fragments 21632 through 21636, which are
still on the disk and still have the first 4K of /unix copied into them?
But like you said - this never happens.. ;)
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 11:01:11 PDT