On Thu, 2005-07-14 at 22:27, Badari Pulavarty wrote:
> Daniel McNeil wrote:
>
> > On Thu, 2005-07-14 at 16:16, Badari Pulavarty wrote:
> >
> >>How does your patch ensures that we meet the driver alignment
> >>restrictions ? Like you said, you need atleast "even" byte alignment
> >>for IDE etc..
> >>
> >>And also, are there any restrictions on how much the "minimum" IO
> >>size has to be ? I mean, can I read "1" byte ? I guess you are
> >>not relaxing it (yet)..
> >>
> >
> >
> > This patch does not change the i/o size requirements -- they
> > must be a multiple of device block size (usually 512).
> >
> > It only relaxes the address alignment restriction. I do not
> > know what the driver alignment restrictions are. Without the
> > 1st patch, it was impossible to relax the address space
> > check and have direct-io generate the correct i/o's to submit.
> >
> > This 2nd patch, is just for testing and generating feedback
> > to find out what the address alignment issues are. Then
> > we can decide how to proceed.
> >
> > Did you look over the 1st patch? Comments?
>
> Yes. I did look at the first patch and my questions were basically
> towards the first patch. I don't see any enforcement of alignment
> with your patch at all. So, we let the driver fail if it can't
> handle it ?
>
The 1st patch re-writes direct-io to handle non-512 aligned
addresses. Without the 2nd patch, it will never see non-512
aligned user address and should work the same as before only
with slightly smaller code :). The drivers will get the
same 512-byte aligned addresses. Am I missing something?
> BTW, I don't think the first patch is really doing the right thing.
> You got little carried away while cleaning up.
> You are trying to relax "user buffer" alignment only. If your
> "offset" is in the middle of a filesystem block (say 4k), you still
> need to zero out the first portion to be able to write into the
> middle. That "evil" code is still needed. :(
>
The code still does zero out the 1st portion. dio_zero_block()
is being called twice still. Sure looks like it is working to
me:
Test program d.c:
------------------------
#define _GNU_SOURCE 1
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
main()
{
int fd;
char *buf;
int io_size = 512;
off_t skip = 512;
int i;
if (posix_memalign((void *)&buf, getpagesize(), io_size) != 0) {
perror("cannot alloc mem");
exit(1);
}
memset(buf, 'a', io_size);
fd = open("direct_test_file", O_RDWR|O_DIRECT|O_TRUNC|O_CREAT, 0666);
lseek(fd, skip, SEEK_SET);
if ((i = write(fd, buf, io_size)) != io_size) {
perror("bad write");
exit(2);
}
printf("write to direct_test_file %d bytes of 'a' at %d\n", i, skip);
memset(buf, 'b', io_size);
lseek(fd, getpagesize(), SEEK_SET);
if ((i = write(fd, buf, io_size)) != io_size) {
perror("bad write");
exit(2);
}
printf("write to direct_test_file %d bytes of 'b' at %d\n", i, getpagesize());
}
--------------------------
$ ./d
write to direct_test_file 512 bytes of 'a' at 512
write to direct_test_file 512 bytes of 'b' at 4096
$ hexdump direct_test_file
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 6161 6161 6161 6161 6161 6161 6161 6161
*
0000400 0000 0000 0000 0000 0000 0000 0000 0000
*
0001000 6262 6262 6262 6262 6262 6262 6262 6262
*
0001200
The 1st 512 bytes are zeroed as well as the bytes between
1k and 4k.
Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |