The following changes since commit 15f7176eb1cccec0a332541285ee752b935c1c85:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://oss.sgi.com/xfs/xfs for-linus
Christoph Hellwig (39):
xfs: fix dentry aliasing issues in open_by_handle
xfs: use mnt_want_write in compat_attrmulti ioctl
xfs: add a separate lock class for the per-mount list of dquots
xfs: lockdep annotations for xfs_dqlock2
xfs: add a lock class for group/project dquots
xfs: fix bad_features2 fixups for the root filesystem
xfs: sanity check attr fork size
xfs: cleanup error handling in xfs_mountfs:
xfs: make sure to free the real-time inodes in the mount error path
xfs: tiny cleanup for xfs_link
xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK
xfs: factor out attr fork reset handling
xfs: merge xfs_inode_flush into xfs_fs_write_inode
xfs: cleanup xfs_find_handle
xfs: remove the unused XFS_QMOPT_DQLOCK flag
xfs: remove iclog calculation special cases
xfs: remove superflous inobt macros
xfs: remove uchar_t/ushort_t/uint_t/ulong_t types
xfs: merge xfs_mkdir into xfs_create
xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE
xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED
xfs: sanitize qh_lock wrappers
xfs: get rid of indirections in the quotaops implementation
xfs: fix error handling in xfs_log_mount
xfs: reject swapext ioctl on swapfiles
xfs: prevent kernel crash due to corrupted inode log format
xfs: prevent lockdep false positive in xfs_iget_cache_miss
xfs: only issues a cache flush on unmount if barriers are enabled
xfs: cleanup log unmount handling
xfs: remove another leftover of the old inode log item format
xfs: cleanup xlog_recover_do_trans
xfs: cleanup xlog_bread
xfs: kill vn_atime_* helpers.
xfs: kill VN_BAD
xfs: kill mutex_t typedef
xfs: kill ino64 mount option
xfs: remove m_litino
xfs: remove m_attroffset
xfs: cleanup uuid handling
Dave Chinner (3):
Long btree pointers are still 64 bit on disk
xfs: Check buffer lengths in log recovery
xfs: factor out code to find the longest free extent in the AG
Eric Sandeen (3):
[XFS] Remove the rest of the macro-to-function indirections.
[XFS] remove always-true #ifndef HAVE_FORMAT32 tests
don't reallocate sxp variable passed into xfs_swapext
Felix Blyakher (25):
Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs
[XFS] Warn on transaction in flight on read-only remount
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
xfs: Update maintainers
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Revert "[XFS] use scalable vmap API"
Revert "[XFS] remove old vmap cache"
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Fix xfs debug build breakage by pushing xfs_error.h after
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
xfs: increase the maximum number of supported ACL entries
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Revert "xfs: increase the maximum number of supported ACL entries"
Hannes Eder (3):
xfs: move declaration to header file
xfs: make symbols static
xfs: include header files for prototypes
Hisashi Hifumi (1):
xfs: pagecache usage optimization
Josef 'Jeff' Sipek (1):
xfs: cleanup error handling in xfs_swap_extents
Lachlan McIlroy (6):
[XFS] Update maintainers
Merge git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/xfs
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux-2.6
Merge git://git.kernel.org/.../torvalds/linux-2.6
Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
Malcolm Parsons (1):
xfs: fix various typos
Nick Piggin (2):
[XFS] remove old vmap cache
[XFS] use scalable vmap API
MAINTAINERS | 3 +-
fs/xfs/Makefile | 1 +
fs/xfs/linux-2.6/mutex.h | 25 ---
fs/xfs/linux-2.6/xfs_aops.c | 1 +
fs/xfs/linux-2.6/xfs_ioctl.c | 117 +++++-------
fs/xfs/linux-2.6/xfs_iops.c | 33 +---
fs/xfs/linux-2.6/xfs_linux.h | 13 +--
fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++
fs/xfs/linux-2.6/xfs_super.c | 137 +++++---------
fs/xfs/linux-2.6/xfs_super.h | 1 +
fs/xfs/linux-2.6/xfs_sync.h | 1 +
fs/xfs/linux-2.6/xfs_vnode.h | 32 ---
fs/xfs/quota/xfs_dquot.c | 28 ++--
fs/xfs/quota/xfs_dquot.h | 18 +--
fs/xfs/quota/xfs_qm.c | 212 ++++++---------------
fs/xfs/quota/xfs_qm.h | 26 ++--
fs/xfs/quota/xfs_qm_bhv.c | 1 -
fs/xfs/quota/xfs_qm_syscalls.c | 190 +-----------------
fs/xfs/quota/xfs_quota_priv.h | 38 ++---
fs/xfs/quota/xfs_trans_dquot.c | 16 +-
fs/xfs/support/debug.c | 1 +
fs/xfs/support/uuid.c | 71 -------
fs/xfs/support/uuid.h | 4 -
fs/xfs/xfs_ag.h | 4 +-
fs/xfs/xfs_alloc.c | 26 ++-
fs/xfs/xfs_alloc.h | 6 +
fs/xfs/xfs_attr_leaf.c | 58 +++---
fs/xfs/xfs_bmap.c | 76 +++++---
fs/xfs/xfs_bmap.h | 6 +-
fs/xfs/xfs_btree.c | 4 +-
fs/xfs/xfs_btree.h | 2 +-
fs/xfs/xfs_da_btree.c | 2 +-
fs/xfs/xfs_da_btree.h | 9 +-
fs/xfs/xfs_dfrag.c | 68 +++----
fs/xfs/xfs_dinode.h | 4 +-
fs/xfs/xfs_dir2.c | 2 -
fs/xfs/xfs_dir2_block.c | 7 +-
fs/xfs/xfs_dir2_data.h | 2 +-
fs/xfs/xfs_dir2_leaf.c | 17 +--
fs/xfs/xfs_dir2_node.c | 2 +-
fs/xfs/xfs_dir2_sf.c | 13 +--
fs/xfs/xfs_extfree_item.h | 6 -
fs/xfs/xfs_filestream.c | 9 +-
fs/xfs/xfs_fsops.c | 2 +-
fs/xfs/xfs_ialloc.c | 12 +-
fs/xfs/xfs_ialloc_btree.c | 2 +-
fs/xfs/xfs_ialloc_btree.h | 22 +--
fs/xfs/xfs_inode.h | 2 +-
fs/xfs/xfs_inode_item.h | 2 -
fs/xfs/xfs_iomap.h | 2 +-
fs/xfs/xfs_itable.c | 9 +-
fs/xfs/xfs_log.c | 67 ++-----
fs/xfs/xfs_log.h | 3 +-
fs/xfs/xfs_log_priv.h | 3 +-
fs/xfs/xfs_log_recover.c | 308 +++++++++++++++++-------------
fs/xfs/xfs_mount.c | 253 ++++++++++++++-----------
fs/xfs/xfs_mount.h | 19 +--
fs/xfs/xfs_qmops.c | 1 -
fs/xfs/xfs_quota.h | 3 +-
fs/xfs/xfs_rtalloc.c | 10 +
fs/xfs/xfs_rtalloc.h | 8 +-
fs/xfs/xfs_trans.h | 24 ++--
fs/xfs/xfs_trans_ail.c | 4 +-
fs/xfs/xfs_trans_item.c | 2 +-
fs/xfs/xfs_trans_space.h | 2 +-
fs/xfs/xfs_types.h | 8 -
fs/xfs/xfs_utils.c | 2 +-
fs/xfs/xfs_vnodeops.c | 408 +++++++++------------------------------
fs/xfs/xfs_vnodeops.h | 3 -
69 files changed, 1031 insertions(+), 1599 deletions(-)
delete mode 100644 fs/xfs/linux-2.6/mutex.h
create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c
Hi Linus,
Were there any problems pulling from the xfs repository?
Thanks,
Felix
On Mar 31, 2009, at 12:30 AM, Felix Blyakher wrote:
> The following changes since commit
> 15f7176eb1cccec0a332541285ee752b935c1c85:
> Linus Torvalds (1):
> Merge git://git.kernel.org/.../davem/net-2.6
>
> are available in the git repository at:
>
> git://oss.sgi.com/xfs/xfs for-linus
>
> Christoph Hellwig (39):
> xfs: fix dentry aliasing issues in open_by_handle
> xfs: use mnt_want_write in compat_attrmulti ioctl
> xfs: add a separate lock class for the per-mount list of dquots
> xfs: lockdep annotations for xfs_dqlock2
> xfs: add a lock class for group/project dquots
> xfs: fix bad_features2 fixups for the root filesystem
> xfs: sanity check attr fork size
> xfs: cleanup error handling in xfs_mountfs:
> xfs: make sure to free the real-time inodes in the mount error
> path
> xfs: tiny cleanup for xfs_link
> xfs: remove unused XFS_MOUNT_ILOCK/XFS_MOUNT_IUNLOCK
> xfs: factor out attr fork reset handling
> xfs: merge xfs_inode_flush into xfs_fs_write_inode
> xfs: cleanup xfs_find_handle
> xfs: remove the unused XFS_QMOPT_DQLOCK flag
> xfs: remove iclog calculation special cases
> xfs: remove superflous inobt macros
> xfs: remove uchar_t/ushort_t/uint_t/ulong_t types
> xfs: merge xfs_mkdir into xfs_create
> xfs: remove XFS_QM_LOCK/XFS_QM_UNLOCK/XFS_QM_HOLD/XFS_QM_RELE
> xfs: use mutex_is_locked in XFS_DQ_IS_LOCKED
> xfs: sanitize qh_lock wrappers
> xfs: get rid of indirections in the quotaops implementation
> xfs: fix error handling in xfs_log_mount
> xfs: reject swapext ioctl on swapfiles
> xfs: prevent kernel crash due to corrupted inode log format
> xfs: prevent lockdep false positive in xfs_iget_cache_miss
> xfs: only issues a cache flush on unmount if barriers are enabled
> xfs: cleanup log unmount handling
> xfs: remove another leftover of the old inode log item format
> xfs: cleanup xlog_recover_do_trans
> xfs: cleanup xlog_bread
> xfs: kill vn_atime_* helpers.
> xfs: kill VN_BAD
> xfs: kill mutex_t typedef
> xfs: kill ino64 mount option
> xfs: remove m_litino
> xfs: remove m_attroffset
> xfs: cleanup uuid handling
>
> Dave Chinner (3):
> Long btree pointers are still 64 bit on disk
> xfs: Check buffer lengths in log recovery
> xfs: factor out code to find the longest free extent in the AG
>
> Eric Sandeen (3):
> [XFS] Remove the rest of the macro-to-function indirections.
> [XFS] remove always-true #ifndef HAVE_FORMAT32 tests
> don't reallocate sxp variable passed into xfs_swapext
>
> Felix Blyakher (25):
> Merge branch 'master' of git+ssh://oss.sgi.com/oss/git/xfs/xfs
> [XFS] Warn on transaction in flight on read-only remount
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> xfs: Update maintainers
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Revert "[XFS] use scalable vmap API"
> Revert "[XFS] remove old vmap cache"
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Fix xfs debug build breakage by pushing xfs_error.h after
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> xfs: increase the maximum number of supported ACL entries
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
> Revert "xfs: increase the maximum number of supported ACL
> entries"
>
> Hannes Eder (3):
> xfs: move declaration to header file
> xfs: make symbols static
> xfs: include header files for prototypes
>
> Hisashi Hifumi (1):
> xfs: pagecache usage optimization
>
> Josef 'Jeff' Sipek (1):
> xfs: cleanup error handling in xfs_swap_extents
>
> Lachlan McIlroy (6):
> [XFS] Update maintainers
> Merge git://git.kernel.org/.../torvalds/linux-2.6
> Merge branch 'for-linus' of git+ssh://git.melbourne.sgi.com/git/
> xfs
> Merge branch 'master' of git://git.kernel.org/.../torvalds/
> linux-2.6
> Merge git://git.kernel.org/.../torvalds/linux-2.6
> Merge branch 'master' of git://git.kernel.org/pub/scm/fs/xfs/xfs
>
> Malcolm Parsons (1):
> xfs: fix various typos
>
> Nick Piggin (2):
> [XFS] remove old vmap cache
> [XFS] use scalable vmap API
>
> MAINTAINERS | 3 +-
> fs/xfs/Makefile | 1 +
> fs/xfs/linux-2.6/mutex.h | 25 ---
> fs/xfs/linux-2.6/xfs_aops.c | 1 +
> fs/xfs/linux-2.6/xfs_ioctl.c | 117 +++++-------
> fs/xfs/linux-2.6/xfs_iops.c | 33 +---
> fs/xfs/linux-2.6/xfs_linux.h | 13 +--
> fs/xfs/linux-2.6/xfs_quotaops.c | 157 +++++++++++++++
> fs/xfs/linux-2.6/xfs_super.c | 137 +++++---------
> fs/xfs/linux-2.6/xfs_super.h | 1 +
> fs/xfs/linux-2.6/xfs_sync.h | 1 +
> fs/xfs/linux-2.6/xfs_vnode.h | 32 ---
> fs/xfs/quota/xfs_dquot.c | 28 ++--
> fs/xfs/quota/xfs_dquot.h | 18 +--
> fs/xfs/quota/xfs_qm.c | 212 ++++++---------------
> fs/xfs/quota/xfs_qm.h | 26 ++--
> fs/xfs/quota/xfs_qm_bhv.c | 1 -
> fs/xfs/quota/xfs_qm_syscalls.c | 190 +-----------------
> fs/xfs/quota/xfs_quota_priv.h | 38 ++---
> fs/xfs/quota/xfs_trans_dquot.c | 16 +-
> fs/xfs/support/debug.c | 1 +
> fs/xfs/support/uuid.c | 71 -------
> fs/xfs/support/uuid.h | 4 -
> fs/xfs/xfs_ag.h | 4 +-
> fs/xfs/xfs_alloc.c | 26 ++-
> fs/xfs/xfs_alloc.h | 6 +
> fs/xfs/xfs_attr_leaf.c | 58 +++---
> fs/xfs/xfs_bmap.c | 76 +++++---
> fs/xfs/xfs_bmap.h | 6 +-
> fs/xfs/xfs_btree.c | 4 +-
> fs/xfs/xfs_btree.h | 2 +-
> fs/xfs/xfs_da_btree.c | 2 +-
> fs/xfs/xfs_da_btree.h | 9 +-
> fs/xfs/xfs_dfrag.c | 68 +++----
> fs/xfs/xfs_dinode.h | 4 +-
> fs/xfs/xfs_dir2.c | 2 -
> fs/xfs/xfs_dir2_block.c | 7 +-
> fs/xfs/xfs_dir2_data.h | 2 +-
> fs/xfs/xfs_dir2_leaf.c | 17 +--
> fs/xfs/xfs_dir2_node.c | 2 +-
> fs/xfs/xfs_dir2_sf.c | 13 +--
> fs/xfs/xfs_extfree_item.h | 6 -
> fs/xfs/xfs_filestream.c | 9 +-
> fs/xfs/xfs_fsops.c | 2 +-
> fs/xfs/xfs_ialloc.c | 12 +-
> fs/xfs/xfs_ialloc_btree.c | 2 +-
> fs/xfs/xfs_ialloc_btree.h | 22 +--
> fs/xfs/xfs_inode.h | 2 +-
> fs/xfs/xfs_inode_item.h | 2 -
> fs/xfs/xfs_iomap.h | 2 +-
> fs/xfs/xfs_itable.c | 9 +-
> fs/xfs/xfs_log.c | 67 ++-----
> fs/xfs/xfs_log.h | 3 +-
> fs/xfs/xfs_log_priv.h | 3 +-
> fs/xfs/xfs_log_recover.c | 308 +++++++++++++++++-------------
> fs/xfs/xfs_mount.c | 253 ++++++++++++++-----------
> fs/xfs/xfs_mount.h | 19 +--
> fs/xfs/xfs_qmops.c | 1 -
> fs/xfs/xfs_quota.h | 3 +-
> fs/xfs/xfs_rtalloc.c | 10 +
> fs/xfs/xfs_rtalloc.h | 8 +-
> fs/xfs/xfs_trans.h | 24 ++--
> fs/xfs/xfs_trans_ail.c | 4 +-
> fs/xfs/xfs_trans_item.c | 2 +-
> fs/xfs/xfs_trans_space.h | 2 +-
> fs/xfs/xfs_types.h | 8 -
> fs/xfs/xfs_utils.c | 2 +-
> fs/xfs/xfs_vnodeops.c | 408 ++++++++
> +------------------------------
> fs/xfs/xfs_vnodeops.h | 3 -
> 69 files changed, 1031 insertions(+), 1599 deletions(-)
> delete mode 100644 fs/xfs/linux-2.6/mutex.h
> create mode 100644 fs/xfs/linux-2.6/xfs_quotaops.c
>
> _______________________________________________
> xfs mailing list
> [email protected]
> http://oss.sgi.com/mailman/listinfo/xfs
On Thu, 2 Apr 2009, Felix Blyakher wrote:
>
> Were there any problems pulling from the xfs repository?
Sorry, no - just too much email, too many trees to look at, too many
people to argue with.
Pulled.
Linus
On Fri, 3 Apr 2009, Linus Torvalds wrote:
>
>
> On Thu, 2 Apr 2009, Felix Blyakher wrote:
> >
> > Were there any problems pulling from the xfs repository?
>
> Sorry, no - just too much email, too many trees to look at, too many
> people to argue with.
>
> Pulled.
Side note - I almost unpulled afterwards.
You've done several apparently totally useless pulls from my tree at
random points.
Daily "keep up-to-date with Linus' tree" pulls are _strongly_ discouraged
(read: if this continues, I'll just stop pulling from you), because it
makes the history totally unreadable after-the-fact. It has some direct
technical downsides (it makes it much harder to run "git bisect" and see
what is going on), but apart from those direct downsides it just makes it
much harder for me - or anybody else who wants to get an overview of what
happened - to visualize things when history is messy.
Instead of having a clear nice line of development that says "this is what
happened to XFS", those merges have basically mixed up all your changes
with all the random _other_ changes in the tree.
In other words, having those extra merges makes the graphical tools almost
useless for getting some kind of "what happened" overview.
I realize that an occasional back-merge may be required to resolve big
conflicts early, but they really have to be pretty big and immediate for
it to be a win.
Linus
On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote:
> On Fri, 3 Apr 2009, Linus Torvalds wrote:
>
>> On Thu, 2 Apr 2009, Felix Blyakher wrote:
>>>
>>> Were there any problems pulling from the xfs repository?
>>
>> Sorry, no - just too much email, too many trees to look at, too many
>> people to argue with.
>>
>> Pulled.
>
> Side note - I almost unpulled afterwards.
That was my concern, i.e. it's not pulled without explicit
NAK. I knew about your possible concerns.
> You've done several apparently totally useless pulls from my tree at
> random points.
Yes, I noticed that, and agree with all your points even
before you brought them up.
I already started talking to people to improve my process.
The reason the intermediate pulls from your tree were done
is to make sure that new xfs patches would not conflict
with some other changes already in the mainline. That was
part of the maintainer cheat sheet given to me, and I
didn't realize the side effects of it.
I probably can verify the possible conflicts without pushing
the merges into the repository and reset the working tree to
pre pull state.
At any rate, I'll find some way to manage that without
cluttering the history with the merges.
Any suggestions are welcome.
Thanks,
Felix
>
>
> Daily "keep up-to-date with Linus' tree" pulls are _strongly_
> discouraged
> (read: if this continues, I'll just stop pulling from you), because it
> makes the history totally unreadable after-the-fact. It has some
> direct
> technical downsides (it makes it much harder to run "git bisect" and
> see
> what is going on), but apart from those direct downsides it just
> makes it
> much harder for me - or anybody else who wants to get an overview of
> what
> happened - to visualize things when history is messy.
>
> Instead of having a clear nice line of development that says "this
> is what
> happened to XFS", those merges have basically mixed up all your
> changes
> with all the random _other_ changes in the tree.
>
> In other words, having those extra merges makes the graphical tools
> almost
> useless for getting some kind of "what happened" overview.
>
> I realize that an occasional back-merge may be required to resolve big
> conflicts early, but they really have to be pretty big and immediate
> for
> it to be a win.
>
> Linus
On Fri, 3 Apr 2009, Felix Blyakher wrote:
> On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote:
>
>> On Fri, 3 Apr 2009, Linus Torvalds wrote:
>>
>>> On Thu, 2 Apr 2009, Felix Blyakher wrote:
>>>>
>>>> Were there any problems pulling from the xfs repository?
>>>
>>> Sorry, no - just too much email, too many trees to look at, too many
>>> people to argue with.
>>>
>>> Pulled.
>>
>> Side note - I almost unpulled afterwards.
>
> That was my concern, i.e. it's not pulled without explicit
> NAK. I knew about your possible concerns.
>
>> You've done several apparently totally useless pulls from my tree at
>> random points.
>
> Yes, I noticed that, and agree with all your points even
> before you brought them up.
> I already started talking to people to improve my process.
> The reason the intermediate pulls from your tree were done
> is to make sure that new xfs patches would not conflict
> with some other changes already in the mainline. That was
> part of the maintainer cheat sheet given to me, and I
> didn't realize the side effects of it.
> I probably can verify the possible conflicts without pushing
> the merges into the repository and reset the working tree to
> pre pull state.
create a temporary branch and do the merge in that. then throw away the
test branch and there is no harm to the main tree.
David Lang
> At any rate, I'll find some way to manage that without
> cluttering the history with the merges.
> Any suggestions are welcome.
>
> Thanks,
> Felix
>
>>
>>
>> Daily "keep up-to-date with Linus' tree" pulls are _strongly_ discouraged
>> (read: if this continues, I'll just stop pulling from you), because it
>> makes the history totally unreadable after-the-fact. It has some direct
>> technical downsides (it makes it much harder to run "git bisect" and see
>> what is going on), but apart from those direct downsides it just makes it
>> much harder for me - or anybody else who wants to get an overview of what
>> happened - to visualize things when history is messy.
>>
>> Instead of having a clear nice line of development that says "this is what
>> happened to XFS", those merges have basically mixed up all your changes
>> with all the random _other_ changes in the tree.
>>
>> In other words, having those extra merges makes the graphical tools almost
>> useless for getting some kind of "what happened" overview.
>>
>> I realize that an occasional back-merge may be required to resolve big
>> conflicts early, but they really have to be pretty big and immediate for
>> it to be a win.
>>
>> Linus
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Apr 3, 2009, at 8:19 PM, [email protected] wrote:
> On Fri, 3 Apr 2009, Felix Blyakher wrote:
>
>> On Apr 3, 2009, at 12:02 PM, Linus Torvalds wrote:
>>
>>> On Fri, 3 Apr 2009, Linus Torvalds wrote:
>>>> On Thu, 2 Apr 2009, Felix Blyakher wrote:
>>>>> Were there any problems pulling from the xfs repository?
>>>> Sorry, no - just too much email, too many trees to look at, too
>>>> many
>>>> people to argue with.
>>>> Pulled.
>>> Side note - I almost unpulled afterwards.
>>
>> That was my concern, i.e. it's not pulled without explicit
>> NAK. I knew about your possible concerns.
>>
>>> You've done several apparently totally useless pulls from my tree at
>>> random points.
>>
>> Yes, I noticed that, and agree with all your points even
>> before you brought them up.
>> I already started talking to people to improve my process.
>> The reason the intermediate pulls from your tree were done
>> is to make sure that new xfs patches would not conflict
>> with some other changes already in the mainline. That was
>> part of the maintainer cheat sheet given to me, and I
>> didn't realize the side effects of it.
>> I probably can verify the possible conflicts without pushing
>> the merges into the repository and reset the working tree to
>> pre pull state.
>
> create a temporary branch and do the merge in that. then throw away
> the test branch and there is no harm to the main tree.
That was suggested among other things by Ingo Molnar as well.
I'm planing to follow this approach.
Thanks,
Felix
>
>
> David Lang
>
>> At any rate, I'll find some way to manage that without
>> cluttering the history with the merges.
>> Any suggestions are welcome.
>>
>> Thanks,
>> Felix
>>
>>> Daily "keep up-to-date with Linus' tree" pulls are _strongly_
>>> discouraged
>>> (read: if this continues, I'll just stop pulling from you),
>>> because it
>>> makes the history totally unreadable after-the-fact. It has some
>>> direct
>>> technical downsides (it makes it much harder to run "git bisect"
>>> and see
>>> what is going on), but apart from those direct downsides it just
>>> makes it
>>> much harder for me - or anybody else who wants to get an overview
>>> of what
>>> happened - to visualize things when history is messy.
>>> Instead of having a clear nice line of development that says "this
>>> is what
>>> happened to XFS", those merges have basically mixed up all your
>>> changes
>>> with all the random _other_ changes in the tree.
>>> In other words, having those extra merges makes the graphical
>>> tools almost
>>> useless for getting some kind of "what happened" overview.
>>> I realize that an occasional back-merge may be required to resolve
>>> big
>>> conflicts early, but they really have to be pretty big and
>>> immediate for
>>> it to be a win.
>>>
>>> Linus
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-
>> kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
Dear Felix Blyakher,
do you know whether there are plans to support the ATA TRIM command /
blkdev_issue_discard() call in XFS for Linux anytime soon?
I ask because as someone who is currently benchmarking solid state disks
for certain usage scenarios I noticed that other filesystems are starting
to support the discarding of unused blocks, which allows to prevent
performance-degradation of SSDs during heavy use.
(See e.g. http://www.mail-archive.com/[email protected]/msg03401.html
on the GFS2 support for the discard feature, it seems not too hard
to implement the support)
Amongst other SSDs, we have one in our tests that supports the ATA TRIM command,
and I would like to test the benefits of it, even if that requires me
to install an early kernel pre-release.
(Currently, XFS is our favorite filesystem for several reasons, so it would
be great if we could run our TRIM-support-benchmarks using it)
Regards,
Peter Niemayer