1. 05 Feb, 2008 1 commit
    • Christoph Lameter's avatar
      Pagecache zeroing: zero_user_segment, zero_user_segments and zero_user · eebd2aa3
      Christoph Lameter authored
      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.
      
      [akpm@linux-foundation.org: fix nfs and ntfs build]
      [akpm@linux-foundation.org: fix ntfs build some more]
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: Michael Halcrow <mhalcrow@us.ibm.com>
      Cc: Steven French <sfrench@us.ibm.com>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      eebd2aa3
  2. 19 Oct, 2007 1 commit
  3. 18 Oct, 2007 1 commit
  4. 16 Oct, 2007 1 commit
  5. 16 Jul, 2007 1 commit
  6. 24 Jun, 2007 1 commit
  7. 09 May, 2007 1 commit
  8. 08 May, 2007 3 commits
    • Jan Kara's avatar
      ext3: copy i_flags to inode flags on write · 28be5abb
      Jan Kara authored
      A patch that stores inode flags such as S_IMMUTABLE, S_APPEND, etc.  from
      i_flags to EXT3_I(inode)->i_flags when inode is written to disk.  The same
      thing is done on GETFLAGS ioctl.
      
      Quota code changes these flags on quota files (to make it harder for
      sysadmin to screw himself) and these changes were not correctly propagated
      into the filesystem (especially, lsattr did not show them and users were
      wondering...).
      
      Propagate flags such as S_APPEND, S_IMMUTABLE, etc.  from i_flags into
      ext3-specific i_flags.  Hence, when someone sets these flags via a
      different interface than ioctl, they are stored correctly.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Cc: <linux-ext4@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      28be5abb
    • Randy Dunlap's avatar
      header cleaning: don't include smp_lock.h when not used · e63340ae
      Randy Dunlap authored
      Remove includes of <linux/smp_lock.h> where it is not used/needed.
      Suggested by Al Viro.
      
      Builds cleanly on x86_64, i386, alpha, ia64, powerpc, sparc,
      sparc64, and arm (all 59 defconfigs).
      Signed-off-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e63340ae
    • Markus Rechberger's avatar
      ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
      Markus Rechberger authored
      Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079
      
      signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit
      
      10000011110110100100111110111101 .. -2,082,844,739
      10000011110110100100111110111101 ..  2,212,122,557 <- this currently gets
      stored on the disk but when converting it to a 64bit signed long value it loses
      its sign and becomes positive.
      
      Cc: Andreas Dilger <adilger@dilger.ca>
      Cc: <linux-ext4@vger.kernel.org>
      
      Andreas says:
      
      This patch is now treating timestamps with the high bit set as negative
      times (before Jan 1, 1970).  This means we lose 1/2 of the possible range
      of timestamps (lopping off 68 years before unix timestamp overflow -
      now only 30 years away :-) to handle the extremely rare case of setting
      timestamps into the distant past.
      
      If we are only interested in fixing the underflow case, we could just
      limit the values to 0 instead of storing negative values.  At worst this
      will skew the timestamp by a few hours for timezones in the far east
      (files would still show Jan 1, 1970 in "ls -l" output).
      
      That said, it seems 32-bit systems (mine at least) allow files to be set
      into the past (01/01/1907 works fine) so it seems this patch is bringing
      the x86_64 behaviour into sync with other kernels.
      
      On the plus side, we have a patch that is ready to add nanosecond timestamps
      to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
      this extends the maximum date to 2242.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4d7bf11d
  9. 02 Apr, 2007 1 commit
    • Andrew Morton's avatar
      [PATCH] revert "retries in ext3_prepare_write() violate ordering requirements" · 1aa9b4b9
      Andrew Morton authored
      Revert e92a4d59.
      
      Dmitry points out
      
      "When we block_prepare_write() failed while ext3_prepare_write() we jump to
       "failure" label and call ext3_prepare_failure() witch search last mapped bh
       and invoke commit_write untill it.  This is wrong!!  because some bh from
       begining to the last mapped bh may be not uptodate.  As a result we commit to
       disk not uptodate page content witch contains garbage from previous usage."
      
      and
      
      "Unexpected file size increasing."
      
         Call trace the same as it was in first issue but result is different.
         For example we have file with i_size is zero.  we want write two blocks ,
         but fs has only one free block.
      
         ->ext3_prepare_write(...from == 0, to == 2048)
           retry:
           ->block_prepare_write() == -ENOSPC# we failed but allocated one block here.
           ->ext3_prepare_failure()
             ->commit_write( from == 0, to == 1024) # after this i_size becomes 1024 :)
           if (ret == -ENOSPC && ext3_should_retry_alloc(inode->i_sb, &retries))
              goto retry;
      
         Finally when all retries will be spended ext3_prepare_failure return
         -ENOSPC, but i_size was increased and later block trimm procedures can't
         help here.
      
      We don't appear to have the horsepower to fix these issues, so let's put
      things back the way they were for now.
      
      Cc: Kirill Korotaev <dev@openvz.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Ken Chen <kenneth.w.chen@intel.com>
      Cc: Andrey Savochkin <saw@sw.ru>
      Cc: <linux-ext4@vger.kernel.org>
      Cc: Dmitriy Monakhov <dmonakhov@openvz.org>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1aa9b4b9
  10. 11 Feb, 2007 1 commit
  11. 07 Dec, 2006 1 commit
  12. 30 Sep, 2006 1 commit
  13. 27 Sep, 2006 4 commits
  14. 16 Sep, 2006 1 commit
    • Suparna Bhattacharya's avatar
      [PATCH] ext3 sequential read regression fix · 20acaa18
      Suparna Bhattacharya authored
      ext3-get-blocks support caused ~20% degrade in Sequential read
      performance (tiobench). Problem is with marking the buffer boundary
      so IO can be submitted right away. Here is the patch to fix it.
      
        2.6.18-rc6:
        -----------
        # ./iotest
        1048576+0 records in
        1048576+0 records out
        4294967296 bytes (4.3 GB) copied, 75.2726 seconds, 57.1 MB/s
      
        real    1m15.285s
        user    0m0.276s
        sys     0m3.884s
      
        2.6.18-rc6 + fix:
        -----------------
        [root@elm3a241 ~]# ./iotest
        1048576+0 records in
        1048576+0 records out
        4294967296 bytes (4.3 GB) copied, 62.9356 seconds, 68.2 MB/s
      
      The boundary block check in ext3_get_blocks_handle needs to be adjusted
      against the count of blocks mapped in this call, now that it can map
      more than one block.
      Signed-off-by: default avatarSuparna Bhattacharya <suparna@in.ibm.com>
      Tested-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      20acaa18
  15. 08 Sep, 2006 1 commit
    • Badari Pulavarty's avatar
      [PATCH] ext3_getblk() should handle HOLE correctly · 3665d0e5
      Badari Pulavarty authored
      It has been reported that ext3_getblk() is not doing the right thing and
      triggering following WARN():
      
      BUG: warning at fs/ext3/inode.c:1016/ext3_getblk()
       <c01c5140> ext3_getblk+0x98/0x2a6  <c03b2806> md_wakeup_thread+0x26/0x2a
       <c01c536d> ext3_bread+0x1f/0x88  <c01cedf9> ext3_quota_read+0x136/0x1ae
       <c018b683> v1_read_dqblk+0x61/0xac  <c0188f32> dquot_acquire+0xf6/0x107
       <c01ceaba> ext3_acquire_dquot+0x46/0x68  <c01897d4> dqget+0x155/0x1e7
       <c018a97b> dquot_transfer+0x3e0/0x3e9  <c016fe52> dput+0x23/0x13e
       <c01c7986> ext3_setattr+0xc3/0x240  <c0120f66> current_fs_time+0x52/0x6a
       <c017320e> notify_change+0x2bd/0x30d  <c0159246> chown_common+0x9c/0xc5
       <c02a222c> strncpy_from_user+0x3b/0x68  <c0167fe6> do_path_lookup+0xdf/0x266
       <c016841b> __user_walk_fd+0x44/0x5a  <c01592b9> sys_chown+0x4a/0x55
       <c015a43c> vfs_write+0xe7/0x13c  <c01695d4> sys_mkdir+0x1f/0x23
       <c0102a97> syscall_call+0x7/0xb
      
      Looking at the code, it looks like it's not handle HOLE correctly.  It ends
      up returning -EIO.  Here is the patch to fix it.
      
      If we really want to be paranoid, we can allow return values 0 (HOLE), 1
      (we asked for one block) and return -EIO for more than 1 block.  But I
      really don't see a reason for doing it - all we need is the block# here.
      (doesn't matter how many blocks are mapped).
      
      ext3_get_blocks_handle() returns number of blocks it mapped.  It returns 0
      in case of HOLE.  ext3_getblk() should handle HOLE properly (currently its
      dumping warning stack and returning -EIO).
      Signed-off-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      3665d0e5
  16. 31 Jul, 2006 2 commits
  17. 28 Jun, 2006 1 commit
  18. 25 Jun, 2006 2 commits
    • Mingming Cao's avatar
      [PATCH] ext3_fsblk_t: the rest of in-kernel filesystem blocks conversion · 43d23f90
      Mingming Cao authored
      Convert the ext3 in-kernel filesystem blocks to ext3_fsblk_t.  Convert the
      rest of all unsigned long type in-kernel filesystem blocks to ext3_fsblk_t,
      and replace the printk format string respondingly.
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      43d23f90
    • Mingming Cao's avatar
      [PATCH] ext3_fsblk_t: filesystem, group blocks and bug fixes · 1c2bf374
      Mingming Cao authored
      Some of the in-kernel ext3 block variable type are treated as signed 4 bytes
      int type, thus limited ext3 filesystem to 8TB (4kblock size based).  While
      trying to fix them, it seems quite confusing in the ext3 code where some
      blocks are filesystem-wide blocks, some are group relative offsets that need
      to be signed value (as -1 has special meaning).  So it seem saner to define
      two types of physical blocks: one is filesystem wide blocks, another is
      group-relative blocks.  The following patches clarify these two types of
      blocks in the ext3 code, and fix the type bugs which limit current 32 bit ext3
      filesystem limit to 8TB.
      
      With this series of patches and the percpu counter data type changes in the mm
      tree, we are able to extend exts filesystem limit to 16TB.
      
      This work is also a pre-request for the recent >32 bit ext3 work, and makes
      the kernel to able to address 48 bit ext3 block a lot easier: Simply redefine
      ext3_fsblk_t from unsigned long to sector_t and redefine the format string for
      ext3 filesystem block corresponding.
      
      Two RFC with a series patches have been posted to ext2-devel list and have
      been reviewed and discussed:
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114722190816690&w=2
      
      http://marc.theaimsgroup.com/?l=ext2-devel&m=114784919525942&w=2
      
      Patches are tested on both 32 bit machine and 64 bit machine, <8TB ext3 and
      >8TB ext3 filesystem(with the latest to be released e2fsprogs-1.39).  Tests
      includes overnight fsx, tiobench, dbench and fsstress.
      
      This patch:
      
      Defines ext3_fsblk_t and ext3_grpblk_t, and the printk format string for
      filesystem wide blocks.
      
      This patch classifies all block group relative blocks, and ext3_fsblk_t blocks
      occurs in the same function where used to be confusing before.  Also include
      kernel bug fixes for filesystem wide in-kernel block variables.  There are
      some fileystem wide blocks are treated as int/unsigned int type in the kernel
      currently, especially in ext3 block allocation and reservation code.  This
      patch fixed those bugs by converting those variables to ext3_fsblk_t(unsigned
      long) type.
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1c2bf374
  19. 03 May, 2006 1 commit
  20. 26 Mar, 2006 6 commits
    • Badari Pulavarty's avatar
      [PATCH] ext3: multi-block get_block() · f91a2ad2
      Badari Pulavarty authored
      Mingming Cao recently added multi-block allocation support for ext3,
      currently used only by DIO.  I added support to map multiple blocks for
      mpage_readpages().  This patch add support for ext3_get_block() to deal
      with multi-block mapping.  Basically it renames ext3_direct_io_get_blocks()
      as ext3_get_block().
      Signed-off-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Cc: Mingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f91a2ad2
    • Andrew Morton's avatar
      [PATCH] ext3: cleanups and WARN_ON() · d6859bfc
      Andrew Morton authored
      - Clean up a few little layout things and comments.
      
      - Add a WARN_ON to a case which I was wondering about.
      
      - Tune up some inlines.
      
      Cc: Mingming Cao <cmm@us.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d6859bfc
    • Badari Pulavarty's avatar
      [PATCH] remove ->get_blocks() support · 1d8fa7a2
      Badari Pulavarty authored
      Now that get_block() can handle mapping multiple disk blocks, no need to have
      ->get_blocks().  This patch removes fs specific ->get_blocks() added for DIO
      and makes it users use get_block() instead.
      Signed-off-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1d8fa7a2
    • Mingming Cao's avatar
      [PATCH] ext3_get_blocks: multiple block allocation · b47b2478
      Mingming Cao authored
      Add support for multiple block allocation in ext3-get-blocks().
      
      Look up the disk block mapping and count the total number of blocks to
      allocate, then pass it to ext3_new_block(), where the real block allocation is
      performed.  Once multiple blocks are allocated, prepare the branch with those
      just allocated blocks info and finally splice the whole branch into the block
      mapping tree.
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b47b2478
    • Mingming Cao's avatar
      [PATCH] ext3_get_blocks: Mapping multiple blocks at a once · 89747d36
      Mingming Cao authored
      Currently ext3_get_block() only maps or allocates one block at a time.  This
      is quite inefficient for sequential IO workload.
      
      I have posted a early implements a simply multiple block map and allocation
      with current ext3.  The basic idea is allocating the 1st block in the existing
      way, and attempting to allocate the next adjacent blocks on a best effort
      basis.  More description about the implementation could be found here:
      http://marc.theaimsgroup.com/?l=ext2-devel&m=112162230003522&w=2
      
      The following the latest version of the patch: break the original patch into 5
      patches, re-worked some logicals, and fixed some bugs.  The break ups are:
      
       [patch 1] Adding map multiple blocks at a time in ext3_get_blocks()
       [patch 2] Extend ext3_get_blocks() to support multiple block allocation
       [patch 3] Implement multiple block allocation in ext3-try-to-allocate
       (called via ext3_new_block()).
       [patch 4] Proper accounting updates in ext3_new_blocks()
       [patch 5] Adjust reservation window size properly (by the given number
       of blocks to allocate) before block allocation to increase the
       possibility of allocating multiple blocks in a single call.
      
      Tests done so far includes fsx,tiobench and dbench.  The following numbers
      collected from Direct IO tests (1G file creation/read) shows the system time
      have been greatly reduced (more than 50% on my 8 cpu system) with the patches.
      
       1G file DIO write:
       	2.6.15		2.6.15+patches
       real    0m31.275s	0m31.161s
       user    0m0.000s	0m0.000s
       sys     0m3.384s	0m0.564s
      
       1G file DIO read:
       	2.6.15		2.6.15+patches
       real    0m30.733s	0m30.624s
       user    0m0.000s	0m0.004s
       sys     0m0.748s	0m0.380s
      
      Some previous test we did on buffered IO with using multiple blocks allocation
      and delayed allocation shows noticeable improvement on throughput and system
      time.
      
      This patch:
      
      Add support of mapping multiple blocks in one call.
      
      This is useful for DIO reads and re-writes (where blocks are already
      allocated), also is in line with Christoph's proposal of using getblocks() in
      mpage_readpage() or mpage_readpages().
      Signed-off-by: default avatarMingming Cao <cmm@us.ibm.com>
      Cc: Badari Pulavarty <pbadari@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      89747d36
    • NeilBrown's avatar
      [PATCH] Make address_space_operations->invalidatepage return void · 2ff28e22
      NeilBrown authored
      The return value of this function is never used, so let's be honest and
      declare it as void.
      
      Some places where invalidatepage returned 0, I have inserted comments
      suggesting a BUG_ON.
      
      [akpm@osdl.org: JBD BUG fix]
      [akpm@osdl.org: rework for git-nfs]
      [akpm@osdl.org: don't go BUG in block_invalidate_page()]
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Acked-by: default avatarDave Kleikamp <shaggy@austin.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2ff28e22
  21. 23 Mar, 2006 2 commits
    • Arjan van de Ven's avatar
      [PATCH] convert ext3's truncate_sem to a mutex · 97461518
      Arjan van de Ven authored
      ext3's truncate_sem is always released in the same function it's taken
      and it otherwise is a mutex as well..
      Signed-off-by: default avatarArjan van de Ven <arjan@infradead.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      97461518
    • Andrew Morton's avatar
      [PATCH] ext3_readdir: use generic readahead · d8733c29
      Andrew Morton authored
      Linus points out that ext3_readdir's readahead only cuts in when
      ext3_readdir() is operating at the very start of the directory.  So for large
      directories we end up performing no readahead at all and we suck.
      
      So take it all out and use the core VM's page_cache_readahead().  This means
      that ext3 directory reads will use all of readahead's dynamic sizing goop.
      
      Note that we're using the directory's filp->f_ra to hold the readahead state,
      but readahead is actually being performed against the underlying blockdev's
      address_space.  Fortunately the readahead code is all set up to handle this.
      
      Tested with printk.  It works.  I was struggling to find a real workload which
      actually cared.
      
      (The patch also exports page_cache_readahead() to GPL modules)
      
      Cc: "Stephen C. Tweedie" <sct@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d8733c29
  22. 11 Mar, 2006 1 commit
  23. 01 Feb, 2006 1 commit
  24. 13 Nov, 2005 1 commit
  25. 30 Oct, 2005 2 commits
  26. 28 Oct, 2005 1 commit
    • Al Viro's avatar
      [PATCH] gfp_t: fs/* · 27496a8c
      Al Viro authored
       - ->releasepage() annotated (s/int/gfp_t), instances updated
       - missing gfp_t in fs/* added
       - fixed misannotation from the original sweep caught by bitwise checks:
         XFS used __nocast both for gfp_t and for flags used by XFS allocator.
         The latter left with unsigned int __nocast; we might want to add a
         different type for those but for now let's leave them alone.  That,
         BTW, is a case when __nocast use had been actively confusing - it had
         been used in the same code for two different and similar types, with
         no way to catch misuses.  Switch of gfp_t to bitwise had caught that
         immediately...
      
      One tricky bit is left alone to be dealt with later - mapping->flags is
      a mix of gfp_t and error indications.  Left alone for now.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      27496a8c