Re: [PATCH e2fsprogs] return status from chattr
On Fri, Oct 19, 2007 at 01:55:07PM -0500, Eric Sandeen wrote: Eric Sandeen wrote: This is for RH bug #180596, Chattr command doesn't provide expected exit code in case of failure. (trying to clear out an e2fsprogs bug backlog, can you tell?) :) Any comments on this one? Can we commit it if it looks ok? It turns out you didn't quite completely fix the problem, since the iterate_on_directory() command wasn't reflecting errors up. Also, while I was at it I cleaned up the code so that it more it attempts to set the flags on special files, instead of just ignoring them. On Linux this will result in an error message, but at least this way the user knows that those files didn't get set, and you can suppress them using the -f flag, just like chmod/chown. - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] libe2p: Use lstat() instead of stat() in fsetflags() and fgetflags()
We can't set the flags on symbolic links, so check for them using
lstat().
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
lib/e2p/fgetflags.c |2 +-
lib/e2p/fsetflags.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/e2p/fgetflags.c b/lib/e2p/fgetflags.c
index 0aed6c8..372304f 100644
--- a/lib/e2p/fgetflags.c
+++ b/lib/e2p/fgetflags.c
@@ -65,7 +65,7 @@ int fgetflags (const char * name, unsigned long * flags)
#if HAVE_EXT2_IOCTLS
int fd, r, f, save_errno = 0;
- if (!stat(name, buf)
+ if (!lstat(name, buf)
!S_ISREG(buf.st_mode) !S_ISDIR(buf.st_mode)) {
goto notsupp;
}
diff --git a/lib/e2p/fsetflags.c b/lib/e2p/fsetflags.c
index 2f1277f..3a05324 100644
--- a/lib/e2p/fsetflags.c
+++ b/lib/e2p/fsetflags.c
@@ -71,7 +71,7 @@ int fsetflags (const char * name, unsigned long flags)
#if HAVE_EXT2_IOCTLS
int fd, r, f, save_errno = 0;
- if (!stat(name, buf)
+ if (!lstat(name, buf)
!S_ISREG(buf.st_mode) !S_ISDIR(buf.st_mode)) {
goto notsupp;
}
--
1.5.3.4.1232.g9991d-dirty
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] chattr: provide an exit code in case of failure and add -f flag
Fix chattr so that if there are errors, it will report it via a
non-zero exit code. It will now explicitly give errors when
attempting to set files that are not files or directories (which are
currently not supported under Linux). The -f flag will suppress error
messages from being printed, although the exit status will still be
non-zero.
Addresses-Red-Hat-Bugzilla: #180596
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
---
misc/chattr.1.in |7 ++--
misc/chattr.c| 83 +++--
2 files changed, 52 insertions(+), 38 deletions(-)
diff --git a/misc/chattr.1.in b/misc/chattr.1.in
index 2b48fb0..2334675 100644
--- a/misc/chattr.1.in
+++ b/misc/chattr.1.in
@@ -5,7 +5,7 @@ chattr \- change file attributes on a Linux second extended
file system
.SH SYNOPSIS
.B chattr
[
-.B \-RV
+.B \-RVf
]
[
.B \-v
@@ -34,12 +34,13 @@ synchronous updates (S), and top of directory hierarchy (T).
.TP
.B \-R
Recursively change attributes of directories and their contents.
-Symbolic links encountered during recursive directory traversals are
-ignored.
.TP
.B \-V
Be verbose with chattr's output and print the program version.
.TP
+.B \-f
+Suppress most error messages.
+.TP
.BI \-v version
Set the file's version/generation number.
.SH ATTRIBUTES
diff --git a/misc/chattr.c b/misc/chattr.c
index c6d8d9f..efaa559 100644
--- a/misc/chattr.c
+++ b/misc/chattr.c
@@ -65,6 +65,7 @@ static unsigned long version;
static int recursive;
static int verbose;
+static int silent;
static unsigned long af;
static unsigned long rf;
@@ -80,8 +81,8 @@ static unsigned long sf;
static void usage(void)
{
- fprintf(stderr,
- _(Usage: %s [-RV] [-+=AacDdijsSu] [-v version] files...\n),
+ fprintf(stderr,
+ _(Usage: %s [-RVf] [-+=AacDdijsSu] [-v version] files...\n),
program_name);
exit(1);
}
@@ -137,6 +138,10 @@ static int decode_arg (int * i, int argc, char ** argv)
verbose = 1;
continue;
}
+ if (*p == 'f') {
+ silent = 1;
+ continue;
+ }
if (*p == 'v') {
(*i)++;
if (*i = argc)
@@ -144,7 +149,7 @@ static int decode_arg (int * i, int argc, char ** argv)
version = strtol (argv[*i], tmp, 0);
if (*tmp) {
com_err (program_name, 0,
-_(bad version - %s\n),
+_(bad version - %s\n),
argv[*i]);
usage ();
}
@@ -182,26 +187,17 @@ static int decode_arg (int * i, int argc, char ** argv)
static int chattr_dir_proc (const char *, struct dirent *, void *);
-static void change_attributes (const char * name)
+static int change_attributes (const char * name, int cmdline)
{
unsigned long flags;
STRUCT_STAT st;
if (LSTAT (name, st) == -1) {
- com_err (program_name, errno, _(while trying to stat %s),
-name);
- return;
+ if (!silent)
+ com_err (program_name, errno,
+_(while trying to stat %s), name);
+ return -1;
}
- if (S_ISLNK(st.st_mode) recursive)
- return;
-
- /* Don't try to open device files, fifos etc. We probably
- ought to display an error if the file was explicitly given
- on the command line (whether or not recursive was
- requested). */
- if (!S_ISREG(st.st_mode) !S_ISLNK(st.st_mode)
- !S_ISDIR(st.st_mode))
- return;
if (set) {
if (verbose) {
@@ -212,10 +208,12 @@ static void change_attributes (const char * name)
if (fsetflags (name, sf) == -1)
perror (name);
} else {
- if (fgetflags (name, flags) == -1)
- com_err (program_name, errno,
-_(while reading flags on %s), name);
- else {
+ if (fgetflags (name, flags) == -1) {
+ if (!silent)
+ com_err (program_name, errno,
+_(while reading flags on %s), name);
+ return -1;
+ } else {
if (rem)
flags = ~rf;
if (add)
@@ -227,25 +225,36 @@ static void change_attributes (const char * name)
[PATCH] libe2p: Change iterate_on_dir so that it counts non-zero returns
To allow error messages to be reflected up, if the callback function
returns a non-zero value, bump a counter and return the number of
times the callback function signals an error by returning a non-zero
status code.
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
lib/e2p/iod.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/e2p/iod.c b/lib/e2p/iod.c
index 808d3a3..84c9709 100644
--- a/lib/e2p/iod.c
+++ b/lib/e2p/iod.c
@@ -27,7 +27,7 @@ int iterate_on_dir (const char * dir_name,
{
DIR * dir;
struct dirent *de, *dep;
- int max_len = -1, len;
+ int max_len = -1, len, ret = 0;
#if HAVE_PATHCONF defined(_PC_NAME_MAX)
max_len = pathconf(dir_name, _PC_NAME_MAX);
@@ -64,9 +64,10 @@ int iterate_on_dir (const char * dir_name,
len = max_len;
#endif
memcpy(de, dep, len);
- (*func) (dir_name, de, private);
+ if ((*func)(dir_name, de, private))
+ ret++;
}
free(de);
closedir(dir);
- return 0;
+ return ret;
}
--
1.5.3.4.1232.g9991d-dirty
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ext2: Fix the max file size for ext2 file system.
The max file size for ext2 file system is now calculated
with hardcoded 4K block size. The patch fixes it to be
calculated with the right block size.
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
---
fs/ext2/super.c | 32
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/fs/ext2/super.c b/fs/ext2/super.c
index 77bd5f9..3d2019e 100644
--- a/fs/ext2/super.c
+++ b/fs/ext2/super.c
@@ -676,11 +676,31 @@ static int ext2_check_descriptors (struct super_block *
sb)
static loff_t ext2_max_size(int bits)
{
loff_t res = EXT2_NDIR_BLOCKS;
- /* This constant is calculated to be the largest file size for a
-* dense, 4k-blocksize file such that the total number of
+ int meta_blocks;
+ loff_t upper_limit;
+
+ /* This is calculated to be the largest file size for a
+* dense, file such that the total number of
* sectors in the file, including data and all indirect blocks,
-* does not exceed 2^32. */
- const loff_t upper_limit = 0x1ff7fffd000LL;
+* does not exceed 2^32 -1
+* __u32 i_blocks representing the total number of
+* 512 bytes blocks of the file
+*/
+ upper_limit = (1LL 32) - 1;
+
+ /* total blocks in file system block size */
+ upper_limit = (bits - 9);
+
+
+ /* indirect blocks */
+ meta_blocks = 1;
+ /* double indirect blocks */
+ meta_blocks += 1 + (1LL (bits-2));
+ /* tripple indirect blocks */
+ meta_blocks += 1 + (1LL (bits-2)) + (1LL (2*(bits-2)));
+
+ upper_limit -= meta_blocks;
+ upper_limit = bits;
res += 1LL (bits-2);
res += 1LL (2*(bits-2));
@@ -688,6 +708,10 @@ static loff_t ext2_max_size(int bits)
res = bits;
if (res upper_limit)
res = upper_limit;
+
+ if (res MAX_LFS_FILESIZE)
+ res = MAX_LFS_FILESIZE;
+
return res;
}
--
1.5.3.4.206.g58ba4-dirty
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ext3: Fix the max file size for ext3 file system.
The max file size for ext3 file system is now calculated
with hardcoded 4K block size. The patch fixes it to be
calculated with the right block size.
Signed-off-by: Aneesh Kumar K.V [EMAIL PROTECTED]
---
fs/ext3/super.c | 32
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 81868c0..0bfd3dc 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -1431,11 +1431,31 @@ static void ext3_orphan_cleanup (struct super_block *
sb,
static loff_t ext3_max_size(int bits)
{
loff_t res = EXT3_NDIR_BLOCKS;
- /* This constant is calculated to be the largest file size for a
-* dense, 4k-blocksize file such that the total number of
+ int meta_blocks;
+ loff_t upper_limit;
+
+ /* This is calculated to be the largest file size for a
+* dense, file such that the total number of
* sectors in the file, including data and all indirect blocks,
-* does not exceed 2^32. */
- const loff_t upper_limit = 0x1ff7fffd000LL;
+* does not exceed 2^32 -1
+* __u32 i_blocks representing the total number of
+* 512 bytes blocks of the file
+*/
+ upper_limit = (1LL 32) - 1;
+
+ /* total blocks in file system block size */
+ upper_limit = (bits - 9);
+
+
+ /* indirect blocks */
+ meta_blocks = 1;
+ /* double indirect blocks */
+ meta_blocks += 1 + (1LL (bits-2));
+ /* tripple indirect blocks */
+ meta_blocks += 1 + (1LL (bits-2)) + (1LL (2*(bits-2)));
+
+ upper_limit -= meta_blocks;
+ upper_limit = bits;
res += 1LL (bits-2);
res += 1LL (2*(bits-2));
@@ -1443,6 +1463,10 @@ static loff_t ext3_max_size(int bits)
res = bits;
if (res upper_limit)
res = upper_limit;
+
+ if (res MAX_LFS_FILESIZE)
+ res = MAX_LFS_FILESIZE;
+
return res;
}
--
1.5.3.4.206.g58ba4-dirty
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] badblocks: Use unsigned int instead of unsigned long for test patterns
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/badblocks.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/misc/badblocks.c b/misc/badblocks.c
index 29c5a5c..155fb77 100644
--- a/misc/badblocks.c
+++ b/misc/badblocks.c
@@ -67,7 +67,7 @@ static int s_flag = 0;/* show
progress of test */
static int force = 0; /* force check of mounted device */
static int t_flag = 0; /* number of test patterns */
static int t_max = 0; /* allocated test patterns */
-static unsigned long *t_patts = NULL; /* test patterns */
+static unsigned int *t_patts = NULL; /* test patterns */
static int current_O_DIRECT = 0; /* Current status of O_DIRECT flag */
static int exclusive_ok = 0;
@@ -221,13 +221,13 @@ static void set_o_direct(int dev, unsigned char *buffer,
size_t size,
}
-static void pattern_fill(unsigned char *buffer, unsigned long pattern,
+static void pattern_fill(unsigned char *buffer, unsigned int pattern,
size_t n)
{
unsigned inti, nb;
unsigned char bpattern[sizeof(pattern)], *ptr;
- if (pattern == (unsigned long) ~0) {
+ if (pattern == (unsigned int) ~0) {
for (ptr = buffer; ptr buffer + n; ptr++) {
(*ptr) = random() % (1 (8 * sizeof(char)));
}
@@ -435,8 +435,8 @@ static unsigned int test_rw (int dev, unsigned long
last_block,
unsigned long blocks_at_once)
{
unsigned char *buffer, *read_buffer;
- const unsigned long patterns[] = {0xaa, 0x55, 0xff, 0x00};
- const unsigned long *pattern;
+ const unsigned int patterns[] = {0xaa, 0x55, 0xff, 0x00};
+ const unsigned int *pattern;
int i, try, got, nr_pattern, pat_idx;
unsigned int bb_count = 0;
@@ -562,8 +562,8 @@ static unsigned int test_nd (int dev, unsigned long
last_block,
unsigned char *blkbuf, *save_ptr, *test_ptr, *read_ptr;
unsigned char *test_base, *save_base, *read_base;
int try, i;
- const unsigned long patterns[] = { ~0 };
- const unsigned long *pattern;
+ const unsigned int patterns[] = { ~0 };
+ const unsigned int *pattern;
int nr_pattern, pat_idx;
long got, used2, written, save_currently_testing;
struct saved_blk_record *test_record;
@@ -830,7 +830,7 @@ int main (int argc, char ** argv)
int passes_clean = 0;
int dev;
errcode_t errcode;
- unsigned long pattern;
+ unsigned int pattern;
unsigned int (*test_func)(int, unsigned long,
int, unsigned long,
unsigned long);
@@ -920,7 +920,7 @@ int main (int argc, char ** argv)
break;
case 't':
if (t_flag + 1 t_max) {
- unsigned long *t_patts_new;
+ unsigned int *t_patts_new;
t_patts_new = realloc(t_patts, t_max + T_INC);
if (!t_patts_new) {
@@ -943,7 +943,7 @@ int main (int argc, char ** argv)
optarg);
exit(1);
}
- if (pattern == (unsigned long) ~0)
+ if (pattern == (unsigned int) ~0)
pattern = 0x;
t_patts[t_flag++] = pattern;
}
@@ -962,7 +962,7 @@ int main (int argc, char ** argv)
in read-only mode));
exit(1);
}
- if (t_patts (t_patts[0] == (unsigned long) ~0)) {
+ if (t_patts (t_patts[0] == (unsigned int) ~0)) {
com_err(program_name, 0,
_(Random test_pattern is not allowed
in read-only mode));
--
1.5.3.4.1232.g9991d-dirty
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] badblocks: Factor out calls to strtoul to a helper function
The strtoul() function has a lot of messy error checking that needs to
be done; by factoring it out into one place we can make sure it's done
right in all of the places where it is called.
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/badblocks.c | 61 ++---
1 files changed, 25 insertions(+), 36 deletions(-)
diff --git a/misc/badblocks.c b/misc/badblocks.c
index a768a8a..709effe 100644
--- a/misc/badblocks.c
+++ b/misc/badblocks.c
@@ -819,11 +819,27 @@ static void check_mount(char *device_name)
}
+/*
+ * This function will convert a string to an unsigned long, printing
+ * an error message if it fails, and returning success or failure in err.
+ */
+static unsigned int parse_uint(const char *str, const char *descr)
+{
+ char*tmp;
+ unsigned long ret;
+
+ ret = strtoul(str, tmp, 0);
+ if (*tmp || errno || (ret UINT_MAX) ||
+ (ret == ULONG_MAX errno == ERANGE)) {
+ com_err (program_name, 0, _(invalid %s - %s), descr, str);
+ exit (1);
+ }
+ return ret;
+}
int main (int argc, char ** argv)
{
int c;
- char * tmp;
char * device_name;
char * host_device_name = NULL;
char * input_file = NULL;
@@ -871,8 +887,8 @@ int main (int argc, char ** argv)
while ((c = getopt (argc, argv, b:fi:o:svwnc:p:h:t:X)) != EOF) {
switch (c) {
case 'b':
- block_size = strtoul (optarg, tmp, 0);
- if (*tmp || block_size 4096) {
+ block_size = parse_uint(optarg, block size);
+ if (block_size 4096) {
com_err (program_name, 0,
_(bad block size - %s), optarg);
exit (1);
@@ -906,20 +922,11 @@ int main (int argc, char ** argv)
w_flag = 2;
break;
case 'c':
- blocks_at_once = strtoul (optarg, tmp, 0);
- if (*tmp) {
- com_err (program_name, 0,
-bad simultaneous block count - %s,
optarg);
- exit (1);
- }
+ blocks_at_once = parse_uint(optarg, blocks at once);
break;
case 'p':
- num_passes = strtoul (optarg, tmp, 0);
- if (*tmp) {
- com_err (program_name, 0,
- bad number of clean passes - %s, optarg);
- exit (1);
- }
+ num_passes = parse_uint(optarg,
+ number of clean passes);
break;
case 'h':
host_device_name = optarg;
@@ -942,13 +949,7 @@ int main (int argc, char ** argv)
if (!strcmp(optarg, r) || !strcmp(optarg,random)) {
t_patts[t_flag++] = ~0;
} else {
- pattern = strtoul(optarg, tmp, 0);
- if (*tmp) {
- com_err(program_name, 0,
- _(invalid test_pattern: %s\n),
- optarg);
- exit(1);
- }
+ pattern = parse_uint(optarg, test pattern);
if (pattern == (unsigned int) ~0)
pattern = 0x;
t_patts[t_flag++] = pattern;
@@ -995,27 +996,15 @@ int main (int argc, char ** argv)
}
} else {
errno = 0;
- last_block = strtoul (argv[optind], tmp, 0);
+ last_block = parse_uint(argv[optind], last block);
printf(last_block = %d (%s)\n, last_block, argv[optind]);
- if (*tmp || errno ||
- (last_block == ULONG_MAX errno == ERANGE)) {
- com_err (program_name, 0, _(invalid blocks count -
%s),
-argv[optind]);
- exit (1);
- }
last_block++;
optind++;
}
if (optind = argc-1) {
errno = 0;
- from_count = strtoul (argv[optind], tmp, 0);
+ from_count = parse_uint(argv[optind], start block);
printf(from_count = %d\n, from_count);
- if (*tmp || errno ||
- (from_count == ULONG_MAX errno == ERANGE)) {
- com_err (program_name, 0, _(invalid starting block
[PATCH] badblocks: Change unsigned long to blk_t and unsigned int, as appropriate
This will make it easier for us to support 64-bit block numbers when
the time comes. Not that running badblocks on a 4TB machine is
anything I want to contemplate!
Signed-off-by: Theodore Ts'o [EMAIL PROTECTED]
---
misc/badblocks.c | 74 +
1 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/misc/badblocks.c b/misc/badblocks.c
index 155fb77..a768a8a 100644
--- a/misc/badblocks.c
+++ b/misc/badblocks.c
@@ -73,7 +73,7 @@ static int exclusive_ok = 0;
#define T_INC 32
-int sys_page_size = 4096;
+unsigned int sys_page_size = 4096;
static void usage(void)
{
@@ -90,8 +90,8 @@ static void exclusive_usage(void)
exit(1);
}
-static unsigned long currently_testing = 0;
-static unsigned long num_blocks = 0;
+static blk_t currently_testing = 0;
+static blk_t num_blocks = 0;
static ext2_badblocks_list bb_list = NULL;
static FILE *out;
static blk_t next_bad = 0;
@@ -124,14 +124,14 @@ static void *allocate_buffer(size_t size)
* This routine reports a new bad block. If the bad block has already
* been seen before, then it returns 0; otherwise it returns 1.
*/
-static int bb_output (unsigned long bad)
+static int bb_output (blk_t bad)
{
errcode_t errcode;
if (ext2fs_badblocks_list_test(bb_list, bad))
return 0;
- fprintf(out, %lu\n, bad);
+ fprintf(out, %lu\n, (unsigned long) bad);
fflush(out);
errcode = ext2fs_badblocks_list_add (bb_list, bad);
@@ -151,7 +151,8 @@ static int bb_output (unsigned long bad)
static void print_status(void)
{
- fprintf(stderr, %15ld/%15ld, currently_testing, num_blocks);
+ fprintf(stderr, %15lu/%15lu, (unsigned long) currently_testing,
+ (unsigned long) num_blocks);
fputs(\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b,
stderr);
fflush (stderr);
}
@@ -197,7 +198,7 @@ static void uncapture_terminate(void)
}
static void set_o_direct(int dev, unsigned char *buffer, size_t size,
-unsigned long current_block)
+blk_t current_block)
{
#ifdef O_DIRECT
int new_flag = O_DIRECT;
@@ -262,8 +263,8 @@ static void pattern_fill(unsigned char *buffer, unsigned
int pattern,
* Perform a read of a sequence of blocks; return the number of blocks
*successfully sequentially read.
*/
-static long do_read (int dev, unsigned char * buffer, int try, int block_size,
-unsigned long current_block)
+static int do_read (int dev, unsigned char * buffer, int try, int block_size,
+ blk_t current_block)
{
long got;
@@ -291,8 +292,8 @@ static long do_read (int dev, unsigned char * buffer, int
try, int block_size,
* Perform a write of a sequence of blocks; return the number of blocks
*successfully sequentially written.
*/
-static long do_write (int dev, unsigned char * buffer, int try, int block_size,
-unsigned long current_block)
+static int do_write(int dev, unsigned char * buffer, int try, int block_size,
+ unsigned long current_block)
{
long got;
@@ -327,13 +328,13 @@ static void flush_bufs(void)
com_err(program_name, retval, _(during ext2fs_sync_device));
}
-static unsigned int test_ro (int dev, unsigned long last_block,
-int block_size, unsigned long from_count,
-unsigned long blocks_at_once)
+static unsigned int test_ro (int dev, blk_t last_block,
+int block_size, blk_t from_count,
+unsigned int blocks_at_once)
{
unsigned char * blkbuf;
int try;
- long got;
+ int got;
unsigned int bb_count = 0;
errcode_t errcode;
@@ -358,8 +359,9 @@ static unsigned int test_ro (int dev, unsigned long
last_block,
exit (1);
}
if (v_flag) {
- fprintf (stderr, _(Checking blocks %lu to %lu\n), from_count,
-last_block - 1);
+ fprintf (stderr, _(Checking blocks %lu to %lu\n),
+(unsigned long) from_count,
+(unsigned long) last_block - 1);
}
if (t_flag) {
fputs(_(Checking for bad blocks in read-only mode\n), stderr);
@@ -404,7 +406,7 @@ static unsigned int test_ro (int dev, unsigned long
last_block,
if (got == try) {
try = blocks_at_once;
/* recover page-aligned offset for O_DIRECT */
- if ( blocks_at_once = (unsigned long) (sys_page_size
9)
+ if ( (blocks_at_once = sys_page_size 9)
(currently_testing % (sys_page_size 9)!= 0))
try -= (sys_page_size 9)
- (currently_testing
@@ -430,9 +432,9 @@ static
Explanation of different branches in git tree
I gues Ted is following the same terminology. http://marc.info/?l=gitm=117965490313979w=2 There are four branches in git.git repository that track the source tree of git: master, maint, next, and pu. I may add more maintenance branches (e.g. maint-1.5.1) if we have huge backward incompatible feature updates in the future to keep an older release alive; I may not, but the distributed nature of git means any volunteer can run a stable-tree like that himself. The master branch is meant to contain what are very well tested and ready to be used in a production setting. There could occasionally be minor breakages or brown paper bag bugs but they are not expected to be anything major. Every now and then, a feature release is cut from the tip of this branch and they typically are named with three dotted decimal digits. The last such release was v1.5.2 done on May 20th this year. Whenever a feature release is made, maint branch is forked off from master at that point. Obvious, safe and urgent fixes after a feature release are applied to this branch and maintenance releases are cut from it. The maintenance releases are named with four dotted decimal, named after the feature release they are updates to; the last such release was v1.5.1.6. New features never go to this branch. This branch is also merged into master to propagate the fixes forward. A trivial and safe enhancement goes directly on top of master. A new development, either initiated by myself or more often by somebody who found his or her own itch to scratch, does not usually happen on master, however. Instead, a separate topic branch is forked from the tip of master, and it first is tested in isolation; I may make minimum fixups at this point. Usually there are a handful such topic branches that are running ahead of master in git.git repository. I do not publish the tip of these branches in my public repository, however, partly to keep the number of branches that downstream developers need to worry about low, and primarily because I am lazy. I judge the quality of topic branches, taking advices from the mailing list discussions. Some of them start out as good idea but obviously is broken in some areas (e.g. breaks the existing testsuite) and then with some more work (either by the original contributor or help from other people on the list) becomes more or less done and can now be tested by wider audience. Luckily, most of them start out in the latter, better shape. The next branch is to merge and test topic branches in the latter category. In general, the branch always contains the tip of master. It might not be quite rock-solid production ready, but is expected to work more or less without major breakage. I usually use next version of git for my own work, so it cannot be _that_ broken to prevent me from pushing the changes out. The next branch is where new and exciting things take place. The above three branches, master, maint and next are never rewound, so you should be able to safely track them (this automatically means the topics that have been merged into next are not rebased, and you can find the tip of topic branches you are interested in from the output of git log next). The pu (proposed updates) branch bundles all the remainder of topic branches. The pu branch, and topic branches that are only in pu, are subject to rebasing in general. When a topic that was in pu proves to be in testable shape, it graduates to next. I do this with: git checkout next git merge that-topic-branch Sometimes, an idea that looked promising turns out to be not so hot and the topic can be dropped from pu in such a case. A topic that is in next is expected to be tweaked and fixed to perfection before it is merged to master (that's why master can be expected to stay very stable). Similarly to the above I do it with this: git checkout master git merge that-topic-branch git branch -d that-topic-branch However, being in next is not a guarantee to appear in the next release (being in master is such a guarantee, unless it is later found seriously broken and reverted), or even in any future release. There even were cases that topics needed reverting a few commits in them before graduating to master, or a topic that already was in next were entirely reverted from next because fatal flaws were found in them later. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/14] Make e2fsck uninit block group aware.
On Mon, Oct 22, 2007 at 11:02:02AM -0500, Jose R. Santos wrote: Hi Ted, Aneesh was nice enough to explain how to checkout the next branch. This is the only patch that broke so I'm attaching one that applies cleanly Thanks, I was able to clean that up fairly easily myself. I noticed though that after applying the patch series, make check blew up: making check in lib/ext2fs make[1]: Entering directory `/usr/projects/e2fsprogs/e2fsprogs/build/lib/ext2fs' CC ../../../lib/ext2fs/tst_bitops.c LD tst_bitops CC ../../../lib/ext2fs/tst_badblocks.c LD tst_badblocks rw_bitmaps.o: In function `read_bitmaps': /usr/projects/e2fsprogs/e2fsprogs/build/lib/ext2fs/../../../lib/ext2fs/rw_bitmaps.c:237: undefined reference to `ext2fs_group_desc_csum_verify' /usr/projects/e2fsprogs/e2fsprogs/build/lib/ext2fs/../../../lib/ext2fs/rw_bitmaps.c:260: undefined reference to `ext2fs_group_desc_csum_verify' collect2: ld returned 1 exit status make[1]: *** [tst_badblocks] Error 1 make[1]: Leaving directory `/usr/projects/e2fsprogs/e2fsprogs/build/lib/ext2fs' make: *** [check-recursive] Error 1 That's a relatively straightforward adjustment to lib/ext2fs/Makefile.in; but please do make sure you run make check at the end of each patch series. In fact, something I will normally try to do is make sure that make check runs cleanly after every single patch in a patch series. That makes it a lot easier to do git bisect runs. Thanks, - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
+ pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user.patch added to -mm tree
The patch titled
Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
has been added to the -mm tree. Its filename is
pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user.patch
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
--
Subject: Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user
From: Christoph Lameter [EMAIL PROTECTED]
Simplify page cache zeroing of segments of pages through 3 functions
zero_user_segments(page, start1, end1, start2, end2)
Zeros two segments of the page. It takes the position where to
start and end the zeroing which avoids length calculations and
makes code clearer.
zero_user_segment(page, start, end)
Same for a single segment.
zero_user(page, start, length)
Length variant for the case where we know the length.
We remove the zero_user_page macro. Issues:
1. Its a macro. Inline functions are preferable.
2. The KM_USER0 macro is only defined for HIGHMEM.
Having to treat this special case everywhere makes the
code needlessly complex. The parameter for zeroing is always
KM_USER0 except in one single case that we open code.
Avoiding KM_USER0 makes a lot of code not having to be dealing
with the special casing for HIGHMEM anymore. Dealing with
kmap is only necessary for HIGHMEM configurations. In those
configurations we use KM_USER0 like we do for a series of other
functions defined in highmem.h.
Since KM_USER0 is depends on HIGHMEM the existing zero_user_page
function could not be a macro. zero_user_* functions introduced
here can be be inline because that constant is not used when these
functions are called.
Also extract the flushing of the caches to be outside of the kmap.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
Cc: Steven French [EMAIL PROTECTED]
Cc: Michael Halcrow [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Cc: Steven Whitehouse [EMAIL PROTECTED]
Cc: Trond Myklebust [EMAIL PROTECTED]
Cc: J. Bruce Fields [EMAIL PROTECTED]
Cc: Anton Altaparmakov [EMAIL PROTECTED]
Cc: Mark Fasheh [EMAIL PROTECTED]
Cc: David Chinner [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
fs/buffer.c| 44 ++-
fs/cifs/inode.c|2 -
fs/direct-io.c |4 +-
fs/ecryptfs/mmap.c |5 +--
fs/ext3/inode.c|4 +-
fs/ext4/inode.c|4 +-
fs/gfs2/bmap.c |2 -
fs/gfs2/ops_address.c |2 -
fs/libfs.c | 11 ++-
fs/mpage.c |7 +
fs/nfs/read.c | 10 +++
fs/nfs/write.c |4 --
fs/ntfs/aops.c | 18 +++-
fs/ntfs/file.c | 32 ++
fs/ocfs2/alloc.c |2 -
fs/ocfs2/aops.c|6 ++--
fs/reiserfs/inode.c|4 +-
fs/xfs/linux-2.6/xfs_lrw.c |2 -
include/linux/highmem.h| 49 ++-
mm/filemap_xip.c |2 -
mm/truncate.c |2 -
21 files changed, 102 insertions(+), 114 deletions(-)
diff -puN
fs/buffer.c~pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user
fs/buffer.c
---
a/fs/buffer.c~pagecache-zeroing-zero_user_segment-zero_user_segments-and-zero_user
+++ a/fs/buffer.c
@@ -1798,7 +1798,7 @@ void page_zero_new_buffers(struct page *
start = max(from, block_start);
size = min(to, block_end) - start;
- zero_user_page(page, start, size,
KM_USER0);
+ zero_user(page, start, size);
set_buffer_uptodate(bh);
}
@@ -1861,19 +1861,10 @@ static int __block_prepare_write(struct
mark_buffer_dirty(bh);
continue;
}
- if (block_end to || block_start from) {
- void *kaddr;
-
- kaddr = kmap_atomic(page, KM_USER0);
- if (block_end to)
- memset(kaddr+to, 0,
- block_end-to);
- if (block_start from)
- memset(kaddr+block_start,
- 0, from-block_start);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
-
Re: [PATCH -mm] Split fs/Kconfig: ext[234]
On Sat, 6 Oct 2007 12:15:08 +0400 Alexey Dobriyan [EMAIL PROTECTED] wrote: Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- fs/Kconfig | 191 -- fs/ext2/Kconfig | 55 + fs/ext3/Kconfig | 67 fs/ext4/Kconfig | 65 +++ 4 files changed, 190 insertions(+), 188 deletions(-) A reasonable thing to do, but poorly timed. I'd prefer not to carry a patch like this through two months of development, please. Late in the -rc timeframe would be a better time. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
compilebench numbers for ext4
Hello everyone, I recently posted some performance numbers for Btrfs with different blocksizes, and to help establish a baseline I did comparisons with Ext3. The graphs, numbers and a basic description of compilebench are here: http://oss.oracle.com/~mason/blocksizes/ Ext3 easily wins the read phase, but scores poorly while creating files and deleting them. Since ext3 is winning the read phase, we can assume the file layout is fairly good. I think most of the problems during the write phase are caused by pdflush doing metadata writeback. The file data and metadata are written separately, and so we end up seeking between things that are actually close together. Andreas asked me to give ext4 a try, so I grabbed the patch queue from Friday along with the latest Linus kernel. The FS was created with: mkfs.ext3 -I 256 /dev/ mount -o delalloc,mballoc,data=ordered -t ext4dev /dev/ I did expect delayed allocation to help the write phases of compilebench, especially the parts where it writes out .o files in random order (basically writing medium sized files all over the directory tree). But, every phase except reads showed huge improvements. http://oss.oracle.com/~mason/compilebench/ext4/ext-create-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-compile-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-rm-compare.png To match the ext4 numbers with Btrfs, I'd probably have to turn off data checksumming... But oddly enough I saw very bad ext4 read throughput even when reading a single kernel tree (outside of compilebench). The time to read the tree was almost 2x ext3. Have others seen similar problems? I think the ext4 delete times are so much better than ext3 because this is a single threaded test. delayed allocation is able to get everything into a few extents, and these all end up in the inode. So, the delete phase only needs to seek around in small directories and seek to well grouped inodes. ext3 probably had to seek all over for the direct/indirect blocks. So, tomorrow I'll run a few tests with delalloc and mballoc independently, but if there are other numbers people are interested in, please let me know. (test box was a desktop machine with single sata drive, barriers were not used). -chris - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compilebench numbers for ext4
On Mon, 22 Oct 2007 19:31:04 -0400 Chris Mason [EMAIL PROTECTED] wrote: I did expect delayed allocation to help the write phases of compilebench, especially the parts where it writes out .o files in random order (basically writing medium sized files all over the directory tree). But, every phase except reads showed huge improvements. http://oss.oracle.com/~mason/compilebench/ext4/ext-create-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-compile-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-rm-compare.png This might make the IO during reads a little easier to see. The dirs will look like the kernel after a make -j. So each directory will have a bunch of small .c files that are close together and a bunch of .o files that are randomly created across the tree. http://oss.oracle.com/~mason/compilebench/ext4/ext4-read.mpg -chris - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compilebench numbers for ext4
On Mon, 2007-10-22 at 19:31 -0400, Chris Mason wrote: Hello everyone, I recently posted some performance numbers for Btrfs with different blocksizes, and to help establish a baseline I did comparisons with Ext3. Thanks for doing this, Chris! The graphs, numbers and a basic description of compilebench are here: http://oss.oracle.com/~mason/blocksizes/ Ext3 easily wins the read phase, but scores poorly while creating files and deleting them. Since ext3 is winning the read phase, we can assume the file layout is fairly good. I think most of the problems during the write phase are caused by pdflush doing metadata writeback. The file data and metadata are written separately, and so we end up seeking between things that are actually close together. Andreas asked me to give ext4 a try, so I grabbed the patch queue from Friday along with the latest Linus kernel. The FS was created with: mkfs.ext3 -I 256 /dev/ mount -o delalloc,mballoc,data=ordered -t ext4dev /dev/ I did expect delayed allocation to help the write phases of compilebench, especially the parts where it writes out .o files in random order (basically writing medium sized files all over the directory tree). Unfortunately delayed allocation support for ordered mode is not there yet. But, every phase except reads showed huge improvements. http://oss.oracle.com/~mason/compilebench/ext4/ext-create-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-compile-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-rm-compare.png To match the ext4 numbers with Btrfs, I'd probably have to turn off data checksumming... But oddly enough I saw very bad ext4 read throughput even when reading a single kernel tree (outside of compilebench). The time to read the tree was almost 2x ext3. Have others seen similar problems? thanks for point this out, will run compilebench. Trying to understand the Disk IO graph http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png it looks like ext3 the blocks are spread over the disk, while ext4 is more around the same place, is this right? I think the ext4 delete times are so much better than ext3 because this is a single threaded test. delayed allocation is able to get everything into a few extents, and these all end up in the inode. So, the delete phase only needs to seek around in small directories and seek to well grouped inodes. ext3 probably had to seek all over for the direct/indirect blocks. So, tomorrow I'll run a few tests with delalloc and mballoc independently, but if there are other numbers people are interested in, please let me know. (test box was a desktop machine with single sata drive, barriers were not used). -chris - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: compilebench numbers for ext4
On Mon, 22 Oct 2007 17:12:58 -0700 Mingming Cao [EMAIL PROTECTED] wrote: On Mon, 2007-10-22 at 19:31 -0400, Chris Mason wrote: Hello everyone, I recently posted some performance numbers for Btrfs with different blocksizes, and to help establish a baseline I did comparisons with Ext3. Thanks for doing this, Chris! The graphs, numbers and a basic description of compilebench are here: http://oss.oracle.com/~mason/blocksizes/ Ext3 easily wins the read phase, but scores poorly while creating files and deleting them. Since ext3 is winning the read phase, we can assume the file layout is fairly good. I think most of the problems during the write phase are caused by pdflush doing metadata writeback. The file data and metadata are written separately, and so we end up seeking between things that are actually close together. Andreas asked me to give ext4 a try, so I grabbed the patch queue from Friday along with the latest Linus kernel. The FS was created with: mkfs.ext3 -I 256 /dev/ mount -o delalloc,mballoc,data=ordered -t ext4dev /dev/ I did expect delayed allocation to help the write phases of compilebench, especially the parts where it writes out .o files in random order (basically writing medium sized files all over the directory tree). Unfortunately delayed allocation support for ordered mode is not there yet. Sorry, I meant to write data=writeback, not sure how my fingers typed ordered instead. But, every phase except reads showed huge improvements. http://oss.oracle.com/~mason/compilebench/ext4/ext-create-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-compile-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png http://oss.oracle.com/~mason/compilebench/ext4/ext-rm-compare.png To match the ext4 numbers with Btrfs, I'd probably have to turn off data checksumming... But oddly enough I saw very bad ext4 read throughput even when reading a single kernel tree (outside of compilebench). The time to read the tree was almost 2x ext3. Have others seen similar problems? thanks for point this out, will run compilebench. Trying to understand the Disk IO graph http://oss.oracle.com/~mason/compilebench/ext4/ext-read-compare.png it looks like ext3 the blocks are spread over the disk, while ext4 is more around the same place, is this right? It does look like that, but the ext4 movie shows the middle line a little differently than the graph. The middle ext4 line is actually comprised of a lot of seeks. For comparison, here's the ext3 movie: http://oss.oracle.com/~mason/compilebench/ext4/ext3-read.mpg Even though the ext3 data looks more spread out, there are more throughput peaks, and fewer seeks overall in ext3. -chris - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
