- ext2-avoid-rec_len-overflow-with-64kb-block-size.patch removed from -mm tree
The patch titled ext2: avoid rec_len overflow with 64KB block size has been removed from the -mm tree. Its filename was ext2-avoid-rec_len-overflow-with-64kb-block-size.patch This patch was dropped because it was merged into mainline or a subsystem tree -- Subject: ext2: avoid rec_len overflow with 64KB block size From: Jan Kara <[EMAIL PROTECTED]> With 64KB blocksize, a directory entry can have size 64KB which does not fit into 16 bits we have for entry length. So we store 0x instead and convert the value when read from / written to disk. [EMAIL PROTECTED]: coding-style fixes] Signed-off-by: Jan Kara <[EMAIL PROTECTED]> Cc: Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- fs/ext2/dir.c | 44 +++--- include/linux/ext2_fs.h |1 2 files changed, 33 insertions(+), 12 deletions(-) diff -puN fs/ext2/dir.c~ext2-avoid-rec_len-overflow-with-64kb-block-size fs/ext2/dir.c --- a/fs/ext2/dir.c~ext2-avoid-rec_len-overflow-with-64kb-block-size +++ a/fs/ext2/dir.c @@ -28,6 +28,24 @@ typedef struct ext2_dir_entry_2 ext2_dirent; +static inline unsigned ext2_rec_len_from_disk(__le16 dlen) +{ + unsigned len = le16_to_cpu(dlen); + + if (len == EXT2_MAX_REC_LEN) + return 1 << 16; + return len; +} + +static inline __le16 ext2_rec_len_to_disk(unsigned len) +{ + if (len == (1 << 16)) + return cpu_to_le16(EXT2_MAX_REC_LEN); + else if (len > (1 << 16)) + BUG(); + return cpu_to_le16(len); +} + /* * ext2 uses block-sized chunks. Arguably, sector-sized ones would be * more robust, but we have what we have @@ -106,7 +124,7 @@ static void ext2_check_page(struct page } for (offs = 0; offs <= limit - EXT2_DIR_REC_LEN(1); offs += rec_len) { p = (ext2_dirent *)(kaddr + offs); - rec_len = le16_to_cpu(p->rec_len); + rec_len = ext2_rec_len_from_disk(p->rec_len); if (rec_len < EXT2_DIR_REC_LEN(1)) goto Eshort; @@ -204,7 +222,8 @@ static inline int ext2_match (int len, c */ static inline ext2_dirent *ext2_next_entry(ext2_dirent *p) { - return (ext2_dirent *)((char*)p + le16_to_cpu(p->rec_len)); + return (ext2_dirent *)((char *)p + + ext2_rec_len_from_disk(p->rec_len)); } static inline unsigned @@ -316,7 +335,7 @@ ext2_readdir (struct file * filp, void * return 0; } } - filp->f_pos += le16_to_cpu(de->rec_len); + filp->f_pos += ext2_rec_len_from_disk(de->rec_len); } ext2_put_page(page); } @@ -425,7 +444,7 @@ void ext2_set_link(struct inode *dir, st { loff_t pos = page_offset(page) + (char *) de - (char *) page_address(page); - unsigned len = le16_to_cpu(de->rec_len); + unsigned len = ext2_rec_len_from_disk(de->rec_len); int err; lock_page(page); @@ -482,7 +501,7 @@ int ext2_add_link (struct dentry *dentry /* We hit i_size */ name_len = 0; rec_len = chunk_size; - de->rec_len = cpu_to_le16(chunk_size); + de->rec_len = ext2_rec_len_to_disk(chunk_size); de->inode = 0; goto got_it; } @@ -496,7 +515,7 @@ int ext2_add_link (struct dentry *dentry if (ext2_match (namelen, name, de)) goto out_unlock; name_len = EXT2_DIR_REC_LEN(de->name_len); - rec_len = le16_to_cpu(de->rec_len); + rec_len = ext2_rec_len_from_disk(de->rec_len); if (!de->inode && rec_len >= reclen) goto got_it; if (rec_len >= name_len + reclen) @@ -518,8 +537,8 @@ got_it: goto out_unlock; if (de->inode) { ext2_dirent *de1 = (ext2_dirent *) ((char *) de + name_len); - de1->rec_len = cpu_to_le16(rec_len - name_len); - de->rec_len = cpu_to_le16(name_len); + de1->rec_len = ext2_rec_len_to_disk(rec_len - name_len); + de->rec_len = ext2_rec_len_to_disk(name_len); de = de1; } de->name_len = namelen; @@ -550,7 +569,8 @@ int ext2_delete_entry (struct ext2_dir_e struct inode *inode = mapping->host; char *kaddr = page_address(page); unsigned from = ((char*)dir - kaddr) & ~(ext2_chunk_size(inode)-1); - unsigned to = ((char*)dir - kaddr) + le16_to_cpu(dir->rec_len); + unsigned to = ((char *)dir - kaddr) + +
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
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 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
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: [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
+ 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: 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 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
Re: [PATCH 10/14] Make e2fsck uninit block group aware.
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. -JRS uninit_e2fsck_support Description: Binary data
Explanation of different branches in git tree
I gues Ted is following the same terminology. http://marc.info/?l=git&m=117965490313979&w=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
[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)) { -
[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
[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] ext4: Return after ext4_error in case of failures
This fix some instances where we were continuing after calling ext4_error. ext4_error call panic only if errors=panic mount option is set. So we need to make sure we return correctly after ext4_error call Reported by: Adrian Bunk <[EMAIL PROTECTED]> Signed-off-by: Aneesh Kumar K.V <[EMAIL PROTECTED]> --- fs/ext4/balloc.c | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c index e906b65..8517dd7 100644 --- a/fs/ext4/balloc.c +++ b/fs/ext4/balloc.c @@ -234,11 +234,13 @@ read_block_bitmap(struct super_block *sb, unsigned int block_group) } else { bh = sb_bread(sb, bitmap_blk); } - if (!bh) + if (!bh) { ext4_error (sb, __FUNCTION__, "Cannot read block bitmap - " "block_group = %d, block_bitmap = %llu", block_group, bitmap_blk); + return NULL; + } /* check whether block bitmap block number is set */ if (!block_in_use(bitmap_blk, sb, bh->b_data)) { @@ -628,11 +630,13 @@ do_more: in_range(ext4_inode_bitmap(sb, desc), block, count) || in_range(block, ext4_inode_table(sb, desc), sbi->s_itb_per_group) || in_range(block + count - 1, ext4_inode_table(sb, desc), -sbi->s_itb_per_group)) +sbi->s_itb_per_group)) { ext4_error (sb, "ext4_free_blocks", "Freeing blocks in system zones - " "Block = %llu, count = %lu", block, count); + goto error_return; + } /* * We are about to start releasing blocks in the bitmap, @@ -1733,11 +1737,13 @@ allocated: in_range(ret_block, ext4_inode_table(sb, gdp), EXT4_SB(sb)->s_itb_per_group) || in_range(ret_block + num - 1, ext4_inode_table(sb, gdp), -EXT4_SB(sb)->s_itb_per_group)) +EXT4_SB(sb)->s_itb_per_group)) { ext4_error(sb, "ext4_new_block", "Allocating block in system zone - " "blocks from %llu, length %lu", ret_block, num); + goto out; + } performed_allocation = 1; -- 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] 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] 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 c
[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] 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
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