headers
Andres Freund | 1 Oct 2011 22:46
Picon

Re: Improve lseek scalability v3

Hi,

On Friday, September 16, 2011 01:06:46 AM Andi Kleen wrote:
> v3: No changes, except rebase. All reviews passed. Just reposting
> for merging.
Is anything/anyone still objecting to this patchset?

I just retested it ontop of v3.1-rc8 minus the btrfs parts (which don't apply 
cleanly anymore because a modified version of 1/7 was merged) and it works 
fine for some hours of fs heavy db using benchmarking/development.

Following is a seemingly trivial forward-port of 7/7. But since I have 
about no clue in fs development and even less about brfts - which I never used -
take it with a grain of salt.
It seems a bit ugly to have the mutex_unlock at three places btw. A 2nd patch
fixes that, no idea whether its worth the churn.
Both are compile tested only.

Even at this (2 x E5520 (4 cores)) machine there seems to be a benefit of 
about 1.5%. Not enough cores to get into the actually problematic performance 
areas as presented by Robert though.
The variance between runs is a bit too high to call it reliable though.

Thanks,

Andres

PS: I have no clue what to do with the s-o-b and changelog when forward 
porting a patch... So I just copied the original message - which seems wrong.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andres Freund | 1 Oct 2011 22:49
Picon

[PATCH 1/2] LSEEK: BTRFS: Avoid i_mutex for SEEK_{CUR,SET,END}


Don't need the i_mutex for those cases, only for SEEK_HOLE/DATA.

Really-From: Andi Kleen <ak <at> linux.intel.com>
Signed-off-by: Andi Kleen <ak <at> linux.intel.com>
Signed-off-by: Andres Freund <andres <at> anarazel.de>
---
 fs/btrfs/file.c |   27 +++++++++++----------------
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index 7a13337..5bc7116 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
 <at>  <at>  -1809,24 +1809,19  <at>  <at>  static loff_t btrfs_file_llseek(struct file *file, loff_t offset, int origin)
 	struct inode *inode = file->f_mapping->host;
 	int ret;

+	if (origin != SEEK_DATA && origin != SEEK_HOLE)
+		return generic_file_llseek(file, offset, origin);
+
 	mutex_lock(&inode->i_mutex);
-	switch (origin) {
-	case SEEK_END:
-	case SEEK_CUR:
-		offset = generic_file_llseek(file, offset, origin);
-		goto out;
-	case SEEK_DATA:
-	case SEEK_HOLE:
-		if (offset >= i_size_read(inode)) {
(Continue reading)

Permalink | Reply | 3 comments |
headers
Andi Kleen | 2 Oct 2011 07:28

Re: Improve lseek scalability v3


Thanks for testing. According to Viro the patchkit is in his queue, so hopefully
next merge window.
-Andi

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Andy Walls | 2 Oct 2011 14:13

Re: [RFCv4 PATCH 2/6] ivtv: only start streaming in poll() if polling for input.

On Thu, 2011-09-29 at 09:44 +0200, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil <at> cisco.com>
> 
> Signed-off-by: Hans Verkuil <hans.verkuil <at> cisco.com>

FWIW:

Acked-by: Andy Walls <awalls <at> md.metrocast.net>

-Andy

> ---
>  drivers/media/video/ivtv/ivtv-fileops.c |    6 ++++--
>  1 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/video/ivtv/ivtv-fileops.c b/drivers/media/video/ivtv/ivtv-fileops.c
> index 38f0522..a931ecf 100644
> --- a/drivers/media/video/ivtv/ivtv-fileops.c
> +++ b/drivers/media/video/ivtv/ivtv-fileops.c
>  <at>  <at>  -744,8 +744,9  <at>  <at>  unsigned int ivtv_v4l2_dec_poll(struct file *filp, poll_table *wait)
>  	return res;
>  }
>  
> -unsigned int ivtv_v4l2_enc_poll(struct file *filp, poll_table * wait)
> +unsigned int ivtv_v4l2_enc_poll(struct file *filp, poll_table *wait)
>  {
> +	unsigned long req_events = poll_requested_events(wait);
>  	struct ivtv_open_id *id = fh2id(filp->private_data);
>  	struct ivtv *itv = id->itv;
>  	struct ivtv_stream *s = &itv->streams[id->type];
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anand Jain | 3 Oct 2011 13:25
Picon
Favicon

Re: [PATCH 3/3] Added test case 259 for the btrfs raid features


Christoph,

  apologies for the delay I was on a long leave.

> Also is there a chance you could allow setting
> only SCRATCH_DEV_POOL for btrfs, and derive SCRATCH_DEV for that as an
> additional step?

  There is some challenge to set SCRATCH_DEV based on FSTYP since
  SCRATCH_DEV is used even before FSTYP is set.

  common.config uses SCRATCH_DEV and we set FSTYP in common.
  check calls these two script files in the following logic.
  --------------------------
  # we need common.config
  if ! . ./common.config
  then
     echo "$iam: failed to source common.config"
     exit 1
  fi

  # we need common
  . ./common
  ---------------------------

  to avoid major changes what we could do is to find-out FSTYP on our
  own in the file common.config and set SCRATCH_DEV based on
  SCRATCH_DEV_POOL, but thats a bit ugly way. I am open to any
  suggestions. thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Amit Sahrawat | 3 Oct 2011 13:46
Picon
Gravatar

UDF: alternate anchor block detection

While mounting UDF media, when the primary AVDP is not found at block
256, UDF code tries to read-in the alternate AVDP.
In the function udf_find_anchor, udf_scan_anchors is called 3 times,
where each call to udf_scan_anchors read 12 blocks.
In case there is no alternate AVDP stored, a total of 36 blocks are
read before mount fails - causing time delay for Mount Failure.

1) After first call to udf_scan_anchors and before the second call
there is varconv conversion, for the older drivers, which skips 7
blocks after every 32 blocks. What are these older drivers? Do we
still require this code?

2) After varconv conversion, why is there a third call to
udf_scan_anchors? In the 1st call and 3rd call to udf_scan_anchors,
exactly same blocks are read, so this 3rd call seems to be redundant.

