Re: XFS / xfs_repair - problem reading very large sparse files on very large filesystem

[Nikola Ciprich <nikola.ciprich@linuxbox.cz>]

> 
> ok, thanks for the clarification.

no problem... in the meantime, xfs_bmap finished as well,
resulting output has 1.5GB, showing total of 25354643 groups :-O

> 
> Though I've never heard of streaming video writes that weren't sequential ...
> have you actually observed that via strace or whatnot?
those are streams from many cameras, somehow multiplexed by processing software.
The guy I communicate with, whos responsible unfortunately does not know
many details


> 
> What might be happening is that if you are streaming multiple files into a single
> directory at the same time, it competes for the allocator, and they will interleave.
> 
> XFS has an allocator mode called "filestreams" which was designed just for this
> (video ingest).
thanks for the tip, I'll check that!

anyways I'll rather preallocate files fully for now, it takes a lot of time, but
should be the safest way before we know what exactly is wrong.. and I'll also
avoid creating such huge filesystems, as it leads to more trouble.. (like needs of huge
amounts of RAM for fs repair)

> 
> If you set the "S" attribute on the target directory, IIRC it should enable this
> mode.  You can do that with the xfs_io "chattr" command.
> 
> Might be worth a test, or wait for dchinner to chime in on whether this is a
> reasonable suggestion...
OK

BR

nik



> 
> -Eric
> 
> >btw blocked read from file I sent backtrace seems to have started finally (after
> >maybe an hour) and runs 8-20MB/s
> 

-- 
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28.rijna 168, 709 00 Ostrava

tel.:   +420 591 166 214
fax:    +420 596 621 273
mobil:  +420 777 093 799
www.linuxbox.cz

mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------