On 09/18/2007 09:44 PM, Linus Torvalds wrote:
Nobody sane would *ever* argue for 16kB+ blocksizes in general.
Well, not so sure about that. What if one of your expected uses for example
is video data storage -- lots of data, especially for multiple streams, and
needs still relatively fast
On 09/19/2007 05:50 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
Well, not so sure about that. What if one of your expected uses for example is
video data storage -- lots of data, especially for multiple streams, and needs
still relatively fast machinery. Why would you
On 09/19/2007 06:33 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
I do feel larger blocksizes continue to make sense in general though. Packet
writing on CD/DVD is a problem already today since the hardware needs 32K or
64K blocks and I'd expect to see more
level extendeds).
Rene.
/*
* Public Domain 2007, Rene Herman
*/
#define _LARGEFILE64_SOURCE
#include stdlib.h
#include stdio.h
#include stdint.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include sys/ioctl.h
#include unistd.h
#include fcntl.h
#include endian.h
#include
On 07/23/2007 12:54 PM, Rene Herman wrote:
static inline uint32_t le_32(uint32_t n)
{
#ifdef __LITTLE_ENDIAN
return n;
#else
return bswap_32(n);
#endif
}
#if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh.
Rene.
-
To unsubscribe from this list: send the line unsubscribe linux
On 07/23/2007 03:15 PM, Jan-Benedict Glaw wrote:
static inline uint32_t le_32(uint32_t n)
{
#ifdef __LITTLE_ENDIAN
return n;
#else
return bswap_32(n);
#endif
}
#if __BYTE_ORDER == __LITTLE_ENDIAN, that is. sigh.
Don't forget PDP11 byteorder :-)
How could I? It cracks me up
On 07/23/2007 03:58 PM, Theodore Tso wrote:
Well, I'm considering this to be a MBR backup scheme, so Minix and BSD
slices are legacy systems which are out of scope. If they are busted in
the same way as MBR in terms of not having redundant backups of critical
data, when they have a lot fewer