I suggest this modified code for udf_find_anchor :-
lastblock = udf_scan_anchors(sb,udf_variable_to_fixed(sbi->s_last_block),fileset);
        if (lastblock)
                goto out;
         else {
                /* VARCONV didn't help. Clear it. */
                UDF_CLEAR_FLAG(sb, UDF_FLAG_VARCONV);
                return 0;
        }

Please share your opinion to the above '2' points.

Thanks & Regards,
Amit Sahrawat
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Stern | 3 Oct 2011 21:53
Picon
Favicon

Re: Re: BUG in kernel: Wrong Handling of USB HDD’s in scsiglue(slave_configure) and scsi/sd(sd_read_cache_type)

On Mon, 3 Oct 2011, James Bottomley wrote:

> On Mon, 2011-10-03 at 14:10 -0400, Alan Stern wrote:
> > > No. You need to also take into account the RBC
> > > device parameters mode page if present. See above.
> > 
> > All right, suppose neither page is present.  Does it then make sense to 
> > assume by default that write caching is enabled?
> 
> You're the USB expert ... if we do that, we'll start sending
> SYNCHRONIZE_CACHE commands down to a whole slew of devices we didn't
> before ... is that going to cause problems with any USB SATLs?

Hmmm...  Actually, I doubt it would bother any SATLs, but it might well
bother other sorts of USB translation layers.  No way to tell without
trying it, and I don't really want to deal with the fallout.

Maybe a better question to be asking is this: What happens when one of 
these drives (the ones that report their caching capabilities 
incorrectly) is plugged into a Windows system?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Herbert Xu | 3 Oct 2011 22:35
Picon
Picon

Re: [PATCH v4] crc32c: Implement CRC32c with slicing-by-8 algorithm

On Mon, Oct 03, 2011 at 10:27:03PM +0200, Joakim Tjernlund wrote:
>
> > > Start from Bobs latest patches and add crc32c to lib/crc32.c
> >
> > If I did that, how should I handle patching in the hardware accelerated version
> > on Intel systems?  That switcheroo ability seems to have been Herbert Xu's
> > motivation for moving crc32c into crypto/ in the first place:
> 
> I don't know, I haven't looked at that problem. I suspect it moved because that
> was the easiest solution. Having an identical impl. of crc32(only the table values differ)
> in crypto compared to the one in lib is not the way forward though.

You can always get crypto/crc32c.c to use call helpers from
lib/crc32.c.

Cheers,
--

-- 
Email: Herbert Xu <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Alex Elder | 5 Oct 2011 15:20
Picon
Favicon

Re: [PATCH 1/2] xfstest: fsstress should kill children tasks before exit

On Sun, 2011-09-18 at 18:54 +0400, Dmitry Monakhov wrote:
> It is very hard to predict runtime for fsstress. In many cases it
> is useful to give test to run a reasonable time, and then kill it.
> But currently there is no reliable way to kill test without leaving
> running children.
> This patch add sanity cleanup logic which looks follow:
>  - On sigterm received by parent, it resend signal to it's children
>  - Wait for each child to terminates
>  - EXTRA_SANITY: Even if parent was killed by other signal, children
>    will be terminated with SIGKILL to preven staled children.
> 
> So now one can simply run fsstress like this:
> ./fsstress -p 1000 -n999999999 -d $TEST_DIR &
> PID=$!
> sleep 300
> kill $PID
> wait $PID
> 
> Signed-off-by: Dmitry Monakhov <dmonakhov <at> openvz.org>

I think this is an interesting change and it looks
OK to me.  I agree with Christoph's suggestion (on
the second patch in this series) that it would be
nice to have at least one of the tests make use of
it, if nothing else just to document that it's a
reasonable thing to do.

But even without that I think this is both useful
and harmless.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alex Elder | 5 Oct 2011 15:20
Picon
Favicon

Re: [PATCH 2/2] xfstest: fsstress add EXT2_IOC_{SET,GET}FLAGS operations

On Sun, 2011-09-18 at 18:54 +0400, Dmitry Monakhov wrote:
> Add two new operations:
> - getattr: ioctl(fd, EXT2_IOC_GETFLAGS, &fl)
> - setattr: ioctl(fd, EXT2_IOC_SETFLAGS, &random_flags)
> By default IOC_SET_SETFLAGS has zero probability because
> it may produce inodes with APPEND or IMMUTABLE flags which
> are not deletable by default. Let's assumes that one who
> enable it knows how to delete such inodes.
> For example like follows:
> find $TEST_PATH -exec chattr -i -a {} \;
> rm -rf $TEST_PATH
> 
> Signed-off-by: Dmitry Monakhov <dmonakhov <at> openvz.org>

I have a question below.  I think this is probably
a good addition, though it should be made so it
works for more than EXTx.

If I understand the way it would be used, this will
simply be another operation that gets randomly performed
by fsstress while it operates, right?

I have not done any testing with this yet.

Reviewed-by: Alex Elder <aelder <at> sgi.com>

. . .

>  <at>  <at>  -1729,6 +1738,58  <at>  <at>  setxattr_f(int opno, long r)
>  }
(Continue reading)

Permalink | Reply | 8 comments |

Gmane