* Bernd Eckenfels:
> In article <[EMAIL PROTECTED]> you wrote:
>> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
>> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
>> Only the second set of writes are synchronous?
>
> I also am curious if one can open a fil
In article <[EMAIL PROTECTED]> you wrote:
> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
> Only the second set of writes are synchronous?
I also am curious if one can open a file, write to it, close it, op
FiSC can still get those warnings with hdparm -W 0, or with a simple
ramdisk that serves the disk requests whenever they are submitted.
Thanks,
-Junfeng
On Mon, 7 Mar 2005, Alan Cox wrote:
> The IDE layer default is still unfortunately broken and leaves write
> caching enabled. Turn it off with
The IDE layer default is still unfortunately broken and leaves write
caching enabled. Turn it off with hdparm.
-
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
Junfeng Yang <[EMAIL PROTECTED]> wrote:
>
> > >From a quick parse, ext2 seems to be full of MS_SYNCHRONOUS holes, and
> > there might be some O_SYNC ones there as well.
>
> I should be able to easily add O_SYNC check to FiSC. Several questions:
> 1. Does O_SYNC apply to directory as well?
Only i
> >From a quick parse, ext2 seems to be full of MS_SYNCHRONOUS holes, and
> there might be some O_SYNC ones there as well.
I should be able to easily add O_SYNC check to FiSC. Several questions:
1. Does O_SYNC apply to directory as well?
2. For the same file, if I open twice, once with O_SYNC and
Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
>
> On 2005-03-04T01:44:06, Junfeng Yang <[EMAIL PROTECTED]> wrote:
>
> > > That would be a bug. Please send the e2fsck output.
> >
> > Here is the trace
> >
> > 1. file system is made with sbin/mkfs.ext2 -F -b 1024 /dev/hda9 60
> > and mounted wit
On 2005-03-04T01:44:06, Junfeng Yang <[EMAIL PROTECTED]> wrote:
> > That would be a bug. Please send the e2fsck output.
>
> Here is the trace
>
> 1. file system is made with sbin/mkfs.ext2 -F -b 1024 /dev/hda9 60
> and mounted with -o sync,dirsync
>
> 1. operations FiSC did:
>
> creat(/mnt/
> That would be a bug. Please send the e2fsck output.
Here is the trace
1. file system is made with sbin/mkfs.ext2 -F -b 1024 /dev/hda9 60
and mounted with -o sync,dirsync
1. operations FiSC did:
creat(/mnt/sbd0/0001)
write(/mnt/sbd0/0001)
rename(/mnt/sbd0/0001, /mnt/sbd0/0002)
mkdir(/mnt/sb
Junfeng Yang <[EMAIL PROTECTED]> wrote:
>
> On Thu, 3 Mar 2005, Junfeng Yang wrote:
>
> >
> > Hi,
> >
> > FiSC (our file system checker) emits several warnings on ext2, jfs and
> > reiserfs, complaining that diretories or files are lost while FiSC
> > believes they should already be persistent on
On Thu, 3 Mar 2005, Junfeng Yang wrote:
>
> Hi,
>
> FiSC (our file system checker) emits several warnings on ext2, jfs and
> reiserfs, complaining that diretories or files are lost while FiSC
> believes they should already be persistent on disk. (ext3 behaves
> correctly.)
I forget to mention, we
> It may happen that FISC reads the disk before the write command even finished.
> With all the HD head movement optimization in the kernel (block layer,
> boiling down to TCQ/NCQ), this sounds possible.
FiSC "crashes" the kernel immediately after a file system operation
(creat, mkdir, write, etc)
>All warnings boil down to a single cause: when these file systems are
>mounted -o sync or dirsync, dirty blocks are still written out
>asynchronously. It appears to me that these mount options don't have any
>effect on these file systems. Is this the intended behavior?
At least my HDD LED flas
On Thu, Mar 03, 2005 at 10:33:40PM -0800, Junfeng Yang wrote:
>
> Hi,
>
> FiSC (our file system checker) emits several warnings on ext2, jfs and
> reiserfs, complaining that diretories or files are lost while FiSC
> believes they should already be persistent on disk. (ext3 behaves
> correctly.)
>
Hi,
FiSC (our file system checker) emits several warnings on ext2, jfs and
reiserfs, complaining that diretories or files are lost while FiSC
believes they should already be persistent on disk. (ext3 behaves
correctly.)
All warnings boil down to a single cause: when these file systems are
mount
15 matches
Mail list logo
