1 Jan 2011 10:53
cc6
Loralee Casey <lcaseytw <at> zionsbank.com>
2011-01-01 09:53:37 GMT
2011-01-01 09:53:37 GMT
g _______________________________________________ xfs mailing list xfs <at> oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
2 Jan 2011 02:49
DNRonline.com Article sent to you by a friend
<michaelle <at> gmail.com>
2011-01-02 01:49:06 GMT
2011-01-02 01:49:06 GMT
Dear maam/sir, This person, mike, has sent you the following article and message: Hi - Could an extra two Hundred bucks per day help you out? How about an extra nine hundred per day? This guy\'s got a COMPLETELY new method. . .I never would dreamed of. But it\'s making all that possible in just DAYS. . . http://www.homeaff.co.cc/aff.php?e=linux-xfs <at> oss.sgi.com And much more. You\'ve got to see this to believe it. http://www.homeaff.co.cc/aff.php?e=linux-xfs <at> oss.sgi.com WBT Marketing East Land Vill, Lilo-an, PH-6002 P.S. I mean. . .if someone had told me this was possible last week. I\'d have laughed him out of the room. Looks like he\'s getting the last laugh. click the link below to unsubscribe: http://www.homeaff.co.cc/un.php?e=linux-xfs <at> oss.sgi.com(Continue reading)
2 Jan 2011 08:34
XFS status update for December 2010
Christoph Hellwig <hch <at> infradead.org>
2011-01-02 07:34:05 GMT
2011-01-02 07:34:05 GMT
The release process of the Linux 2.6.37 kernel with it's large XFS updates was in it's final days in December, which explains why we only saw a single one-liner regression fix for XFS in Linus' tree. The XFS development tree finally saw some updates when the writeback updates and some small cleanups to the allocator and log recovery code were merged, but the large metadata scalability updates that have been posted to the list multiple times are still missing. In addition to this on-going work the list also saw patches that fix smaller issues, which are also still waiting to be merged. On the userspace side xfsprogs and xfsdump development has been quit, with no commits to either repository in December, although a large series of updates to the metadump command has been reposted near the end of the month. The xfstests repository saw a new regression test for a btrfs problem, and various updates to existing tests. _______________________________________________ xfs mailing list xfs <at> oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
2 Jan 2011 08:22
[PATCH] xfs: add FITRIM support
Christoph Hellwig <hch <at> infradead.org>
2011-01-02 07:22:02 GMT
2011-01-02 07:22:02 GMT
Allow manual discards from userspace using the FITRIM ioctl. This is not intended to be run during normal workloads, as the freepsace btree walks can cause large performance degradation. Signed-off-by: Christoph Hellwig <hch <at> lst.de> --- V1 -> V2 - added __user annotations as noted by Alex - removed non-blocking agf read as noted by Alex - update range->len as noted by Alex This does not implement the by-bno search or lock break suggestions from Dave. Given that the 2.6.38 window is about to close those seem a bit risky to me. I'll look into these later. Index: xfs/fs/xfs/xfs_alloc.c =================================================================== --- xfs.orig/fs/xfs/xfs_alloc.c 2011-01-02 07:11:41.245003791 +0100 +++ xfs/fs/xfs/xfs_alloc.c 2011-01-02 07:24:43.120004698 +0100 <at> <at> -41,10 +41,6 <at> <at> #define XFSA_FIXUP_BNO_OK 1 #define XFSA_FIXUP_CNT_OK 2 -static int -xfs_alloc_busy_search(struct xfs_mount *mp, xfs_agnumber_t agno, - xfs_agblock_t bno, xfs_extlen_t len); -(Continue reading)
3 Jan 2011 04:47
Win 4D, DIRECT TOP 3 Now!
Melvin Yap <melvin <at> healthyfirst.com>
2011-01-03 03:47:50 GMT
2011-01-03 03:47:50 GMT
Hi 4D Friend, STOP DREAMING OF WINNING THE 4D TOP 3 PRIZE! Start winning it NOW!... and win it DIRECTLY. No System, Box or whatsoever. With this amazing 4D Top 3 winning online services, winning the Direct Top 3 becomes reality. If you are serious about winning the Top 3, then do yourself a favour and check it out for yourself. http://www.smart4d123.com/index.php?afid=2 You must see it to believe it... it will definately change the way you play the game...FOREVER! http://www.smart4d123.com/index.php?afid=2 I will see you there! Melvin _______________________________________________ xfs mailing list xfs <at> oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
3 Jan 2011 11:57
Re: xfs: add FITRIM support
Lukas Czerner <lczerner <at> redhat.com>
2011-01-03 10:57:23 GMT
2011-01-03 10:57:23 GMT
On Thu, 30 Dec 2010, Christoph Hellwig wrote:
> On Thu, Dec 23, 2010 at 12:44:09PM +1100, Dave Chinner wrote:
> > Hmmmm - if we are given a range to trim, wouldn't we do better to
> > walk the by-bno btree instead? i.e, we have two different cases
> > here - trim an entire AG, and trim part of an AG given by {start, end}.
> >
> > We only need these range checks on the AGs that are only partially
> > trimmed, and it would seem more efficient to me to walk the by-bno
> > tree for those rather than walk the by-size tree trying to find
> > range matches.
>
> It might be, but I'm not sure it's really worth the complexity. I can't
> really find any good use case for a partially trim anyway.
>
> Ccing Lukas to figure out what his intent with this was.
Hi, I assume that you're talking about situation, when you call FITRIM
with start and len not covering the whole filesystem possibly resulting
in trimming just a part of the AG ? In this case I just copy my answer
from previous mail...
I had two reasons to do this as it is, but only one is really worth it.
Since we want to run FITRIM from the userspace on the background, we want
to disturb other IO as little as possible and whole filesystem trim can
take minutes on some devices (not talking about LUNs which is even more
painful). So you'll probably agree that we do not want to have possibly
minute long stalls when doing FITRIM. And presumably we do not want the
users to care about the size of AG, nor the blocksize (preferably).
(Continue reading)
3 Jan 2011 11:49
Re: xfs: add FITRIM support
Lukas Czerner <lczerner <at> redhat.com>
2011-01-03 10:49:13 GMT
2011-01-03 10:49:13 GMT
On Tue, 28 Dec 2010, Christoph Hellwig wrote:
> On Wed, Dec 22, 2010 at 03:41:13PM -0600, Alex Elder wrote:
> > > + error = xfs_alloc_read_agf(mp, NULL, agno,
> > > + XFS_ALLOC_FLAG_TRYLOCK, &agbp);
> > > + if (error || !agbp) {
> > > + if (error == EAGAIN)
> > > + error = 0;
> >
> > EAGAIN is ignored because it's an advisory interface, right?
> > How hard are we expected to try? What I really mean is,
> > is the benefit of FITRIM enough that we should try again
> > later when we can get a buffer or lock on it?
>
> That was the idea when I wrote this code. But back then we called it
> regularly from a kernel thread. For FITRIM it makes more sense to just
> remove the trylock.
>
> > I don't know where (or if) FITRIM is precisely documented.
> > But I question whether truncating down the start offset is
> > the correct thing to do. If the starting byte offset given
> > were not block-aligned, it seems like you should not assume
> > that the caller wanted the bytes below unmapped. (This is
> > a broader question, not related directly to your change.)
> >
> > Similarly, on the length it is probably best to truncate
> > it, because it avoids any bytes beyond the specified range
> > getting unmapped. (I.e., in my mind what you did is the
> > right way to do it.) But these interpretations are
> > dependent on the specific interpretation of FITRIM...
(Continue reading)
3 Jan 2011 22:57
Re: Hole Punching V3
Josef Bacik <josef <at> redhat.com>
2011-01-03 21:57:21 GMT
2011-01-03 21:57:21 GMT
On Wed, Nov 17, 2010 at 08:46:14PM -0500, Josef Bacik wrote: > This is version 3 of the hole punching series I've been posting. Not much has > changed, the history is below > > V2->V3 > -FALLOC_FL_PUNCH_HOLE must also have FALLOC_FL_KEEP_SIZE in order to work > -formatting fixes > > V1->V2 > -Hole punching doesn't change file size > -Fixed the mode checks in ext4/btrfs/gfs2 so they do what they are supposed to > > I've updated my local copies of the xfsprogs patches I have to test this to use > KEEP_SIZE and PUNCH_HOLE together, I'll post them after it looks like these > patches are good to go, including the manpage update. The xfstest I wrote ran > fine both on xfs and btrfs (failing on btrfs obviously). Thanks, > I'd like to try and get this into the next merge window, it seems everybody is happy with it so far, any other comments? Provided everybody is ok with it, how would you like me to send it to you Linus? Would you prefer a pull request or will you just pull the patches off the mailinglist? Thanks, Josef _______________________________________________ xfs mailing list xfs <at> oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs(Continue reading)
4 Jan 2011 00:25
Re: xfs: add FITRIM support
Dave Chinner <david <at> fromorbit.com>
2011-01-03 23:25:14 GMT
2011-01-03 23:25:14 GMT
On Mon, Jan 03, 2011 at 11:57:23AM +0100, Lukas Czerner wrote:
> On Thu, 30 Dec 2010, Christoph Hellwig wrote:
>
> > On Thu, Dec 23, 2010 at 12:44:09PM +1100, Dave Chinner wrote:
> > > Hmmmm - if we are given a range to trim, wouldn't we do better to
> > > walk the by-bno btree instead? i.e, we have two different cases
> > > here - trim an entire AG, and trim part of an AG given by {start, end}.
> > >
> > > We only need these range checks on the AGs that are only partially
> > > trimmed, and it would seem more efficient to me to walk the by-bno
> > > tree for those rather than walk the by-size tree trying to find
> > > range matches.
> >
> > It might be, but I'm not sure it's really worth the complexity. I can't
> > really find any good use case for a partially trim anyway.
> >
> > Ccing Lukas to figure out what his intent with this was.
>
> Hi, I assume that you're talking about situation, when you call FITRIM
> with start and len not covering the whole filesystem possibly resulting
> in trimming just a part of the AG ? In this case I just copy my answer
> from previous mail...
Yes.
> I had two reasons to do this as it is, but only one is really worth it.
> Since we want to run FITRIM from the userspace on the background, we want
> to disturb other IO as little as possible and whole filesystem trim can
> take minutes on some devices (not talking about LUNs which is even more
> painful).
(Continue reading)
4 Jan 2011 01:15
Re: [PATCH] xfs: add FITRIM support
Dave Chinner <david <at> fromorbit.com>
2011-01-04 00:15:18 GMT
2011-01-04 00:15:18 GMT
On Sun, Jan 02, 2011 at 02:22:02AM -0500, Christoph Hellwig wrote: > Allow manual discards from userspace using the FITRIM ioctl. This is not > intended to be run during normal workloads, as the freepsace btree walks > can cause large performance degradation. > > Signed-off-by: Christoph Hellwig <hch <at> lst.de> > > --- > > V1 -> V2 > > - added __user annotations as noted by Alex > - removed non-blocking agf read as noted by Alex > - update range->len as noted by Alex > > This does not implement the by-bno search or lock break suggestions from > Dave. Given that the 2.6.38 window is about to close those seem a bit > risky to me. I'll look into these later. Ok, seemms like a good way to proceed. Reviewed-by: Dave Chinner <dchinner <at> redhat.com> Cheers, Dave. -- -- Dave Chinner david <at> fromorbit.com(Continue reading)
RSS Feed